Avoiding Decision Asteroids in Scrum
Ever have the experience that a decision made at one meeting later gets undone by decision made at a different meeting? Or perhaps you have sat through a real long meeting to discuss an important issue only to find out the real decision was made later in the week by a different team? Both experiences are what I call “Decision Asteroids”.
For those of you unfamiliar, Asteroids was a classic arcade game from the late 1970’s\early 1980’s. It was the very first video game I played and if you are interested you can play here on-line. The objective was to fly thorough space in a small, triangular rocket in order to blow-up all the rocks (asteroids) while avoiding a collision with other asteroids and a flying saucer. What made the game fun was that when you blew up an asteroid, it became two or three smaller asteroids which you then had to avoid…and the game got faster at higher levels.
When Scrum is a single team working on a single Product Backlog, making decisions is fairly straight forward and decision asteroids are simple to avoid. However, I cannot think of any non-trivial software project that does not include multiple teams and when multiple teams are working on the same product, we have more decisions to coordinate. For a traditionally managed project, it is the project manager’s responsibility to finalize decisions and avoid collisions. It is no wonder that being a project manager is so stressful – hundreds of decisions need to be made and managed throughout the life of the project.
With Scrum and Agile projects, we push the decision making authority to the self-organizing Team members. Since each Team member has autonomy to make decisions over their work, they also need to be mindful of the impact of their decisions on others. Again, for the simple case of a single team working on a single Product Backlog, there is not a great deal of complexity and coordination to manage here. Yet, Scrum Teams regularly struggle to avoid these collisions. Good thing Scrum Teams have the Daily Scrum and its fixed agenda to help Team members avoid their decision asteroids.
But what happens for Scrum Teams in the non-trivial case? Do we simply limit a Team member’s authority to make decisions and let team leads (or functional managers) make all the important decisions? Or perhaps this is a good job for a ScrumMaster – manage and coordinate all the decisions to ensure there are no collisions between teams? Of course not!! That is basically going back to the old way of working and throws out all the benefits of self-organizing teams.
Jeff Sutherland likes to say everything you need to scale Scrum is embedded in the framework. He often talks about how multiple Scrum teams working together is like those six legged, autonomous spider robots learning how to walk for the first time. They need a set of simple rules to ensure they can self-organize the behavior of their legs and that the interaction of each leg works in concert with one another. Unfortunately, Scrum does not give a set of rules to help avoid team collisions. That would be too easy and reduce an organization’s ability to self-organize.
So is there a starter kit we can begin with regarding decision making and iterate from there? As it turns out, Mike Dwyer (@MikeD999) offered this easy-to-use set of heuristics on the CST mailing list that could be beneficial for Scrum Teams. Rather than re-invent the wheel, I figured I would share them with you.
- All Scrum Teams must respect the priorities of other teams and only ask that in return. Since every team is interconnected, it makes sense that we search for win-win-win solutions.
- The purpose of all meetings held by Scrum Teams is to make decisions that move them closer to the desired outcome in front of them, i.e. meetings end in action not analysis. No using meetings as a way to get noticed on how smart you are.
- Any one participating in a meeting with a Scrum Team must be empowered to make a decision their organization will stand behind. It is crucial that other teams send the right person to a meeting otherwise decisions get undone.
While our goal with these heuristics is to make timely decisions with the relevant and invested decision-makers in order to avoid decision asteroids, we should not force a decision before it is ready. In cases where we have conflicting priorities or decision makers cannot build a consensus, our default position should be to move into a timeboxed experiment to gather data collaboratively with our peers and seek feedback to refine our understanding.
When we have data from the experiment, the outcome is normally clear and obvious. And if that does not work, we can always make a small decision that moves us forward and we can re-visit, iterate or refactor that decision later.
