Scrum - Are you selling Snake Oil or the Real Deal?

Scrum is a highly effective methodology for Software Development Project Management. Companies transitioning to Scrum have witnessed massive performance boosts of 300% upward. Scrum has low adaption barriers, transitioning to Scrum just takes a few days. Scrum will seamlessly integrate with your current organization and can be applied by any team. Anyone can do Scrum. All you need is a couple days of CSM/CSPO training and you're ready to get going. The traditional problems of long time-to-market, high cost of delivery and poor quality are all of the past: You will see new, valuable features delivered every 2 weeks!

This is the claim of Snake Oil Scrum. Let us examine what happens when you buy and apply it. Let's contrast this with the actual intentions behind Scrum:

Snake Oil Scrum - debunked!

Now, let's be more honest.

What is Scrum?

When you are familiar with traditional Software development, you will see Scrum as a vastly different approach. Few of the paradigms in traditional management are applicable in the modern business world, and Scrum takes that into account.
Embracing Scrum's agile mindset can tremendously boost productivity, morale and revenue.
Scrum's structure is easy to implement. It provides a solid basis to reinvent your organization completely.
Scrum's learning curve is steep: bad practices will become transparent and opened up to scrutinous inspection and adaption. Scrum will quickly reveal the unsolved problems in your organization, then encourage teams to experiment and find their own solutions. Continously challenging the status quo leads to a journey of lifelong learning - for the benefit of customers, the organization and employees alike.
Scrum focuses on value, increments and short delivery timespans.
Consequently keeping this focus delights customers, reveals quality issues early and permits robust, yet flexible planning even in challenging circumstances.
As a manager, there are only a few things you must do: Bring the right people together - and enable them to do the right thing! Scrum has no place for management hierarchies, reporting and controls. Do you dare to let your teams succeed?

Understanding "Definitions of ..."

The Scrum guide advises having a Working for a Definition of Done. It also hints that a Definition of Ready might be useful. New teams occasionally struggle with defining these agreements appropriately. Here is a small summary of what these definitions imply:

Relationships between DoR, Sprint and DoD

Definition of Done

The simplest "Definition of Done" is "No more work to do.", in the sense that "The customer has the final product." For some teams just starting the agile journey, it is not possible to achieve this within the Sprint. They might rely on a manual User Acceptance Test done by a testing department, a deployment done by SysOps and many other things.
Their DoD excludes all the work from the sprint which will not be done by the team.

The ideal DoD

"Done" does not exclude anything, so the DoD would imply to include everything. This usually is the case for teams using Continuous Deployment, delivering complete value to the customer many times a day.
In this situation, a formal DoD becomes unnecessary - but many organizational impediments need to be removed until then.

Definition of Ready

The simplest "Definition of Ready" is "We can start to work.", in the sense that "We have an idea to work with." Some teams still feel insecure working with little or no upfront planning and/or analysis, so they would not achieve getting from idea to solution within one Sprint. They might rely on (big) upfront planning, design and analysis, in the worst case on a full specification document. That, for example, would be the case when only "developers" transition to Scrum, without forming a cross-functional team. 

The ideal DoR

"Ready" is reached as soon as an idea comes up, so the DoR would imply to not require any upfront work at all. Teams need to have a firm grasp on their product, technology and a high customer centric mindset to reach this state.
In this situation, a formal DoR becomes unnecessary, just like a DoD.

Sprint Work

Sprint work includes every work that is not done "outside the Sprint". Everything included by the DoD that was not included in the DoR creates the bracket we call "Sprint". Based on Scrum's definition of a Sprint, this should be all relevant work: Scrum does not account for "pre-Sprint" or "post-Sprint" work.

The ideal Sprint

With this understanding, it becomes obvious that the larger the amount of "undone work" (i.e. DoR work or post-DoD work), the less impact the Sprint has on overall product success.

A large DoR or a strictly limited DoD imply that significant amounts of development work is actually done outside the Sprint - making Sprints an illusion of control!

Conclusion

When first experimenting with Scrum, it's a good idea to make DoD and DoR explicit. This will help the team understand the impediments towards successful end to end delivery of customer value. 
Any limitations imposed on the DoD should be put under scrutiny - as should any items in the DoR.

When looking for ways to optimize your Scrum, look at the size of your Definitions: the DoR should completely disappear, and the DoD should be unconditionally reduced to "Done".

Three types of Customers

As a Product Owner and/or member of an agile team, you might be challenged with the concept of "customer value". Some people consider that only things which are useful to those who are end users of the product have real value. However, that falls short of what a customer is, so here is an overview of which groups of customers you must consider.

Primary Customers

Also known as "end users". The people who actively use your product until the end of the product's lifecycle. If we consider a Teddy bear, that might be the kid who actually plays with it.
This group of customers is typically the easiest to please, because you can directly study their behaviours.
A Product Owner should understand their Primary Customers to make a great product.

Based on the Kano Model, you can please them by triggering their "Excitement".

Secondary Customers

Also known as "Buyers". They are the ones making the purchasing decision. For some products, they might be "users", for others - not. If we consider the Teddy bear, that might be the parents or relatives who wants to buy a present for a child.
This group of customers may not even understand what incites the Primary customers and may even have conflicting interests with them.
A Product Owner must be aware of the Secondary Customers, because they determine the financial success of the product.

Based on the Kano Model, they typically look at "Performance" criteria and try to find the best value.

Indirect Customers

Also known as "Regulators". They might neither buy nor use your specific product, but they still want some say. If they actually get in touch with your product, that may be because of a dual role. If we consider the Teddy bear, that could be an activist group asking for a statement that you pay Fair Wages and provide Safe Working Conditions - it could also be the government demanding the teddy to be non-flammable and non-toxic.

This group of customers is impossible to please and will not generate a cent of revenue. The best thing you can do is not to displease them or draw their attention towards you. Keep them satisfied with minimal cost and effort.

As Product Owner, you must understand the demands of your Indirect Customers, because if you don't - they'll kick your product off the market. The hardest part may be not diluting your Product Vision in doing so.
Indirect customers are the worst nightmare of every product owner, because they will add as many non-value adding, potentially counterproductive requirements as possible into even the simplest product.

Based on the Kano Model, they require "Hygiene" criteria.

Summary

You must be aware of all customer groups. Never lose sight of any of these groups. Invest sufficient time to understand them. Do what is necessary to make your product positive towards their needs and demands.

Suggestion: Do you want to make these explicit in your Plannings?

Story slicing 101

A repeating theme in agile transformations is: "Our stories are too large, and we can only deliver all or nothing - we have no idea how to slice them". The consequences? Teams can only do few, but large stories, variation and failure probability is high - predictability and flexibility are low. None of these are desirable from a business perspective - regardless of agility. Story slicing solves this.

Since we will be dealing with fairly abstract concepts, let us create a specific example to make the subject more tangible. Let us start with the "too big" story:

As a user of the platform, I want to have a response time of less than 2 seconds, so that I can spend more time actually making progress.

This is a typical case of nonfunctional requirement, phrased as a user story with clear success condition and clear indication of business value. Unfortunately, for large systems, this pretty much means rewriting the entire code base - there is no way to get this done in a few days!

Step 1 - Start asking questions

The above story leaves plenty of room for interpretation. The first misunderstanding is that "We have to do everything, otherwise it might not work". Teams end up creating seemingly endless to-Do lists for changes that all need to be made. But they don't really ask questions.
A good way is to break up the team in a Refinement session and let them actually build a model around the story to help them discover questions, independently.
Here is what the team might come up with:

Which type of users do we have?
Do admins have the same needs as application users?
Does it really hurt if user creation takes a bit longer?
Which function actually takes the longest?
Is 2.1 seconds a problem?
We could make transactions faster by splitting into multiple minor steps, but that has more clicks - would the users accept that?

Regardless of what questions come up, what you need is that these questions are written down explicitly, not a detailed discussion to answer these questions (yet).

Step 2 - Bring the questions together

Different sub-groups will probably discover different questions. There is no "right" or "wrong" at this time, only different models, resulting in different questions. All questions are good, because they reveal how people think. By having each group bring their questions to the board, we can start to cluster questions. Most likely we will have more than one cluster.
For example:

Users and their needs
Function specific boundaries
Worst-case scenarios

What you need now is not the similarities within the clusters, but the differences between the clusters.

Step 3 - Slice based on clusters

Slicing is best done across differences, but keep real user value in mind. None claim to solve the entire problem, all will contribute a meaningful partial solution. At the moment, let us "forget" about the overall problem we have and specifically focus on partial delivery.
Here are examples for extract user-relevant, deliverable stories from the basic story:

As a new user, I want to create a new account in less than 2 seconds.
As admin, I want to wipe a user account in less than 2 seconds.
As transaction user, I want to complete a transaction in the system in less than 2 seconds.

These stories are still quite different in size, but they are much easier to handle than the entire block. After we are "Done" on the first two stories, there is still a large amount of work to be done - but also a tangible result. Some of these stories might be discarded immediately, because the team realizes that this specific need is already met.

Step 4 - Drill in, Rinse + Repeat

Looking at our example, most of the work will probably be in the third sub-story. We can drill into this sub-story in exactly the same way we drilled into our initial story. Drill-in can be channeled by moderating the team to look for specific aspects.

Here is a small list of aspects to look for:

• Workflow: Steps, user goals, scenarios
• Transactions: activities, operations (CRUD)
• Users: personae (user types), roles, responsibilities
• Technology: configuration, context, data streams (& interfaces)
• Data: content, types, subsets

With this list, you could instruct one group to look for workflow aspects and another group might examine data.

Here is an example of what the "data" group might come up with:

• 60 second timeout when the database is down.
• Stuck in a "Waiting" dialog when the Internet connection is unstable.
• Mass update speed is proportional to amount of updates.

Step 5 - Verify & Engage

Depending on how far you take this, you can slice down any large topic to as many small topics as needed until the team arrives at the following two conclusions:

1. We have discovered relevant areas for change
2. We can resolve a few stories in a fairly short amount of time

Put the most important, workable stories high in your backlog, preferrably starting with the first stories right in the next sprint - and sort the remaining relevant items into the backlog at an appropriate place. If you want to, you can keep the "master story" in the product backlog, but it's priority will be lower than that of the lowest identified story.

After all known stories are closed, the master story will pop up again - at that time, the first question is: "Do we still have a relevant problem?"

Conclusion

World hunger stories are common. The most common problem teams encounter is that they dive into the solution space before working on the story definition. However, since the story with it's Acceptance Criteria defines "success", it is most important to have a realistic goal in mind. Otherwise, there is no way to succeed.
The next time you encounter a backlog item that is "too large to do in a Sprint", try asking tough questions and slicing along the differences between the questions.

Setting up an initial Product Backlog

Companies just start on their Agile journey, starting on a pilot project, typically are stuck with an un-answered question: "How do we obtain our initial Product Backlog?" Of course, first you need a Product Owner. Someone to drive the Product Vision in a desirable direction. But then: What are the steps for creating an initial Backlog?

Step 1: You need a Product Vision.

Some people don't like the term "Vision", because it sounds a bit esoterical. You may refer to it as "Product Purpose". That's about the same and sounds a bit more conservative. In this section, we will stick to the common term "Vision".

A Product Vision is a simple, yet compelling statement of why the product should even exist. It should not be too restrictive, yet sufficiently precise to be meaningful.

How do you get a Product Vision? Ideally, you already have one. Otherwise, you should group people with good ideas together to come up with one. Brainstorming business opportunities is a good way. Typically, someone with some money has a certain need - meeting this need can be the initial vision.

Here is the starting template:

I want to create a product that does [ONE THING]. 

For example, "A new way of communication." would be a decent product vision.

Once you have the Product Vision, it will be your sieve for filtering out stuff that you want to do - and discard everything that will not help in achieving the vision.

Step 2: Drill into the Product Vision.

Just like "Rome wasn't built in one day", neither will your product be. In order to make the Vision a bit more tangible and easier to verify, you need to say who should use your product and how they would be using it in the first place.
At this stage, you know nothing about what the market has to say, so keep it as simple as possible. To simplify the matter, feel free to completely ignore edge cases and negative case scenarios.

Here is the template:

Our primary customers are [ONE target audience].
To reach this goal, first we are going to [do ONE thing] in order to [achieve ONE customer-centric purpose].

Let's take our initial vision. We could specify: "We want to target train commuters who have smartphones to communicate without relying on the presence of mobile telco carrier networks,"

The next thing to do: Verify the viability of your vision quickly and as cheap as possible.

Step 3: Make the vision verifiable.

In order to know whether your product stands a sporting chance on the market, you need to collect evidence that it can do so. Regardless of whether you start with a disposable prototype or an actual MVP, you don't want to waste much time or effort before you know whether to proceed. If your vision doesn't fit the market - stop and reconsider.

When doing checks, please note that you are in the realm of hypothesis testing: You want to prove the idea that your product is viable - you can't assume by default that it is. But it is hard to prove something which does not exist will be viable. Therefore, you need to gather evidence that your product is actually not viable - when you manage to do that, trash the idea. When you can't - you still don't have proof that it is.
The easier the condition of viability can be falsified, the faster you can discard bad ideas. Disposable prototypes might allow you to falsify the viability hypothesis at a miniscule fraction of the cost incurred by an actually viable product - especially when hardware production is involved, so try to see how you want to check the viability condition.

Here is the template:

We know that we're on the right track by [checking ONE condition].

But we also need to be aware of [other conditions].

An example viability check would be: "We built a smartphone with extra long antennae and hand them to commuters, see what they think. If they don't like it, they won't buy our product." Well - you can guess the outcome, but it was just an example.

Step 4: The other stuff.

Your head is probably bursting with ideas of things your product can do. Don't prioritize all of them! There is only ONE priority 1, and that's easy to forget when you have a hundred great ideas. Put all but one of them into the backseat until you know your product actually works.

Again, here is your template:

Once we're on the right track, we will build [more of the same thing] until [a certain condition is reached].

Over time, we might also add [some more things] in order to [achieve other purposes].

Conclusion

You are on the right track with your product vision if you can meaningfully state:

I want to create a product that does [ONE THING].
Our primary customers are [ONE target audience].
To reach this goal, first we are going to [do ONE thing] in order to [achieve ONE customer-centric purpose].
We know that we're on the right track by [checking ONE condition]. But we also need to be aware of [other conditions].
Once we're on the right track, we will build [more of the same thing] until [a certain condition is reached].
Over time, we might also add [some more things] in order to [achieve other purposes].

The bold-faced items are your initial, prioritized Product Backlog in descending order. Congratulations - now it's time for the first Refinement session!

Scrum is not Agile!

So, the headline is obviously a teaser. Now, why would I state something like that?
There is a large group in the IT community, regardless of whether Scrum / Agile / non-Agile who seem to be confused with this matter: They use Scrum and Agile interchangably. Unfortunately, even thought leaders in the Scrum community propagate this misunderstanding.

Time and again, we can hear people state: "Oh we tried Agile a couple years ago. Didn't help much, we went back to Waterfall." Upon further inquiry, we find out they did Scrum, but neither understood nor embraced the Agile Manifesto. Usually, that is combined with a failure to be cross-functional, to apply solid Engineering Practices and to let go of ineffective organizational habits.

So then, what is Scrum?

Before I go into details, let me clear up one thing: Scrum is part of the agile community and therefore qualifies as an agile framework. However, neither is Scrum representative of all agile methods - nor does applying Scrum in your organization automatically mean you're agile.

Why being Agile doesn't mean you do Scrum.

This one goes down two streams:

You can't simply interchange the words "Scrum" and "Agile"

First, there is a huge difference between an equivalence (A <==> B) and an implication (A ==> B). In logic, we typically use this analogy: "When it rains, the street is wet. The street is wet: Did it rain? -  No, maybe someone poured a bucket of water or a lawn sprinkler went rampant."
You can apply this for Scrum and agility as well. When you do good(!) Scrum, you are agile. The reverse, however, is not true. For example, as stated in the Post-Scrum Manifesto, even when you started with Scrum, your Scrum should evolve over time until it doesn't even resemble Scrum any more.

Agile teams don't necessarily use Scrum

Truly agile teams are doing highly effective work and deliver great results, but chances are - they're not doing Scrum.

Maybe they did Scrum at one time, but maybe they also started with a different agile framework like XP, Lean, Design Thinking, Crystal, DAD, DSDM - or simply evolved whatever way of working they started with. Chances are they are agile and haven't even heard of Scrum - albeit the odds are quite low, given how widely spread Scrum is today.

Why doing Scrum doesn't mean you're Agile

Let's start with linguistics here: You do Scrum, but you are agile. You can't be Scrum or do Agile.

Scrum (mis-)understood as a process

Unfortunately, there is a wide spread misunderstanding that Scrum is a "method" or "process". Many consultants, trainers and managers fail to properly discern the consequences of merely applying Scrum as a process. The result is always the same: Scrum is being applied as a Cargo Cult, doing everything exactly as prescribed, but not reaping any benefit. This is the problem with frameworks: They only serve as a yardstick, you still need to fill them with life by yourself. Failure to actually change structures and behaviours inside and around Scrum will result in product/project failure.

There is a weak relationship between Scrum and the Agile Manifesto

There is no reference in the Agile Manifesto to Scrum. In fact, only the signatures of Jeff Sutherland and Ken Schwaber correlate the Manifesto with Scrum. It's not the Scrum Manifesto: Jeff and Ken were two of 17 contributors, implying that Scrum only accounts for roughly 10% of agility.

Vice versa, Scrum does not primarily focus on agility. The Agile Manifesto is typically just a "Must-Have" module in a Scrum training - but just one small block. You're lucky if your trainer sponsors more than an hour for the Manifesto. The Agile Principles are sometimes even skipped in Scrum classes. Agility makes up less than 10% of a Scrum course, making the relationship inherently weak from the outset.

Scrum without agile principles

Most people practice Scrum without taking heed of the Agile principles. Even if they know about them somewhere back in the recesses of their mind, they do not consciously work to conform the organization towards agile principles. Much rather, they use their organization as an excuse for circumvening these principles.

However, a "principle" is not a recommendation for something you could do, but a "law" - similar to gravity: It applies even when you don't like it. Scrum can be implemented within an organization in complete disregard of Agile principles, although it should not.

So then, what is Agile?

While Scrum is fairly easy to comprehensively explain, agility is much harder to explain. Based on my knowledge, to this point, the agile community has yet not found an accurate, comprehensive description of what "being agile" really means, beyond applying the values and heeding the principles of the Manifesto. 

Probably the most adequate description of "agile" is: A mindset of Continuous Improvement and Customer Value Orientation. A consequence of being agile is that no method, no process, no piece of information is sacred - everything is up for scrutiny, inspection, change and possibly complete discarding when a better path becomes known: Even the mindset itself.

Conclusion

You are free to do Scrum in your organization without being agile. You can find many quacks and snake oil sellers who will gladly support you with that. But it's setting up for failure.
Likewise, you can be completely agile without doing anything that even remotely resembles Scrum. In fact, that's what is naturally going to happen once you pursue down the agile road.

Therefore, you should never confuse "doing Scrum" with "being agile".

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!