Discover more from Maarten’s Newsletter
Recognizing the two types of Monkeys in Scrum
A useful analogy for deciding which problems you should tackle as a Scrum Master.
A development team will face many problems. A crippling production issue that needs to be picked up immediately. A team member who has friction with everyone else in the team. Not having enough licenses of a ETL tool to be able work together at the same time.
As a Scrum Master it is vital to take on the right problems. Take on too many problems and you will limit the self-organization and growth of your team. Take on too few of problems and the team will drown in problems with the same end result.
A careful balance of problems you pick-up and help the team to pick-up is essential.
As a Scrum Master, how do you decide what problems to take on?
Framing problems as Monkeys to decide which problems to tackle
In 1974 a famous Harvard Business Review article was published called “Management Time: Who’s Got the Monkey?”. It provides a useful analogy of a monkey jumping from back to back when deciding which problems to take on. It helps managers to decide how to manage their own time.
Imagine you are a Scrum Master walking down a hallway to grab a cup of coffee. On the way you bump into one of your team members. She’s struggling with a complex problem and asks for your help. You do not have enough knowledge to answer on the spot.
You tell her:“No problem, I will take care of it and get back to you”. You grab a coffee and go along your own busy way. One week later she comes knocking on your door and asks for an update on her problem.
Two things happened:
The Scrum Master now took on a responsibility of a team member.
The Scrum Master has promised a progress report to the team member.
Before the two met, the monkey (problem) was on the back of the team member. After the chat in the hallway the monkey was on the back of the Scrum Master.
Now imagine that the Scrum Master followed a different approach. She would meet her in the hallway and say:”Interesting problem. If you want to exchange thoughts, I would suggest to have a short discussion where you come prepared with a couple of potential solutions. Then we can discuss and decide together what the best approach might be.”
Using this approach, the monkey remains on the back of the team member. The original owner of the problem keeps owning the problem. In most cases this is exactly what you want to achieve, to promote ownership and self-organization.
In some cases the Scrum Master actually will want to take on the problem from the team member. This would be the case if the team member will not be able to solve it on their own, even with help. An example would be an issue that requires convincing many organisational layers above the team to make changes.
Identifying the two types of monkeys in Scrum
There are two types of monkeys in Scrum:
A problem monkey is defined as something the team is able to solve on their own. With or without help of the Scrum Master. This is where the Scrum Masters should spend the majority of their time: helping others to solve their own problems.
By doing this you will grow the capabilities of your team. It will promote self-organisation and ownership. As the problem-solving capabilities of your team grow, some things you consider an impediment now enter the realm of problems the team can solve on their own.
As a Scrum Master this is exactly what you want to achieve. You want your team to depend on you only where absolutely necessary.
A lot of Scrum Masters talk about protecting and guarding the team. This is what I like to call the ‘babysitter’ Scrum Master anti-pattern. If you treat your team like babies, that’s what you get: babies. If you treat your team members like leaders, you will get leaders.
In self-organizing teams you want to help people lead and collaborate together to solve problems.
If a Scrum Master notices a problem monkey, then he should allow the team to resolve it. Even if the team fails, it will provide an opportunity for learning and growing. As self-organizing teams become more self-organizing, they will need less help and guidance tackling these problem monkeys.
You should only help your team where absolutely necessary. Failure is an essential part of learning. Babies fall around 100 times per day when learning how to walk. It is not possible to learn how to walk without failing.
In general the same applies when you want to grow the capabilities of your team. You should try to get them slightly out of their comfort zone where there is risk of failure and slight discomfort. To grow your team needs to tackle problems that are in the stretch zone.
Impediment monkeys, by nature, are problems that cannot be resolved by the team. The Scrum Master should take on these monkeys and get rid of them swiftly. As an impediment remover, he is the chief impediment monkey handler.
How to distinguish an impediment from a problem the team can solve? This is a difficult call to make.
In novice teams impediments will be on both the team and organisational level. As teams mature, impediments will shift towards being mostly on the organisational level. Mature teams should be able to solve most, if not all, issues which are on the team level.
Solving issues on the organisational level often remains hard for teams. Regardless of how mature they are. Solving organisational problems requires a very different skill set than what most team members in the Scrum team will have.
And even if they would have the capabilities, implementing organisational changes often requires a lot of attention and effort across many Sprints. Often it is not possible for Development Team members to give these organisational problems sufficient attention to solve them.
Scrum Masters should help their teams to help themselves
As a Scrum Master it is essential to balance which problems you pick up and which ones your team needs to take care of. If you take on too many or too little problems, the growth and self-organisation of your team will suffer
Scrum Masters should nudge teams to pick up problem monkeys that are in their comfort or stretch zone. Failure is okay. Failure is necessary for the team to grow and learn.
Impediment monkeys are problems the team is not able to solve and therefore the Scrum Master must take these on. These problems are in the discomfort zone, where the team has no clue how to properly tackle them.
Help your team to help itself. Create time for yourself so you can help the team where it really matters: to solve problems they can’t solve in their own. By helping the team resolving problems, you grow the capabilities of your team. As a result, some of the impediments will become problems your team can solve.
In order for self-organizing teams to be a success, Scrum Masters need to help teams to step up so they can lead the way. By growing the capabilities of your team you will create more time for yourself as a Scrum Master to tackle the hard organisational problems that cannot be solved without your help. And that’s where ultimately Scrum Masters can make the biggest difference for the organisation.