Full utilization and whitespace
Recently, I found myself having conversations, both at work and online, on the topics of Sprint Tetris, backlog length, and cognitive load.
I had the feeling that I was having the same conversation over and over again, but was unsure of what the connective tissue was until I remembered Dave Farley’s most excellent talk on “Taking back software engineering” at YOW2017, where he drew some parallels between manufacturing and software engineering.
In manufacturing, there were three distinct eras: craftsmanship, mass production, and lean.
In software, we are mostly still building using the craftsmanship approach. We skipped mass production as a boneheaded idea, and have not quite yet achieved lean-like-parity, although agile software development, devops, et al. are some transitional lean-like artefacts.
I suspect the fact that mass production is a boneheaded idea for software may, however, have escaped some people’s notice. This may explain the appearance of some artefacts which are usually associated with “cost and efficiency” mindsets rather than a value mindset.
In mass production, for instance, if you want to churn out a metric bajillion of gizmos, you get your hands on as many gizmo components as you can and put them on a conveyor belt leading to the gizmo-assembling machine. Assembled gizmos get carted off to the packing plant and shipped off to parts unknown. Want more gizmos? More machines! More components! Run 3 shifts a day! MORE!
And if we were trying to apply the ill-advised parallel in software, what would we do?
We could, for instance, have a gigantic backlog of stories, going forward quarters, years, even! From our enlightened bird’s-eye view, we could manage the dependencies and ensure simultaneous delivery!
We could treat each iteration as an opportunity to fully utilise our teams and extract the maximum amount of work from them! Every man-hour accounted for, with flawless precision, full utilisation! MORE!
The results are as predictable as they are unavoidable.
A fully utilised highway resembles nothing so much as a malodorous parking lot.
Likewise, the productivity of a technology delivery team has clearly diminishing returns after a certain level of utilisation. Some reasons for this:
- Simple mathematics: a constant level of skill and technique applied to an increasing level of complication and complexity in the technical domain yields ever-decreasing value-adds.
- My so-called “Second Law of Agile Thermodynamics”, that I alluded to in Some riffs on sustainability — practices decay if not maintained.
- Technical debt accrual: With no time available to improve their work, the team will be unable to make their changes harmonious with the system, and functionality will become “tacked on” instead of “built in” until the whole system shakes itself apart.
- Architectural debt accrual: the technical (and business!) architecture that served you well at a given point in time will almost inevitably cease to serve you at some time in the future. Full utilisation precludes the teams from evolving the architecture so it serves your business and software. Instead coupling goes up, alignment goes down, and change becomes increasingly difficult.
At this point in my draft, my wife was looking at the illustration and reading over my shoulder. She said: “Ah, it’s like visual design with insufficient whitespace”. Gentle reader, I was floored. Her piercing insight has, yet again, led me to conclude she keeps me around to reach the high shelves and provide occasional entertainment value.
A “fully utilised team” is, indeed, exactly like a design with insufficient whitespace. Let’s look at some of the jobs we hire whitespace to do in design:
- give space for attention
- enhance focus, prioritisation, flow
- provide comfort and serenity
- signal quality and value
And when you think of it, are these not the very same things we want to enable in our work?
Once you step away from “full utilisation” and create the appropriate amount of whitespace in your work, a few things may happen:
- You may look back at work you did and realise you have learned something new and useful. This will increase the quality of all future work.
- You may look back at work you did and realise it’s not really up to par in some way. You now have an opportunity to go back and fix it, maintaining readability and preventing the accrual of technical debt, thereby making all your future work easier.
- You may be better able to grasp pieces of work in context, understand their place in the value narrative, and focus your attention on how to deliver them with consistency and integrity.
- You may feel the space, confidence and safety to engage with your work to the best of your ability, instead of justifying compromises in quality and customer empathy.
How do you feel “whitespace” — or the lack thereof — impacts your work?