When Scrum Teams discuss too many problems during the Retrospective they may lose focus. That results in shallow decisions that barely scratch the surface. Teams are disappointed and lose faith in the Sprint Retrospective. Let’s see how to improve the event with the Scrum Patterns.

Too Many Improvements Uphold New Challenges

I want to share a story of the Scrum Team I have been working with as a Scrum Master long time ago.

There were too many problems the Scrum Team had accounted for. And there was a pressure to cover all of them during the Retrospective timebox. Therefore, the time spent per item was not enough to conduct in-depth analysis and investigate the underlying causes. Not surprisingly, the quality and depth of the improvement experiments were low. The problems did not go away and stayed over many Sprints. In fact, the number of challenges increased as the chronic disability to improve was a problem itself. From Systems Thinking perspective the Scrum Team got into the vicious cycle (see in Figure 1).

Decreased Team Commitment

There was also one more issue. Discussing too many problems and improvements did not generate enough commitment for the team during the Retrospective. There was not enough time for the team to achieve consensus. Therefore, the actions and follow-through suffered from lack of collective energy and were not implemented. That is how the second vicious loop was created (see in Figure 2).

It turned out through the years that I was not the only Scrum Master who made these mistakes. Let’s see how Scrum Patterns might help to improve the situation.

Improving Sprint Retrospective With Scrum Patterns

The Scrum Patterns are typical solutions that were applied to the well known problems around the globe in different organizations and teams. A pattern is an instruction to shape something we build to increase the “Wholeness of the Whole”. Let’s see how we can improve the wholeness of the Sprint Retrospective. If you are not familiar with the Scrum Patterns yet, the following articles may guide you:

In Figure 3 you can see one of many possible sequences that could be created with Scrum Patterns.

I will put a short description of each of the selected patterns below:

  • One Step at a Time. Attempt one improvement at a time, incrementally.
  • Impediment List. Make all non-trivial issues visible with an Impediment List; raise them up to the right people in the organization for resolution.
  • Involve the Managers. Sustain a management function that can act from a position of power to initiate, and take responsibility for, radical changes in the organization, and deal with impediments that may be too weighty for the ScrumMaster or Product Owner in the Scrum Team.
  • Scrumming the Scrum. Identify the single most important impediment at the Sprint Retrospective and remove it before the end of the next Sprint.
  • Testable Improvements. Write improvement plans in terms of specific concrete actions (not goals) that the team can measure objectively to assess whether the team is applying the process change. 
  • Kaizen Pulse. Alternate periods of controlled velocity with spikes of process improvement.
  • Happiness Metric. Drive the improvement process with a single, small improvement at a time, chosen through team consensus. Pose a question to the team that helps it reflect on which of the alternatives on the table will best tap into their collective passion or sense of engagement, and use the answer to choose the kaizen that will most energize the team.

Remember that there are no “wrong” or “right” pattern sequences. Occasionally a pattern or a sequence doesn’t work as expected, and it makes sense to try another one or to try patterns in a different order. Follow the principle to refine the largest “wholes” first and then proceed to the smaller ones.

How would you use Scrum Patterns to improve the Sprint Retrospective? 🙂

How to start an Agile transformation? What are the initial steps? In this article I explain how transformations could be planned using Scrum Patterns and systems thinking.

Study Organizational Context

Any collaboration with an enterprise starts with an immersion in organizational context using Gemba Walks and Go See approach. Observing how teams work, collaborate and conduct their regular events is crucial in understanding patterns of behavior that exist in an organization. Why is that important? System structures reside behind the patterns of behavior and they are the main focus of Scrum Master intervention. Go See results are usually collected in a report that includes observations, description of the discovered system structures, and recommendations.

Take a look at the excerpt from one of the Go See reports:

The product group consists of 16 Scrum teams. They are component teams made narrow specialists who work in “their” components. There are 16 “Product Backlogs” and 16 “Product Owners”. Customer features usually involve a large number of components. Work at the product level is not evenly distributed across all teams, so some of them are overloaded, while others are forced to make themselves busy with less important work. Features are eventually delivered to the market in 5-10 Sprints. Features usually span over multiple Sprints due to dependencies between teams.

How to start a transformation if the final goal is creating an adaptive organization? Before answering the question, let’s get back to the basics of systems thinking.

Car as a System

A car is a deterministic system consisting of three parts: a body, a chassis, and an engine. If we look at the chassis gear then it, in turn, includes smaller systems: a frame, suspensions, axles and wheels

Larger systems contain smaller ones and cannot function properly without them. It can be said that smaller systems “improve” or “refine” the larger systems that they are part of.

In order for the minimum version of the car (MVP) to move and fulfill its functions, the interaction of the body, chassis and engine is necessary. You can refine the car with the golden rims, but this will be a less important improvement from systems thinking perspective. Without an engine, the car will not budge.

Scrum as a “Product Organization” And a “Value Stream”

Scrum can be viewed as two interconnected systems or two “wholes”. The first one is the product organization. It establishes the relationships between people and teams. For example, the Scrum Team and Stable Teams are the patterns from the product organization language.

Picture from “A Scrum Book”

The second “whole” is the value stream that structures time. For example, Product Backlog and Product Backlog Items are patterns that are commonly used in order to achieve a product Vision.

Picture from “A Scrum Book”

Both systems are highly dependent on each other. In practice, it is worth simultaneously build both “wholes” to maximize the benefits of Scrum. Two forms of Scrum, as in the case of a machine, form a system of nested patterns. They visualize the relationships between patterns and suggest the order in which they should be applied. 

The general principle is refining larger system first and focusing on the smaller ones later.

Product Organization Pattern Language

The product organization language starts with four sequential patterns: The Mist, The Spirit of the Game, Fertile Soil and Conway’s Law. Then it diverges into parallel nodes (patterns): MetaScrum, Involve the Managers, Scrum Team, Birds of a Feather

If you look at the product organization language you may notice that it incorporates five levels of nested patterns, if we count from the Conway’s Law level. Each pattern is a system and is a part of the larger system. Let’s investigate the Happiness Metric metric: 

The greatest impact at the product organization level can be achieved when we focus first on improving larger system, and only then improving the smaller ones. Maybe Happiness Metric is not the first pattern to start with when transforming an organization. If you don’t have cross-functional (Cross-Functional Team pattern) Scrum Teams and management support (Involve the Managers pattern) maybe you should focus on something more critical first.

Planning an Adoption

Let’s get back to the excerpt from the Go See report. Teams are organized around architectural components, functions, and internal business processes and are so called component teams. This structure and its associated patterns of behavior and trends (dependency management, long release cycles) can be solved by the pattern Conway’s Law, which implies transition to product teams and the creation of an adaptive organization.

Conway’s Law pattern in short:

  • Problem: effective communication and feedback are at the heart of effective complex system development, and the organization structure should be optimized for the most crucial paths of communication. 
  • Solution: organize the workforce into Small Teams of more or less five people, partitioned according to the most important concerns for the creation of value by the enterprise. Supplement this structure with a small number of cross-cutting structures for secondary but important concerns, never forgetting that these structures are only optimizations in what is otherwise an open environment of unconstrained cooperation. 

What other patterns could be helpful in transition to product teams as Conway’s Law states? Thoroughly investigating the product organization language you could come with the following start-up pattern sequence: 

In order to create an adaptive organization you choose the Conway’s Law pattern first. Then it’s critical to get management support and thus you Involve the Managers. After that you create the overall Product Backlog, analyze it and define the Value Areas. Next step could be creating the best possible Cross-Functional Teams и starting up the Birds of a Feather. And this is just the beginning of the transformation journey.

Avoid Local Optimizations Whenever Possible

Recently I had a telephone conversation with the managers of one foreign bank. The initial request was to support the launched Scrum Teams and mentor Scrum Masters. The simplest thing that could be done was to negotiate the price and fill up their request. But it would be incorrect and unethical from my side to propose a solution without understanding the underlying issue. An express assessment that followed showed that what managers asked would be a local optimization. Agile transformation in the bank had much more serious challenges. Supporting teams and mentoring Scrum Masters would not be the best possible solution from systems thinking perspective. 

Scrum Values Create a Breeding Ground For Systemic Optimizations

Adhering to Scrum Values (Fertile Soil pattern) creates a breeding ground for the creation of the product organization. Scrum Master guides and leads by employing Scrum Values.

The job of the Scrum Master is to propose systemic solutions that solve the fundamental problems of the organization. Avoid local optimizations whenever possible. In order to do this, the Scrum Master relies on the Scrum Values. This is a touch job, but demonstrating courage and openness continuously, the Scrum Master creates the crucial transparency for everyone involved in the transformation. Thus, it becomes the basement for future changes.

Main Ideas

  • Scrum can be viewed as two interconnected wholes: one looks at structure (“product organization”), the other looks at time (“value stream”).
  • The general principle is to refine a larger system first and focusing on the smaller ones later.
  • Adhering to Scrum Values (Fertile Soil pattern) creates a breeding ground for the product organization.
  • The job of the Scrum Master is to propose systemic solutions that solve fundamental problems.

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.

Practices are actions to deliberately get a certain result. Each practice has been developed to try to achieve a specific goal or mitigate a risk/problem, In software development, practices are used all the time. Some teams use Behavior Driven Development which helps to understand what to build, while others use Impact mapping to understand why you build the feature, and some use Test Driven Development to build the software right.

In my coaching I noticed most of the teams do not actively try out new practices. Most teams look for improvements in retrospectives where the suggested improvements are usually around their current practices. This implies the team knows the practice already. Trying out new practices is beneficial for these teams especially in practices areas the team does not consider.

There are three possible reasons why teams find it hard to adopt new practices.

  • Teams don’t get triggered to search for a new practice 
  • Teams don’t know when to use which practice.
  • Teams don’t know the available practices

To address these points we created a workshop. In this workshop, the team creates an overview of practices they currently use on the Product Practices Canvas. Then they uses that overview to assess where they are underinvested and can possibly adopt new practices to improve their performance. 

The Product Practices Canvas is divided into 5 practice areas:  

  • IMAGINE IT => Practices that are used to generate product ideas or give insights for product ideas. It consists of a clear why.
  • BUILD IT(create) => Practices to build the product increment to fulfil the business case (the how).
  • RUN IT (collect)=> Practices to maintain the product and makes sure it performs on production.
  • (IM)PROVE IT (insight)=> Practices to prove the business case (the why) will be answered with results, do we prove the business case and do we need to improve it.
  • PROCESS => Practices that are part of the team’s current way of work?

After mapping the current used practices onto the canvas areas, the team has a view of which practices are used in a certain area. Usually, the teams have a lot of practices in the BUILD IT area and only a view in the other areas. An example of these practices are, in the BUILD IT area: Pair Programming, BDD, Specification by Example, code review, etc. And in the IMAGINE IT area Story Mapping and User Stories. 

The next step is to identify an area the team wants to improve and search for practices that can be applied. A useful way is to explore, what is slowing down the team. 

For the teams to be inspired and have an overview of the popular practices that could be applied we have created a deck of 50 practice cards with a brief explanation that will help teams to decide how and if this practice can serve them. The workshop ends when the team finds one or more practices they understand and find safe to try in their team.

Examples what was discovered during this workshop were: 

  • The team found it difficult to develop the right product? 
    • The practice they started was Impact Mapping.
  • A different team found out that they don’t have good insight into how satisfied the customers and stakeholders were?
    • The practice they started was a Sprint Review with stakeholders and customers. They also started by adding logging to collect user statistics.

To order the product practices canvas for your team. visit http://productpracticescanvas.org

In this article, we will be sharing an example of organizational coaching, in which we successfully applied the Systems Thinking approach. We were working with a service organization and found fundamental solutions to several chronic problems. We believe that effective organizational coaching is not possible without Systems Thinking.

Why Systems Thinking

Large organizations are complex social systems. Although the causes and effects are not obvious, possible solutions are found in the most unexpected places.

Systems Thinking recognizes mental models and structures in work and in everyday life. It reveals the reasons for chronic problems in complex organizational contexts. It is an important thinking approach for creating a general picture of reality, by means of engaging individuals with different viewpoints. 

In one service organization

Recently, we worked with a group of Scrum Masters in a large service organization. During multiple interviews, we asked how much time they spent on organizational coaching. The Scrum Masters gave evasive answers while agreeing that it was an important part of their job. They complained of a major lack of time. In their words, team activities were absorbing all of their time. 

The company understood the importance of full time Scrum Master role. Each Scrum Master was working with only one team. We became fascinated by their lack of time for organizational coaching, and conducted investigation. Now we are going to share the results with you.

The language of systems diagrams

In this article, we’ll be employing systemic diagrams. They depict the stories of people’s behavior patterns and help observe the whole system. Causal-Loop Diagrams (CLD) are one of the most widespread tools in Systems Thinking. The main elements of the diagrams are:

  • Variables (behavior, condition);
  • Cause-and-effect relationships (direct and opposite);
  • Reinforcing and balancing loops (indicated by “R” and “B” respectively); 
  • Time delay;
  • Quick fixes and non-fundamental solutions (QF);
  • A strong deterministic cause-and-effect relationship (the bold arrow);
  • A short-term cause-and-effect relationship (“short-term”);
  • Mental models (the cloud icon) that stay behind the cause-and-effect relationships.

Now that you are familiar with the language of systems diagrams, let’s have a look at the results of the investigation.

The team’s dependence on the Scrum Master

We observed how the Scrum Masters were working with their teams and discovered that the teams were highly dependent upon them. For example, the Scrum Masters conducted all the Daily Scrums, even though the teams had been working together for more than a year and could have learned to do this themselves (see ScrumMaster Incognito pattern). A Daily Scrum is an event that is for the Development Team. The Scrum Master’s (see Scrum Master pattern) job is to teach their team to conduct it effectively within a timebox.

The teams were also unable to independently facilitate other Scrum events. There was also no discussion regarding how to address impediments or internal conflicts. The Scrum Master was required to participate in everything. 

A Scrum Master has two options: to get involved and solve the issue/problem themselves, or coach their team, making it more self-managed and autonomous (see Autonomous Team pattern). 

The teams and the management regarded the Scrum Masters’ roles as being exclusively to serve their team. The mental model that we came across in many of our interviews was that “Scrum Master is a team level role.” If we visualize the story in the form of a diagram, then we obtain a “Shifting the Burden” system archetype, which explains the dependence on the Scrum Masters. As a result, we get two balancing loops and one reinforcing loop. 

  • B1 (quick fix): the less ability for the team to handle their own challenges the more the Scrum Master’s services are required, the more often the Scrum Master tends to get directly involved, and the problem temporarily goes away.
  • B2 (fundamental solution): the less ability for the team to handle their own challenges the more the Scrum Master’s services are required, the more often he or she makes decisions in favor of coaching the team. In time, the team becomes more independent and shows high levels of self-organization and independence. Thus, it increases the ability of the team to handle challenges themselves.
  • R1 (dependence on the Scrum Master): the more frequently the Scrum Master chooses to get directly involved, the more the team will come to depend upon him or her, and the less likely it is that the Scrum Master will be able to apply fundamental solution B2.

Organizational impediments uphold new challenges

Since the Scrum Masters have been entirely absorbed by the “operational stuff” on the team level, they have not been devoting time to organization coaching. But organizational dysfunctions were still present. They were the reason for many of the team’s challenges, with which the Scrum Masters subsequently had to deal locally. 

Examples of dysfunction might be multiple dependencies between teams due to narrow product definition, coordination between teams, insufficient Product Owner authority, handoffs, and so on. Needless to say, organizational dysfunctions were decreasing the ability of the team to handle challenges themselves. By visualizing this on a system diagram, we obtain reinforcing loop R2:

  • R2: the less ability of the team the more the Scrum Master’s services are required, and the more direct involvement occurs on the part of the Scrum Master, the less time he or she devotes to the organization and to the elimination of organizational dysfunction, which in itself decreases the ability of the team.

An organization’s dependence on external consultants

The organization’s management was employing the Go See approach. Organizational dysfunctions were on their radar. But since, in the management’s mental model, the Scrum Masters were not suited to working with organizational impediments, for many years the company had engaged external consultants to work with top managers and organization. The consultants did not work in tandem with the Scrum Masters and did not develop them (see Scrum (Master) Coach pattern). Thus, in time, dependence upon external consulting arose. Let’s indicate this on our system diagram with the three loops, B3, B4, and R3, which depict the second archetype, “Shifting the Burden”:

  • B3 (quick fix): the more organizational impediments there are, the more the company needs to engage external expertise without mentoring Scrum Masters, which temporarily clears up the issue.
  • B4 (fundamental solution): the more effort to develop Scrum Masters, in time, the more they are capable of coaching the organization themselves.
  • R3 (dependence): the organization is dependent upon external consultants, and a mental model is formed, in which Scrum Masters are not capable of removing organizational impediments.

Combining two archetypes we get the resulting system diagram:

Three steps for change

The investigation we conducted and the resulting system diagram would have been impossible without the three steps for change, which we practice during organizational coaching. It seems that there is nothing simpler than conducting an honest and independent audit and subsequently presenting the results. In practice, however, it is very likely that there will be resistance, since it is difficult for people to accept reality and take responsibility. Evolution has taught us to avoid conflict and social confrontation.

The first step: interviews with the individuals and Go See. 

We had dozens of conversations with Scrum Masters, team members, and top managers. We were present at various Scrum Events (Sprint Planning, Daily Scrums, etc.) We painstakingly noted down any repeating patterns (anything that happens more than three times) in behavior and looked for the system structures that were supporting them. In other words, we delved deeply into the context.

The second step: teaching system thinking and the basic archetypes. 

We conducted several Systems Thinking workshops for everyone we had interviewed. Why was that important? The issue is that we do not recommend you compiling a system diagram yourself and imposing it on people. There is a big difference between the insights that people obtain as a result of creating model themselves and by the one-way transmission of information by an external consultant.

The third step: creating a system diagram and solutions.

After the staff had been taught the basics of Systems Thinking, we gathered them in one room to create a system diagram. We also brought in and presented the most important variables.

The world of large organizations is made ever more complex by politics. Occasionally, the most important question that came into the minds of those in the room was: “whose fault is it?” We therefore created a safe environment, by getting the message across that in social systems there is no blame. 

If you are part of the system, then you are also part of the problem. In a system, everyone is right, but only partially.

By working in small groups, we came up with several versions of the diagram, each of which shed light on the real picture in a different way. The final result of the workshop was the final system diagram that is presented above. Those who took part in the workshop agreed that it depicted precisely their organization. “That’s us,” said one, with a sigh. When people create a picture of reality together, and then a common solution, then they are significantly more inclined to support it. 

Here are the systemic solutions that came out of the workshop:

  • The Scrum Masters are starting to coach their teams in conducting events, resolving conflicts, problem-solving, and facilitation. This is no simple matter, when you consider the teams’ reluctance to do so because of the established mental models. It is important to do this gradually, giving teams the opportunity to make mistakes, but not subjecting them to excessive stress.
  • Scrum Masters are beginning to work in tandem with external consultants in order to learn to work at the organization level and with top management.
  • The company’s management is communicating to the whole organization the message that the role of a Scrum Master is not limited to the teams only.

Key points

  • A Scrum Masters always have two options: to get involved and solve the issue/problem themselves, or coach the teams, making them more self-managed;
  • It is a myth that Scrum Master only works at a team level;
  • One of the essential services of a Scrum Master is a service to organization;
  • Systems Thinking is an important approach for creating a picture of current reality, by means of engaging individuals with different viewpoints;
  • Bring the whole system into a room;
  • Establish an atmosphere of trust;
  • Create a system diagram together and come with a systemic improvement experiment.

This article is about how we improved on the Dutch Bank Spotify inspired model in a tribe.

We work with over 20  teams on our Business Lending product.

We develop our product across 3 sites, with dispersed teams. Each team contains business, IT and operations skills. In this configuration we deliver valuable product for our customers every 2 weeks. We did this by amongst others, adopting LeSS principles to further optimise our Spotify inspired way of working.

So, how did we transform? Read the complete case study.

In Scrum, we strive for cross-functionality, a foundational element in teamwork. However, I experience people having different interpretations and misunderstandings of it. The most common ones are:

1.       You have to be able to do everything

2.       It’s only useful when someone’s on holiday or sick leave

3.       People don’t want to learn other skills

First, let’s look at the definition in the Scrum Guide:

Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team.

In perfect Scrum, we have one Scrum team that has all the competencies to deliver the Product. We’re not only talking about developing and testing, but also sales, marketing, operations, accounting, etc

You might think: “This is not realistic”.

You’re right and that’s fine! It’s a perfection goal that you will never achieve but is still really valuable. It gives direction and guides you in your improvement process.  

Advantages

The main advantage of having a cross-functional team is that it can take on a problem and solve it completely and will never be blocked. 

Other advantages are:

  • Full autonomy and ownership
  • Less handoffs and waste (rework)
  • Shorter feedback loops
  • Increased learning 
  • Increased diversity (better insights, more creativity)
  • Increased engagement of team members
  • Exercising management and communication skills
  • Foster understanding

Misunderstandings

Let’s look at the misunderstandings:

1: You have to be able to do everything

The idea is that all competencies exist on the team level, not on the individual level. So not everybody should be able to do everything. Being specialised in everything is a contradictio in terminis. It still makes perfect sense to be very good in one skill; the difference lies in the fact that you should not limit yourself to that single skill. You should at least be able to do the work of one of your team members, and it doesn’t matter if it takes you ten times longer. This way, you’re not only more adaptable as a team, having an understanding of other skills is beneficial for your expertise as well.
When work calls for an additional individual for each required skill, the team will become too big to be effective.

2: It’s only useful when someone’s on holiday or sick leave

In these scenarios, the benefits are very apparent. Even though a colleague is absent, the work continues. However, it’s not worthwhile to invest in cross-functionality just for these less common situations.

The main advantage of cross-functionality is in day-to-day work! This is because work never distributes evenly. There’s always a bottleneck! Most people see this clearly when having component teams, where a front-end team has to wait for the back-end team. But only a few realise this also continuously happens within the team.

People have to be ready when the work comes in. A tester, for example, has to be ready when a piece of functionality is delivered, or a requirements engineer has to be available when there are questions about the requirements. The teams should work in such a way that there is enough room to absorb variation in demand, again keeping work queues small and, therefore, the ability to react to opportunities high.

3: People don’t want to learn other skills

In practice, a lot of people only develop a single skill. I think this has mostly to do with the organisations they’re working in and less with their willingness to learn a secondary skill.

The majority of current HR policies promote increasing your single skill. It’s challenging to change this to a culture where having multiple skills is promoted, especially when working with external vendors, who have bring their own policies.

Taking these incentives out of the equation, there are three things that motivate people: purpose, autonomy and mastery. A developer loves to write clean code all day and a tester tests (think: mastery). Tap even more into intrinsic motivators by learning secondary skills. This way, the team is blocked less (think: autonomy) and delivers more value (think: purpose).

Conclusion

The team model in Scrum is designed to optimise flexibility, creativity, and productivity.
There are major benefits of cross-functional teams and having multi-skilled team members, which are often underestimated.

… It’s not a matter of believing, but understanding.

More info
Silos game – getting in T-shape (a game to experience the problems with working in silos)
Mike Cohn’s blogpost on the impact of multi-skilled members.

In this article, I will discuss the dangerous dynamic that can arise when a Product Owner, Scrum Master, or the management of an organization focuses a Development Team on velocity.

What does velocity refer to?

The concept of velocity signifies:

The speed at which a Development Team converts Product Backlog Items into a Product Increment that is RELEASABLE.

Pay particular attention to the highlighted word. Feature velocity is applicable when a Development Team can deliver an Increment that is releasable at least once per Sprint. In this case, Done = DoD = releasable. Awesome!

But even in this case velocity does not show:

  • Whether the client’s problem was resolved.
  • Whether team is working on the highest priority problems.
  • Amount of value delivered.
  • Level of client satisfaction.

Velocity only shows that the team was busy with something.

But is this an accurate measure of the success of the products and services? Do the clients value products based on how busy company’s staff are?

To put it another way, Velocity reflects the volume of a Development Team’s output. Unfortunately, this is not enough for the creation of successful products and services.

The feature velocity of component teams = 0

Component teams have the most stable feature velocity. Because it always equals zero. Component teams are by definition not able to convert Product Backlog Items into value for a client. At a minimum they need integration with other component teams.

When a team has Undone work

In my opinion, the most dangerous dynamic arises in cases where a Development Team is not capable of generating a Product Increment that is releasable each Sprint. This means that Done = DoD + Undone and team optimizes just the part of the whole flow.

Let us examine a system diagram that shows the link between the strength of DoD and organizational agility.

The stronger the DoD, the smaller Undone work in the Sprint. Undone work limits the team regarding the number of potential releases, and, as a result, also regarding the amount of feedback that can be received from the market. The more feedback, the more decisions can be made by the Product Owner on the re-ordering of a Product Backlog. That could be called organizational agility — being able to quickly change the direction of a Product’s development. This may prompt a Scrum Team to undertake additional improvements to create an even stronger and more exhaustive DoD.

By strengthening the DoD, velocity decreases and becomes real

How is the strengthening of a DoD reflected in velocity? The velocity will decrease at least in the short term. But this is not a problem if the goal is flow optimization (shortest Lead Time), learning and agility. Velocity decreases and becomes more real!

But how likely is it that a Development Team would strengthen the DoD, if they know that team effectiveness is evaluated according to the velocity?

My answer is unlikely. Focus on velocity keeps the team away from strengthening their DoD. As a result, that inhibits feedback from market, learning and agility.

Focusing on velocity inhibits organizational agility.

When I was a young and an inexperienced Scrum Master many years ago, I focused my teams on velocity excessively, which reduced their agility and increased the amount of Undone work. Nowadays, my advice to Scrum Masters who are just starting out goes something like this:

Forget about velocity, if your team cannot produce an increment that is releasable at least every Sprint. Focus on strengthening your DoD first.

What should we measure then?

I recommend focusing on metrics that show the ability to deliver actual value to the market and satisfy client’s needs. For example, Scrum.org has developed framework Evidence-Based Management, and is offering a range of metrics that shows:

  • A team’s ability to create value in the long term
  • The speed at which value is generated (Time 2 Market).
  • How much actual value is delivered to the market.

In conclusion

I would like to repeat once more the fundamental idea that I want to convey with this article. The basic idea of a Scrum is to create an increment that is releasable at least every Sprint. If your team is already at that stage, then the concept of velocity is useful and genuinely demonstrates the speed at which a team converts Product Backlog Item elements into an increment. If not, please focus on strengthening Definition of Done (DoD) and flow optimization.

The Article’s Main Ideas

  • Velocity denotes the speed at which a Development Team converts Product Backlog Items into a Product Increment that is releasable.
  • Velocity does not show whether clients’ problems are being resolved, nor whether value is being delivered, as reflects volume of output.
  • Velocity only shows that a team was busy with something.
  • The feature velocity of component teams is always zero.
  • When team focuses on velocity and has Undone, it is unlikely they would strengthen the DoD.
  • Focusing on velocity inhibits organizational agility.
  • Focus on the value that is actually delivered to the market.

Scrum ON!


In this little blog I share some tips for multi-team Product Backlog refinement.

What is Product Backlog Refinement?

Product Backlog Refinement (PBR) is an activity that Scrum Teams regularly do to clarify potential upcoming Product Backlog Items (PBI). In single team Scrum, typically the Scrum Team gets together for one or more workshops during a Sprint to create and maintain a Refined Product Backlog

Below some example activities you can consider:

  • Understanding what is the right problem to solve: The Product Owner tells a coherent set of stories with a goal and links them back to the business objective. The team discusses “why we are doing this?”, “how do we know we are solving the right problem?”. Some teams use story-maps, impact-maps, Speedboat, Me and My Shadow, or the 5 Whys. 
  • Splitting big items for discussion and learning
  • Estimating items for learning and alignment
  • Understanding Customer needs: The team discusses “Why does the user want this?”, “Are we solving the problem right?”. Some teams use a Storyboard (before/after) and Pain Gain maps.
  • Clarify Items: Some teams use Specification By Example and create acceptance tests for the user stories; use story narratives with Gherkin specifications, flow tables and/or decisions tables.
  • Define Exploratory Test Charters: Identify risks to target; Identify which features need manual testing. Some teams use exploratory test charter for each and use exploratory testing tours to test as a team.
  • Create initial designs: Modelling at whiteboard, design sketches,…

( see our paper in Testing Experience magazine for some more examples ) 

Teams that work together on a single product can benefit from doing multi-team refinement. But how can you do refinement with multiple teams at the same time? And why should you?

Why multi-team refinement?

Multi-team PBR is when all members of all teams refine PBIs together without yet deciding which team will implement which item.

Below you can find some benefits that multi-team refinement can give you: (there are many more benefits, but that would make this blog too long)

  • Adaptability at the product level. Why? because all teams understand all PBIs on the Product Backlog, instead of each team understanding only ‘their’ PBIs ( a subset ) of the Product Backlog. If all teams understand all PBIs then the PO can put any PBIs she seems most valuable at the top without being constraint to the PBIs a particular team understands.
  • Improved self-coordination: Why? because the teams maintain a broad understanding of the whole product and the upcoming PBIs, and therefore are more likely to know of “dependencies” between PBIs.
  • Transparant measure of progress at the product level. Why? because all teams participate in estimating all PBIs and therefore there is one common velocity at the product level, instead of a distinct velocity per team that needs to be combined into a total.

How to do multi-team refinement?

The activities for single team refinement can also be used with multi-team refinement; the biggest change is in the facilitation of large groups.

I like to create new groups from the teams that participate in a refinement session instead of using the regular teams. So, let’s say that there are four teams A, B, C and D. Then at refinement, I ask the teams to form four new groups, each group consisting of a person from team A, B, C and D. Why? With groups consisting of members from each team, all PBIs are refined by at least one person of every team. This creates a shared ownership and broad understanding about the PBIs.

Multi-team refinement formats

When I work with teams, I show the teams 4 ways of doing multi-team refinement so that the teams can then choose the way they like most to continue with and improve.

I work with the following 4 formats:

0. Full Roulette

Each group picks a PBI for refinement and start refining at their station. After a timebox -I like 15 min timeboxes- all groups move to the next station and continue refining where the other group left off; this is continued until the PBIs are refined or the workshop timebox expires. The groups can use whatever technique the like for refinement. 

The full roulette results in good refinements because the groups feel pressure to leave their work clear and understandable as possible for the next group.

1. Partial Roulette

Just like Full Roulette, but instead of the whole group moving to another stations, 1 person stays at the station. This person then teaches the new group what was discussed before they continue with refinement.

I use this approach in the beginning because is that it is easy to start with. After the teams have experienced this Partial Roulette, I encourage them to try Full Roulette.

2. Diverge and merge

In this approach, the groups do a diverge-merge action after each timebox. One person stays at each station and becomes the teacher. Then all groups send a person to each of the other stations. So, let’s say you gave groups A, B, C and D. Then 1 person from group A stays at the station to teach back and 1 other person visits group B, another group C and another group D.After the teach back, the persons return to their original group and share their learnings. Any puzzles, questions are then discussed as a group.

I have worked with this technique with up-to 35 people or so.

3. Teach Back

Each group picks a PBI and refines it. After the timebox is over, each group teaches their work so far back to the other teams and have a Q&A discussion. 

This technique works not so good with a large number of teams, because the teach backs easily take too for long for big groups, and its harder to have a focused discussion with lots of people.

Role of the Product Owner and Customers

During the refinement sessions the Product Owner (PO) and customers play an important role. The Product Owner has to be prepared and understand what is needed from the business perspective. The PO will discuss overall topics at for example a Storymap and also participate in each group when requested. 

You also would like the end-customers or people closest to the end-customers like sales, helpdesk etc to participate in detailed refinement sessions.

The approach I like the most and have seen be most effective is the Full Roulette. If you decide to try any of the above approaches, I would enjoy hearing from you how it worked out.

Back in the early days of Scrum, the Scrum Master role was exciting. The days of the pigs & chickens, the days when being a Scrum Master was considered dangerous.

In those times there was the saying

a dead Scrum Master is a useless Scrum Master 

And even today I still use that when selecting a Scrum Master to work with. 

If you never got fired as a Scrum Master then you probably did not show enough courage to achieve breakthrough improvements.

Scrum Master as a Sheep Dog

As a Scrum Master you would work with the Product Owner on value; coach management on organizational design; and work with the Development Team on self-organization and technical excellence. The Scrum Master would strive for the team to put the product into the hands of the customer every Sprint. It was natural to work on test automation, code quality and deployment. If the Scrum Master would catch a project manager sneaking in from the back, breaking the rules and disturbing the teams, the Scrum Master would go for a frontal confrontation, or as Brian Marick once said:

“the Scrum Master would rip out their throats”. 

The Scrum Master would ensure everyone remained moving in the right direction by challenging, facilitating, teaching, intervening and cajoling. 

Scrum Master as a Lap Dog

How times have changed.

The Scrum Master role I see these days is more that of a lapdog; just like the lapdogs that Paris Hilton carries around in her fancy bags

—sit down, roll over, good boy, have a biscuit—

The Scrum Masters I too often see, are nothing like a Sheep Dog. There are the part-time Scrum Masters: for example testers or programmers who next to their full-time job, also move some stickies around in JIRA during the Daily Scrum, and run a retrospective once in a while.  I see Scrum Masters that represent the teams at the Sprint Review; are the spokesperson of the team to management; Scrum Masters that drive Sprint Planning using JIRA (Agile is spelled differently these days, it is spelled J.I.R.A.) and Scrum Masters that order the Sprint Backlog. 

On top of that, there are Agile Coaches, Agile Coaches are everywhere. Where do all these Agile Coaches come from? and why do you need one? After all, an Agile coach basically does all the same things a good Scrum Master should do. Maybe an Agile coach is just a Scrum Master with presumed better overall skills and therefore wants a better daily rate. 

All this is removing the true spirit of the Scrum Master; the Scrum Master role is going from Sheep Dog to Lap Dog.

The feedback loop on Scrum itself

The Scrum Master is a change agent, a team builder, a servant leader, an innovator and inspires for greatness. So, please do not forget the true spirit of the Scrum Master. You as the Scrum Master, you are the feedback loop on Scrum itself.