Improving flow: why it's better not to be busy all the time

As a conscientious person, I like to be busy. I'm not alone in this - many people will actively seek out work as soon as they've finished the last piece, to ensure they feel like they're adding value to their team every minute of the day. The trouble is, their great intentions may be exactly why their team is so slow at delivery.

If you've read The Goal by Eliyahu Goldratt, you'll be familiar with the idea that 'bottlenecks' in your production line (or software team) will obstruct the flow of work through your system and slow down delivery. In other words, you need to look for the slowest part of your delivery cycle, give it as much support as you can and allow it to set the pace of delivery. For example, if you're working in a team with a single tester and 4 developers, it's a good bet that testing is likely to be your bottleneck. If developers only write code and testers only test, you're going to quickly find that work stacks up behind the tester. They'll have very little to do when the developers start coding, only to be met with an avalanche of work as soon as the newly developed features need testing.

There are a number of things you can do about this: working cross functionally (i.e. developers and testings working together to get code to 'done'); focus on 'right to left' delivery (get something that's nearly finished to 'done' before you pick up something new), and introducing Work in Progress limits to protect your bottleneck of testing and alert the team when support is needed in this area.

These process changes will help, but you will also need a shift in mindset.

Developers often feel they're providing most value when they're coding, testers when they're testing, designers when they're designing, etc. So imagine this scenario: it's the last day of the sprint, the tester has been supported and it looks like the team's whole sprint backlog is going to get delivered by the end of the sprint. But there's nothing in the 'to do' column and the developer is starting to get anxious that it looks like they're doing nothing. Shouldn't they just get a head start on the next sprint's work?

NO!!

I find a useful analogy is of traffic on a motorway. If the motorway is completely full on every lane then nothing moves at all - there is no flow and everything grinds to a halt. However, if each lane is only 20% full, all the traffic can move freely and get to their destination much more quickly. With space between cars, each driver can adjust their speed, change lanes and react to what's happening around them without disrupting the flow of cars behind them. Those spaces between cars are crucial.

It's the same in a software team. If everyone is 100% busy on delivery work all of the time, it's impossible for work to 'change lanes' - or move from one person in the team to another. Code reviews and merge requests go unanswered. Tickets wait for days for someone to test them and everyone is too busy to prep the next release - nothing gets delivered and flow stops. Teams need a little slack to react to anything unexpected and to ensure that work continues to flow. Being busy all the time means nothing will get done.

That doesn't mean it's time to kick back and stick Netflix on your screen. But if you've truly thought right to left and there's no planned work downstream that you can add value to, then it's OK to not start something new. Can you refine tickets for the next sprint? Find out a bit more about your customers? Learn about a new technology? Catch up on your inbox nightmare? Take the time to breathe, catch up and avoid piling up yet more work downstream. You'll feel better for it, and your team will deliver more as a result. It's OK not to be busy all the time.