In many, if not most, circumstances, insisting that a team must come up with a custom method is harmful. At best, it is a false expectation and at worst designed to create a dependency on consulting skills. For many, if not most, teams, a recipe based approach is useful and in some, is absolutely essential.

I’m increasingly hearing arguments that bringing a defined method process to a team is A Bad Idea. That recipes is not how great chefs work, and that a process defined elsewhere will necessarily be a poor fit for a team, and will render harm when introduced. Therefore the only true method is a meta-method that teaches pure process improvement and customised method design

I think there are a number of lazy fallacies in this thinking, and some that are born of an instinct for partisanship and naked commercial competition rather than the claimed Best Fit for Customer. I’ve particularly seen it in response to SAFe, from thought leaders of competing methods, which is interesting.

Let’s get the points of agreement out of the way before I get onto my argument. Yes, of course we should teach pure process improvement. Yes, we should always seek to learn the lessons of our own environment and, using the capabilities of those doing the work, adapt our ways of working to be more effective in our own environments. Yes, we should run safe to fail experiments that take us off the beaten path and may evolve entirely new paths. Insisting on conformity for its own sake is dumb and limiting, and that’s a huge risk of imposed method and certification schemes. So I am obviously not arguing that there is a single Best Practise that can simply be rolled out without further thought or space for Serendipity.


Every time you talk about recipes as being A Bad Thing you’re fundamentally ignoring how people learn. Whether you call it ShuHaRi or you go to the more nuanced Dreyfus model, when people learn a new domain of skill, their initial learning is entirely driven by rules and direction.

Dreyfus model of skill acquisition

Dreyfus Model of Skill Acquisition.
Image source:

This is absolutely true in traditional kitchens (and catering trade education), where every would be Michelin-starred chef starts off with the 5 Mother Sauces, cuts of meat, and preparations of vegetables. If that novice is very, very lucky, they may be allowed to try some of these techniques out in a real restaurant under the very close supervision of a real chef (or more likely: chef-de-partie), as a break from the traditional starting kitchen role, the plongeur (i.e. dishwasher). If the plongeur does this without too many mistakes, they may in time and with education graduate up to being a Commis. Where they will very much be following the Chef’s recipes, written or verbal, and will absolutely not be allowed to improvise or invent.

Yes, it’s a hierarchy of practitioners. But so are most skilled trades and crafts. And it absolutely recognises that only a minority of practitioners get to mastery, and those not there will be following rules and direction to an extent dictated by their skill level and ability to understand the context that the rules operate in.

I’m a pretty good cook. And for most things, I can throw together a tasty meal given any sane availability of ingredients and budget. For some dishes though, I follow my mother’s recipe. Or one in one of the range of cookbooks we have. Or at least will check for elements like roasting time, and I have a timer app for steak. I’m also a competent baker, but like to have my recipes to hand. And for pastry which needs to be precise otherwise it fails spectacularly, I use a recipe every time. Or pre-made.

Similarly, I’ve been a musician, performing in public since I was under 5 years old. On some instruments and in some genres, I intimately know the repertoire. For example, I know where a Scots fiddle tune is going in 4 bars, 8 bars, 16 bars and right away, and can accompany on guitar, bass or piano, even if I’ve never heard it before. However, I can’t cope with free jazz. I don’t know it well enough. The sound isn’t in my head. For blues, the sound is in my head well enough to scat sing, but not in my fingers to improvise solos, and certainly not when it goes outside the core 12 bar blues format. There, the recipe of a 12 bar blues gives me enough structure to have confidence that my zone of freedom in improvising is still going to sound basically OK. And as I practise, I move from simple recreation of solos to embellishing and varying them, to adding totally new phrases. The recipe – far from being a constraint – has become a liberating factor that gives me more freedom, knowing that the stylistic boundaries will help ensure the sense of what I’m playing.

To expect teams without mastery level experience to be able to improvise their own solutions is expecting them to jump Dreyfus levels. Until they fully and deeply understand (‘grok’ is a great word) the method they’re introducing and how their environment responds to it, expecting this is a sure fire accident waiting to happen.

This all seems familiar ground to me, though. To me it sounds a lot like a rehash of the old “packaged or custom written?” software argument. In that argument, “packaged” won hands down, and you know and accept this, unless you’re currently reading on a machine you built from components with an OS you built from very low level up. If so, Hi Linus! For the rest of you, you’re relying on packaged generalised work of other people, with some degrees of customisation. Because most problem spaces are similar, and for the gross problems of any organisation new to better ways of working, the same big problems surface time after time, with the same causes. The very fact that there is a Lean/Agile community that talks about method at all indicates this.

Just as in software development, large areas of the problem space are complicated, not complex. They’re problems of multitasking, starting not finishing, wait time, management direction of detail but not purpose, high WiP, the Toast method of testing and so on. Liz Keogh expressed this beautifully way back in 2012 with my emphasis

We treat a lot of software as if it’s complex, and we talk about self-organising teams and high learning environments, but in reality there are huge chunks in most applications which follow well-established rules, have been done a thousand times before and probably have libraries or third-party apps to do the job for you. They’re not complex. They’re complicated. They require the application of a bit of expertise, and are likely to be done right and never changed again. User registration and logging in are great examples of this. You don’t need a big, thick document to describe them. The fine details might change, of course, but we already know not to sweat the petty stuff.

… Even better than requirements documents, and quicker, is to say, “It’s user registration. Make it work like Twitter’s, but we also need the user’s loyalty card number. We should offer to send them a card if they don’t have one.” Dan North calls this pattern “Ginger Cake” – it’s like a chocolate cake, but with ginger. He even cuts and pastes code. And it’s OK! Honestly, it is! This code is also absolutely prime for TDDing – if you actually have to write it yourself, that is, since it’s been done before so someone’s probably written something to do it for you already. You can also give this code to junior devs, for whom it’s new, and guide them in TDDing, making it perfect pair-programming territory. 

Let me say that last bit again:

You can give this code to junior devs, for whom it’s new, and guide them in TDDing, making it perfect pair-programming territory.

Similarly in the problem solving skill domain, most problems (and certainly a large part of the most painful ones) are not complex adaptive situations, at most they’re complicated ones. So repeatedly telling me that “recipes don’t work in complex adaptive situations” — while true in its own terms — doesn’t help because most of the time it doesn’t apply.

There’s a whole class of problems that occur again and again. So why not bring to bear extra-organisational learning? Not “answer at the back of the book” single point Best Practises, but repeatedly tried Good Practises, validated in a number of “situations like yours.” Yes, some of these won’t be helpful but aren’t we trying to learn by doing? Give them a good go before rejecting them, and even then, evaluate carefully to see if there are sub-practises that are helpful in their own right.

In resolving these complicated, not complex, you can develop the improvement capabilities of the team who may be vastly experienced in code, but not in continuous improvement, moving up the Dreyfus curve.

Most people are no more than Competent in any discipline. Let’s stop insisting that newcomers to continuous improvement can magically hop levels, and bring them structures to help them both gain the benefits of improvement and skill in doing so.

Follow me
Latest posts by Martin Burns (see all)

CC BY-NC-SA 4.0 Dreyfus Hopping Mad by Martin Burns is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.

%d bloggers like this: