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.
The IT Risk Manager 
December 30th, 2014 at 10:41 am
As on previous occasions I contend this misrepresents the triumvirate of theory, practice and action. Recipe makers are not theorists, food scientists are. Chef’s possess a strong theoretical background channelled through and modified by practice, as anyone who’s watched Paul Hollywood pontificate on GBBO can attest. Theorists can happily cope with Newtonian mechanics and Quantum phenomenon despite their observable contradictions. Development of new recipes requires a strong understanding of food theory validated through execution. But there is a another class of practitioner: the Good Food magazine subscriber. They want something actionable, recipes which match their subjective constraints: vegetarian, a 15 minute meal, something complicated with chocolate. No theory accompanies these recipes, to the home cook they would be an unnecessarily cognitive distraction. It’s this body I suggest forms the largest body of Scrum management today. They have extensive practical experience but haven’t invested in the wide and growing body of theoretical knowledge that would assist them in critique or developing new recipes.
December 30th, 2014 at 11:52 am
Hi Anthony
I think I get where you coming from now. Let me see I’ve got this right. My belief is that you are coming at these terms and definitions from a philosophical perspective. I am coming at them from how they fit the context I see related to Scaled Agile.
For me, a theorist is someone who theorises about a thing. Normally they theorise about things they have not done. There is a particular strain of theorist which is the one who takes something that works in a particular context and then pronounces that it works in all contexts. In addition, there are those ( e.g. Malcolm Gladwell ) who reads a few books, synthesise it into a readable theory, often knocking off the edges along the way ( e.g. The 10,000 of practice ).
For me, practitioners are the people that apply the ideas within a context. Some practitioners simply follow the recipe as specified without much thought. I think these are the ones you refer to. There are then the practitioners who use theory to evolve their practice ( Praxis ). Both theory and practice co-evolve. These are the practitioners that have moved the Agile Movement forward. Rather than state their solutions as universal, they offer them as experience reports in the hope that other practitioners will learn from them and extract what is useful. Sometimes the practice pre-dates the thoery ( e.g. The Battle of Thermopylae came 200 years before Theory of Constraints ), sometimes the theory is used to create practice ( Capacity Planning developed from Theory of Constraints ).
The worst scenario is where we have theorists making recipes up that is simply consumed by practitioners who accept it as scripture and follow the instructions by rote. I agree that sadly this is the most dominant scenario. Whilst I am ranting at the theoretical recipe makers, you are ranting at those following the recipe without understanding the theory.
For those following by rote, I suspect the reason is that the organisation has imposed a practice on its people without explaining why the practice benefits them as individuals (other than they keep their job or extrinsic motiivation ). In learning terms, they have been forced from unconscious incompetence to conscious competence without going through the important stage of conscious incompetence. Conscious incompetence means they are aware of the thing and they can understand its value, especially “Whats in it for me”. ( This is an uncomfortable position to understand their are tools that are valuable that you do not know, and requires good leadership to sustain. ) Once they are consciously incompetent, the learner is intrinsically motivated to learn which is where they will read around the subject. This creates practitioners with theory.
Sadly most Agile training is focused on teaching skills rather than building intrinsic motivation. As such it creates the situation you describe. Blame the managers who buy courses that sell skills and practices, rather than buy experiences that inspire people to learn. And here we are back with context. Inspiring people can require people to understand context and speak the language of power ( the domain ) whereas teaching skills does not require that understanding of context. Funnily enough, the theorist tells us context does matter for learning, the practitioner might have another view.
December 30th, 2014 at 12:59 pm
I have reservations about exalting contextual constraints without a theoretical understanding of Cynefin. Post-hoc rationalisation has led many astray: imagining an idealised future state in a typical system-thinking approach and thereby colouring the present. “It’s not what we don’t know that gets us into trouble, it’s what we know that just ain’t so.” Cynefin proffers (at least one) recipe: Sense-making, the theory being if we can better judge the present we can, using constraint-based techniques (recipes?), manage emergent coherence.
December 30th, 2014 at 1:21 pm
Hi Anthony
I’m confused. Did i understand you correctly or not?
January 2nd, 2015 at 4:34 pm
Snowden provides a lengthy description of the relationships between theory, practice, praxis and recipes in this presentation from XP 2012: http://youtu.be/yXIePVkTY0A?list=PL5GYLAAgBWJerzjXIE7f-GGEzVLR69P9b In it he intimates it’s practices that have a propensity to recipes rather than theory.
January 2nd, 2015 at 9:25 pm
Anthony
You have an important point to make here.
Would you like to write a guest blog?
Chris
January 4th, 2015 at 8:33 pm
In your example, you have two POs trying to influence two teams, with different priorities, because each product requires work from each team.
But wait! Scrum calls for a cross functional team capable of building the product increments. Neither of these POs has been given the kind of team Scrum calls for. Had they been, this problem would not arise.
The company might object that “we can’t set up cross-functional teams”. Well, maybe they can’t, but more likely they just choose not to.
Scrum has identified the problem: teams not cross-functional. One response is to make cross-functional teams. Another is to do something else, quite likely not as effective but perhaps easier.
The people get to choose.