Agility and the power of No

One of the nice things for me about writing is I get to go back to my old articles every once in a while and see where my viewpoint has matured, where it's changed... and where it's stayed rigidly the same while I rack up an impressive run of, "told you so" outcomes.

Way back at the end of 2015 I put up a thing about Waste, in which I suggested you could differentiate a hopeless team from an okay team from a great team by their attitude to pointless unproductive activity.

I still stand by that viewpoint, but it's not the thing - it's the thing that gets us to the thing. I was reminded of this because I had a conversation the other day about how to know when you're getting it right, and I barely mentioned waste at all. Blame another 3.5 years of experience and too much time staying up late at night reading Accelerate. So what was the viewpoint I superseded it with?

You know you're doing well when your average lead time is short.

This means that on average when you have an idea, that idea will be in customers' hands within weeks or even days. A small number of weeks or days, not one where using months or years would be more appropriate. This won't - and shouldn't - be the case for everything as you'll have some longer term strategic bets, but you should still be in a place where getting from "we should do this" to "it's released" is more toward the time it takes to read A Song Of Ice And Fire than the time it takes to write it. Similarly, "on average" means you can't judge yourself by the one card you managed to release within a single sprint; you've got to be consistent to give yourself the pat on the back.

And?

This is great and all, but it's very much an output metric. You can't go to your team and say, "hey, have less lead time, it'll be totally more Agile". Well... you can, but it's not going to have results unless you count laughing behind your back as a result. What's sitting under that lead time metric, making it happen?

Stick on your Shadows records and let's go back to 1961 to look at something called the Kingman Approximation. This little bit of maths approximates the waiting time for a machine in a factory to process some inputs. In full, it looks like this:

E(W) = ( ρ / (1-ρ) ) * ( C_a² * C_s² ) * μ_s

Where E(W) is expected wait time, C_a² is the coefficient of variation of time for materials to arrive, C_s² is the coefficient of variation of time for the machine to process materials, and μ_s is the mean time for one process. I'm deliberately glossing over these because you can treat most of these as constant. The interesting bit of the Kingman approximation is that (ρ / ( 1 - ρ ) ) part.

I haven't defined ρ yet, so here we go: it's the utilisation of the machine. This is calculated by dividing the mean time to process a thing by the mean time between new things arriving. That relationship of E(W) ≈ (ρ / (1 - ρ)) gives the following:

It might seem counter-intuitive that you have an asymptote approaching infinity at 100% rather than a linear relationship, but think about it: if things are arriving faster than you can process them your input queue will constantly be growing and therefore the average time you'll wait for something will eventually be infinite even if the front of the queue is still being processed. Going back to my original bold statement, it's that average lead time we care about, not the, "I tapped someone on the shoulder and they jumped straight to that" lead time.

Saying No

From this we can see that if Kingman is correct and the posit we want short lead times is also correct, the only way forward is to reduce the utilisation of the machine - in this case, the team. The definition of ρ gives us two levers to pull. We can either:

• Reduce the mean time to service a request.
• Increase the mean time between requests arriving.

The former is why I still stand by what I said about waste. A good team who keep their lead time short won't tolerate things which increase the mean time to service a request for no useful output. Therefore if "short lead time" is a measure of team performance we'd expect to see the high performers eliminate waste and the low performers allow it to build up and slow down their development.

But this only gets you so far. Eventually you need to pull the other lever - make less stuff arrive. If you have a backlog that's constantly getting new things added to it, the time to service any one thing is going to get longer. You might even get to the point where so many new things are becoming top priority that the average item in the backlog never gets done, i.e. you hit infinite wait time on average even though it feels like the team are always working on stuff.

And how do you do this? You say no. Not, "no, we'll make it a lower priority." Not, "no, we'll figure out a quicker and dirtier way to do this." Not, "no, we'll put it to a another team and deal with the tech debt of doing it in the wrong place later". You straight up say, "no, we will not do this thing" and stick by it.

This is hard to do. If you're not used to saying no it will result in bruised egos, angry conversations and the nagging doubt that you've missed out on some attainable opportunity. It means learning not only to prioritise, but also to focus: which of these two important things is more aligned to what you do as an organisation? Which one makes sense? What has long-term importance and what is merely a temporary distraction?

Again we're into counter-intuitive territory but think about it. How many times have you worked on something that seemed critical or important only for it to be a flop on launch? How often did something that was supposed to be game-changing end up merely another burdensome liability that had to maintained and supported for little benefit? How many of these instances were off the back of someone declaring importance by fiat or giving out an arbitrary date without considering the consequences?

This is the deeper problem with saying yes to everything: if there's no need to prioritise things and justify them against your roadmap and the wider sense of what it is you're about, then it's easy to pick what's within reach and not consider what might be higher up the tree. This is the surprising result I've found wherever teams and organisations have started saying no - not only do they get things from idea to execution faster, but the things they work on are more impactful. Asking "should we do this?" doesn't just ensure only the best ideas make it to the work queue - it raises the standard of the ideas being brought to the discussion in the first place.