I’ve heard it said that sometimes we learn a different way of looking at things, and it influences the way we see the world from that point forward.
For me, one such way of looking at things is Lean Thinking. I became aware of that school of thought about fifteen years ago, and it had a profound effect on the way I approached my work in software consulting and team coaching.
As I learned more about Lean, it became the default lens through which I viewed software development and support processes. It changed the way I think about two concepts that people talk about a lot: value and waste.
My observation is there are two kinds of value and most people don’t distinguish them. Similarly, there are two kinds of waste and most people don’t distinguish them. One of the kinds of value overlaps with one of the kinds of waste. As a result, in many organizations people emphasize the wrong kind of value, while simultaneously treating some forms of waste as “value.”
Instead of striving to reduce that waste, they elevate its importance and build a formal process around it. The activity is necessary because something else is wrong with the process, but the people believe they have solved the problem. They have only created a workaround for the problem.
It feels like a “win” because the workaround does make things a little better; but the underlying problem remains.
Creating a Thing
Having devised a practical workaround for a problem, the team faces a choice. They can depend on the workaround temporarily while they work toward solving the underlying problems; or they can define formal processes, coin buzzwords, and write software tooling to make the workaround “better.” In my view, the second response maximizes waste instead of minimizing it. It happens often. The workaround becomes a Thing in its own right.
Some go further, and present the Thing to the world as if it were a real “solution” to something, through conference presentations, articles, books, podcasts, videos, meetups, and promotion on social media and online forums. Training courses, certifications, and other such decorations give the Thing a cachet of legitimacy. Once the Thing starts to generate revenue, there’s no going back.
The revenue may be the obvious kind – a big company markets a Framework or an Organizational Transformation Process, complete with paid training courses, certifications or accreditations, and Abbreviations of Distinction that may follow a certified practitioner’s name in their professional branding; a kind of badge.
But the revenue stream can be of a more modest sort, too – a Wonderful Thing that “only the best” coaches and mentors can teach your staff. Either way, it’s Game Over for solving the actual problem.
Institutionalizing the Thing
Originally, the workaround helped an organization or team that had not (yet) reached the level of maturity necessary to dispense with the wasteful practice. They had to do it because organizational constraints prevented their doing things in a more effective way – at least, for the moment.
But instead of cultivating mindfully the necessary maturity to make it feasible to eliminate the workaround, they became comfortable with the workaround and made it a “best practice.” Once a workaround becomes accepted as a “best practice,” people stop thinking about the underlying problems, because they believe they have solved the underlying problems.
The workaround becomes institutionalized.
Two Kinds of Value
In my opinion, the 2003 book, Lean Thinking: Banish Waste and Create Wealth in Your Corporation, by James Womack and Daniel Jones, remains an excellent introduction to the subject. I also recommend the business novel by Eliyahu Goldratt, The Goal: A Process of Ongoing Improvement. Another recommended reference is Principles of Product Development Flow, by Donald Reinertsen.
Womack and Jones define value in the context of Lean Thinking as anything your customer is willing to pay for. Ideally, we want to spend all our time building the products and providing the services that customers want to pay for. That work is called value-add activity.
But there are always other things we have to do in order to deliver that value. That work is called non-value-add activity, not because it isn’t useful at all, but because it doesn’t directly move the product toward delivery. Without it, we wouldn’t have the scaffolding or mechanisms or skills to deliver customer-defined value; or our product would lack characteristics like regulatory compliance, security, resilience, performance, usability, etc.
Lean Thinking derives from the manufacturing sector. Software work differs from manufacturing in a number of ways. For one thing, once you’ve set up an assembly line in the optimal way, you can just run the line. Every unit of product is the same. You can apply statistical methods of quality control. Active management of the process usually concerns matching the rate of production with demand, to avoid producing unsold finished goods inventory, and leveling the rate of flow, to avoid producing unfinished good inventory.
Software work isn’t like that. Every product is unique. To do the work effectively requires continuous learning and adaptation. The implication is we have to spend proportionally more time on non-value-add activity than is necessary in a manufacturing operation.
For example, in the financial sector, regulatory compliance is mandatory. But customers don’t consider regulatory compliance to be a “feature” of a software product; it isn’t what they want to pay for. They simply expect it, as well they should. We want to ensure our software complies with regulations, but we don’t want to spend an excessive amount of time and effort on that, since it isn’t what differentiates our product in the market.
The difference between value-add and non-value-add activity implies that we need to be cognizant of two different kinds of waste, and how best to address each.
Two Kinds of Waste
Three Japanese terms emerged from lean manufacturing in the 20th century – muri (overburdening), mura (uneven flow), and muda (unnecessary activity). The term muda is usually translated as “waste.”
Womack and Jones describe two forms of waste. Type 1 Muda is non-value-activity that supports requirements we can’t avoid, but that aren’t market-differentiating features customers want to pay for – like ensuring regulatory compliance.
Type 2 Muda is waste that has become institutionalized in the organization for historical reasons, but that could simply be discontinued with no negative impact to the business. You’ve heard people say, “It’s always been done this way,” without being able to explain why it’s done that way.
Compared with manufacturing, effective software development and delivery involves more activity that the customer is not asking for explicitly. Software professionals must keep their skills up to date and sharp. Development teams must ensure the product does what they intend it to do, even if that requires activity other than simply putting the pieces together. The mechanics of coordinating work performed by multiple individuals or teams creates process overhead. Some (hopefully, most) of that overhead yields a kind of secondary “value” in that it enables the organization to produce customer-defined value effectively.
Type 1 Muda In Software Development
People who work in the software field often make a key mistake in how they distinguish between value-add and non-value-add activity: They conflate Type 1 Muda and customer-defined value.
Any activity that does not directly add value to the product is muda according to Lean’s definition of the term. Software professionals often consider any activity that “does some form of good” to be value-add activity. The beneficial aspect of such activity is not the activity itself, but the outcome it produces.
Those who don’t distinguish between the desired outcome and the activity that produces the outcome will have difficulty understanding where the muda is in their process and how to address it.
One example is merge conflicts. The time spent in resolving merge conflicts is time lost to developing the product. And yet, when more than one person contributes to the product, their work will have to be merged.
One software team recently reported, with great enthusiasm and pleasure, how they had crafted a robust process to manage pull requests (PRs). Furthermore, they had devised metrics to track the cost of PRs that demonstrated their process had reduced the cost, which they proudly reported to management.
But PRs are not valuable. The outcome of a PR – handling a merge smoothly – brings secondary value (not customer-defined) in that it enables the delivery process to move forward despite organizational constraints or suboptimal work practices that make it necessary to deal with merge conflicts in the first place.
That team has a workaround for the inherent issues with PRs. They have institutionalized the workaround, which is now seen as a “best practice” in their organization. Now some people in the organization are focused on how to master and perfect the PR process. They are maximizing the waste instead of minimizing it.
They have started to present their PR process at conferences and recommending it to other teams and organizations. They are no longer thinking about how to minimize or eliminate merge conflicts. It’s Game Over – they will improve no more.
What To Do About Type 1 Muda
Type 2 Muda is pretty easy to handle – just stop doing it.
I recall an engagement on which we had to fill out three different time reports. Each summarized our work hours differently – weekly, every two weeks, and semi-monthly on the 15th and last day of the month. It turned out that three managers had different preferences about how they wanted to see the information. Two of them no longer worked there. The remaining one no longer used time reports in his work, and ignored them. We stopped doing it, and no one complained.
Type 1 Muda is more challenging. The goal is to minimize the impact of the non-value-add activity on product development flow.
In the case of merging software changes, we want a process that has a very light touch. The last thing we want to do is create a formal process that becomes a product in its own right, with a whole new career path to support it, calling for training courses and certifications and all the rest of it.
To ensure our product works well enough to meet our customer’s needs, we want methods that do not interrupt flow. Formal code reviews create a halt in the middle of the process. Manually checking predictable software behavior requires substantially more time than automated methods; it’s non-value-add time. We want the outcome from code review and checking the behavior of our product, and we want it with a minimum of overhead, not a maximum.
Don’t ask how you can work around interruptions in flow. Ask how you can get the work done without interruptions in flow.
Don’t ask, “How can we improve our PR process?” Ask, “What is causing the need for PRs? How can we change our process so they aren’t necessary?”
Don’t ask, “How can we do code reviews better?” Ask, “Why do we need to interrupt flow to have formal code reviews? How can we change our process to eliminate the overhead of formal code reviews without losing the benefit they bring?”
Don’t ask, “How can we finish our daily stand-up within the time-box?” Ask, “How can we gain the benefit provided by a daily stand-up without having a daily stand-up?”
There are many more examples besides those. In all such cases, we need the outcome provided by the non-value-add activity, and we need to get it at low cost in terms of time and money. What we absolutely do not want to do is create bloated institutionalized workarounds that fill up lead time with activity that doesn’t add value to the product, and bleeds away skilled people’s time as they strive to perfect the workaround instead of focusing on customer-defined value.
Conclusion
As always, your mileage may vary. For what it’s worth, I’ve found Lean Thinking to be very useful for improving software development, delivery, and support processes.
How can you start? Here’s a hint: muri and muda almost always result from mura. If you focus on continuous flow and ruthlessly eliminate work practices that interrupt flow, I think you will see improvement in a short time.
Be thoughtful about this. Understand the reason a workaround was put into place before you discontinue it. It’s possible your team will have to develop some new skill in order to “earn” the ability to remove the workaround safely.
Returning to the PR story, it’s quite likely that team is not in a position to discontinue PRs and let everyone commit to main all day without causing chaos. They need to consider how to change their work practices in such a way that the issues the PRs address are no longer issues. Then they can stop doing PRs.
The problem isn’t that they are doing PRs. The problem is that they believe PRs are the real solution to delivery issues. They aren’t the solution; they are a symptom indicating something else could be improved. Whatever that may be in their case, it won’t be improved – or even identified – as long as people believe the problem has already been solved.