Yes, Chef: Why the Best Delivery Management Isn’t About the Methodology

Good delivery is methodology agnostic.

Most conversations about delivery management start and end with methodology - which framework to certify in, which ceremonies to run, which board to use. But plenty of teams tick every one of those boxes and still end up delivering badly, while others with none of the right scaffolding deliver brilliantly. So why is that?

This article endeavours to explain that gap. Not by picking a specific methodology, but looking at what’s actually doing the work when delivery goes well. To explore that, I’m going to borrow lessons from an industry that is not forgiving when it comes to delivering quality on time.

I’m going to draw on the few years I spent working as a chef de partie in a professional kitchen, a world that hasn’t necessarily heard of a sprint, yet consistently gets delivery right.

The methodology trap

We're all aware of the usual jargon that comes with software delivery, and we've all heard our share of businesses' own derivatives of methodologies - like "Fr-Agile", shortly followed by the collective sound of eyes rolling off camera. Whether it's old school PRINCE2 or more "contemporary" approaches like SAFe, each one comes with a new set of techniques ready to be misused. Poor delivery often hides behind impractical application of proven methodology and misuse of methodology-specific terms.

How many times have you seen businesses (maybe your own) qualify teams in SAFe only to see the framework applied to two teams of 5 people, or develop an exhaustive, signed-off list of requirements in two-week "sprints", or kanban boards completely overloaded with tickets?

So, what - if not just methodology - makes delivery good? For starters, I'm not claiming that methodology isn't valuable. Some fundamentals are certainly true for any delivery, but it's all about how these are applied. Methodologies obviously have their value otherwise businesses wouldn't be spending so much money on them, but they are not intrinsically valuable.

What this article is arguing is that the skill of any delivery manager worth their salt is to apply the right methodology, to the right level, in the right situation. And that is what makes delivery good.

What is good delivery?

Ok but what is "good delivery"? We see really impressive examples of delivery in day-to-day life, nothing new of course given methodologies like lean coming from entirely different industries, I'm not the first to draw comparisons. But one that always struck me is a well-run restaurant. I've been lucky enough to moonlight as a chef de partie for a couple of years before the pandemic, and I learned a lot about delivery in practice from working with the team. And those guys don't know the first thing about delivery methodologies. I'll caveat though that I don't claim to be an expert in hospitality.

Restaurants also aren't so different to software delivery. There are customers, "deadlines", resources, delays, except all of it on much smaller timescales than most projects. So what things are common?

Processes:

I don't think anyone working in hospitality would likely refer to what they're doing as a process in the sense it's meant here. But they do exist. Mise-en-place for instance - chefs prepare their stations including making sure everything is clean, ready to work, and any ingredients or components of dishes are ready. Anything that needs topping up or sorting is done during this time and at the end of each shift notes are made of what needs to be done at the beginning of the next. It's not too dissimilar to planning the next sprint or milestone, or iteration. Ensuring everything is ready (Definition of Ready (DoR) for example) for the work to commence and complete and outlining what needs doing for the next period to run smoothly. This is done by each team member, with the head chef having an overall view for the kitchen. Front of house will do something similar for instance in preparation for events (maybe there's a film night and props are needed, or pub quiz materials, etc etc).

That process is flexible enough to accommodate some days requiring more involved prep and sometimes the odd, unexpected task, it's not rigid. It can't become stale because with every menu change the prep work changes. Depending on the day the prep work changes, for example Sunday might cater for brunch or a roast dinner. The process serves the team; there are some common core parts but it's different for each restaurant and changes. In software delivery it should be the same, a process has to serve the team. Sometimes it's easy to lose sight of it and doggedly follow what the process "should" be rather than what works for that team in that context. Best practice is sometimes similar to the US building Lt. Gilbert S. Daniels' one-size-fits-all cockpit for planes post-WW2, only to realise no person had the dimensions of the "average" person.

Communication:

Fans of Amazon's "The Bear" will recognise the chants of "YES CHEF", and that clear acknowledgement to a customer order or communication. It's commonplace in kitchens and a really important part of communication so everyone knows that what has been said has been heard and understood. It means that the individuals who have replied are getting on with whatever needs to be done as a result.

I'm not saying as delivery managers we should therefore be barking orders on stand ups and expecting a "YES DELIVERY MANAGER", although I'm sure it would certainly make some dry stand ups a lot more exciting. But the point is that not only for stand ups but team meetings of any kind there has to be a clear communication that what is being shared is understood and that the team can work on the next piece. If it isn't then it's the transparency on where the gaps are and what is missing or how much time it will take is so important. It's exactly the reason why regular communication forums like refinements or retros need to always take on feedback from the team because if these channels of communication don't adapt with the team, then that communication falls apart.

Culture:

This is so often overlooked or given lip service only. People will groan having heard "we fail and succeed as a team" for the millionth time but it's an excellent mantra for a team. It's the same in kitchens as it is in project teams. If someone hasn't got a component ready for a dish the dish can't go out, everything has to be co-ordinated perfectly to come together at the same time and not let the dish go cold. That means sometimes another chef on a station that's less busy (e.g. pastry chef at the beginning of service) can help out with certain elements.

To maybe put this into slightly more methodology-based language - this works the same as the WIP game from actionable agile. The game gives you various developers and tickets to work through on a kanban board, it even throws problems at you during the game. In a kitchen this is exactly the same on a small timescale, you have a self-managing team that is led by the head chef, and people sometimes need to step in if something has unexpectedly run out or one station is overloaded, same as developers.

I once remember a chef throwing a pan at a waiter who'd accepted an order for cauliflower cheese when we weren't serving it that night. Did the customer get her cauliflower cheese? You bet. Did the waiter make that mistake again. No. But good culture and management make it possible, and both projects and restaurants can have very demanding customers so a passionate, happy and engaged team is critical.

Method to the madness:

So, I've not really covered any approaches really, some touches on Lean or Kanban and there's a few comparisons made to methods or a nod to one here or there. Why not? Because I can't tell you what to use or when to use it. Anyone who claims to know what approach to use without looking at your business properly including op models, skills, tech stack, etc, is just trying to sell the method and isn't interested in the success of establishing it because they likely move on before benefits can be measured.

There's a very fine balance between using methodology to the right level of fidelity. Every approach comes with pros and cons, but people are often too focused on the pros to consider and compare methodologies in a balanced way, let alone the level of fidelity in terms of adhering with the concepts.

Now - purists will absolutely disagree and say things should be done by the book to the letter. Of course, in some businesses that can work! Especially newer or smaller businesses. But for the types of clients, we most often deal with there are a lot of very embedded practices that we often have to work with, and within. How often have we all seen a business dress up waterfall as agile by changing the names of regular meetings? But the thing is, although it's far from the intention of the methodology there will be elements that are incompatible with some of these businesses, fixed release cycles come to mind for instance.

I admit that of course there are many drawbacks with not following methodology to at least a decent level of fidelity because of course it otherwise becomes something entirely different. But we see businesses get caught up in the theory for far too long to put anything into practice that is actually feasible and sustainable.

Going back to the comparison to the restaurant - there are so many different forms of cuisine across the world and with so many techniques. Some are incredibly refined like Japanese for instance; some have some very strong basic "rules" like French or Italian. But ask an Italian whether Gordon's street pizza is pizza and you might get a different answer to Gordon. He's taken principles of good food, high quality and good dining experience and implemented them to a degree of fidelity to Italian pizza making but still has a Hawaiian pizza on the menu. And I'm fairly sure he's successful...

Summary

Good delivery managers do the same thing with the client they are working with and the methodologies that are in place or need to be put in place. They take it to the level of fidelity the situation calls for, and no further. That judgement is the actual skill.

Combine that with processes that serves the team, communication that leaves no doubt about what’s understood and what isn’t, and a culture where people step in when someone is overloaded. Then you should find that delivery goes smoothly, and if not it’s time to review as a team and keep refining how you deliver not just your stories. This isn’t exhaustive but it’s always been a good basis for me.