Agile First Principles
Recently I put out a post calling for the agile community to stop focusing so much on executing methodologies and return to a principles based approach. To stop doing scrum, or SAFe or Less or whatever and start being agile. That has generated a small amount of comment, mostly people asking me what I mean by a principles based approach and what I think those principles are. Here is my attempt to explain both.
To illustrate what I mean by a principles based approach, I will continue with the analogy of cooking because it's my other favourite activity and because it seemed to strike a chord with those that read my last post on this. There are, as I said before (and to massively generalise), two types of cook, those that follow recipes and those that don't. Recipe following cooks can be great cooks but if they want their chocolate cake to be a little more chocolatey, they need to look for a new recipe. They can't adjust it themselves. Cooks that don't use recipes tend to work from a set of fundamental principles - this flavour goes well with that flavour, adding extra dry ingredients means you need to add extra wet ingredients, bacon makes everything taste better, and so on. So when they want a more chocolatey chocolate cake, they can adjust (add more cocoa and some extra milk to balance). When the cake collapses coming out of the oven, they can diagnose why and adjust so it works next time. When they have a recipe for chocolate cake but don't have any chocolate they can improvise a vanilla cake from the same recipe.
That's the sign of a really good cook - to be able to walk into a kitchen, take a look at the ingredients that are there and make a meal from those ingredients that works. No need to go shopping for special ingredients, just use what's there and improvise something great out of first principles. That's where we need to be with agile. To be able to walk into a company and, using the ingredients they already have, design an agile methodology that works for them.
In the agile world right now we are recipe followers. We have found a number of recipes that work - Scrum, Kanban, Safe, less, Xscale and so on, and we apply them. They are our cookbook and generally they come out pretty well. But sometimes they don't. Why do some teams that follow scrum work spectacularly well but others don't? Without the principles that underlie the recipes we don't really know.
What about modifying the recipes? If a team wants to drop the daily standup, what will happen? What happens if we start teams with no scrum masters? Do we need product owners? Many of the methodologies explicitly state that they must be adopted as is and with no modification, otherwise they won't work. Do we really need to implement all of scrum? Or is there a minimum viable scrum we could adopt? Does that minimum viable set stay consistent across organisations or does it change from place to place?
The trouble with not being able to alter recipes is, as anyone who has ever tried to bake a cake in an unfamiliar kitchen will tell you, every kitchen is different. A recipe that works brilliantly in my kitchen may fail in yours because your oven is different, your brand of flour is different, your eggs are a different size and so on. Lots of small, subtle changes can mean the difference between a great result and a failure. Likewise, every team and every organisation is different. What works for one may not work for others so modifying methodologies, just like modifying recipes, is essential.
What about creating a new methodology? What makes some methodologies successful and others failures? Why does Scrum work? Why does Kanban work? Why do many home grown agile methodologies end up fragile rather than agile? Surely Scrum and Kanban can't be the only possible methodologies? That's like saying chocolate and vanilla are the only possible cakes.
What we need are the principles behind the recipes. Just like in cooking, you learn the principles behind the recipes by following lots of recipes and working out what is common between them.
What about the agile manifesto and its principles? Are these the principles I am talking about? No. Well, yes, kind of. The manifesto and its principles are like the taste test for a recipe. You know a recipe is a success if it tastes great. You know a methodology is a success if the team using it ends up following the agile principles. But what determines whether a recipe will taste great? What determines whether a methodology will be successful and end up following the agile principles?
When I bake bread, my manifesto is crumb and crust. It needs both to be a great loaf. My recipe design principles, the things that ensure my recipes will end up with great crumb and crust, are things like protein content of the flour, ratio of flour to water, amount of yeast and salt, how the dough is worked and so on. Using these principles I can design a bread recipe that I know will be a success, and I can adjust that recipe to work in any kitchen.
That's what we lack at the moment with agile - those recipe design principles that ensure what we are doing will be successful.
So, that's what I mean by a principles based approach. But what about some actual principles? After studying, and using in practice a large number of agile methodologies, some successful and some not, I have built up a set of principles that I think all successful methodologies share -
They are built around small, self-organising teams
The team has a clear vision of what they are doing and where they fit into the bigger picture
The team delivers a flow of value via a well defined backlog of work
There is a content authority responsible for making sure decisions are made quickly
There is a clear bidirectional service agreement between the team and the rest of the organisation
There is a fast feedback loop that allows the team and organisation to optimise both the process and the product.
The methodology is self similar at scale.
So there you go. I have put my money where my mouth is and come up with a set of principles. I'll spend the next few posts running through these to clarify what I mean and putting forward my case as to why I consider each of these fundamental.