A Continuous Flow Of Coffee

Wednesday 31 January 2018 at 08:00 GMT

I've watched software developers (in the broadest sense—programmers, designers, testers, managers, coaches, etc.) struggle with the idea of "one-piece continuous flow" for a long time.

Recently I was reminded of my favourite metaphor for this. I was in Brooklyn Coffee (the best little café in London) and watched the staff (there's typically 3 people working there at any given time) work. I was waiting to place my order, but there were two people operating the coffee machine and one handling something in the back, so I had to wait about a minute before one of the baristas (who happens to own the place) came to take my order.

Now, the reason I had to wait is because there was a couple of large orders in front of me: 2–4 coffees each. There was absolutely no point taking my order earlier—it wouldn't save me any time, and it would just slow down the orders in front. And after she took my order, our hero went straight back to making coffee.

In a café where the staff know their trade, no one really has a "job". People have skills—some can use the espresso machine, some the V60s, some are good at waiting tables, some best at cleaning up. But everyone does everything as necessary. In a well-oiled café, there are no bottlenecks in the pipeline, because the (human) resources are fluid, changing to adapt to the situation at any given moment.

When developing a product, allocating people to jobs is wasteful. If you have two programmers, a designer, a tester, a sysadmin, a product owner and a coach, at any given moment, most of them will be either idle or doing busy-work. Because the reality is that the distribution of work to be done isn't fixed. You don't always need design work, programming is useless if you haven't decided what to make, and testers are always overworked.

Instead, what if we worked on one feature at a time?

Figure out what we want, design the UX, implement it, test it, ship it.

It sounds more wasteful. After all, our designers can't test, and our programmers can't design.

Yet.

If they could, it would be vastly less wasteful. We'd end up mobbing most of the time. And then we could approach the wastefulness problem from the opposite direction. Instead of figuring out what to do with idle time, we could figure out when we're putting too many people on the problem. They could then peel off to prep the next piece of work—but only when necessary.

If we did this, we'd end up with similar roles to the way we started, except everyone would be able to change roles to meet demand.

Because when you're a programmer blocked on testing, the right thing to do isn't to program more, it's to go and be a tester.