Herding Sheep: Fewer In, Faster Out

I was out running (shuffling) past a field of sheep thinking about how much software development has changed over the years. Then the sheep got me thinking... the more sheep you have, the harder it is to herd them.

In the banks, energy suppliers and telcos I've worked with, very little software is built from scratch any more. Gone are the days of self-contained solutions. Most delivery now is about orchestration: stitching together SaaS platforms, APIs, data feeds and the odd legacy core that nobody wants to touch, or even knows how to touch.

That has changed the shape of the work. A single feature that will deliver business benefit might touch a CRM, a billing engine, a data platform and a customer app, each with its own team, backlog and release cycle. The work rarely arrives as a big project. It's a continuous stream of change requests, regulatory deadlines and "quick wins", all landing in the same 'field'.

So every extra feature or business requirement doesn't just add one more thing to deliver. It adds more dependencies, more hand-offs, and more conversations about whose turn it is to add their contribution.

This contemporary delivery style, I thought, is more susceptible to flow issues than previous delivery landscapes. This is where the sheep come in to help visualise the problem. Herding sheep is a tricky task at the best of times and the more sheep you have in your field, the harder it gets.

The sheep get in each other's way. They divide into groups. The herders have their attention split. The sheep that moves last gets the focus of the inexperienced sheepdog. If all those sheep need different treatment – some need dipping, some need shearing, some need tagging – it is not hard to imagine how chaotic and inefficient this would become.

The instinct perhaps is to send in another team of herders to help out. Anyone who has worked on a large programme knows how that ends: two farmers, four dogs, and a field of chaos.

One way to avoid the chaos is to simply put fewer sheep in the field at any one time. This isn't just a hunch from a startled ewe. It's a well-established theory called Little's Law, and it's surprisingly simple:

If a team finishes 10 features a week and has 50 on the go, each one takes about five weeks on average. Halve the work in progress and, at the same pace, each feature arrives in half the time. Nobody has to work harder. You just slow down or stop work coming in. Or stop letting so many sheep into your field.

But in practice it can be worse than the equation suggests. Every extra item in flight costs something in context switching, meetings and waiting for someone else to finish something. Throughput drops, so the average time to deliver rises even further.

There's a related idea that is even more overlooked, I think. As a team gets closer to 100% busy, waiting times don't rise steadily; they accelerate. That's why a motorway at full capacity jams, and why controlled motorways slow everyone down to keep traffic moving. Yet so many organisations measure success by how fully occupied their people are.

A fully busy team is more of a warning sign than a target.

If each field served a different purpose – one for dipping, one for shearing, one for tagging – then the flow problem gets worse. Any one field can become a bottleneck and hold up the whole show. A multidisciplinary team that can shear, dip and tag removes much of the waiting and handover. It's a real improvement.

However, even inside one team, the stages take different skills and different amounts of time. If you have two good shearers and one person confident with the dip, the dip sets the pace. The best teams spot this and swarm: the shearers help at the dip rather than shearing more sheep to stand in a queue. That only happens when there's a limit on how many sheep are in play. Without one, a cross-functional team quietly rebuilds the old pipeline inside itself, with everyone working on their own sheep.

And in a regulated UK business, some of the most important stages sit outside the team altogether. The sheep dip is mandatory, it protects the whole flock, and you don't control when it's open. Change boards, security sign-off, the platform team that owns the billing engine, the vendor's release window. A brilliant team can still end up with a crowd of sheep waiting at someone else's dip.

I don't think there's a neat answer that fits every organisation. But I've started asking myself a few questions, and I'd be curious how others would answer them:

How many sheep are in your field right now? Not the ones in the backlog, but the ones genuinely in progress.

Where is your dip? Which stage, inside or outside the team, do sheep wait at longest?

If you halved the number of things in flight tomorrow, what would actually happen? What are you afraid would happen?

Do you measure how busy people are, or how quickly value reaches the pen?

Would your teams benefit from understanding flow concepts?

Would you be open to exploring how game-based learning can help you improve your flow?

Smart farmers don't run around shouting. They let a few sheep through at a time and wait for the gate to clear. It may look slow. But it's the fastest way to get the job done.

I'd love to hear from anyone who has tried limiting work in progress in a large organisation. What happened, and what did it take to convince people?