Going Faster Doesn't Get Sooner - Doing Less Does

I think an image of Sysiphus pulling a backlog up a hill sums this post up. Co-pilot wants the agile coaches to wear capes and a sprint review party at the top of the hill. Scary stuff!

I say things like ‘Humans cannot intuit multiplication’, ‘complexity is multiplication’, ‘we can manage complexity but not remove it’.

TLDR

The glue for all this is that the amount you go faster does not produce a straight line with reduction of time to get there. As a result the approach to be able in reduce delivery time in a linear way cannot just be about capacity increase - it has to be accompanied with reducing the amount of work being done (ie the distance). The good news is that most systems contain 80% waste. This is why any approach to improving engineering delivery timescales must also take a hollistic view and optomise the organisation for engineering delivery - afterall we know we must subordinate systems to their bottleneck.

Stop talking about velocity

How long does it take to cover a distance to arrive at a location as we increase velocity?

to explain the analogy up front:

• Distance is the amount of work done - it represents the amount of ‘steps’ taken
• Location is the desired outcome - the value of all this work is arrival. When we don’t arrive then all was for nothing
• Velocity is the amount of distance towards location per time period

The difference between speed and velocity is that velocity has a direction. Origionally this was a piece about speed vs velocity - however because the shortest path is theoretical the example felt childish.

A linear increase in velocity has diminishing returns!

This graph shows that as velocity linearly increases the difference in time taken decreases.

It cannot be understated how important this is. It means that to begin with a small increase in velocity has a tremendous effect on arrival time, however once moving past 30-40 an increase in 10 produces very little difference in arrival time.

10->20 halves the time from 10 to 5. 40->50 reduces time from 2.5 to 2, that is a 20% reduction

A 20% reduction?! Most people would expect this to be a 25% reduction. I would make this mistake too unless I was being exceptionally careful. I will let the reader try to figure out why we make this mistake - it will help you identify situations where you are in danger of making it. This is the battle we have here, things seem backwards to our intuition.

By talking about velocity we encourage a culture of wanting to go faster - the problem here is that we know that going faster doesn’t make a significant difference in arrival time on any team that has already made a few iterations of improvement.

I tried to explain this to somebody once, he drew a crappy picture of a plane and saying that waste is drag and that all we need to do is reduce drag. The problem here is that drag also has a non-linear relationship with velocity. All of the metaphors around scrum talking about velocity are broken and direct peoples attention towards analogies that are highly counter productive.

Don’t tell people their baby is ugly

So if increasing velocity has very little difference on our arrival time once we make a 2-4 steps of improvement then why are we so focussed on it?

I have no idea - maybe its because our methodologies reflect the completley counter intuitive nature of these systems? It does concern me however that as an industry very few people are talking about these things whilst so many are parroting without critical thinking.

If we measured these things then we would all be observing these problems - arguably we are because we all know that most projects are late / reduced scope / over cost - normally all 3. Unfortunatley it is nobodies benefit to point this out about projects or to record it which blocks our ability to learn. Hence a catchphrase of a trusted collegue to me regularly -‘Nobody likes it when you say their baby is ugly’.

If we can’t get there sooner by going faster then what?

So what things are linearly related in this metaphor? Distance and time!

What if instead of trying to go faster - we simply tried to do less? Now we have a linear relationship. If we have to do 100 things and we do 10 in a time period then it takes 100/10=10 time if we remove 10 things and keep speed the same it takes 90/10 = 9 time

Eliminating things reduces work linearly with time. The value of constantly removing things constantly delivers value.

The obvious objection here is that the cost of finding things will increase with time - but the same is true with velocity. It takes tremendous energy to increase velocity. the difference is that the outcome from increasing velocity diminishes with its increase wheras the outcome of removing things that we have to do remains constant.

So to go quicker find ways to do less

So the next time you are on a project and we want to go faster - as always - then when someone wants to add people, introduce a new step etc we know that we need to ask a bunch of questions.

Instead when we want to go faster we should be asking ‘what do we do?’ what is our process, what steps do we have and how can we find ways to reduce the steps.

The TLDR is

1. steps imply a handover process
2. having handover implies communication loss and so quality reduction

We haven’t talked about feedback loops here directly - suffice to say, quality reduction causes an increase in rework which causes feedback loops. Feedback loops increase the distance. This is why a focus on bottlenecks and feedback loops can provide easy to identify points to yield dramatic improvements.

If your organisation is incapable of changing its process and system there is no hope. Scaling people is just scaling velocity and we know what the best case outcome of that is from above - the reality is far worse. We have to understand the steps and quality.

The Pitch

These systems are counter intuitive. Because I have spent years in these problems I see things differently. I want to come and help you build the knowledge and tools to embed these physical truths into your organisation. When we find ways of working that go with the flow instead of fighting it we can achieve amazing things.

These ideas are not new, I am no genius - I first read about them in mythical man month when I was a teenager, a book written before I was born. But I like to collect, organise and exploit ideas and then help share them so that you can have a running start into these kinds of problems. I love them - and hope you will too, this is just the tip of an iceberg.

Bring me in, I can coach engineering teams in TDD, refactoring building up to continuous deployment. But I also have spent a decade on product problems figuring out how to measure, path to value and designing product and technology teams to align to this value in order to facilitate scaling. My passion is in connecting product into devSecOps - for me it is just an extension to quality engineering and a natural part of ensemble engineering.

I see an industry where people think they are buying risk reduction through buying companies that can throw bodies at problems. Whilst this will get there eventually there has to be a better way.