12. Experiments
Culture is just a shambling zombie that repeats what it did in life;
bits of it drop off, and it doesn’t appear to notice.
—Alan Moore, comic book writer
In This Chapter
• Explore ten experiments to foster and promote self-organization.
• Learn what impact the experiments have on surviving Zombie Scrum.
• Discover how to perform each experiment and what to look for.
In this chapter, we share practical experiments to create more space for self-management by teams and to foster and encourage self-organization for teams and for the entire organization. Although the experiments vary in difficulty, each one makes subsequent steps easier.
Experiments to Increase Autonomy
The following experiments are designed to increase the autonomy of teams, or at least make the lack thereof transparent. Self-organization is more likely to take off when teams have autonomy to come up with their own solutions.
Make the Cost of Low Autonomy Transparent with Permission Tokens
The autonomy of teams decreases as their dependencies on external people increase. Some dependencies are explicit, such as when a Scrum Team needs someone outside the team to do something for them. Other dependencies are more implicit. Having to ask for permission or approval from someone outside the team in order to proceed is a good example. This experiment is about making transparent where and how often permission is required (see Figure 12.1).
Figure 12.1 Without considering all the things that constrain Scrum Teams, it’s easy to expect miracles from them.
Effort/Impact Ratio
Steps
To try this experiment, do the following:
1. Find an empty jar, or another container, and place it in the team room. Somewhere near the Sprint Backlog is the best spot.
2. Give everyone on your team a bunch of permission tokens. You can use marbles, LEGO bricks, magnets, or stickies. Use different colors for the various permission categories. For example, the permission to release something, to move an item to another column on your Scrum Board, or to change your tools or environment. We recommend a limit of five categories to keep things simple.
3. During the Sprint, put an approval token in the jar every time someone on the Scrum Team has to ask permission from someone outside the team. For example, put a token in the jar when an external architect needs to approve that an item is done. Or when the Product Owner has to vet an item with an external manager. Put a token in the jar when you need permission from office management to purchase stickies. And put a token in the jar when you need a configuration to be changed by an external administrator. Aside from requests for permission, also add a token every time you need someone outside the team to perform a specific action as well.
4. During the Sprint Review, and with stakeholders present, share the number of tokens in the jar. Ask: “How does this affect our ability to quickly adapt in the moment and do what is the most valuable? Where can we simplify things?” Invite people to first consider this question for themselves and in silence, then in pairs for two minutes, and then paired with another pair for four more minutes. Capture the most salient improvements with the whole group. The Sprint Retrospective is a great opportunity for digging into potential improvements.
Our Findings
• For another perspective, you can use different colors for everyone on your team. This allows you to identify who is most often in need of permission.
• If you want to focus on the amount of organizational bureaucracy, don’t add permission tokens for requests from direct stakeholders such as customers, users, or people who otherwise invest significant money or time in your product.
• The experiment “Break the Rules!” elsewhere in this chapter is great to test where asking for permission matters, and where it just gets in the way of doing the right thing.
Find Actions That Boost Both Integration and Autonomy
Organizations with self-managing Scrum Teams face the difficult challenge of balancing their autonomy while keeping their work integrated with the rest of the organization. Because both of these aspects are equally desirable, and we can’t simply make an either-or decision, we are faced with what is called a “wicked question.” Instead of letting the pendulum swing entirely to one side, this experiment is about finding ways of supporting both sides. With this approach, you help groups move from “either-or” to “yes-and” thinking. This experiment and its corresponding worksheet (see Figure 12.2) are based on the Liberating Structure “Integrated~Autonomy.”1
1 Lipmanowicz, H., and K. McCandless. 2014. The Surprising Power of Liberating Structures: Simple Rules to Unleash a Culture of Innovation. Liberating Structures Press. ASN: 978-0615975306.
Figure 12.2 A simple worksheet for Integrated~Autonomy2
2 Source: Lipmanowicz and McCandless, The Surprising Power of Liberating Structures.
Effort/Impact Ratio
Steps
To try this experiment, do the following:
1. Invite people who have a stake in either increasing the autonomy of Scrum Teams or keeping them integrated with work done elsewhere. This includes the Scrum Teams themselves, departments they depend on (and vice versa), and management.
2. Begin by helping people make tensions between autonomy and integration tangible. Ask “For the Scrum Teams, where in their work is there tension between the desire for autonomy and the desire for integration?” Start with a minute of silent thinking (one minute), then invite people to share their ideas in pairs (two minutes). Capture salient examples from the whole group (five minutes). For example, there can be tension between the autonomy that Scrum Teams have over their Sprint Backlog and the need to be able to pick up urgent issues from people outside the team that emerge during a Sprint. There can be tension between the autonomy of a Product Owner to order the Product Backlog and keeping that ordering aligned with corporate strategy. Or between allowing Scrum Teams to pick their own tools and having mandated tools that are safe for corporate environments.
3. The next step is to explore actions that promote integration. For this step, the participants work with the Integrated~Autonomy worksheet shown in Figure 12.2. It shows three columns with space for writing down ideas that lead to either more integration (A), more autonomy (C), or both (B). The group will focus on column A first. Ask “What actions boost integration of the Scrum Teams’ activities with what is happening elsewhere?” Start with a minute of silent thinking (one minute), then invite people to share their ideas in groups of four (five minutes). Capture the most salient actions from the small groups on the left side of the worksheet (ten minutes).
4. As a follow-up, explore actions that promote autonomy. Ask “What actions boost the autonomy of Scrum Teams?” Capture them in the right column of the worksheet. Start with a minute of silent thinking (one minute), then invite people to share their ideas in groups of four (five minutes). Capture the most salient actions from the small groups on the right side of the worksheet (ten minutes).
5. Now that you have actions that each address one side of the wicked question, help the group move into yes-and thinking. Ask “Which actions boost both integration and autonomy?” Capture them on the worksheet in the middle. Start with a minute of silent thinking (one minute), then invite people to share their ideas in groups of four (five minutes). Capture the most salient actions from the small groups on the middle of the worksheet (ten minutes).
6. Now that people have experience identifying actions that serve both sides, investigate earlier actions to see if they can be shifted to the middle. Ask “Which actions on the left or the right of the worksheet can be creatively modified to boost both integration and autonomy?” Start with a minute of silent thinking (one minute), then invite people to share their ideas in groups of four (five minutes). Capture the most salient actions from the small groups on the middle of the worksheet (ten minutes).
7. Order actions by their ability to promote both integration and autonomy and identify 15% Solutions for the most impactful ones (see Chapter 10).
Our Findings
• Coming up with specific and tangible actions can be difficult. Keep asking “How would you do that for us?” or “What would that look like here?” in order to move groups beyond abstract ideas and platitudes (such as “more communication”).
• If you have a large group, you can make each group of four responsible for one of the actions you identified during step 2. Let them fill in the entire worksheet in their small group from the perspective of that action.
• You can replace the sides—integration and autonomy—with other wicked challenges. For example, there is also tension between responding to change as quickly as possible and preventing huge mistakes. Or the tension between standardization on the one hand and customization on the other. Work with whatever wicked challenge makes the most sense!
Break the Rules!
Organizations create rules for a good reason. Usually they are intended to protect the company and the people working there from harm by preventing mistakes. But some mistakes are not as bad as the rule that exists to prevent them. Many Scrum Teams are unable to self-organize and act in the best interest of the company because rules get in their way. This experiment is about testing which rules matter. It might sound risky in a big company, but we will help you prepare.
Effort/Impact Ratio
Steps
To try this experiment, do the following:
1. Gather your entire Scrum Team. Identify an action that you are prohibited from taking but that has a clear benefit to your organization or your stakeholders, or would make your team more effective. For example, fixing a bug in the code base of another team or approving a change without asking for permission from a designated manager first might enable your team to fix a problem immediately when you encounter it rather than having to hand it off to someone else. The experiment “Make the Cost of Low Autonomy Transparent with Permission Tokens” elsewhere in this chapter is a great way to find more rules.
2. Discuss what would happen if you broke that rule. What would the consequences be? Does the result justify the means? What would happen to the organization if other teams disregarded this rule as well?
3. Make a plan for what you can do if you break the rule and get into trouble. How would you justify your actions? Is there a way to soften the blow in advance, such as sending a nice email or a box of chocolates?
4. When you are sure that your actions are in the best interest of the organization and the risk is acceptable, break the rule. Don’t break the rule if you’re not sure.
5. If you are successful, gather the team and discuss whether and how it would be possible to permanently change the rule. You can use your actions as an example of why the rule is obsolete. Experiments such as “Share an Impediment Newsletter throughout the Organization” and “Use Formal and Informal Networks to Drive Change” from Chapter 10 can help you get started.
Our Findings
• The goal of this experiment is not to create rebellious teams that disrupt everyone’s work and cause harm, but to challenge obsolete rules that impede success. Don’t choose actions that benefit only your team and not the organization.
• Don’t cause lasting harm to individuals or the organization; choose a gentler way to question the rule than to simply break it.
Experiments to Encourage Self-Organization
Self-organization happens when the people who are doing the work develop their own rules and ways of working to deal with local challenges. These local solutions are more attuned to the challenges that teams face and more likely to work than solutions that are invented by others or copied from elsewhere. But teams often struggle to come up with high-quality local solutions until they become confident in their ability to make decisions for themselves. The following experiments help build that confidence.
Find a Minimum Set of Rules for Self-Organization
As we explored in Chapter 11, self-organization is the process by which rules spontaneously emerge when self-managing teams work together. A very small number of highly essential rules is better than having many inessential rules. You can facilitate the process of identifying these essential rules with the following experiment. It is based on the Liberating Structure “Min Specs.”3
3 Lipmanowicz and McCandless, The Surprising Power of Liberating Structures.
Effort/Impact Ratio
Steps
To try this experiment, do the following:
1. Invite all Scrum Teams that are working on a specific product. Also include people that the teams depend on or people who benefit from the work done by the teams, such as stakeholders, management, and related departments. The purpose of the gathering is to clarify the rules that must be followed in order to be successful with Scrum.
2. A time box of two hours should be sufficient. Set the stage by clarifying the challenge: “What rules are absolutely essential for us to work together to deliver one integrated and Done Increment every Sprint?”
3. Invite everyone to take a few minutes for themselves and write down the rules—both large and small—that are necessary to achieve the challenge. Write rules as “We must . . .” or “We must not . . .” (two minutes). Then ask people to form small groups (three to five people) and combine their lists into one longer list (fifteen minutes). These are the “Max Specs.” With the whole group, ask for some examples to spread ideas (five minutes).
4. Reiterate the challenge so that it’s fresh in everyone’s mind.
5. Ask people to take a look at the list created in their small groups. In silence, let them test each item against the challenge (two minutes). Is it possible to achieve the challenge if that rule is broken or ignored? After a few minutes, encourage people to move their thinking into their small groups and work together to reduce the list to the smallest number (fifteen minutes). Remove rules where breaking or ignoring them doesn’t prevent the group from achieving the challenge. Also remove or reformulate rules that are not clear about what they require in terms of behavior (e.g., “We must communicate more” or “We must work in a trusting environment”). Collect the remaining “Min Specs” and debrief them together.
6. You can run another reduction round on the collected “Min Specs” when you or the group feels that it can be trimmed down further. In that case, ask the small groups to consider the list of collected “Min Specs” and repeat the same steps.
7. Capture the resulting “Min Specs” as a set of essential rules for collaboration. Repeat this experiment periodically to update the rules. You can follow up with the experiment “Express Clear Requests for Help” elsewhere in this chapter to clearly express needs from the people involved in maintaining the rule.
Our Findings
• Teams are often tempted to come up with many rules. Their goal should be to identify the smallest possible number, which is more challenging than it sounds. We find that formulating three to five rules is a good goal for this exercise. The essential rules should be so important and specific that people will spring into action immediately when they are violated.
• The Liberating Structure “Min Specs” is ideally suited for helping groups identify rules for collaboration. You can apply it to challenges such as “As management, what rules must we follow in order to support our Scrum Teams?” or “As a Scrum Team, what rules must we follow in order to successfully achieve our Sprint Goal every Sprint?”
Express Clear Requests for Help
It’s easy to complain when you don’t get what you need from others, but how clear was your request? How clear was the actual response? It isn’t easy to clearly express what you need from others to be successful, and it isn’t easy to give a clear response when you are the recipient of such a request.
Vague communication can easily lead to frustration and blaming, and that’s unfortunate, because self-managing teams often need a lot from others to be successful. The following experiment gives teams the opportunity to clearly express requests for help and give an unambiguous answer to the requests that come their way. It establishes more-effective communication patterns that make a lasting impact. It is based on the Liberating Structure “What I Need from You.”4
4 Lipmanowicz and McCandless, The Surprising Power of Liberating Structures.
Effort/Impact Ratio
Steps
To try this experiment, do the following:
1. Invite the Scrum Team(s) and the other functions that contribute directly or indirectly to releasing a Done Product Increment. This can include maintenance or infrastructure teams, human resources, marketing, or management. Explain that the goal is for each function to ask others for things they need in order to be successful. They will then receive a clear response whether that request can be met or not.
2. Ask the participants to form groups corresponding to the function in which they normally work. A Scrum Team is one group, human resources is another group, and so on.
3. Ask the participants to make a list of their top needs from each of the other functions in the room. Invite them to do this first individually (one minute), then mixed in pairs (two minutes), then in groups of four (four minutes). Finally, have people gather with others from their group or function and reduce their collective needs to only the two most important ones (ten minutes). These requests are written in the form of “What I need from you is . . .” and should address a specific other group. Give the groups additional time to discuss and refine their requests, about five to ten minutes depending on their size. Ask them to be clear and unambiguous.
4. Ask each function to select a spokesperson and invite them into a circle in the middle. Each spokesperson states their top two needs to the relevant spokespersons from other functions. When a need is addressed to a group, its spokesperson takes notes but doesn’t answer. It’s important that there is no discussion or clarification.
5. When every request has been made, the spokespersons return to their groups and discuss what their answer is to each request. Answers are purposefully limited to “Yes,” “No,” or “Huh? (We don’t understand your request.)”.
6. The spokespersons gather in the circle again. One by one, each of them repeats the requests that were made to them and their answer. Again, there is no discussion and no elaboration.
7. Depending on the situation, you can do additional rounds of making requests and giving answers. The goal is to make (painfully) clear how crucial it is to be specific when asking for help. That’s why we usually stop after one round. However, there are moments when the group has understood the concept clearly and being able to make another request might help them make a big leap forward. In this case, the benefits of doing another round outweigh the need for discipline and rigor.
Our Findings
• The goal of this experiment is to practice making precise requests and giving unambiguous answers. This is not a place for discussion. If requests are unclear, it is a sign that the group needs to work on being clearer in their communication.
• Some tension during this experiment is natural as groups express clear requests and (finally) get clear answers. Recognize that tension and accept it when it happens.
• Encourage participants to continue communicating their needs outside of this gathering using the same format. If a request was not understood or denied, try asking differently.
• If you see members of a group complaining about and blaming other people, ask them what it is they need specifically and whether they have communicated this need adequately.
Observe What Is Happening
Inexperienced Scrum Masters often rush to solve problems, offer suggestions, and show the path forward. While this can be helpful, it can also impede a team’s ability to learn and grow, and undermine their ability to self-organize. This experiment is designed for Scrum Masters to find a better balance between solving problems and enabling growth and autonomy.
Effort/Impact Ratio
Steps
To try this experiment, do the following:
1. At the start of a Sprint, ask for permission from the team to step back this Sprint. This is a good moment to talk about self-organization and how you can get in the way of that. As a Scrum Master, you still participate in the various events, but not actively. No facilitation, no making suggestions or taking the lead. You remain available to answer questions or help when the team is stuck.
2. During the Sprint, observe what is happening as the team does its work. Use the list as described in the next section as inspiration. Whenever you observe something, don’t jump to conclusions or interpretations. Instead, ask yourself what you are specifically seeing or hearing.
3. In the Sprint Retrospective, explore what it was like for your team to have you in a passive role. What became possible because of it? Where did they notice self-organization?
4. If the team is up for this, you can share your factual observations during the Sprint Retrospective. For example, say “I see that seven out of ten items are ‘In Progress’ on the first day of the Sprint” or “I noticed that the Daily Scrum usually starts five to eight minutes later as people have to wait for others to join.” Give your team the first opportunity to recognize and make sense of the observations, then share your own in a constructive way. What has the team learned about their work together? Which impediments have you noticed?
5. Use other experiments in this book to analyze and resolve the impediments that you discover. Use your observations to drive the open questions you ask during the Sprint. A well-timed powerful question, built on observations, can create huge insights that would otherwise take months to discover. For example: “This Sprint, we never interacted with our stakeholders. How does this align with our goal to build a valuable product for them?”
Here are some things you can pay attention to in your observations:
• What do interactions on the team look like? Who is often talking? Who is not?
• What usually happens when someone on the team suggests something? Is it considered? Ignored? Criticized? Expanded on with additional ideas?
• What does the flow of work look like during a Sprint? How much work is in progress on a given day of the Sprint? What kind of items tend to remain in their column for a long time? Who notices this?
• What impact do dependencies have on the team? When do they happen? What do they look like? How long do they have to wait in order to continue?
• What is the atmosphere like during a Sprint? Are people laughing or smiling? Are there strong emotional responses? Do people work with others or mostly alone?
• What happens when the team runs into problems? Who takes the initiative to resolve them? Who is involved and who isn’t? Is it always the same person taking the lead? Do they explore different options and then pick one, or do they go straight to a solution?
• How does the Development Team interact with the Product Owner? How often is the Product Owner present? What kind of questions does the Product Owner get? And what kind of answers are given? What considerations does a Product Owner use in deciding how to order the Product Backlog? Is the Development Team involved in this?
• How does the team organize and coordinate its work? What kinds of decisions are made during the Daily Scrum?
• How does the team interact with its environment? How often do they interact with other Scrum Teams? How often are they interrupted by people walking in with requests?
Our Findings
• The skill to observe what is happening is also one for the Development Team to learn. You can experiment with rotating the role. The “observer” still does their work but takes a passive role during gatherings.
• It can be hard to sit on your hands when you’re used to taking the lead. Especially when you notice that the team is struggling. Trust in their ability to figure things out. The flip side is also true: don’t sit on your hands all the time. Scrum Masters have a lot of work to do when they want to help entire organizations work empirically. Consider this experiment as taking a breather and using that time to inform your next steps.
• This experiment requires that the team trusts you as a Scrum Master. Otherwise, observation will feel like spying. Be very clear about the purpose of your observations and that you share them only with the team. If trust is low, start with other experiments to build that trust. Or practice the role of observer for a single Scrum Event first.
Experiments to Promote Self-Alignment
The work of teams usually takes place in a broader organizational environment. Some form of alignment with work done elsewhere is often needed. Instead of the traditional approaches that rely on centralized management and top-down control, self-organization benefits from a process of self-alignment. Here, teams and individuals align themselves based on valuable goals and what is happening in their environment. The following experiments make this more concrete.
Create Better Sprint Goals with Powerful Questions
A Sprint Goal helps Scrum Teams self-organize their collaboration. The Sprint Goal also clarifies the purpose and value of the work on this Sprint. It gives flexibility to the Scrum Team to change their Sprint Backlog as needed in response to sudden changes. But creating clear goals is something many teams struggle with, especially in Zombie Scrum environments. This experiment offers ten powerful questions to help your Scrum Team create clear Sprint Goals.
Effort/Impact Ratio
Steps
To try this experiment, do the following:
1. Print the questions, as described next, on index cards and take them with you to the various Scrum Events.
2. Invite people to ask one of the questions, or ask one yourself as an example, when the Scrum Team is considering what to focus on for the coming Sprint. Some questions are helpful to start creating the Sprint Goal while others are helpful when the team has one in mind, but it isn’t clear enough yet.
• If we were paying for this Sprint with our own money, what work would give us the highest chance to get that money back?
• When we achieve this Sprint Goal, what has clearly changed or improved from the perspective of stakeholders?
• If we didn’t have another Sprint after this one because we ran out of money or time, what would be the one thing we’d still have to do in order to deliver at least some value?
• If we just canceled the next Sprint and went on vacation, what would be inevitably lost or become much harder later?
• Which steps are required to achieve this Sprint Goal? Which are the least required or could we do without if we really had to?
• If we suddenly had half the team available and we could only do half the work required for the Sprint Goal, what should absolutely be on our Sprint Backlog to still be okay with the outcome? What could we let go of for now and return to later?
• If there’s an “and” in the Sprint Goal (that is, if the goal consists of more than one thing to achieve): Which would you naturally do first if you had to choose? What is irrevocably lost if we do that thing first and the second thing in another Sprint?
• What would need to happen while working on this Sprint Goal that would be cause for celebration?
• What worry about our product is keeping you up at night? What can we build or test this Sprint to make you sleep a bit better?
• In terms of value and learning about what else is needed from us as a team, what is the worst way to spend the upcoming Sprint? What should we focus on this Sprint to prevent that?
You may discover that these questions won’t immediately offer you an answer because of constraints in your environment. How do you answer them when you are working on multiple products at the same time? Or when your Product Owner has no say in what order to implement work? Or when your Scrum Team is unable to deliver working software within a single Sprint? You should not focus on how to craft Sprint Goals within those constraints, but explore the impact of those constraints on your ability to work empirically.
As it turns out, struggling to craft Sprint Goals is a clear sign that you may need to improve elsewhere. Sprint Goals help a Scrum Team to find the impediments that are truly getting in your way.
Our Findings
• Ask for permission from the Scrum Team to run this experiment. When possible, do it together. Learning to think about coming Sprints in the light of these questions is a vital skill for teams to acquire.
• Don’t fall into the trap of postponing the use of Sprint Goals until you’ve removed all the constraints that are making it hard. Imperfect Sprint Goals are still better than no goals. Without Sprint Goals, the implicit goal usually becomes to just complete everything on the Sprint Backlog. That doesn’t give any flexibility to the team nor does it clarify the purpose and value of the work. Instead, it implicitly signals to teams to put their blinders on and work as fast as possible. It undermines the ability of a team to self-organize their collaboration around a common goal.
Use a Physical Scrum Board
In Chapter 11, we explored how stigmergy is a form of self-organization where coordination happens spontaneously by the traces that people leave in their environment. This may sound abstract, but it is remarkably applicable to Scrum Teams. In this experiment, we offer a great way to encourage stigmergy on the team level (see Figure 12.3).
Figure 12.3 Create a tailor-made physical Scrum Board together with your Scrum Team.
Effort/Impact Ratio
Steps
To try this experiment, do the following:
1. Together with your team, pick an empty wall or window in your team room and create a physical Scrum Board based on your Sprint Backlog. Use your preferred approach to structure your Scrum Board. We like to start with a column that holds the items on the Sprint Backlog on large index cards. Each item in the first column essentially gets its own row. The second column contains smaller cards to hold the actions needed to complete an item in the first column. Further columns represent the steps in the workflow of your team, for example “To Do,” “Coding,” “Testing,” and “Done.”
2. Add a set of visual markers to signal important information. We often use red magnets to mark items that are blocked. You can use green magnets to mark items in the first column that are Done. Another idea is to give everyone on the team one unique avatar marker to add to the item they are actively working on.
3. Add your Definition of Done next to your Scrum Board and the Sprint Goal as a banner above it.
4. Add other elements that help your team coordinate their work. You may be tempted to throw everything you have at the wall. But keep in mind that it needs to be maintained in order to work. Also, your wall is best used for traces that are updated frequently during a Sprint and are so clear that seeing them tells you what to do next. The workflow for doing a release and your team’s vacation planning are better kept elsewhere.
5. Together, update the board throughout the Sprint. Help your team use the board by drawing attention to it when something happens (e.g., an item becomes blocked or is completed). Set the example by writing clear items and helping others do the same.
6. Use your Sprint Retrospective to reflect on how you are using the Scrum Board. Specifically, look for ways to improve the actionability of the items you make transparent on it.
You can add other actionable traces to your team room, such as the following:
• The status of a build pipeline
• Process metrics that are frequently updated and inform decisions about what to work on next (e.g., “work in progress” or wait time on urgent issues)
• Status indicators for important services that your team maintains
Nothing beats a physical Scrum Board when it comes to stigmergy. There are no constraints on how or what you display on it. The mere act of getting up to move a card to another column is a stigmergic action as it signals that something is ready for the next step. If you don’t want to waste paper with stickies, you can also use writable sticky-size magnets. If your team is adamant about a digital board, make sure to have a big, movable monitor in the room to display it on.
Our Findings
• Initially, people may struggle to see the benefit of a physical Scrum Board compared to a digital one. This is a good opportunity to talk about stigmergy with your team and how it promotes self-organization. Give this experiment a try for a couple of Sprints and then decide what works best for your team.
• The book 96 Visualization Examples: How Great Teams Visualize Their Work5 by Jimmy Janlén is a great source of other examples.
5 Janlén, J. 2015. 96 Visualization Examples: How Great Teams Visualize Their Work. Leanpub.
Find Local Solutions
Although self-organization happens on individual teams, it becomes progressively more powerful as the scale increases. Also, some of the challenges that teams face may be so difficult that they can’t figure out a solution on their own. The following experiments create an environment for getting help and for devising local solutions together.
Organize Scrum Master Impediment Gatherings
Scrum Masters are there to help their team and the entire organization understand and work empirically. This is hard, especially in environments infected with Zombie Scrum. We always start by bringing together the Scrum Masters to see where they can help and support each other. This experiment helps you do that. It is based on the Liberating Structure “Wise Crowds.”6
6 Lipmanowicz and McCandless, The Surprising Power of Liberating Structures.
Effort/Impact Ratio
Steps
To try this experiment, do the following:
1. Invite all Scrum Masters in your organization for the first “Scrum Master Impediment Gathering.” Schedule an hour, remotely or in person. Once per Sprint is a good starting point, preferably after the Sprint Retrospectives so that impediments are fresh in mind. Be clear that the purpose is to resolve tough impediments. Ask everyone to bring their most difficult impediments, preferably those that transcend a single team.
2. The first step is to identify the most important patterns on which to focus this gathering. Ask everyone to pair up with someone else and take a few minutes to share their most urgent impediments (two minutes). Repeat this two more times in changing pairs (four minutes). Afterwards, capture the most obvious patterns noticed by the group (five minutes).
3. Ask everyone to pull up a chair and sit in a (large) circle. In the next steps, pick two or three Scrum Masters who will be getting help with their impediments. Each round, one of them is the client and the other participants are the consultants. Pick impediments that correspond to the patterns you noticed as a group.
4. The client shares their impediment and request for help (two minutes). The consultants ask open-ended, clarifying questions (three minutes). Then ask the client to turn their back to the consultants. Or turn the webcam off in a remote call. While the client has their back turned, the consultants talk among themselves by asking questions, offering suggestions, and giving recommendations to help the client. In the meantime, the client gives their best impression of a statue and only takes notes (eight minutes). Then the client turns back to the consultants and shares what was useful (two minutes).
5. Move to the next client. You have time for two or three rounds. Other Scrum Masters and impediments can be the focus for a subsequent gathering.
6. Capture action steps with “Create 15% Solutions” (Chapter 10). Consultants usually also get a lot of inspiration for their own team. Action steps can also involve helping others.
Our Findings
• The experiments “Use Formal and Informal Networks to Drive Change,” “Dig Deeper into Problems and Potential Solutions, Together,” “Create 15% Solutions,” and “Create Improvement Recipes” from Chapter 10 are very useful when you want to spend a gathering digging deeper into specific, recurring impediments.
• Even when it feels awkward, make sure that the client has their back fully turned to the consultants during the third step of each round (that’s number 4 in the preceding list of steps). The slightest facial expression from the client can influence the consultants in the ideas they’re offering.
• You can also use this experiment for developers, architects, managers, and other roles. Or mixed together. There is a smaller variation called “Troika Consulting,”7 where groups of three give and get help. Here, one person is the client and others become consultants. In three rounds, each participant gets to be the client once.
7 Lipmanowicz and McCandless, The Surprising Power of Liberating Structures.
Develop Local Solutions with Open Space Technology
Organizations that suffer from Zombie Scrum often rely on solutions and best practices that may have worked elsewhere but are not tuned to the local challenges and environments. You can spur the development of localized solutions by providing people with space and time to work on overcoming shared challenges together.
Open Space Technology8 is a great way to do this. The agenda is created by the participants. People go where they feel they can contribute the most. Its self-organizing nature makes Open Space Technology a great way to learn self-organization. In this experiment we outline an abbreviated version and give options to make it more effective.
8 Harrison, O. H. 2008. Open Space Technology: A User’s Guide. Berrett-Koehler Publishers. ASN: 978-1576754764.
Effort/Impact Ratio
Steps
To try this experiment, do the following:
1. Invite the entire organization or a subset to an Open Space session that lasts anywhere from a couple of hours to several days. The invitation for an Open Space should always be on an opt-in basis. Open Spaces work best in large spaces or venues with a lot of smaller rooms. Prepare by creating a grid for the marketplace and providing stickies, markers, flip charts, and chairs.
2. Introduce the concept and mechanics of Open Space. Participants are free to vote with their feet by joining the session that is most useful to them, or leaving one that they can’t contribute to. This is called the “Law of Two Feet.” Furthermore, four essential rules maximize self-organization: (1) Whoever comes are the right people, (2) whenever it starts is the right time, (3) whatever happens is the only thing that could have, and (4) when it’s over, it’s over.
3. Introduce the core topic for the Open Space. Broad topics such as “What are current challenges we need to work on?”, “How can we increase the autonomy of our teams?” or “How do we make progress with our Zombie Scrum situation?” work better than narrow topics.
4. Open the marketplace. Participants are invited to propose challenges or topics they want to explore with others along with a time and location where the session is going to take place. Display the sessions on a prominent timetable. Session proposers are also the ones initiating it, but they don’t need to have experience with the topic.
5. Sessions take place at the scheduled time and at the specified place.
6. If it makes sense, you can ask the participants of each session to give a brief overview of the results or to publish them in a virtual space.
Our Findings
• You can support session proposers by having a group of volunteers ready to facilitate the session. This is especially helpful in sessions with marked power imbalances between participants. These imbalances often manifest between hierarchical layers, for example, and can drastically affect the discussion.
• A common pitfall of Open Spaces is that sessions devolve into unstructured group conversations where loud voices dominate. Or the session proposer takes the entire time slot to “broadcast information” without tapping into the knowledge and experience of those present. You can overcome this by making use of Liberating Structures such as “What, So What, Now What?”, “Discovery and Action Dialogue,” “1-2-4-All,” and “15% Solutions.” Make sure that every session has materials to capture people’s insights (e.g., flips, stickies, and so on).
Now What?
In this chapter, we explored experiments that help your teams increase their autonomy and take responsibility for their own way of working. It is the final piece of the puzzle in this Zombie Scrum Survival Guide. Self-organization is a great catalyst that helps you build what stakeholders need, ship it fast, and improve continuously. When you create space for it to occur, the local solutions that emerge can drive lifelessness away and speed up your progress towards full recovery.
Looking for more experiments, recruit? There is an extensive arsenal available at zombiescrum.org. You can also help expand our arsenal by suggesting what worked well for you.”
