I’m a huge fan of Dave Snowden’s work, especially as it comes to Scaling Agile. In particular I love the “Recipe Follower and Chefs” metaphor. It captures the difference between what I call theorists and practitioners, although I should really refer to practitioners as praxis-ists. To me, the theorists are the ones who make up the recipes rather than the ones who follow them.
The problem with recipes is that they ignore context. A practitioner operates within a context and so cannot ignore context. The recipe for making a cup of tea is simple… unless you are on a beach, or in the Himalayas where the boiling point for water is much lower.
I love Scrum for its simplicity. Its an approach that can be explained in half an hour yet takes a life time to fully master. Scrum has three roles “Product owner”, “Team” and “Scrum Master”. The product owner makes all the decisions about the product, they prioritise (order) the backlog. Simple! In the context of a single team, Scrum is great.
The problem with Scrum is when you have multiple teams. Or rather, Scrum is not designed for a multi-team development and assumes a single team environment. There is no problem with Scrum, the problem is that reality does not fit into the context that Scrum was designed for.
So lets look at this problem in more detail. Imagine an organisation with two teams (TeamA & TeamB), each of which has a backlog owned by a product owner. TeamA has an MVP called MVPA which requires work from both TeamA and TeamB. TeamB has an MVP called MVPB which also requires work from both TeamA and TeamB. The product owners prioritise their own MVP in their respective backlog… TeamA will has MVPA at the top and MVPB at the bottom. TeamB has MVPB at the top and MVPA at the bottom. This means that MVPA and MVPB will not ship until both are complete.This might seem a crazy situation but it is exactly what happens if a mechanism is not put in place to manage it. Product Owners will prioritise the requirement of the last senior executive to shout at them to get their work prioritised. Furthermore, this is an abdication of responsibility by the executives of the organisation who should be providing direction and focus. In effect the executives have devolved responsibility for the companies direction to the product owners of the Scrum Teams. Although the product owners may understand their product, they do not necessarily have an organisation wide perspective.
What we need is some mechanism to unpick these dependencies so that either MVPA or MVPB is at the top of both backlogs. What are the solutions?
1. The immediate response it to organise the teams into proper Scrum Teams or “Feature Teams”. Each team should be able to deliver a full MVP without any dependency on other teams. This is the ideal situation and should be the first approach. There are contexts where this is not possible. There are organisations and products that are so large that specialisation is needed and a team of 6 to 9 developers cannot cover the entire space. This is the context of Scaling Agile. If you are following a recipe, this is where you will struggle as the Scrum recipe does not work. Its like trying to follow a recipe to make an omelette without eggs.
2. In this situation, we decided to use the “theory of constraints” to find the constraints and create an organisational backlog. We were no longer following a recipe, instead we were having to experiment like Chef’s do. The product owner recipe actually became a problem for us. The theorists ( Recipe Maker ) told us that the product owner should always own the ordering of the backlog. The context meant that to deliver fast, the product owner needed to prioritise their backlog according to a higher level “organisational backlog”. Scaling the Product Owner role creates a direct conflict with the principles of Scrum. If we follow the Scrum Principles we have no control over delivery at the organisational level, however if we create an “organisational backlog”, we violate the Scrum Principles.
For an organisation trying to scale the Product Owner role, this presents a very real challenge. We had executives who saw the need for an “organisational backlog” but also the need for product owner autonomy. In some ways this was a good thing as the executives were thinking hard about not undermining the product owner. On the other hand, it hampered our ability to deliver.
Note that this does not even consider how the “executive backlog” is prioritised / ordered. Whether the prioritisation is top-down, bottom-up, collaborative or directive, democratic or autocratic. Simply the need for an “organisational backlog” causes the Product Owner role recipe to “fail”.
If you are Scaling Agile, you need to hire a (team of) Chefs. You need to hire people with years of experience applying Agile in the role of product management, architecture and IT (risk) management. This team will be coaches to help you handle the situations where the recipes fail. You will also need the people churning out the recipe books and training the teams in team level Agile practices. Your teams will need to follow the recipes but you will also need Chefs for when the context causes the recipes to fail.
A final word of warning, beware of Nigella Lawson. Nigella simply copies other people’s recipes (She has a vast library of Cookery books) but does not invent recipes herself. She is famous but she is not a Chef as should not be listened to when the recipe fails. Instead, hire the Chef from your local gastro pub where you like the food.
I’m conscious that I am not an expert in Scrum. If I have misunderstood something, please let me know and I will update the post.