People say there are certain things that are hard to unsee once you’ve seen them. When you start to see software development and delivery processes through the lens of lean thinking, it seems you can never unsee it again. You can’t fail to notice opportunities for improvement. Sometimes it’s puzzling that others don’t see the same things, but it may be they’re looking at the situation through a different lens.
Years ago, I worked for a short time with Alan Shalloway, the founder and CEO of a small consulting firm called NetObjectives. He has applied lean thinking to problems in software development processes for many years. One of his catch phrases is induced work. It refers to a task (call it Task B) that is only necessary because of the way someone performed some other task (call it Task A). Often, Task A could be performed in a way that does not induce the need for Task B at all, and the process could be simplified.
Al had a presentation slide that contained a cartoon of two men digging holes. They were back to back and not watching each other work. Both men were throwing dirt into the hole the other man was trying to dig. Neither of them noticed. They just kept on digging. The additional digging was induced work, caused by the way the men were working.
Often enough, people create unnecessary work for themselves. The same person who performed Task A ends up saddled with Task B as well, due to the way they performed Task A. They don’t see this because they aren’t looking for it. We tend to find what we look for. Lean thinking leads us to see this sort of thing.
There’s a lot of induced work in the way software teams carry out their tasks. Often it’s the result of teams never examining their process to discover places where flow is impeded or interrupted. They aren’t looking for impediments to flow.
Instead, they look at their work in terms of whether they are dutifully performing the defined steps in some process – be it a formal process or a de facto one, a set of habits that came about in their workplace and has never been revisited to see if it is still relevant and helpful.
Maybe we’re having difficulty delivering software changes without delay. Somehow, adding more developers to the team hasn’t helped. It seems to have slowed us down even further. How many more developers should we hire?
Maybe we hold formal code reviews. We know there’s value in reviewing code. The review sessions halt flow and create backflows. We want the value of reviewing code without the interruption in flow. How can we improve our code reviews?
Maybe we work on feature branches. We know there’s value in merging changes. Merging the branches halts flow. “Merge Hell” is induced work. We want the value of smoothly-merged code without the interruption in flow. How can we improve our merge process?
Maybe we use a pull request process to manage changes by multiple developers. We know there’s value in vetting changes and getting the right changes into main. The PR process interrupts flow. It’s induced work. We want the value without the extra work and lost time. How can we improve the PR process?
Maybe we find we’re spending more and more time in each release cycle on regression checking. We know there’s value in detecting regressions early. The testing processes halts flow. How many more testers should we hire?
There are better questions to ask.
Adding more developers also adds more intra-team and cross-team communication paths. That means longer lead times for changes. It doesn’t matter how skilled the developers are.
Formal code reviews tend to lock senior developers into a permanent role of reviewer, and prevent others from building their skills to offload some of the heavy work from their senior colleagues.
Feature branches create Merge Hell; the solution is mainline development (also known as trunk-based development). A PR process may be necessary for distributed teams that work asynchronously (e.g., Open Source projects), but is not necessary for a corporate software development team that collaborates in real time (even if remotely). Mainline development is safe for teams who practice robust and proven software engineering methods, and who collaborate closely so that everyone knows what’s going on. In fact, the quickest way to complete a list of tasks is to finish them off one by one, and teams that use Ensemble Programming do just that. There are no “extra” branches to merge.
Adding more testers to handle the increased regression checking workload will only slow the process down. It doesn’t matter how skilled the testers are. That kind of checking can be automated, mostly.
If teams would only stop shovelling dirt into each other’s holes and learn to see their work through a lean lens, they would probably discover even more effective methods than we know of today. Before they can get there, they need to catch up on the problems that have already been solved, like the ones mentioned in this post.
I frequently observe that teams don’t assess their process to find interruptions in flow. Instead, they tend to create more and more overhead activities to try and compensate for the problems. I wrote about this recently under the heading, Institutionalized Workarounds. Rather than eliminating unnecessary work, many people try to “do the wrong thing righter.” Things get worse instead of better. They don’t see the reasons why because they’re looking for something else.