Software Kitchen Nightmares

[From the Archive: Originally posted at Amplify.com Nov 20, 2011]

Explaining FlowChain Via A Restaurant Analogy

I love Gordon Ramsay’s TV series “Kitchen Nightmares” (including the USA version).

As well as being entertaining, I share Gordon’s obvious passion for helping folks improve their businesses (in my case, technology-related businesses – not restaurants!). The series illustrate in an almost visceral way the key issues facing any business, and a simple means to address these issues.

He follows much the same strategy in each encounter, a strategy which guides the changes he proposes to owners:

• Understand what the customers actually want in the way of food, prices, dining experience, etc..
• Change the restaurant’s offerings to more closely match that demand.
• Get the management and workers to care about what they’re doing again (intrinsic motivation).
• Sort out the kitchen so it has the capacity and capability to meet the expected increase in demand.

It’s the latter point which I’m going to use, as an analogy, to illustrate FlowChain and how the FlowChain perspective can benefit technology businesses. (In this post, for the sake of clarity, I’ll talk exclusively about the software development aspects of producing or enhancing a technology-based product or service).

Things In Common

In a restaurant kitchen, orders from customers arrive at the pass.

Newly-arriving orders are inserted into a running backlog, according to some prioritisation scheme, as the whole kitchen, synchronised by e.g. the Head Chef, works to prepare each element of the highest-priority orders. As elements become ready, they arrive at the pass, where they are assembled and checked before being dispatched, in small batches (one course for one table at a time), to front-of-house and the waiting diners.

In a FlowChain context, orders (in the guise of, say, new user stories) enter the software development department (or maybe it’s called the IT department – that’s an issue for another day).

Newly-arriving orders are inserted into a running backlog, according to some prioritisation scheme, as the whole department works to prepare each element of the highest-priority orders. As elements become ready (with Continuous Integration we can skip a separate assembly step, and with e.g. TDD/BDD we can skip much or all of the checking) the orders are dispatched to the waiting customers. (With Continuous Deployment we can skip much of the dispatch step, too).

So, the essential aspects which these two scenarios (kitchen, software development department) have in common are:

• Incoming orders arrive with unpredictable variation in e.g. size, timing, priority and requested customisations.
• There’s a constantly-changing, enterprise-wide backlog of pending orders.
• Workers assign themselves to the highest-priority items, depending on their skills.
• Customers do not want, nor expect, their entire meal to arrive at once.
• Customers do expect to have a single course for the whole table arrive at the same time.
• Continuous operation, day-in, day-out.

Benefits

The benefits of this approach include:

• Elimination of overheads such as project management (no projects!) and programme management (no brawls over resources for competing projects).
• Elimination of project set-up and tear-down overhead (no project teams!).
• Reduction in delays due to e.g. elimination of handovers and sequential processing.
• Much improved flow (of valuable user-stories to customers). Increased flexibility in responding to customer needs.
• Improved collaboration between workers, and between front-of- house and the delivery unit.
• Provides opportunities for learning and, especially, multi-skilling, in the workforce.
• Requires leadership (although not necessarily ONE leader), not management.

Of course, as we described in Gordon’s strategy, building a successful business as a whole means we have simultaneously to attend to a range of issues, not just simply ensure that the “delivery” part of the organisation has sufficient capability to play its part in the new scheme of things.

And please accept that this is ONLY an analogy, to help explain FlowChain a little better. A software development department is not a kitchen, and the issues – whilst similar in some aspects – are sufficiently different that I for one would not want to run a software shop in the same way as a restaurant kitchen.

– Bob