Scrum Patterns – Putting Scrum Into Practice

In 2017 I was talking to the head of the Agile Coach Group of a large bank. She asked me to come over to work with her and help to roll out their standard way of working across all branches in Europe. The idea was that they had invented the best way of working over the last 5 years, and now the other branches just needed to implement their method.

I asked her how she would know that her method would work in other contexts as well? Many things may be different; maybe their customers are different? maybe the market is different? Maybe solutions that work here do not work very well in the other offices? maybe they have different problems to solve?

She assured me that after all these years, she knew her way was the best way and she did not want to start the whole discussion again.

The birth of spreadsheet Agile adoption

Assuming that the best way of working is known, the only thing left to do is to ensure that all branches and teams work according to it. The result is what I call spreadsheet Agile Adoption and the approach usually goes like this:

Step 1. Smart people come up with the best process that the teams, groups, and branches should follow.

Step 2. They create a model for measuring compliance with this process/method.

Step 3. They create Spreadsheets with questions/measures to assess how well these teams, groups and branches are complying with the standard way of working.

Step 4. They send out Agile Coaches to assess, train and coach the teams, groups, and branches to work according to the standard process.

This approach is very much in line with Frederick Winslow Taylor’s ideas about industrial efficiency; there is a “best way” and we need to “separate the head from the hands”.

Although it is very unlikely that the process will actually be the “best” in the other contexts as well, the most important concern with this approach is the potential lack of ownership by the teams and branches. In Agile we want the people to improve their own processes because they probable know their own environment best, and that is more likely to happen if they can create their own process. Handing them the “best” process will very likely not create the feeling of ownership, and if it is already the “best” process why bother improving it anyway!

Avoid Frederick W. Taylor inspired spreadsheet Agile adoption

You probably have had coffee at many Starbucks coffee shops. And you probably have noticed that the way of working is very much the same across the shops. What might surprise you is that it is not a global standard way of working! Starbucks leaves the local shop to create their standard process based on its local environment.

“…With brewed coffee, for instance, differences can be significant in how the work area is set up—the equipment may be different, the layout and location, even the counter height or length may vary. Whether the store is high-volume and staffed with six employees versus low-volume and staffed with two, all impact what the best process for that coffee shop will be. The point is while the role of barista has the same objective in all stores—including brewing and serving a perfect cup of coffee every time—the site-specific job conditions necessitate that for the process to be optimal, it must be somewhat different in each location…”

Treating all groups that do similar work in the same way and measuring compliance to the one standard process is ineffective and:

• Creates a focus on spreadsheet compliance to the “best” way of working, instead of a focus on ownership of the process.
• Does not create engaged problem solvers who create and improve their products and processes, quite the opposite.
• Ignores the local environment of teams, groups, products, and instead proposes a quick fix.
• Gives a false sense of progress in the adoption. I call it the progress by check-box measurements.
• And probably most importantly it signals that workers are not expected to think and solve problems in their process, products and services.

You probably do not want this.

No Spreadsheet adoption…. but then what else can you do?

In September 2019, the book I co-authored, called A Scrum Book was finally published. It took us, the ScrumPatterns Group, around 10 years to write it. The book is 528 pages long and contains 94 Scrum patterns. Contrast that to the Scrum Guide of only 19 pages. Hmm…. what is going on here?

Knowing the rules of Scrum does not make you a great player of Scrum, in very much the same way that knowing the rules of Chess does not make you a great Chess player. So, while the Scrum Guide provides the rules of Scrum, the Scrum patterns explain teams how to solve problems in a specific context.

Scrum Patterns

A Scrum Pattern captures proven solutions that we have distilled from observing many Scrum Teams across the planet— both their successes and failures. Below you can find a simplified and short summary of the pattern for the famous Daily Scrum.

What does a Scrum Pattern look like? A Scrum pattern consists of the following parts.

Initial Context …the Development Team has created a Sprint Backlog and is working to achieve the Sprint Goal…

Problem Statement …The team makes progress in a Sprint by finishing Sprint Backlog Items, but given the complexity of the work, the characteristics, size, and quantity of tasks change frequently—sometimes minute by minute…

Forces … there are 3.628,800 ways to order 10 tasks, yet only a few of these ways will put the team “in the zone”. ….too much re-planning and re-estimating wastes time and suffocates developers.

Solution …Have a short event every day to replan the Sprint, to optimize the chances first of meeting the Sprint Goal and second of completing all Sprint Backlog Items…

Resulting Context …Daily Scrums have additional benefits as well: Reduces time wasted because the team makes impediments visible daily; Help find opportunities for coordination because everyone knows what everyone else is working on; …

Patterns help you identify which problems you want to address and provides a proven solution that very likely will point you in the right direction.

A Scrum pattern:

• Is only applicable in a specific context. If your context does not match the particular context then the Scrum Pattern is probably not useful for you.
• Describes a problem in that context. If you do not have the problem, then you probably do not need the solution either.
• Explains the forces that need to be considered when applying the pattern. The forces guide you to come up with your own specific solution that works in your specific environment. This is a key idea!
• Offers a canonical solution to a problem in that context for inspiration. The solution can be implemented in many different ways.
• Explains why the solution solves the problem and balances the forces so that you can create your own implementation of the solution.
• Points to new Scrum Patterns to consider applying.

What can Scrum Patterns be used for?

You can use Scrum Patterns to put the Scrum framework into practice. The patterns build your Scrum Team; your Product Organization and your Value Stream. Using patterns will not only help to create more ownership of process, and better solutions, but will also more likely create more engaged teams.

So, instead of Spreadsheet Agile adoption where the goal is compliance, Scrum patterns give you a path to create your own process that works in your context by solving problems one at a time.

Business & Finance Articles on Business 2 Community

(37)