I’m a developer who is fascinated by the delivery flow in project management systems. I’ve spent a lot of time thinking about it, and read books like Agile Management for Software Engineering, The Art of Agile Development, Slack, and my personal favorite, The Phoenix Project.
The Phoenix Project has really opened my eyes to the many inefficiencies we face. I’m also really fortunate to have had the opportunity not to just study different delivery methods, but to practice them by managing delivery teams.
For this article I’ve decided to combine my two passions: software engineering and delivery flow.
In fact, I’ve ended up building a basic throughput simulator!
What You’re Going to Learn
- Eight major inefficiencies that increase wait time
- How the following delivery flows perform in practice:
- Why everyone should chill out and give each other some slack
- Why wait time is the root of all evil when it comes to efficiency
- That it’s all about the team, not the individual, when it comes to delivering software
The 8 Wastes in Software Development
Before we start, it’s important that you understand different types of waste in software development.
This list is not comprehensive, and I am sure that someone could write a book on this that runs hundreds of pages long. But this list will give you the main models you need to consider.
These inefficiencies occur when you are moving artefacts around. Perhaps you’re submitting code to several branches, or cherry-picking check-ins.
This is when produced artefacts are not being used.
Artefacts such as:
- Architecture designs
- Graphics and wireframes
… are produced weeks or months upfront. The moment an artefact is produced, it’s out of date and needs changing.
These inefficiencies occur during the creation of artefacts.
Most developers need to juggle many tasks at the same time. There’s a cost that comes with context switching and multitasking.
Maybe you need to keep track of different software versions, projects and roadmaps. Or people are constantly calling you, or coming over to see you about something.
You need to pick up work that you haven’t touched in days, months or years, and you need to relearn what you’ve already done.
You’re waiting for your check-in to build. Or you are waiting for artefacts to be produced.
Your IT infrastructure is flaky, your computer stops working, the internet goes down, or the email server is not working.
Your testers in the team get back-ended. They’re waiting around for work for days, and get it right at the end of the iteration.
You have discovered that you have misunderstood the requirement — now there is more work to do.
Or maybe you’re waiting on someone to review your code.
You’ve produced your software, but you’re not shipping it. It’s sitting on the shelf and nobody is buying it. The work you’ve produced is no longer needed.
This happens when you produce artefacts that weren’t requested.
You’re polishing your code and adding in extra extension points for those amazing features that’ll be built in the future.
You actually working on something that nobody asked for, and you are doing it because it’s “cool”.
This occurs when your artefacts have errors in them.
What you have produced doesn’t meet the agreed acceptance criteria. Or maybe what it doesn’t meet the technical standards (performance, security, maintainability).
This occurs when the producer of the artefacts is being under-utilized.
Perhaps you have not been given adequate training to do the actual job. Or you can do much more complicated work… but it’s not being given to you.
What Is Slack?
Yes, it’s a messaging app — but in this case, I’m talking about an influential book called “Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency.” It’s 209 pages long — I’m not going to do it justice, but here’s a summary:
In order for your teams to be happier, less burnt out, more innovative, and for your organisation to respond better to change, you should add “free time” to your delivery process.
When you plan your iteration, you just add 10%, 20% or whatever percentage of time you decide for innovation.
Our simulation is going to put this theory to the test, and see if it improves delivery rate.
I’ve created a set of simulations for three project management methodologies. You’ll see them below, as well as a chart that will compare the throughput speed of each delivery approach.
This simulation was simplified for my benefit and yours. The ball in the queue can either move forward or just stay where it is (skip a turn). The ball in the queue can’t move forward if there is a ball in front of it. If the queue is full, a new ball will not be added to it.
How Are These Rules Relevant?
You might be thinking: why would the ball just stay in one place, why would it skip a turn? Well, I’ve tried to simulate the real world.
Remember the eight wastes? They all cause wait time, and this is why the ball might choose to skip a turn.
But this means that all the balls behind it can’t move forward. They are blocked. When ball is blocked, it will flash.
In the real world, things are also messy and a bit random. I’ve added some random blocks to all delivery flows to make things more realistic.
For example, Kanban should, in theory, perform amazingly as it minimizes many of the 8 wastes — but we are human, we make mistakes, and customer priorities change.
Let’s simulate some delivery approaches!
This is a sequential batch approach. One team of a particular discipline does some work and passes it to the next discipline, and so on until you ship.
Typically there is very little feedback, and when there is feedback it’s very late in the process.
People are mass-batching work and passing it down the chain.
However, very often, this work comes back up to the original author before going down the chain again.
Simulation with slack
This is a single piece flow approach. Cross-discipline or component teams are working on something, and release it immediately.
Feedback is immediate, and work is added and removed in an ad-hoc fashion.
Simulation with slack
Scrum is a parallel batch process. Cross-discipline teams are working on a problem at the same time for a short while, and then they ship their software.
Teams have retrospective meetings, planning meetings, grooming, and so on. Time is allocated for preparation and improvement.
Delivery Rate Comparison
This chart shows the number of balls delivered across every delivery approach after 10,000 iterations have passed.
What Can We Learn From This Simulation?
1. We need to chill out and cut each other some slack.
In any system where there is randomness, we should factor in some slack.
The more randomness in the system, the more slack you need to add.
By adding time you reduce randomness, which reduces the interlocks, which reduces the lead time. The slack time just allows you to deal with things better. However, you are paying for it — with time.
But the idea is that paying for it with time actually gives you a lot more time back. People make fewer mistakes, have higher quality discussions, are happier at work, share knowledge better, do less rework, and they don’t quit as often.
But it’s still a lot better to have a good, strong process in place, where randomness is eliminated as much as possible and there is a bit of slack factored in as well.
2. We need to reduce the wait time to increase the delivery rate.
(Delivery Rate) - (Wait Time In The System) = Actual Delivery Rate
This equation sounds painfully obvious.
But look around you. In your organisation, are things are setup to reduce wait time? The answer is probably going to be: no.
How do we reduce wait times? Here are a few tips:
- Have fewer projects going on at the same time.
- Make sure that delivery teams are small. Big teams require more communication and more management, which is all pure waste.
- Ensure that delivery scope is super clear by using INVEST criteria.
- Deliver just-in-time.
- Deliver just-enough.
- Give people time to do the actual work. Reduce the number of meetings and general interruptions.
- Break work down into very small chunks, so that people feel and see progress.
- Break work down into very small chunks, so it’s easier to estimate and plan.
- Give people more time to do something than they’re asking for. The worst case is that they will take longer because something came up (they discovered more work, got interrupted, etc). The best case is that they will actually deliver early and feel motivated to get onto the next item.
This list is not intuitive. It feels like we should do the opposite, as we live in a society where people think that by putting a huge amount of pressure on people, cutting down their delivery estimate, they can deliver faster and better quality work.
I blame self-help books for miscommunicating Parkinson’s Law: “work expands so as to fill the time available for its completion.”
This sentence is not a scientific ”law”, was not proven with evidence, and was taken out of context. People also often forget that being effective is a lot more important than just being efficient. People need time to think, in a positive environment, so that they can be effective.
3. It’s all about the team, and not all about the individual.
An important concept to remember: when you are in the system, it’s not about your individual delivery rate. It’s about the delivery rate of the overall system. Let me explain.
You might be a super efficient individual. You might work around wait time as you do overtime because you really love your work.
Let’s say you are programmer and you are doing this.
If you are not getting requirements from business analysts fast enough, you might end up guessing what you need to be producing next. As you are writing code almost blind, you are creating inventory, defects, and you are almost certainly overproducing.
You might want to refactor some code because it’s not that good. It has been sitting on the shelf for a while and you have not shipped it yet, but you just don’t like how it looks. In this case, you are most likely over-processing and creating waste.
Imagine you are a back-end developer and front-end is not yet ready.
Guess what will happen? You will start working on some other feature while the front-end developer completes his work.
This means that you are now working on two features. What if the front-end guy gets sick? Now you are working on three, four, five features.
In the meantime, no real value was added to the organization. Why? Because nothing was shipped, and nobody is using what you have written.
You are just building up inventory, and you are not learning anything as you are not getting any feedback from your customers.
Believe it or not, by being a super efficient employee and working on the wrong thing, you can actually do more damage then good.
If you really want to work hard, that’s fine! Refactor shipped but buggy code, improve quality of service (performance, security, etc), pair up with a junior engineer, improve internal processes, or do some research instead.
When you are in the system, you are only as strong as the weakest link in the system.
So fix the weakest link the system and enjoy a better delivery rate.
This is where the Theory of Constraints (ToC) comes in read my ToC article here.
The more randomness there is in the system, the more slack you need to factor in to improve the delivery rate.
Find the bottleneck and do whatever you can to reduce wait times to improve the overall delivery rate (this is what the Theory of Constraints teaches us).
Remember the eight wastes and ruthlessly remove them from your processes.
If you’re interested in seeing how these simulations work or would like to adapt them to create your own simulations, you can find the code on GitHub.
Zan Kavtaskin is a software engineer and architect. He works at MHR as a Software Design Director and he has also written software for companies such as Experian, Emirates and RoyalMail.