The myth of full utilization - Part 2: Flow efficiency

In my last article I discussed several reasons for why I think that parallelizing software development work at all costs is not such a good idea. I didn't present an alternative though which makes the post pretty useless on it's own. Let's change that.

Most often the concept of parallelizing work originates from the desire to maximize what is commonly referred to as resource efficiency. The goal is to keep every individual engineer continuously busy to get the maximal possible output in the given time. As we've seen this can have some severe downsides, so let's look at the alternative: flow efficiency. 

A disclaimer upfront: in my experience there is no silver bullet. Every team and every project are different and so will be the optimal work-mode. Strategies that yield good results in one domain might be problematic in another. You'll have to try things out and see what works best for you. The important thing to keep in mind is that you want to optimize for the project, not for individuals (1).

You want to optimize for the project, not for individuals.

You can reap the benefits of parallelization without putting up with its drawbacks by having the whole team work on the same topic at a time. For example, two developers could work on different aspects of a new feature while a third one implements the unit-tests and the QA engineer prepares the integration tests. Since everyone is actively involved in that same feature, the overhead for explicit information exchange is minimal. Working together, the engineers will almost certainly come up with better solutions and code-reviews should be very quick. The team spirit will benefit, information silos will cease to exist and there'll be much less potential for creating loose ends. 

If the features are too small to be tackled by the whole team, you can scale down the approach and create sub-teams that work on one feature each. In that case it is crucial that you mix / rotate the sub-teams continuously so that all engineers work on every part of the codebase every once in a while. In any case, all engineers should talk about the implementation ideas upfront and do code-reviews after finishing the task.

As pointed out in my previous article, late integration imposes a lot of risk on your project and may result in a significant slowdown late in the game. Therefore it's generally a good idea to structure the roadmap in short milestones. Not only does that allow you to identify technical problems early. It also enables you to get user-feedback on your features quickly and change course if necessary. Since a lot of the features you implement will actually turn out not to be beneficial (2), this can be a bigger cost saver than any optimization of your development processes.

Getting user feedback quickly can be a bigger cost saver than any optimization of your development processes.

As individual engineers it is really important that you try to shift your perspective from your own tasks, progress and productivity to that of the team. There often is a significant difference between what would make you most successful right now and what the project needs the most. In other words, if the rest of the team is blocked it is more or less irrelevant how fast you are. You also need to get away from any sort of superstar mentality ( "I'm the only one who can do this" ). I assure you: most likely you're not. And if you really are this needs to change. Being an information silo is not an asset, it's a liability. It means that you are a single point of failure for the project. That might be massaging your ego but for a professional engineer it's a definitive no-go.

If the rest of the team is blocked it is irrelevant how fast you are.

Putting this shift of mindset into practice can feel really uncomfortable, especially to less experienced engineers. It definitely is an awkward situation not to be working full-steam on a task of your own when your project manager demands faster progress. In that situation the urge to pick the next ticket from the ToDo column can be really really strong and all the rationales I've given so far may seem theoretical and idealistic. That is a natural and understandable reaction, our intuition fails us here.

Maybe it helps a bit to keep comparable situations in mind where our intuition works better (3):

• think about your computer. How productive is it to work with when all it's processor cores are 100% busy?
• think about a street during rush-hour. All it's lanes are fully utilized, but how fast does traffic go?

However, if the rationales weren't enough to convince you or your project manager, chances are that metaphors won't do the trick either. And unfortunately it's really hard to get reliable data to prove the point. After all, you'd have to have two equivalent teams that execute the same project in parallel with the work mode being the only difference. And you'd have to repeat this experiment several times to make the results trustworthy. To my knowledge, nobody has yet invested in this research.

What we can do though is take a look at other domains. The widely used software-engineering methodology of Kanban implements the same concept of teams working together on the tasks by prescribing strict work-in-progress limits (as my colleague Alex Pukinskis formulated it recently: "starting a new task is not the default move in Kanban"). As it happens, Kanban originates from a production-workflow that was implemented at Toyota which today is one of the biggest and most successful car manufacturers in the world.

70% of the work is done by only 30% of the workers

If that is still not enough, let's take a look at the most competitive environment of all: evolution. Any species that does not claim it's niche in the ecosystem with maximum efficiency will eventually be replaced by one that is more efficient. I think it's safe to say that ants are a very successful species around the globe, creating impressive colonies. Yet, when ants build a tunnel 70% of the work is done by only 30% of the workers (4). Two thirds of the ants seem to be slacking (they aren't, they are keeping themselves ready to support, but as a casual observer you probably wouldn't notice). Apparently nature found out in millions of years of trial and error that this is the most efficient way of working.

I hope this article was useful and has given you some ideas how to tackle these common challenges in software engineering. Thanks for reading, I'm happy to learn about your experiences and strategies.

TL;DR:

Focusing on flow efficiency, i.e. the productivity of the team, instead of optimizing for maximum utilization of every single engineer will likely give you better results faster and with less risk.

References:

1. https://www.jrothman.com/mpd/agile/2015/09/resource-efficiency-vs-flow-efficiency-part-1-seeing-your-system/
2. https://www.youtube.com/watch?v=2zYxWEZ0gYg&feature=youtu.be&t=1483
3. https://www.agileconnection.com/article/management-myth-1-myth-100-utilization
4. https://science.sciencemag.org/content/361/6403/672

Acknowledgements

Many thanks to Tom Smith for introducing me to the concept of flow efficiency and the rationales behind it. I'd also like to thank Alex Pukinskis for his insights on what the important aspects in Kanban really are.