This is a description of the workshop I did at the LeSS Conference in Amsterdam.

You can use this workshop to have a thorough discussion about your new LeSS group or to repair an existing LeSS adoption.

For a general workshop, you can use the starting situation I wrote about in my Copy Paste Scaling articles that you can find here and another one there. I now call it the MeSS, then your goal is to go from MeSS to LeSS.

In the context of your organization, you start with your current situation.

Step 1

In this step, you generate a list of problems that you want to address.

The question to answer is, What should be removed from the MeSS ( or from your current situation ) to get to LeSS?

  • With your group generate a list of problems that you would need to address in your LeSS organization. You can use liberating structures if you have many people in the room.
  • Write each problem or improvement on a Post-Its. I like to ask people to write it in the form: “How do you …”
  • Use affinity mapping to remove duplicates and create a common understanding of the problems.

Step 2

In this step, you are going to discover which LeSS Pattern cards, if any, could be helpful.

Place the LeSS Cards front down on the table.

  • Choose a problem to work on.
  • Each person picks 4 LeSS cards from the deck.
  • Each player selects a card(s) from his hand, if any, that describes the problem and plays that card on the table.
  • The group then discusses the potential LeSS Patterns that could be useful in addressing that specific problem.
  • When agreed, place the pattern cards under the matching problem. If you have multiple cards that solve the problem place the cards in a sequence.
  • Each person refills their hand to 4 cards. If the new cards solve the current problem, you place the card, discuss and refill your hand again.
  • Then repeat with the next problem.

Step 3

In this third and last step, you discuss the sequences that you created and decide which pattern you want to apply.

A sequence is your best guess on how to improve the organization at the moment in time. When you adopt a pattern, you will learn if it works or not. If it works, you keep it; if not, you backtrack and try another. The basic process is as follows:

  1. Choose the pattern that will most strengthen your LeSS group.
  2. Apply the pattern.
  3. Assess if it indeed solves your problem at the end of the Sprint, then recognize your new context and choose the next pattern that you want to try.
  4. If not, undo the pattern and try another at Step 2 instead.

Keep an experimental mindset, be ready to learn and adjust, and understand that there is no “best” sequence. A sequence shows a path, but the teams have to do the walking and discover how to implement it.

The LeSS Pattern Cards

I created the LeSS Pattern cards for free use by the LeSS community. Just drop me an email if you want to obtain a deck. I will send you a printed deck.

There are 2 positions you can take when thinking about scaling Scrum.

  1. You consider Scrum a team level framework only, and then ask what needs to be added to Scrum to make it fit in your organization. You likely have Copy Paste Scaling and a narrow product definition.
  2. You consider Scrum a framework for your complete process, and then ask how to scale Scrum itself. Nothing needs to be added to Scrum. You need a broad product definition.

I explain the effects of these two approaches and how to define your product in the webinar: De-Scaling with LeSS from the perspective of the Product Definition.

This blog is part of a series of previews from my upcoming book Coaching Agile Organisations

In the first part of this blog series, I explained how to identify the organizational elements to include in your product definition. In this blog, I explain how you can refine your product definition to organize into effective cross-functional teams.

Some elements are more equal than others.

Below you can see a simplified view of the organizational elements at one of my customers.

We discovered that some organizational elements are required more than others to develop product features. The more often a particular element is required, the stronger the dependency. We visualised the strength of the dependencies with a heat map—see the figure below for a anonymised simplified example. 

The y-axis shows product features. The x-axis shows the organizational elements. A green area indicates an element that is needed to deliver the feature.

The elements that heat up the most indicate the strength of the dependency—these are the hotspots. Note that the WEB element is needed in 28% of the time to develop product features, the APP 20% of the time, while Legal is required only 7%.

NOTE: Avoid focusing too much on the percentages, this is not an exact science but rather a guide to help you move forward. Next to percentages I also successfully used different scales to estimate the strength of the dependencies like: Seldom, Now and Then, Frequent.

When all the teams can pick up any work that comes in and deliver it completely to done, you have maximum adaptability. That would mean that each team has the skills to cover the whole heat map. Unfortunately, this was not the case for us. There were just too many technologies and domain knowledge for the teams to comprehend. Also, there is value in team specialisation. The solution was for teams to specialise in the customer domain first, and then to learn about the other product domains as needed.

Learning can take many months or even years, and in the meantime, we needed to determine how to start. Which organisational elements should the teams cover first and which shall we add later? This decision depends upon the strength and type of the dependencies.

Find the balance between adaptability and speed 

When a team can work on all components but only one feature, a team covers a complete row, as drawn in the figure below. Such a team has no external dependencies; hence they probably deliver fast. On the other hand, when a team covers all features but only one component, a team covers a complete column in the heatmap. Such a team can work on all feature-parts; hence they can adapt to all work that comes in, but cannot deliver end-to-end. 

Therefore, the size of the heat map area that a team covers strongly determines its

  • feature delivery speed
  • flexibility to pick up work from the product backlog.

Our challenge was to find the optimal balance between speed and adaptability in our 11 team context, and that depended upon several variables:

  • The teams’ cognitive capacity. When teams specialise in a customer domain they can still work on customer features without needing to understand the other customer domains of the product.
  • The type of dependencies between the elements. This helps the teams determine which organizational elements to cover first and which later.

Specialise in the Customer Domain

Our product was a large insurance system. We used interviews and questionnaires to determine where users spend most of their time when using the product. It turned out that there were a couple of main groups of users. (For this blog, I just use the 2 groups Claims and Evaluation. and call them red and yellow.) Some users mostly used the red-colored features—red area— while the other group primarily used the yellow-colored features—yellow area. The orange features are used by both sets of users—they overlap or intersect both red and yellow areas. 

The red and yellow areas let the teams specialize in a customer domain—see Requirement Areas in LeSS ( and Value Area Scrum pattern ( This reduces the cognitive demand on the teams.

The next step was to find the most significant heat map area that the teams could cover. 

The type of dependencies between the elements

We used the following rules to decide which elements to include from the beginning and which to add later.

  • Rule 1 – Contain reciprocal dependencies within one Value Area: The work of one team is input for another team and vice-versa, and there is uncertainty about how to accomplish the task, which makes frequent alignment necessary
  • Rule 2 – Ensure sequential dependencies between Value Areas with iterative planning: A team is dependent upon the work done by another team. Applicable to work with low uncertainty and predictable work.
  • Rule 3 – Manage pooled dependencies across Teams and Value Areas with simple coordination rules: For example, the sharing of a single test environment, or dependency of a person with a scarce skill.

Below you can see an example result for the red Value Area.

The Web, App, Siebel, Portal components are used often together and their interdependencies are reciprocal. The teams in the red area decided that they woud need to cover at least these elements.

Furthermore, you can see that the area has a pooled interdependency with Legal, and that it is a relatively strong dependency. of 14% The weakest interdependency is with Sales Force. We choose not to include Sales Force initially and only add it when the teams mastered the other elements. Legal was also not included because it was a pooled dependency.

The yellow Value Area below has a different set of dependencies.

The teams decided that they needed to cover at least the APP, Sales Force, Siebel and WEB components

For this area, Legal is not needed at all. And there is a weak sequential dependency on Portal. We decided to not include Portal in the first step. In the exceptional case that a feature needed a change in Portal the teams would coordinate with the red-area to get it done. We also used these as opportunities to learn more about Portal.

How to handle the features in the intersecting orange area? A solution is to decide based on the feature itself.

For example, F10 could be picked up by either the red or yellow area. F18 require only APP and can be picked up by the yellow area. The only complicated feature is F11. It requires Sales Force and Portal which neither the red or yellow area possess. So, how to handle this one? Well…., remember the golden rule of Scrum Mastership: “Always ask the team.”

Final Result

The product definition includes all elements, but we choose to not include Legal skills in any of the teams from the start. Why? Because it is a pooled and weak dependency. Also, the teams felt they were not yet able to cover more skills right from the start. Instead, Legal became the next activity to include in their Definition Of Done.

In the unfrequent case when a feature requiring Legal skills would appear on top of the Product Backlog, we would plan for that by working together with Legal in refinement events and during the Sprint.

At Sprint Planning, the team that selected that feature would then coordinate to work together with someone from Legal to get the feature done. Preferably, the Legal person(s) would also use the opportunity to teach the team so that they understood a little bit more about Legal at the end of the Sprint. When a team keeps selecting to work on features with a Legal part, eventually they learn enough to add Legal to their Definition Of Done. Bas Vodde calls this accidental specialization.

NOTE Not all teams need to know everything about all element in the Product Definition right from the start. Teams can have their own speciality as long as all teams as a group can pick up all element from the top of the Product Backlog.

You can use this Kahoot Scaling Scrum to have some fun with your team or as an energizer during a workshop or training.


This blog is part of a series of peek previews from my upcoming book Coaching Agile Organisations

This is the first part of a blog series about product definition in LeSS.

In large product development, teams tend to work on just a part of the real product. The part—a narrow product definition– is often a component or a specific activity in the development process; it is not a product.  

A narrow product definition creates all kinds of problems for a product group. It locally optimizes the performance of the teams at the cost of the performance of the group. The causal loop diagram (CLD) below explains this dynamic. ( See this blog for a quick overview of CLD notation. ) 

Narrow product definitions make it more likely to have specialized teams that only work in their silo, which in turn decreases adaptability and speed of learning at the overall product level. Broader product definitions lead to teams that cover multiple components and activities that together address the needs of end-users. 

Remove Local Optimization Of Narrow Product Definition

A commonly used definition of a product is “something that is made to be sold.” The product provides a way of making a profit.

  • A product has users who are people;
  • A product provides features to those users that address their needs and problems;
  • A product has a business model, revenue stream, independent profit & loss, or return on investment.
  • A product is developed and sustained by a system of people, components, and processes.

The product definition determines what organizational elements (people, components, processes, and systems) are needed to develop and run the product. If your product is Mortgages, then your Product Owner is probably a business person who understands the market. The Product Backlog might have items like “Loan offers to small businesses,” and the users are likely to be paying customers. Mortgages is a broad product definition when it contains all the parts needed to produce an end-to-end solution to the end customer.

How To Define the Product?

The product definition includes multiple components, activities, and provides solutions to the needs and problems of end-users. You can define your product using the following two steps:

Step 1 – Identify the required organization elements to develop and sustain the product.

You start with the elements—your component teams— you currently call products, the activities, the people, and the processes you have presently in your group. You then study how the work works for your group so that you understand the types of dependencies that exist to develop, maintain, and sustain your product. 

The typical steps to achieve this are:    

  • Identify some typical external end-users of your group.
  • Identify some regular needs these end-users want to be addressed or tasks they need to complete.
  • Identify some features for each of the users that they consume to address their needs or perform their jobs.
  • Identify the boundaries through which the users consume the features to satisfy their needs/problems etc. (for example a Browser, App, API, Connector or Helpdesk)
  • Next, you want to identify the organizational elements that are needed to produce the feature and satisfy the customer. You do that by studying how each feature flows through your organization into the hands of the customer. You start at the boundaries and work through the components, systems, people, and processes until completion. 

Step 2 – Clarify the revenue streams

A proper product definition identifies a group broad enough so that it includes revenue streams. Without it, the teams in the group will likely be disconnected from market concerns where the real value lies, and instead, the teams focus only on the part of the whole product.

In this step we ask the question: Do the identified organizational elements produce a product that generates revenue for the organization? Or are there missing parts to do so? The way we prefer is to find answers to the following questions:

  • How do the elements together generate cash? For example, is the product definition able to have usage fees? Asset sales? Subscription fees?, Licensing? If not, what would need to be added to the product definition?
  • Does the product definition have an independent profit & loss? If not, what organizational elements are missing?
  • What business KPIs can you assign to the product definition? For example, can you assign it an increase in gross income? An increase in new customers? Customer satisfaction?

If you cannot give a meaningful answer to all of the questions above, then your product definition is too narrow, and you would need to expand it. 

Product definition completed?

At this point, you identified a set of organizational elements that together produce value for end-users and have an independent revenue stream. The result typically includes tens of components, skills, activities, and it can involve hundreds of people in total.

With such a large group, you may ask yourself, “How can I create effective cross-functional teams that include all these capabilities? In the case of more than around ten teams, we recommend to organize the teams among Value Areas[1] and contain dependencies per area.

This is the topic of my next blog, Part 2.


[1] –

In my first article, I explained what Scrum Patterns are and why they could be useful for you in your transformation. The second article explained how to select the Scrum Patterns from the Pattern Languages. 

In this 3rd article, I build on the previous two articles and give an example of how to use the two Pattern Languages to develop your pattern sequence. 

How To Create Your Pattern Sequences?

A pattern sequence is the order of patterns in which the organization wants to transform.  Organizations create their sequence by selecting the patterns that are most appropriate in their context. 

But how can you determine the context? And how do you handle the relationships between the patterns?

Handling the Pattern Relationships

There are two relationships between patterns. 

  • A pattern can be an alternative to another pattern. Alternative patterns refine a common larger pattern.
  • A pattern refines another pattern. The refinement relationship defines a dependency between patterns.

For example: In the graphic below, you can see that Sprint Burndown Chart, Scrum Board, and Yesterday’s Weather refine Sprint Backlog —a dependency relation. Before applying the Sprint Burndown Chart, I recommended using the Sprint Backlog first. 

Also, the patterns Sprint Burndown Chart, Scrum Board, and Yesterday’s Weather are alternatives to each other —You can try any of those after Sprint Backlog.

For example, these are some valid sequences that are generated by the graphic above:

  • Sprint Backlog -> Sprint Burndown Chart -> Scrum Board
  • Sprint Backlog -> Sprint Burndown Chart -> Yesterday’s Weather -> Scrum Board
  • Sprint Backlog -> Sprint Burndown Chart -> Information Radiator -> Scrum Board

Finding the context at one of my customers

As mentioned above, you need to understand your current context to selects patterns and form a sequence. A way to determine that is to perform Go-See sessions and help the organization and teams understand it. Below you can find a small part of Go-See results from working with a customer that we used to understand the current context. 

The team’s conclusions: 

  • In lots of the Scrum events like Sprint Planning, the team lead asks most of the questions; there is a poor shared understanding of the work to do.
  • We do not break the stories down, a lot of work remains hidden during the Sprint, and this gives us unpleasant surprises. Also, team members find it hard to help each other during the Sprint.
  • There are no acceptance criteria for the stories, and the teams do not understand what to achieve.
  • There is no clear goal for the Sprints. Sprint Planning is about ‘fixing 50% of the errors’, and the team is not involved in deciding on this plan.
  • Unclear what the improvement actions are, what problem we want to solve, and how we know that the problem is solved.
  • Work is not transparent to team members or Product Owner. For example, a team member spends three weeks on test suite updates, and we just discovered this a Sprint Review.

This excerpt portraits some of the contexts in which the teams operate. 

Select The Patterns

In a workshop, the team selected the following patterns to try:

  • try Definition Of Done
  • try Sprint Goal
  • try Dependencies First
  • try Enabling Specification
  • try Swarming
  • try Definition Of Ready 
  • try Visible Status
  • try Release Plan
  • try Refined Product Backlog

The next step is to create a sequence to decide with which pattern to start. 

Create the Patterns Sequences

Using the languages, we came up with the following possible sequences:

The orange-colored patterns are from the Value Stream language; the Swarming pattern —the blue one— is from the Product Organization language. The initial context of Swarming expects Sprint Goal to be adopted, that is why it is positioned after Sprint Goal. 

The team started with the sequence: Refined Product Backlog -> Definition Of Done -> Testable Improvements.

Apply one pattern at a time

A sequence is your best guess on how to improve the organization at the moment in time. When you adopt a pattern, you will learn if it works or not. If it works, you keep it; if not, you backtrack and try another. The basic process is as follows:

  1. Find your current context
  2. Choose the pattern in that context that will most strengthen the Whole
  3. Apply the pattern
  4. If it makes the system more Whole, then recognize your new context and go to step 2
  5. If not, undo the pattern and try another at Step 2 instead.

Keep an experimental mindset, be ready to learn and adjust, and understand that there is no “best” sequence. A sequence shows a path, but the teams have to do the walking and discover how to implement it.

Create Your Own Pattern Language and Share

You can find the patterns in this post at If you decide to make use of the patterns, I look very much forward to your experience. You can create your own sequences, augment with your patterns, and create a language that works in your organization. 

I am looking forward to your experience and contribution.

Want to know more?

I will be regularly writing more blogs about Scrum patterns. If you want to keep updated, you can register for the newsletter here, or keep an eye open on social media.

You can also use:

A Scrum Book | Our book about Scrum Patterns. 

Scrum Patterns Training | Our 2 day class.

ScrumPlop | Our Scrum Pattern conference.

In my earlier article, I explained what Scrum Patterns are and why they could be useful for you in your transformation. In this blog, I discuss how to select and use the Scrum Patterns from the Pattern Languages.

Scrum Pattern Languages

The patterns in our book organized into two pattern languages that contain 94 patterns in total — the Value Stream language structures time to deliver a product. The Product Organization language structures the relationships between people to deliver Scrum Teams. These two pattern languages form the two Wholes of Scrum.

Now, how to use these languages?

Systems Thinking

How do you design a house? Ackoff explains: The architect designs to satisfy the needs of the residents, and first draws the house ( the Whole). Then divides the house into rooms ( the parts ). A room is only improved if it also improves the house, and it can be the case that the architect chooses to make a room worse to improve the house as a whole. So, you start with determining the function of the larger Whole, and then improve the Whole by refining it with parts. 

We apply the same approach with the Scrum Patterns. You start with the most extensive pattern( the Whole) and then refine it with subsequent patterns. You are always keeping in mind the goals of the Whole.

You might be thinking, so what? Well, it is crucial to understand the boundaries of your system and the goal you are striving to improve, because you are unlikely to improve the performance of the Whole by improving the parts taken seperatly— R. L. Ackoff, Re-Creating the Corporation, page 21. Let me try to explain using a simple example.

Use Patterns to build your Team

Let’s say that a team is having trouble aligning during the Sprint because of the complexity of the work. Thinking about the Scrum framework, what does Scrum offer to help the team members align …..? Yes, you are right, the Daily Scrum event. You can verify that the Daily Scrum might be appropriate for this team by verifying that the pattern’s problem statement matches your current problem. The problem statement of the Daily Scrum pattern states

“The team makes progress in a Sprint by finishing ¶73 Sprint Backlog Items, but given the complexity of the work, the characteristics, size, and quantity of tasks change frequently — sometimes minute by minute.”

A good match! So, let’s apply the pattern, right? Well, maybe. Let’s look at the Daily Scrum pattern position on the Product Organization pattern language. 

Scrum Pattern language product organization

You can see the location of the Daily Scrum pattern in the language. The Daily Scrum pattern has two incoming arrows, one from Sprint Planning and one from the Development Team pattern. The arrows mean that the Daily Scrum pattern refines both of these patterns, or said otherwise: it improves the larger system’s Sprint Planning and Development Team.

To what use is having a Daily Scrum if the team did not do Sprint Planning…? exactly not very useful. The team will improve its performance with the Daily Scrum pattern if it already works from a Sprint Backlog created at Sprint Planning. Sprint Planning is the more extensive system, and Daily Scrum is a smaller part of that system. 

So, before applying the Daily Scrum pattern, the language suggests investigating if you need first to apply the Sprint Planning pattern. If you have not implemented the Sprint Planning pattern already, then do that first. 

Expanding system boundaries

Sprint Planning has an incoming arrow from Scrum Team, an even larger system. 

So, how do you create a Scrum Team? What is the first step? Do you first need a Development Team?, a Product Backlog, or a Scrum Master?, or maybe a Product Owner? When I ask this question to people, they usually choose a temporal approach. For example, they suggest to start with the Product Owner or Development team and then add to make up a Scrum Team. A problem with this approach is a focus on the parts, Product Owner, Development Team, or Scrum Master instead of a focus on the Whole, the Scrum Team.

Scrum pattern sequence

Again the language points you in the right direction. The Scrum Team pattern suggests having a Vision for a Product for your customers and gathering people who can make and deliver the product. After you have that then you might refine the Scrum Team by for example Development Team when you face the problems it solves. Key is that you start with the Whole, the Scrum Team, and only improve the parts if it also improves the Scrum Team.

How to select a pattern?

The initial context and problem statements of the individual patterns help you identify if a pattern could be useful for your specific situation, the pattern language help you identify the sequence of patterns you might need to implement. Usually, my customers discover that they need to move up the language graph and create a pattern sequence. In the next blog I will explain how to create a pattern sequence to use in your specific context.

Want to know more?

I will be regularly writing more blogs about Scrum patterns. If you want to keep updated you can register for the newsletter here, or just keep an eye open on social media.

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

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.

Want to know more?

I will be regularly writing more blogs about Scrum patterns. See part 2 and part 3. If you want to keep updated you can register for the newsletter here, or just keep an eye open on social media.

In my next blog, I will discuss how to find patterns to apply and how to use the Scrum Pattern languages.

On September 21, Cesario Ramos gave a talk about Scrum Patterns at the Agile Rocks conference in Kiev. You can see the recording of this talk here. Enjoy.

On September 12 2019, we ( Nadine, Joris, Vaishal and Cesario ) provided the keynote at the LeSS conference in Munich. We shared the story about how we improved the Spotify inspired ING model with LeSS. My friend Rowan Bunning was present at the keynote and wrote a super nice summary of the talk. You can find his blog here.