I once engaged with a team that had just finished the development of a new service and were blocked, waiting for legal approval, before they could turn it on. They effectively had nothing to do and so management thought this was a good time to bring some coaches in.
We didn’t know how long we’d have before the approval arrived so we started with a bit of training on technical practices and then started working all together (ensemble work) on reviewing and improving their existing code. We refactored the code to make it cleaner and more maintainable, and improved the automated testing. We optimized their build pipeline and got them ready for continuous delivery (CD), something they hadn’t previously considered.
When the legal approval came along a few weeks later, this codebase was already in far better shape than when we’d arrived. The code was cleaner, there were fewer bugs, and all the team members had a better shared understanding of everything.
Additionally, this new service was released on a working CD pipeline, releasing to production on every commit.
How was this all possible? The most significant reason is that for the first time, they had no delivery pressure. Nothing was splitting their attention twenty different ways. Nobody was insisting that they work on multiple things at once, or watching to make sure they were busy.
Their only goal was improving what they already had. They had time to focus on the quality of the code. They had time to optimize their pipeline. They had time to learn new skills that they didn’t already have.
And then they delivered something amazing.
The most frequent objection that I get to new improvement activities is “delivery pressure”. We’re too busy to do that now. The problem, of course, is that no matter what we might tell ourselves, that pressure is never going away. We won’t have time to improve unless we make time.
If we don’t improve then we’ll continue to deliver at the same rate that we were delivering before. If we do improve, we’re likely to deliver much faster than that. There is a cost to not improving, and it’s one we often disregard.
If that team at the beginning hadn’t taken a few weeks to fix their system then they’d still be responding to quality issues the way they always had. They’d still be manually deploying the way they always had. They’d be just as busy, and as ineffective as they always had been.
They were lucky. A legal complication had given them an amazing opportunity to improve and they did. Other teams aren’t as fortunate and don’t have that slack time handed to them.
If we want to improve, we have to make the time for that, regardless of how much delivery pressure we might feel.
See also:
- Tom DeMarco’s classic book Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency
- Playing the long game