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".