De investering voor deze training is Euro 2495, – ex BTW en Euro 2095, – ex BTW voor vroege vogels tot 1 maand voor de start. 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 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.

Over the last weeks I’ve been working on a paper about the role of a Business Analysts within Large Scale Scrum, and I thought I’d write a little post on it too, here it goes.

On the website of the IIBA you can find their definition of a Business Analyst.

liaison among stakeholders in order to understand the structure, policies, and operations of an organization, and to recommend solutions that enable the organization to achieve its goals

www.iiba.org

In a Large Scale Scrum organization this definition often results in Business Analysts working as a liaison between stakeholder and the teams. And this liaison role turns out not to be very effective at scale.

A business analyst is not the same as a Product Owner

We know that there is only 1 Product Owner for a product, see the Scrum Guide; but in Large Scale Scrum adoptions, you often see lots of Product Owners although only 1 product is being developed. You can expect to see that each Development Team has its own unique Product Owner (PO) and that a BA plays the PO role. This is an understandable and easy step to take for an organisation; all you have to do is change the role name from BA to PO.

All these BAs stay a liaison between the Development Teams and the customers. And the liaison role introduces unnecessary hand-off; documentation; information scatter; and poor customer understanding by the teams – see my paper Copy Paste Scaling for more details on this.

A BA can play the role of a PO if she has the right market understanding, skills and mandate; but it is generally a bad idea in Large Scale Scrum to have a separate BA play the role of PO for each Development Team. Instead keep it simple, have 1 PO and create true cross-functional teams. 

From recomending to developing

A BA with a responsibility for analysis alone does not work anymore and the reason is simple: Analysis is not something that adds customer value on its own; it is just one of the activities in the end-to-end value chain. So you would like to avoid locally optimising Business Analysis. Instead you would like a BA to be responsible for delivering working product and that they directly work on validation and implementation of the product.

These days it is essential to validate assumptions quickly. Answers to questions like:

  • Are we solving the right problem?;
  • are we solving the problem correctly?;
  • and does the solution add enough value to us?

 requires frequent feedback. 

Therefore, you would like to have a BA as one of the Development Team members, just like a programmer, tester or domain expert are too. Now, the BA can use its expertise, which is essential for success, more effective and help to optimize the whole of product development.

As a Development Team member the BA:

  • keeps a focus on the end result;
  • can see if ides actually work;
  • can adjust rapidly if ideas do not work;
  • can easily share his expertise with the rest of the Development Team;
  • and can take the lead during refinement sessions. 

So, if you want to optimise for speed, agility and learning, it is probably better to have a BA be part of your Development Team and not be a fake Product Owner.