De Professional Scrum Product Owners hebben begrip nodig van alle zaken die waarde toevoegen aan hun producten. De Product Owner training helpt deze kennis te ontwikkelen, van stakeholder management tot release planning en delivery

Meer details van de Product Owner Training.

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 your organization, some problems seem to recur, they are difficult to fix using the tools, tricks and practices you developed over the years as a manager. Maybe this problem is different and the perspective of an expert-outsider might help?

At Agilix, we regularly get asked by companies “to discuss some challenges with Scrum”. This is a great compliment for us and it is exciting to submerge into these unknown worlds, being totally blank, without prejudice and mandate; simply bringing knowledge and experience. It feels like being a “Flying doctor”, and yes, we love it!

Let me tell you a bit more how the “flying Scrum doctor” operates….

Intake

The first conversation a Scrum doctor usually has is a one on one with the manager. She starts with giving the context of the problem. It’s time to listen and try to build a mind-map of the problems, company structure, their product and customers, the teams, processes, solutions they tried before but did not work, etc. Towards the end of the conversation questions are asked to verify stuff, because we need to validate the collected data. To get a clearer picture of the problem, data has to be collected from the people in the teams and from management above the hiring manager.

Diagnose

We need to talk to lots of people, remembering their names and roles, smiling, listening carefully, trying to store everything that can be captured. Especially the things that are not so obvious; like the people not talking and nonverbal communication. It’s a bit like you are the new employee and you must meet the whole company at your first day at work. The difference is that we are on a mission: There is a pain that needs to be diagnosed and these people need help to find a cure. My personal preference is to work my way through the organization bottom-up, i.e. I want to talk to the teams first.

The problems we investigate are always systemic, if not, they would have been solved easily by the hiring manager. This also implies the intervention will probably not be found in the area where the manager thinks the problem lies. We observe the company as if it were a system, a living organism and try to understand what is really going on. Therefore, we need to collect input from different angles and layers across organizational boundaries and share all the things we learn and ask a lot of open questions. By doing this, people discover themselves how their system works and which part they play to keep the system in its current state. With the right people communicating at the right level (management and team representatives), good insights emerge and decisions to start or stop doing things to intervene in the system are easily taken. A condition for this approach to work is that all participants can communicate in a safe and transparent way. If not, we would not be addressing the true root causes.

Preparing the teams

Once an intervention has been identified and agreed we need to inform the teams and get them on board for a change. We all know from experience that change is difficult. Well is it? Really? I have learned it is not. Think about it: Did you ever move? Or did your get a new haircut? That is change too, and you did not mind at all! But if your wife tells you you must change your hairdo, it becomes a whole different ball game. Conclusion: Change is not difficult at all as long as it is voluntary.

Therefore, we need to get the change emerging from within. For this we need to ensure everybody gets the space and time to discover the system dynamics themselves and to contribute to the solution. Voluntary participation creates ownership of the change. This empowerment increases the chances of a successful change. We get all people involved by organising one or more discovery sessions in which teams go through the same motions we experienced when unraveling this mystery ourselves.

Preparing management

Some managers automatically assume that once a solution has been discovered, they need to communicate it to the teams. We need to ensure this knee-jerk reaction is gently suppressed. In other cases, management fears that the teams will not come up with good solutions and team empowerment is seen as a possible threat. In such cases it requires persuading management and informal leaders to agree on the principle of voluntary change. They need to learn that the solution they crafted so far will get better when it is discussed with all people involved.

Treatment

To solidify empowerment, we want to find people to facilitate the discovery sessions with the teams. These are not the managers, but volunteers from the teams (might be the informal leaders). In order to facilitate well, they need to know what the key principles are of the solution, for example: more flexibility, fulfilling work, learning, etc. By understanding the key principles, they will be able to guide discussions that will emerge during the discovery session(s). The details of the final solution less important than everybody understanding what is needed to fix the problem.

Conclusion

When you try to unravel and solve complex systemic problems, gather lots of data, be curious, cut across organizational boundaries. Understanding that problems are systemic and therefore that there are multiple root causes is essential. Involve all people that appear to be related to the problem and make those who are in power aware of their possible contribution to both the problem and the solution. This awareness is what people lack. Change is easy as long as it is voluntary, so engage people in the change by offering them the opportunity to discover how their system works. Remember to love the problem, not the solution. The solution will become better when more people contribute to constructing it.

Besides coaching and writing blogs, I also teach Scrum. Maybe you want to join my upcoming PSM-2 class.

Intended audience: Scrum masters, Product owners, Managers and Agile coaches.

I was working with various groups over the last year and noticed some commonalities in the problems they faced. In this blog I want to share some common collaboration problems and solutions I experimented with

1. Lack of product focus

The lack of product focus is related to a series of underlying product related problems. Firstly, there is often no clearly formulated vision, or a missing plan on how to achieve a vision. The PO’s are then unsure what needs to be developed. Secondly, there usually are too many PO’s having difficulties to align. People then volunteer to fix these problems. For instance, a lead developer or architect prepares the work for sprints ahead, acting as a proxy between the teams and the PO’s, splitting the requirements in tasks per team. Thirdly, I see multiple over-complex jira-backlogs and lastly there is lots of non-product related work on these backlogs.

I advise to start finding one person to be the single Product Owner for all teams. The other “fake PO’s” should be moved inside the development teams as subject matter experts so they can provide detailed requirements. I avoid having the “we are all dev-team members” discussion and let them keep their business title such as “Product Manager”. The Product Owner should develop an inspiring vision and a plan to make it happen. This plan needs to be communicated to the teams by the PO. Consolidate the work into one single Product Backlog with a view for each team. Aim at a visual representation of the work on an office wall representing the single source of truth.

A single source of truth

2. No Release management

Delivering working software is perceived as an IT responsibility instead of a Business-IT collaboration. Many teams are component teams and planning and managing releases with component teams is hard. The content of the release is not understood by the business, and there is an atmosphere of continuous disappointment. To get more grip on delivering value predictably, I advise to first move the focus from component-, towards customer-centric features. This is not a big problem if your teams are end to end capable, but have component responsibility. It takes a couple of iterations for Business and IT to collaborate on defining properly sliced features and to optimise the sizing of a releasable feature. I was successful with optimising for feature size that could be delivered in a two-sprint cadence. The features need to be split and made smaller until the group thinks they can be delivered in two sprints. This approach is ideal to get a cadence from the influx of new features to done, closing the empirical process control loop from design to delivery.

Be very strict on the administration of releases (in Jira) creating a 100% transparency on which items are in or not in a specific release. Ensure Product Owner(s) see the relevance of monitoring the scope and progress. This provides a simple cross-team progress monitor

3. Poor collaboration between business and IT

In many organisations, there is a very thick invisible wall between Business and IT. I’m sure you have “seen” it before (lol). Two worlds that do not speak the same language and do not communicate at a constructive level. The Business sees IT as an necessary evil where simple ideas become difficult and expensive. Business strategy to mitigate development cost often is many months of preparation with UX before handing off the designs to the IT teams. The waterfall smell is everywhere. The IT teams are not involved in the exploratory phases at all for obvious (business) reasons. Hence, they feel excluded because a solution is thrown over the wall onto their desk. IT people have a hard time accepting designs containing impossible combinations of data and illogical flows, so they start (angrily) asking critical questions. A stance that is answered by the Business people with irritation and disbelief. My approach here is placing the UX-ers visible at desks close to the teams, make the “fake” Product Owners members of the development teams and involve everyone in ideation. Connect the dots by making reporting on market research data and customer feedback data a mandatory item of the Sprint Review

4. Component ownership

I see many groups building and supporting components in dev-ops teams. Teams inherit support responsibility for “old” components and dev-ops is “the way to go”. However, it creates work on the backlog that is not related to the new product initiative and slows the teams down. The solution is to transfer all work that is not directly contributing to the new product increment to a team outside the product group. Interestingly, I experienced that this intervention initiated a new discussion about decoupling teams and components for operational responsibilities and moving ops-responsibility to group level, making everybody responsible for all components. The underlying conflict was that the teams were not willing to provide operational support on each other’s code, because there was no common coding standard and agreed DoD at group level. This dynamic is very common for component teams.

To create better cross-team collaboration, create a common minimal DoD. Also have each team define their team norms of conduct and organise a workshop to create cross-team working agreements. Stop working in feature branches and work directly on master. This will open up all code for all developers to understand and change. This requires the teams to be prepared to collaborate and to agree on standards. I can recommend to approach the lack of coding standards via the concept of “damage control”: For teams to first protect “their” code, “foreign” code changes were monitored by each team. The teams all created a list of emerging technical debt on their component. These were changes on “their” code that was not in line with “their” (unwritten) coding standard. Note that the list of technical debt is the exact opposite of coding standards. After each sprint, the technical debt issues were discussed among the teams which resulted in an emerging common coding standard

5. Unsuitable communication practices

Last but not least, watch out for delegated meeting cultures. Delegated meetings is a practice which is based on the assumption that it is more efficient to send a delegate to meetings instead of having the full team participating. This practice is used to fight the “too many meetings problem”. However, this communication structure has downsides. It requires to bring the information back to the teams, which either does not happen or happens but the information is filtered or (mis)interpreted. This is not a helpful practice because it requires good participant scheduling, is time consuming, causes information scatter, lowers productivity and creates misalignment.

On the other hand, killing meetings is hard to do. The belief is that meetings are there for a reason. I start with challenging the teams to try to improve non-valuable meetings, and ultimately stop attending them if that did not work. By consequence non-Scrum meetings will die out. In parallel make everybody in the group participate in the majority of the valuable meetings, rather than having sub-meetings with delegates. Also create more suitable alternatives for “bad” meetings rather than killing them. For example, a top-down driven architectural meeting will lose its value in favour of multi-team design sessions during refinement. In the refinements, the lead architect will serve as subject matter expert to advise the teams. Note that good facilitation techniques (diverge/merge and the likes) are a required Scrum Master skill to handle sessions with larger groups.

our 2-sprint meeting flow

When you want to improve the collaboration between multiple scrum teams, you will benefit from verifying the performance of these areas:

  • Product focus: is there one Product Owner and do we know where we are heading for?
  • Delivery abilities: do we know when we will reach or next goal?
  • Business-it alignment: do we all speak the same language and serve the same goal?
  • Team responsibilities: are the teams setup to do what we expect them to do?
  • Communication practices: does the way we communicate support our goal?

If you would like to hear more details or learn about other Scrum-related issues, contact me or join one of my upcoming classes.

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.

This article is directed to all who think that being a Scrum Master is inferior, and therefore think (ab)using the term “Agile Coach” is justified.

Note. A serious warning before you read on: If you consider yourself to be an Agile Coach and you are not up to digesting some painful transparency about your role, please stop here.

OK, so when you read this line, I have captured your attention, which means the agile community might be one small step closer to transparency. Thank you for giving me this opportunity. I want to reward you with the management summary: “We should re-establish the title of Scrum Master to stop the proliferation of oblique role nomenclature. Our professionalism demands this from us; We need to practice the transparency we preach.

Last week I was running a series of interviews trying to find an experienced Scrum Master for a company I am currently working with. They want to scale, and as per my advice we started looking for an experienced Scrum Master to service their teams. We were looking for high calibre candidates. The Scrum Master I am looking for has to be experienced: A person who understands what’s not in the Scrum guide, has empathy, understands the trade off of “not now”, who supports the PO, can deal with 3 to 4 teams, a master in the art of “doing nothing”, a sheepdog that knows how to be loved and trusted and a little bit feared. In other words, I am looking for a REAL Scrum Master. My high standards do not seem to be a problem: Looking at the pile of resumes we got, I was baffled: mainly Agile Coaches applied for the job. 

Looking back at these candidates and the interviews, I observe that people think the Scrum Master title is too common, too ordinary, too inferior and most of all: too cheap. The title “Scrum Master” does not impress friends at parties. Neither does it resonate inside the Agile community, you’re “just” a Scrum Master, it’s a beginners position. Whereas the term “coach” impresses everybody and radiates seniority. 

Friends Agilists, we need to stop this. We need to practice what we preach. We have the obligation uphold transparency in the Agile community, we should not only leave it up to agile institutions to verify true knowledge and experience by certification (like scrum.org, scrum alliance, agile consortium, etc); We need to do more because we are agile.

Firstly, I want to call out to all people that HIRE: Hire a Scrum Master

You stop further deterioration of the title “Scrum Master” by recruiting a Scrum Master when you need one (i.e. don’t ask for a carpenter if you need a macon). You will waste valuable time interviewing them and waste even more employing them. Probably you were tempted to hire an Agile Coach because you experienced the people reacting are mostly Scrum Masters saying they are Agile Coaches, just upping their profile to be invited for the interview. The real Scrum Masters might not apply because your job request is not transparent. Or maybe the reason you are calling out for an Agile Coach is because Scrum says you need one Scrum Master per team and you think that is a waste. It’s easy to do the math: you will pay a bit more for only one Agile Coach, doing the work of two or three Scrum Masters. Here is some news: One Scrum Master can handle multiple teams. So next time hiring, you could try recruiting a Scrum Master and even better, include in your text that candidates using the term “Agile Coach” in their resume will not be invited.

Secondly I need to reach out to all who want to GET HIRED: Be proud of being a Scrum Master.

The title “Agile Coach” is not described in any Agile framework. If you are a rookie and you spiced up your cv to impress HR personnel or head hunters, I hope you will be (respectfully) roasted. The world of Agile Coaches is about money and status. Don’t feed the system with the idea that a Scrum Master is a job of no importance and Agile Coaches are a step up in the hierarchy. This attitude is unethical towards the agile values.

Instead, be open and say you are proud of being a Scrum Master. Show respect to the servant leader management role it actually is. Be courageous towards HR people and explain and teach the aspects of Scrum Mastership. Stay committed to offering opportunities for learning to the teams you dearly care about and to the organisation that employs you. If you are unsure about the complexity of the Scrum Master role, read the white paper by Barry Overveem: http://www.barryovereem.com/the-8-stances-of-a-scrum-master/

Finally, I need to reach out to the Agile community to eradicate this “Agile Coach” virus: Let’s institutionalise this title with proper certification ASAP. Find out more here: http://whatisagilecoaching.org/ and http://agilecoachinginstitute.com/

Am I free of blame? No. off course not. At times I found it troublesome to be a Scrum Master too. I didn’t understand the value of the role either. But after reading this blog, I agreed with myself to reword my linkedin profile title:  Roland Flemm. Scrum Master, LeSS Practitioner and Lecturer.

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.