Be Available, Not Busy
We all like to be busy; at least most people I’ve worked with would much prefer to get on with something than just sit around all day twiddling their thumbs. That’s not to say taking a break once in a while is not desirable, or even beneficial, but that by-and-large we generally have a good work ethic which means we want to pull our weight and make an equal contribution to the team’s efforts. In essence if we’re always busy we can’t be accused of not earning our keep through being idle.
However anyone who’s ever had to employ builders to do any non-trivial building work, like an extension for example, will be all too aware of how detrimental busy people can be to a project’s progress. The extension starts great – the builders are in full time so the footings and walls spring up nicely and they move on to the roof. Then the unexpected happens – it starts to rain – and the builders don’t appear that day. It might be for safety reasons they haven’t shown up, or just because no one likes working outside in the cold, driving rain when they could be doing something else in the warm indoors instead.
The following day it’s raining again and it’s a no-show as before, fair enough. But by the fourth day the rain has stopped and the builders are still nowhere to be seen, so you give them a call to find out what’s going on. It turns out it was unsafe for them to put on the roof in the horrendous weather so they spent the last few days on another job whilst waiting for the weather to clear up. Despite the rain stopping they decided to finish up this other job as it was only going to be a couple of days. Only, this other job hasn’t quite gone according to plan either and the owner currently has no windows so they really need to get that sorted before coming back to carry on your extension. They’ve sent the faulty ones back and the manufacturer has absolutely promised them replacements this afternoon…
And so it goes on. This is a classic example of how people’s desire to be busy means that their own agenda comes before that of the project – in this instance your extension. Your goal is probably to have the extension built as quickly and cheaply as possible with the minimum of disruption, whereas the builder’s is likely after maximising their income. To offer the cheapest price and yet still earn income on days where work on your project is not possible, they will find other paid work to do. The alternative for you and them would probably be a retainer in the form of a more expensive overall cost. Don’t get me wrong, I’m not suggesting that builders do not have our interests at heart as I’m sure they want a successful outcome too, but that their top priority and the customer’s top priority may not always be in alignment.
This effect of context switching and delay often becomes even more apparent as the project moves to completion. Once the structural work is done and we move onto the plumbing, electrics and decorating then, every time we have a handover or need a different trade, we may have to wait an indeterminate amount of time for them to become free if they are not being very tightly orchestrated. If the job is not done satisfactorily any rework may also have to be fitted in around other client’s jobs and so the eventual date of completion gradually slips back again, and again.
So that’s how it pans out in small scale construction, but how about for software delivery?
There are potentially different forces at play here because of inherent differences in the two industries, but there are definitely parallels, even when you have a dedicated team on a software project. Unless the team is truly cross-functional with the full gamut of infrastructure and security skills, along with complete autonomy, it will require collaboration with people outside their control. The question is whether inside the team, at least, they can operate in a way that reduces delays and maximises the flow of features.
Intuition tells us that if everyone is working as efficiently as possible then the whole team must, by definition, also be working as efficiently as possible. Hence if we’re always busy we are being efficient (time wise) because there is no slack in the day. And this all makes perfect sense if the aim is to keep people busy, but sadly it does not appear to be the most effective way to get new features and fixes as quickly into production as possible.
There is a moment in Eliyahu Goldratt’s The Goal where there is a suggestion that it may be more beneficial for a worker to be idle for 10 minutes than to immediately get on with the next piece of work. This almost certainly sounds like heresy and goes against our intuition which is likely why the characters in the book were suspicious of the hypothesis too. The difference of course is that the work they could pick up now might not be as important as the piece they pick up in 10 minutes time. If they start work on a lower priority task and have to finish it, it will delay the start of the higher priority one. Anyone who’s ever looked into priority inversion problems in a multi-threaded system will be all too aware of how lower priority work can starve the more important stuff when it can’t be interrupted. The overall effect is that work is being done but it’s not necessarily the work we want to be done right now.
In software delivery we’re ideally looking to ensure that the moment a piece of work enters the team the finished article pops out the other end as quickly as possible. The quicker we put a feature into production the quicker we can exploit its “value”. Potentially more importantly though is that the faster we can move a change through the pipeline the quicker we can remediate unforeseen problems and react to new customer feedback. Unless you’ve got a product owner who paradoxically believes “everything is the number one priority” then you will find greater riches in ensuring you finish what you start, rather than keep starting new things.
Context switching, as we know from watching computers thrash about when they have too many tasks on the go at once, does not appear to be the answer – smaller units of change (done to completion) however appears to work better. If you’re used to working on features that take many days or weeks to complete then it might seem impossible to imagine how you can break your work down into such small pieces that they generally only last a few hours to a couple of days, but in many cases you can.
For example refactoring work, by definition, does not change the observable behaviour of the system and therefore is a candidate for delivery into production the moment it’s complete. Similarly the use of feature toggles enables us to deliver working code straight into production, even if real users don’t have access to it whilst we iron out the wrinkles. Finally the use of “spikes” allows us to decouple the act of learning about a problem from delivering the solution to it.
Outside of writing production code the modern programmer has many other tasks on their plate too which can be separated off into distinct units of work. These can be independently prioritised and executed, such as documentation, updating tools, reviewing other people’s changes, improving the deployment process, monitoring, etc. Even if all that is done and dusted there is always far more learning to do than we have hours in the day so reading a few blog posts, book chapters or articles about the tools and technology stack is another excellent way to spend a very small amount of time in a valuable way. Note that this should not be “busy work” work invented just to keep you out of trouble; everything we do should be because it adds value to the product directly or indirectly through improving the delivery process – “being available” does not mean “killing time”.
The net result of this decomposition of chunks of work into much, much smaller units is that it’s easier to smooth out the flow because at the huddle each day you can reprioritise based on the previous day’s events. With really small tasks (on most days) people in the team are available to either pick something new up or even pair or mob with others to help get the most important feature out the door. If someone goes off sick for a few days, rather than waiting for their return you could probably finish whatever it was they were doing, or even repeat their work again because the time lost is minimal and you may generate more disruption by trying to work around their unfinished efforts.
Being busy is a natural state that we will find ourselves in most of the time, but that should be because the work we are doing is effectively the most useful thing we could be doing at that moment in time. What we need to be aware of is the consequences of being busy all the time so that we begin to lose sight of the proverbial wood hidden behind the trees. Not all tasks are created equally and some even become redundant before we’ve started them so it’s important that we keep re-evaluating what we’re doing and why. If you begin to realise you can fork off the latter part of a task into a separate lower value one and finish early you will be available to trade-off lower value work for something higher. Whether you actually do or not is somewhat irrelevant, being able to is what really counts.
Switching management styles to one that focuses on the outcome of the work instead of what each “resource” is up to is hugely liberating for the workers but also difficult for some to grasp. When a team self-organises almost on a daily basis to meet the demands of the product backlog it may be harder to know exactly what any one individual is up to or what contribution they may make to any single piece of work.
In essence it shouldn’t matter as long as the cost of developing any feature is less than the value it generates, but given how hard it is to put a figure on that for any one item, it’s even more important that the team continuously delivers a working product to see how the costs are measuring up. Always being available to work on the next most important thing helps ensure that the money is biased towards the more valuable pursuits rather than being diluted within bigger tasks of mixed value.
Agility comes from being in a position to make a change in direction sooner. To react to the ever changing landscape, which could easily be a daily occurrence (or sometime less!) the members of the team should work in a way that allows them to start and complete “useful” tasks in a small period of time. Being more aware of what is going on around us and where our current piece sits in the pecking order means we can make a judgement call on whether to soldier on alone, call for reinforcements or even stop short and offer ourselves up instead. If the spotlight switches from the people to the outcome then it helps those people to self-organise around that goal when their availability is higher.
Chris Oldwood
14 December 2016
Chris is a freelance programmer who started out as a bedroom coder in the 80’s writing assembler on 8-bit micros. These days it's enterprise grade technology in plush corporate offices. He also commentates on the Godmanchester duck race and can be easily distracted via gort@cix.co.uk or @chrisoldwood.