When is Data Driven Decision Making applicable?

Agile companies usually declare "Data Driven Decision Making" as a fundamental principle, because data forms the basis for empiricism.
The standard Retrospective format lists "Gather data" as one of the key stages. But when is it actually a good idea to start gathering data - and when do we stop gathering data?

To understand why we would even gather data, let us start with the problem. Basically, we want to gather data in order to help define the problem we observe and how we are going to solve it. Gathering data without a problem that needs to be solved is waste.

Here are a few types of problems you might be facing:

We don't (really) have a problem with that

Well, then ... work on something that is a problem. Easy.

We already know the root cause and solution

Well, then ... Go Fix it! Easy.

We know the root cause, but no solution

We need to devise an experiment that may bring us one step closer to the solution. After weeding out alternatives, we definitely need to gather data of some sort to help us decide if this experiment can be successful and - after trying it out - whether it actually helped.

We know the root cause, but it's outside our sphere of control

If you can't control it, but you can influence it, the best strategy may be to "make it the problem of someone who can solve it". Find a problem owner who can actually help.
There is not much value in gathering more data, unless that data is required to win a problem owner.

We know the root cause, but it's outside our sphere of influence

This happens, for example, when the problem is caused by a new law passed by the government. You have two choices here: Either, adapt to the new situation or work around. Gathering data will not help you solve the problem, because no solution you devise will be realistic.
However, you might want to collect data which helps you re-define the problem "given the existing external constraints".

We don't know the root cause, or: We don't understand our problem

This is the obvious use case for "Gather data" - go find the root cause, and learn which data can help you do that.

Summary

Data Driven Decision Making has it's uses. However, it is also limited in use. Gathering the wrong or unnecessary data is waste and should be avoided. Which data is "wrong or unnecessary" depends on the problem you are facing.
Therefore, a clear understanding of your problem is essential before actually spending time with data acquisition.

Know your customer!

The Agile Manifesto states "Customer Collaboration over Contract Negotiation". But that's not easy to practice without understanding who the customer actually is.
As organizations grow, the question "Who is the customer?" becomes increasingly difficult to answer, and the answer is often hidden in plain sight. 
In this article, we will discuss how to identify and classify customers, using the practical example of an e-Commerce Platform.

Product Customers

The most obvious category of customers are those who actually use the product. However, even they come in two categories: Those who actively go out to use the product - and those who get to use what others got for them.

Primary Customers

This is the kind of customer you can actively reach out towards. When they like the product, they will be generating revenue for you. It's a good idea to build a direct feedback cycle with them.
These could be web users who like to do online shopping.

Secondary Customers

This is the kind of customer you may not even know to exist. Whether they like the product or not is out of reach. If anything, they would give feedback to the Primary Customers - but you don't have much control over that.
These could be the workers in a company who has decided to get their supplies from our online shop.

Value Stream Customers

How does the value stream "Order to cash" map for your company? Typically, it's not the same people who have an idea, deliver it - and have to live with the consequences. In big companies, ideas are collected, then brought into a type of solution design, then implemented, launched - and then become "business as usual".
Depending on how your organization looks like, that will usually involve different departments, teams and people. Each person involved in product creation has a place in the value stream, and to know "who will receive the result of my work" is a good idea. These people are the value stream customers.
Yes, they are also customers! Life can be quite miserable if you ignore this fact.

(Other) Internal Customers

Sometimes also called "Stakeholder", but let's be explicit here. These are people in the company who actually want something from the product and who will usually assign a portion of (their) company budget towards the realization of a request.
For example, that could be Marketing or Sales desiring access to business performance metrics - or Customer Service asking for a functionality reducing the amount of service calls.
These people usually do not actively use the product, but they do have an important impact on how it is being used.
Since they are in the "large" revenue chain of the Product and receive services from Software Development, they are clearly also customers and it's a good idea to keep them happy for mutual benefit. One thing you should never forget: They do not actively create value for the product, they merely assist in value creation. No matter how many features you build for Marketing, there is no benefit unless you actually see an increase in Product Customers!

Indirect Customers

Living in a society, there is a whole bunch of people who neither want your product, buy your product - or even care about your product, but still place demands on your product.
For example, that could be the Better Business Bureau, the legislature around Data Security - or even the IRS. There is no way to "Please" these customers, but they will kill you if you don't fulfil their requests. The best thing to do is invest minimal effort to keep them off your back.

Summary

In large organizations, the relationships between supplier (you) and customer are often either unknown or agreed in contractual form. If they are unknown, there is a huge risk of misfiring. Hand-Over Contracts (responsibility lists) are good to create transparency, but do not help to solve problems or grow the business. To be successful, you have to go beyond the contractual level with your customer - and collaborate with them for mutual benefit.
The simplest Customer relationship every Scrum team should be aware of is that with the PO. The interface contracts are Definition of Ready (PO => Team) and Definition of Done (Team => PO). There are more customers - how do you handle your relationship with them?

"Bug Team" for Legacy Systems

Legacy systems often have an equally large "defect backlog" - a list of well-known, relevant issues that need to be resolved at some point. The work of digging in old dirt is not fun. No developer enjoys doing this. Consequently, these defects tend to linger. But they do impede customer value, develpoment speed and sustainability. So - what to do?
A common solution is: "Let's make a bugfixing team."

Organizational role of the bugfixing team

The bugfixing team may have directly or indirectly measurable targets, typically a reduction.Targetted metrics may include, for instance, defect count, defect cycle time, technical debt, customer complaints, waste incurred by sighting [customer] problems, unplanned system outages, release delay etc.
Their value lies in the reduction of ongoing loss. At the same time, theyprevent of further loss.

From a technical perspective, the bugfixing team is a development team like any other. They work with backlog items and bring them towards meeting a Definition of Done. To achieve this, they elaborate Acceptance Criteria, work on the source code, verify solutions, produce and deploy builds.

Why a bugfixing team is good

The elephant in the room finally disappears: Something is happening.
The introduction of a bugfixing team is a clear signal from management that Quality is being taken serious.
A dedicated bugfixing team has much better levers than regular development teams of not only "fixing the symptom", but digging all the way down to the root cause.
At best, the bugfixing teams gain intricate knowledge about what makes the system click and tick - where the risks, threats and opportunities are. This knowledge is very valuable not only in solving bugs, but in sustaining the current (legacy) platform and potentially in the introduction of a new platform in the future.

A bugfixing team has no choice other than working as a "feature team", because bugs are hardly limited to individual components - although they typically cluster. In this way, bugfixing teams are a way of successfully introducing the idea of feature teams in an organization.

Why a bugfixing team is bad

The bugfixing team may create an impression within the organization that "regular development teams" are absolved from delivering quality. 

Management and Scrum Masters/coaches must clearly communicate and emphasize at every opportunity that the bugfix team is dealing with existing impediments, but is not an excuse to shove "undone work" onto Production: There is no excuse for introducing "new bugs".

Developers on dedicated bugfixing team easily get frustrated: While other developers get to create fancy new stuff, they merely fix things which should have been working a long time ago already. Innovation potential on a bugfixing team is much lower.

Long term perspective

A bugfixing team should strive to "run out of work" as quickly as possible. The best state is reached when there are no important legacy bugs left to fix. The knowledge a bugfix team has obtained will be very valuable for the organization. After working in bugfixing for about half a year, developers possess a deep, intricate understanding of the system which other developers may not possess. 

This knowledge is very valuable to the organization: The bugfix team should be encouraged and motivated by the idea that the role is temporary and the entrance towards "something greater".

Summary

A bugfix team is not necessary in every organization. Management should state quickly that the main idea is getting out of the quagmire of Poor Quality and the institution is temporary. Developers must understand their responsibility is not "working off defects", but closing the manholes in the system, so they can move on as a team.

The Product Owner in charge of the bugfixing team should prefer "defect areas" over small-scoped, local problems, although these provide quick-wins.
The Scrum Master working with the bugfixing team must harp constantly on the "Continuous Improvment" of the system, the team and the organization. Only by focussing on Continuous Improvement will the team overcome the unsatisfactory treadmill of fixing an endless flow of reported defects.

A potential solution to prevent developers from feeling stuck in "bugfix mode" is to rotate the "bugfixing team" in the organization every few months.

Management and PO must keenly observe when the point is reached where the loss associated with existing defects turns the team into a negative business case. At that point, the team should stop being a "bugfixing team" and take on more valuable feature development activity.

Conclusion

If there is a clear business case for introducing a bugfixing team - by all means: at least consider the option. When moving forward - keep focused and provide perspective to bugfixing developers.

MoSCoW - yes or no?

I was recently confronted with the question: "What is wrong with MoSCoW prioritization method?" - as a rhetorical question. The answer: "It is based on wishful thinking, the idea that when we turn something into 'Must', we somehow will have it." - effectively suggesting not to use MoSCoW. Let me take a different stand here.

As a Product Owner, I am forced to make tough calls. And I admit that I use MoSCoW as a tool.

The criticism of MoSCoW

It is correct to state that "just because someone claims something must be done, it does not mean that it will be done.". Just because my customer says we must deliver that new teleporter by the end of the month, doesn't mean he will get it.
Likewise, simply defining all work as "mandatory" doesn't mean that more will be delivered.
To suggest that people from business don't understand this is merely beating up a strawman.

Maybe they are unaware of the consequence of their action when defining a "must", and the organization is in such a mess that people don't understand the complex intricacies of what "defining as must" means.

Not a prioritization tool

MoSCoW can be very easily misused when used with the wrong question, such as "Is this a 'Must' requirement?". But that's actually just a stupid question, because everyone knows the answer will be "Yes", regardless of how important something really is. 

By using MoSCoW as prioritization tool, you will end up with a backlog consisting pretty much of 100% "Must do" stuff. Next thing you know is that everyone is blaming the team and/or PO for not doing stuff that "must be done". This approach completely destroys trust. 

Take a closer look at the four terms: They are not priorities, they are categories.  

Then, learn to ask the right question:

MoSCoW as a filter

By asking the requester/stakeholder: "What happens if we don't do it?" - the answer pretty much falls into one of the following categories: 

a) We are all dead. ("must do")

b) We will suffer a lot. ("should do")

c) Someone's uncomfortable. ("could do")

d) It doesn't matter. ("won't do")

Like this, MoSCoW can be used as a very easy, quick, reliable and comprehensible way to brush off stakeholder requests that are definitely not going to be delivered: In practice, that's everything from "C" and "W". 

Not a delivery requirement

The first thing to realize is that "Must/should" is not a priority. It also does not mean "We must/should deliver this". It should be understood as: "At this time, we understand that this must/should be added into the backlog." In due order. Weighted against all of the other stuff that is already there. The backlog only consists of "Must" or "Should" items. So, these terms are effectively worthless fill words in the context of a Product Backlog.

Just like all Java programmers know Java, the term "Java" means absolutely nothing to a group of "Java programmers" - so the words "must" or "should" means nothing in a group consisting solely of " 'must or should' items".

Backlog content

"Must", in this context, does not refer to a specific date or scope of delivery. 

It refers to being appropriate for addition to the Product Backlog.

If the PBL is too big already, the PO can suggest: "If this must go into the backlog, you need to take out one thing, because I'm not going to juggle more chainsaws than we can sensibly handle."
Like that, stakeholders can be forced to make tough decisions.

The terms "must/should" are not absolute. They becomes context-sensitive. For example, "Must do" might turn into "Must do instead of [doing something else]" or: "Must do before [doing certain other things]".

You can use a very simple sentence to explain why some "Must" item just got kicked out of the backlog; "When this issue was brought up, we decided we must add this item to the backlog. Given this new information, we decided that now we won't do any work on it."

This is a highly powerful mechanism for limiting both Scope and Work in Progress.

Used appropriately, it's a real-time adaption mechanism for keeping the Product Strategy both focused and flexible.

Summary

MoSCoW is actually a principle and not a tool: We always separate work into stuff we do - and stuff we don't do - and we always call it a day at some point. Assigning a category to "not done work" only makes this explicit. The labelling process is just turning the principle behind separation of concerns into a tool.
Like every other tool, it can be abused when understood as a tool. When used to define inclusion, you will encounter a myriad of problems.  But that doesn't mean we should throw the baby out with the bath wather.

Use MoSCoW to define exclusion. It keeps the backlog short and creates transparency on why certain things are in focus - and others are not.

Continuous Integration Flow

Continuous Integration is essential in reaching high-paced, sustainable software development.
Some people think "We have CI" means "We use Jenkins". Well, that's a good start - but it's nowhere near enough. Here is a small infographics to illustrate what CI actually means:

Key activities in CI

Of course, if you start to do everything at once, you will get nowhere.

If you are just taking your first steps with CI, obviously you want to start at stage 1: Checking out the source code repository and producing a build.
Once you got that, you want to be able to put that build somewhere - preferrably, you start with putting it on the Acceptance Test Stage.
Next, you start firing test suites. A unit test suite should exist, others probably still need to be created.

Just work on those items which cause the most pain first and work from there.


Maybe the journey will take you to Continuous Delivery or even Continuous Deployment? Attempting to go there without a good CI is actually suicide.
So, get your CI straight first.

What makes a good test?

In agile development, the team is responsible not only for development, but also for testing. However, many developers are challenged with the notion that not just any test is a good test.
Here is a fairly comprehensive list of criteria which good tests meet:

1. Valid: It measures what it is supposed to measure. It tests what it ought to test.
2. Clear: Test instruction and test objective should be clear.
3. Comprehensible: The language of the test should be comprehensible to the reader.
4. Relevant: It appropriately and accurately covers a significant portion of the Object Under Test. 
5. Focused: It should do one, and only one thing (“Single Purpose Principle”).
6. Detailed: Failure conditions should be sufficiently specific to discover the source of the defect. 
7. Practical: It is easy to conduct and requires a low amount of preparation.
8. Fast: It should take only an insignificant amount of time.
9. Efficient: It only consumes a reasonable amount of resources.
10. Unique: For one specific attribute of the software, there is only one test.
11. Repeatable: If it is repeated, the result will not differ.
12. Reproducible: It should yield the same result, regardless of where it is executed.
13. Independent: It should not rely on the results of other tests.
14. Economical: It should require lower creation and maintenance efforts than the value of the test (risk covered)

Violation of these criteria may (or may not) be a problem. However, they provide a good guideline when designing tests. regardless of whether these are acceptance, system or component (unit) tests.

Working with the list

When your test process has problems, check a sample of your tests against this list and try to discover hotspots for improvement.

When creating your first couple tests, you should pick some criteria from the list which seem to be the most difficult to achieve. Then design your tests to actually meet these criteria.

Project Managers and Agility

The statement "Now we're agile, we don't need Project Managers any more" - causes fear in those who used to have a PM role and leads organizations to a very difficult question: "What do we do with our Project Managers?" - sometimes, they hastily conclude "Get rid of them". Let us discuss why this conclusion might be too hasty.

The Ugly

Let us examine first what is wrong with Project Management. For brevity sake, we will only list a few points:

• Gantt Charts presume an organization form that doesn't work in practice
• Role Separation which presumably increases productivity when all it does is add waste
• Perverse incentives, such as rewarding testers for finding defects rather than stopping the root cause
• Watermelon Reporting,  e.g. "we know we're Red, but report Green because that's what management expects" 

In short, Project Managers spend a lot of time setting up a highly wasteful structure and then deceive themselves and the organization that they're doing the right thing.

The Bad

Again, for brevity sake, let us examine briefly what causes the underlying problems in Project Management:

• The Plan: A project Manager gets paid to make and follow a plan. However, there is always some stuff you can't plan: The elements subject to exploration and/or unpredictable change. 
• Complexity: People who fail to make the perfect plan aren't imbeciles, because the world is too complex, with a notion of unpredictability sprinkled in: Planning is good, flexibility is better.
• Detail: Project Manager must work on a certain level of abstraction. Unfortunately, "the devil is in the detail" - i.e. the tricky part can often only be decided by people who are lower in the hierarchy: Only by delegating critical decision authority into the team can a PM succeed.

In short, the world around the Project Manager requires them to do an impossible feat. Only by putting slack ("big gray areas") into the plan and permitting the team to do what they actually should not - i.e. deviating from the plan and breaking the chain of Command - can a project be successful.
As such, the PM role is inherently broken.

The Good

Project Managers do actually bring some skills to the table that are always needed to be successful in an organization. These are:

• - Organizing: Discipline and doing the right thing at the right time are important for success. Nobody has as much experience in organizaing stuff as the PM. Agile teams find a good organizer very helpful - as long as they don't organize things nobody asked for!
• - Breaking down work: Both backlog refinement and Sprint Planning are work breakdown activities - one on a strategic, the other on a tactical level. Poor work breakdown will result in missed goals and frustrated teams and customers. The only question remaining: How do you do it appropriately?
• - Creating transparency: Status reports are only one way to create transparency. However, the PM is used to creating an appropriate level of transparency. Once they rise beyond the non-valuable metrics, the PM will be very useful to help the team be better understood in the organization.

In short, a PM is very useful for getting the right things done rightly - and helping the team get the necessary credibility in the organization to succeed.

Summary

Whether the organization needs a PM or not - is not a question based on the role of the PM. The PM's skills are needed, while the activity a PM did do in the past are not. A PM may add value to the organization in the roles of Product Owner, Scrum Master / Agile coach or team member. However, the PM must unlearn certain prejudices, notices and abandon practices to rise into their new role. Likewise, they must learn agile practices and adopt a new mindset. A PM who is ready to leave their former title and old behaviours behind will be very valuable to an agile organizations.

Reaching Sprint Commitment

The Scrum Primer discusses "Sprint Commitments" as an outcome of the Sprint Planning. This Sprint Commitment means that "the team commits to doing the best they can to reach their target". Often, this is implemented as part of a ceremonious event. The PO asks: "Team, will you commit to this?" - "Yes" - "Go". This, however, is a "Commitment Cargo Cult": It's not how you reach Commitment.

What Commitment is

Based on the "Chicken and Pig" Metaphor, Commitment is an exclusive dedication to a specific purpose.
In Scrum, it is actually desirable that a team exclusively focuses on the specified Sprint Goal. As such, gaining the team's commitment is highly desirable.
However, "exclusive dedication" has a bigger scope than stating to dedicate a couple weeks to a specific topic. Commitment is also a state of mind.

Let us take the example of an Ice Cream Seller at the corner. Maybe he really loves selling ice cream, he enjoys making fancy ice cream cones with perfectly round scoops and some decoration on top. This seller is 100% committed to selling ice cream. His actions are ruled by his love for ice cream.

Now, let's look at the other seller across the street. She is a hired hand, with small children. She, too, sells ice cream as a full time job - but she is actually committed to taking care of her family. Her actions, including the very fact that she is selling ice cream, are ruled by her love for her family.

Both will dedicate 8 hours a day to producing ice cream, and both will strive to sell as much ice cream as possible. But their motive is different. The first seller will continuously think of ways to produce even better ice cream - not because he wants to earn more money, but because he likes to do that. The second seller will spend as little time as possible with ice cream, even during work she will use any free minute to think of their family. She will only think about ice cream sales when the sales are going down (because that affects her directly), but she will not think about new ways of serving ice cream proactively.

We can see very clearly that "commitment" is not really about asking someone to do a certain piece of work, but much deeper.
Developers obviously also have a family life and they have all the right to have this. Let us ignore how much % of their time they spend with work and how much without - but when they work, they should be committed to developing a great product - and not to spend their time doing as much work as possible.

Gaining Commitment

As a Product Owner, you need the team's commitment to plan the next steps.
However, do not ask for a statement of commitment. People might "give commitment" just to get out of a long, boring meeting. They also might "give commitment" because they don't even understand what the problems will be.

You should ask the opposite questions: "What will stop us from reaching this?" - or, "Is there anything that makes you uncomfortable with this goal?"

When developers come up with their own plan for the sprint and do not see road blocks, you can count on their commitment.

Plan Commitment

As a Scrum Team, your responsibility is commitment to a Sprint. 

In Agile Software Development, we never commit to a plan. This is based on the 4th Value of the Agile Manifesto, "Valuing Responding to Change over Following a Plan." What this means: By all means, make a plan, but commit to the goal - not to the plan! Accept that even during the sprint, we may discover information which invalidates the plan.
As team members, when discussing the Sprint Plan, you should not be asking the question, "Can we do all of this?". Much rather, you should ask: "Does it make sense to do this?" - and: "Can I work with this?"

Commitment Culture

As a Scrum Master, your responsibility is that the team is committed.
Your approach to creating commitment should never be focused on method or applying pressure.
Here is a three-stage approach to gaining commitment.

In the first stage, you take the backseat. Do not ask the team to commit - and do not ask the Product Owner to ask for commitment. Observe if the team is actually committed.
During planning, there are a few very good indicators on team commitment. For example, team members who fiddle on their smart phone rather than asking questions are probably not committed.

In the second stage, you move into the passenger seat. After you have a good idea on who is not committed, you must find out the reasons. Taking personal reasons out of the equation, you usually have either organizational or product related issues which impede commitment. Aside from observing closer, you may want to seek the dialogue with people are not committed. Careful - you do not want to suggest they are performing inadequately. You want to find out what could be changed in the organization so that they can commit better.

In the third stage, you must move into the driver seat. Understanding the root causes of lacking commitment, you create transparency around the issue and involve those who can actually do something about it. This may be the Product Owner who is asking the wrong questions to the team - it could be managers giving perverse incentives to developers or just those in charge of existing bullshit processes - or many other things.
Your goal is to change the organization so that developers can commit.

Then, you go back to Stage One - and observe if the situation has improved.

Summary

Sprint Commitment is not a statement during Planning. It is a mindset within the team - and to achieve this mindset, you must have a culture that allows developers to truly commit.
This culture requires a clear goal to orient on (Purpose), developers owning the solution by themselves (Autonomy) - and having what it takes to actually do something meaningful with this goal (Mastery).

You will never gain proper "Sprint Commitment" without this basis.

The "Mini Team" Approach to introduce Enterprise Agility

When an organization has decided to "go agile", there is often the question: "How do we do this best?" - unfortunately, since the organization does not yet have agile experience, this is a problem of working in the realm of the "unknown Unknown", i.e. we don't know what we don't know about what we need to know in order to be successful. Since the empirical approach includes learning, this is not problematic if approached properly. 

In this article, I will summarize quickly how we typically approach the first steps with organizational agility in huge, Waterfall-oriented companies. I have dubbed this approach "Mini Team", because it is intended to be minimally complex for maximum effect. The reason for calling this "Mini Team" is because of the huge amount of "Minimums" in setup.

1 - Find a Challenge

The best way to introduce agile ways of working is by actually working on something that is both urgent and important. In the best case, this would be some kind of major crisis or incredible opportunity. The reason why we would want to start with a Challenge is to get everybody's attention that this is important. This concerns workers and management alike.

 2 - Get the right people together as a team

A challenge is usually not mastered by managers, but by people actually doing some work. Consider the following questions: "What are we really trying to do?" - and "What do we need to get that done?". Put together a minimal amount of people who are capable of mastering this challenge. Get the minimal amount of domain experts spanning the biggest possible scope of expertise in regards to the challenge, ideally between 4 and 6.

Do not give these people a manager or team leader, let them self-organize.

We call this "Working with minimum viable skillset".

3 - Free Pass on Processes

The Challenge is set up to imply that "this can't be done with our current organization". As such, the existing processes will most likely be inadequate to master the challenge. We would claim "We don't know what the right process looks like". Therefore, we permit the team to simply ignore existing company processes whenever they do not seem helpful - and take whatever shortcut is helpful to master the challenge.
Do not let them design processes upfront for getting their work done, much rather let the process evolve.
We call this "Working with minimal process."

4 - Apply Scrum principles

Working agile implies being flexible, but some basic Scrum principles should be adhered to: Work iteratively, set goals and plan what you want to do next, collaborate on achieving your goal, reflecting on your progress - and reserving time to think about whether you're still doing the right thing right.
We call this "Working with minimal deviation."

5 - Define a meaningful goal

The Mini Team will not be able to "solve World Hunger" problems, but they can make a significant contribution in a very short timespan. Therefore, the team should not be bogged with a long-term vision or objective, but much rather focus on producing something tangible in a minimum timespan. Since the objective of Mini Teams is both resolving a challenge and getting familiar with an empirical approach to work, a period of no more than 3 months is good. Set a "SMART" goal.

Do not give the team a significant amount of time, like a year or more. Challenge them!

While the goal may or may not be a software or physical product, their target is a "Minimum Viable Product (MVP)."

6 - Discover the solution

Traditional companies often struggle with the notion of not planning the entire journey before taking the first step. However, in the case of our challenge - nobody in the company knows how it can be resolved (otherwise, it would be routine work and no challenge). A specific result may be desired, but nobody knows what the outcome will actually be. Similar to planning a field trip - it's kind of difficult when you know neither where your destination is, nor how to get there. 

Christopher Columbus in the discovery of the New World knew pretty much how long he had to sustain his crew, but not what the journey would bring. The best thing he could do was start to "Sail West". Every once in a while, he observed the Sun and steered back on course. This is what a Mini Team does - decide roughly who will be on the journed to the defined goal for how long, but there is no way to plan the trip. It's an adventure - a journey of discovery!

Abolish long term plans, most of all, resource allocation - since you don't know if it will help.

Instead, plan for short iterations (I suggest: weekly) and check how you must adjust your course.

We call this "Working with minimal upfront design".

7 - Effective Learning

To be successful in the endeavour, it is essential that the team make their own decisions and learns from feedback quickly. Since time is strictly constrained, a seasoned coach/Scrum Master is vital to guide discovery and learning in this learning period. This concerns both within the Mini Team and within the organization. There is no problem with doing something wrong, because nobody in the organization would have known how to do it better.
Accept failure, as long as something new has been learned and action is being taken.
We call this "Minimal feedback cycles".

Summary

A "Mini Team" minimizes organizational and technical constraints in order to deliver a feasible solution to a new challenge. With this, the Mini Team becomes the forerunner to change - where teams answer to challenges every day. The Mini Team can bring traction to agilize an organization - if the challenge was sufficiently significant to be convincing.
The experiences gained in the Mini Team will guide the change efforts of the organization. Therefore, the best way to proceed after the Challenge has been met is by "seeding" the members of the Mini Team into different teams and adopt the same things mentioned in this article there. Take advantage of a "ripple effect" and iteratively set up such "Mini Teams" in your organization to transform an entire organization to agility.

Key benefits of this approach are: 

1. The most significant challenges in the organization get resolved quickly.
   The organization makes progress!
2. Within 4 iterations, you could roll out the new way of working to over 1000 people.
   This is a rapid adoption strategy!
3. During the entire transformation period, you focus on maximizing ROI.
   The adoption itself may already be a positive business case!

Dealing with Meeting Madness

Meetings run rampant in many organizations. In extreme cases, people hardly have time for focused work because they rush from meeting to meeting. What to do?

Working a lot in the Telco industry, I often jest: "What is the primary characteristic of Telecommunication? - That face to face communication does not work."

This is no offense to Telco and definitely not limited to the Telco industry, but actually a characteristic of many organizations, and IT as a means for communication makes this problem even more profound: It's so easy to schedule a meeting that people put up meetings without even considering whether a meeting makes sense.

Symptom

We often observe people's schedules crammed with meetings. Working as Project Manager for one specific organization, I complained to the CTO that I had thirty six (36) hours of scheduled meetings in my calendar - recurring daily and/or weekly stuff. The reason for the complaint was this: "How do you expect me to give you a meaningful status report when the only thing I'm doing is running from one meeting to the next without actually looking what the teams are doing?"
Long story short: The CTO gave me a blank check to not attend any meeting I didn't consider valuable. Two days later, I was down to 10 hours of scheduled meetings per week and actually started spending time with my teams.

Cause

One cause of Meeting Madness is that ceremonies are not used effectively: When daily standups move from collaboration to reporting, further synchronization meetings become necessary. When plannings are improperly prepared (Refinement/Grooming was not done well) - then multiple planning and clarification meetings become necessary. And so on.
The consequence is that meetings start filling the schedule to the point where people meet, and do not communicate.

Root Cause

In dysfunctional organizations, people focus on two things: Themselves - and their work. Both must look good. Regardless of whether this is the result of perverse incentives provided by management or inherent company culture - it does not help anyone.

People in your organization who care more for "looking good" than for helping out the company in times of need? You've got a staffing problem. 

People feel the need to vindicate themselves rather than solving the issue at hand? You've got a mindset problem!

The Agile way

The most important aspect in communication is considering which information should be conveyed and how that is being received. A general rule is cutting down on complexity as much as possible. Use information radiators to remove the need for "obvious" discussions. Only engage into detailed discussion when they point at something unusual. Do not call meetings whenever you feel they could help: use formal meetings as a last resort. Exhaust small face-to-face discussions, such as during Pair Programming or over a cup of coffee - as preferred methods of communication.

Put every recurring meeting that does not correspond to a Scrum ceremony under scrutiny.

The Scrum way

In Scrum, we should be spending less than 15% of our time in the so-called ceremonies. Scrum does not intend for any other scheduled meetings on top, because the ceremonies should provide enough transparency that no additional planning, reporting, status or coordination meetings are necessary on top. In theory. Many organizations are not there.

Summary

Resolving the meeting madness issue is best done by continuous, scrutinous examination of all the meetings going on in your organization.
Establish a culture where people are welcome to leave ineffective meetings - and at the same time, have the freedom to communicate in whatever way is effective for them.

Try applying Open Space principles to your meetings: 

1 - Don't demand people to come
2 - Don't demand them to stay
3 - Don't demand to fill the entire time
4 - Don't demand to stick to the agenda,

See what happens. The meetings where nobody shows up, stays or talks are probably not important. The meetings where people leave the agenda should make you think.

Is you Kanban board healthy?

Have you ever stood in front of a Kanban board and wondered whether the team is actually doing fine?

Here we will discuss a few key concerns that will easily help you discern whether your Kanban board has problems:

What do you see on your Kanban board?

Broken Priority

When picking up a new piece of work, you should choose the top item on the board which is not yet completed. Sometimes people pick the item they prefer doing - ending up with lower priority items getting done first. The good news is that this becomes visible immediately.
If this happens frequently - or your Kanban board looks more like a dotted map than a flow system, you should seriously raise the question "Why do people not work on the highest priority?"

Unfinished Pile

The objective of Kanban is to get as many things into "Done" as fast as possible, where "Done" means "Delivered to the customer". Unfortunately, a wrong definition of "Customer" (e.g. "The next person down the line") invites team members to simply hand over an unfinished item, and work on yet another unfinished item.
When team members do not pick the rightmost "not done" item on the board, but rather any other, this should lead to the question "What prevents us from getting those things done quickly?"

Broken WIP Limits

Specialists often fall into a habit of simply working off their portion of a backlog item, completely disregarding what happens around them. This may cause an "Inventory" problem: The next step down the line may be clogged, with more and more undone work piling up.
Kanban suggests setting WIP limits on queues and stopping the production of ever more inventory before something new gets started.
Observing WIP limits makes it very easy to recognize when this point is reached. Sometimes, teams ignore this and individual columns on the Kanban start cluttering up. In this case, you should raise the question: "How can we avoid clogging this queue?"

Bottlenecks

Another problem of specialists is that they may be a limited resource in completing a specific step in the delivery workflow. If this is the case, we often observe that this step becomes a bottleneck: Some teams permit a huge WIP limit "because it's normal that a lot of stuff is there". Even worse, some abolish the WIP limit for such a step "because we always break it". A bottleneck should never be taken as irresolvable impediment.
When a bottleneck is observed, the team should be even stricter on setting a very low WIP limit. As this WIP limit is broken, this should trigger the question: "Can we re-organize work so that the bottleneck is resolved?"

Queue Mania

Some teams go crazy on Kanban boards - specifically, on electronic boards. It is very convenient to add a column whenever needed, because people feel it helps them organize their work better. Unfortunately, this fails to consider one underlying problem: Each column represents a queue, and each queue is actually a representation of a handover in the process. Handovers cause delay and are considered wasteful in Lean.
When you observe more columns on your Kanban board than you have fingers on one hand, you should ask: "How can we de-fragment our workflow?"

Summary

Starting Kanban is easy, customizing it is also easy. A Kanban board only visualizes what you are doing. To get real benefit out of Kanban, the layout of the board should continuously be put under scrutiny.
When the board looks unhealthy, the team should "stop and fix", using a Retrospective and define measures for Continuous Improvement. Only then will you get real value from doing Kanban.

To estimate or not to estimate - #noestimates by slicing

At the risk of stating something that is already obvious - "#noestimates" does not mean "We don't have any idea what we're building or how much it costs". It means we have simplified the process to a point where risk and reward are in a sound correlation.
There are many ways to reach a state where estimates are no longer relevant. Here, we will discuss Backlog Slicing and its effect on estimation.

One way to remove the need for estimation is to slice deliverables into packages no bigger than 1 single day: At worst, you have lost 1 day and learned that in 1 day.

When you can do this slicing for any given backlog item within a couple minutes, it becomes completely irrelevant whether the slice is actually 1 minute or 8 hours, since the Law of Big Numbers starts to kick in at some point and it becomes fair to say that a deliverable is about 4 hours.

So, even with #noestimates we actually do have an estimate, but we don't bother going through all of the items individually, attaching a "4 hour, could be more or less" label to each and every one of them.

With this information, we can also predict cost and duration:
How many slices do we get out of a "requirement"? 1, 20, 1000? How many of them are really needed?

 Then we optimize: Can we deliver the bulk of the value by doing only a couple of them?

 Lastly, we can quickly observe and act: Do we consistently deliver an about even amount of slices per week? Does the number increase or decrease? Are there any significant outliers that clog the pipeline?
By observing the answer to this question, we imply data without actually measuring it:
As long as the consistent flow of delivery is there and there are no outliers, there is no problem.
On the other hand, when we seem clogged or bogged down, we realize this immediately, because we're not delivering any more.

 This becomes visible and can be fixed within a couple of days, so we can go without a company-wide measuring system that may tell us the obvious by the time the team is already working on a solution - or even worse, waste precious development time by holding the team accountable to solve a problem that we can't influence.


 Summary
#noEstimates is not equal to abolishing good business practice due to negligence or inability.
 Much rather, #noEstimates is a sensible step of evolution for developers who have mastered their technical domain, whose Product Owner is crystal clear on business value and priorities - and for  people with a very rigorous and keen Continuous Improvement mindset.

 A team avoiding Estimates without these three aspects in place may act haphazard.

So, #noEstimates is effectively "Implicit Estimates without explicit estimation overhead".

Quantify problems before solving them

I was recently asked: "How many automated tests, do you think, we need?". An underlying premise was that I would provide an expert opinion on whether the team had the right amount of tests.
I could only reply: "I don't know. If you have a problem with quality, you might need more. If you have a problem with the maintenance of your tests, maybe you need fewer. However, if there is no problem, you're probably doing the right thing."

This one can be abstracted, away from the specific issue of test automation.

If there is no problem, there is nothing to fix. But how do you know if you have a problem then?

Here is a simple suggestion:  Collect data. Then, decide based on facts.

This is an example of how you can track:
Each time your team encounters an issue and spends time with or because of it, make a mark. Your result might then look like this, depending on which activities you are tracking and how you track:

In your retrospectives, you can simply look at the numbers and ask the following questions:

• Does this make sense?
• If not: What should we do about this?
• Will we gain more insight if we get more data in the next iteration?

Summary

"Data Driven Decision Making" is not rocket science. Collecting data can be simple and easy - and require very little preparation or technology. While you may want to refine your collection process depending on your understanding of the problem, the simplest possible solution will often suffice to rule out wasting time on dealing with corner cases or imaginary issues.

Stakeholder Management 101

In large enterprises, Product Owners often get bombarded with stakeholder requests of all sorts, which they all need to manage. Soon, the poor PO will find themselves juggling requirements rather than advancing the product in the best interest of the companies. Because all of these requirements are important to the person raising them, the PO will quickly become the victim not only of enormous pressure, but also of constant nagging "Why isn't this done yet?"

Here is a simplified request appraisal process for Product Owners to stay ahead of the game:

Evolving Kanban Boards

Regardless of whether your board is electronic or physical, boards have a huge advantage of making workflows visible and making problems transparent without much overhead.

Here is a real world example of a electronic Kanban board. Let us discuss what this board actually means. As a disclaimer: This is not intended to be a pattern of "how your Kanban board should look like", but "how you could work on your Kanban board". Feel free ignore the detailed contents, because they are irrelevant to our cause in this article.

First thing you may notice: the board is a bit more complex than our usual "toDo, In Progress, Done" board.
This board has evolved over time and it is owned by the team. As such, it does not reflect "how the team should be working", but "how the team is actually working".

A little background

This board belongs to a cross-functional feature team, applying a rigorous Test-First Zero-Defects approach which mandates "no code change without test coverage" and "no deployment with known defects".
Consequently, there is no "In Test" or "Fix" column: Devising the right tests (e.g., "analysis") is as much part of software development as fixing any potentially discovered defects.
When the team moves a backlog item into "Done", it is unconditionally ready to go live.

An evolution journey

As the team discovered that the original 3 columns "ToDo, In Progress, Done" do not provide a sufficient level of transparency to understand at a glance what is actually going on and how they could collaborate, additional columns came in.

The first column that came in was the "to Review" column.
With this, a developer indicated that "My code is ready - from my perspective. I need a code review". Along with the Review column came the Working Agreement to always accept a review before starting a new Work Item. This was intended to minimize inventory.

When a work item was technically complete, the Product Owner inspects the delivered software and determines whether a go-live is a good idea. This may be by discussing with real users, with relevant stakeholders or simply by looking at the software on screen. In some cases, the item is so simple that simply trusting the developers to have completed the Acceptance Criteria is enough.
As the responsibility for this decision rests with the Product Owner, developers move tickets to "Resolved" when they have built Working Software ready for a demo.

The Review process became a bit more complicated, because this team is not  fully autonomous - they are part of a large scaled Scrum organization. Occasionally, the input of members from other teams became essential to maintain Collective Code Ownership. Because such reviews from other teams could take a while, the team created an [in] "Review" column.
The Source Code Management System (in their case, Stash) takes care of managing team external Pull Request reviewers and their feedback - but the ticket sticks "In Review" as long as essential feedback is still missing.

An organization problem sometimes made it impossible to merge fully tested, reviewed code: The Red Master.  Nobody is allowed to merge into a Red Master for any reason other than fixing the broken build - so the team introduced an "Pull Request Open" column to indicate work items that are just waiting to be merged into a Green Master.

Due to not only being a large scaled Scrum organization, but also due to B2B dependencies, the team quickly discovered that sometimes, they would be blocked based on external dependencies. They introduced an "On Hold" column to park any work item which they could not feasibly make progress on because they had to wait for an external party to complete their work. Examples for "on hold" would be, for example, an interface adaption in an external 3rd party software.

After introducing Kanban for a long time, the team encountered a new problem: They could pull work as fast as it arrived. However, not every request that was brought forth to the team makes sense. Any feature and/or information requests were parked on the "Backlog", for the Product Owner to inspect. The Working Agreement became that the Product Owner had responsibility to groom and refine stories in the Backlog before developers would pull them.

Had the PO decided the items would actually be an improvement towards the product vision - and met the team's Definition of Ready, the item would be moved to "Selected for Development". The Team's Working Agreement became that the team completely ignored the "Backlog" column, because it could contain worthless, incomprehensible or conflicting requests - or simply those which were misrouted in the organization.

Conclusion

The specific status model of a team's Kanban board must suit this specific team.
This article is not intended to provide a "better model", but to provide an understanding in the though patterns which can lead teams to evolve their board.

It is generally the best approach to start with a simple board. During Kaizen Events, you might then add columns when inevitable. Working with a complex board and not knowing how (or why) to work with it from the beginning is not a good idea.

This article purposefully omits the steps where workflow columns were added and later discarded because they were found un-necessary. That happens - and is actually good, because it means that people care and Continuous Improvement works.