Muda
non-value adding activities
Probably when I mention non-value adding activities, you’re thinking of that last meeting which was a total waste of time. Fair enough, we should talk about that too, but I want to focus on non-value adding activities in another sense. In software development, familiar ways of wasting time are building features that are never used and everyone’s favorite: unnecessary complexity.
One way we end up building features that aren’t needed happens because of the way the feature is specified. We start with a business objective, which is expressed as an epic and elaborated in stories. During the discovery phase, it’s reasonable and correct to explore a fully elaborated expression of the feature, but what’s often missed is a ruthless tear-down to barest essentials before committing it to work.
If we get it right, then it should be quick to deliver, relative to having built the whole vision, leaving time for further iterations. If we learn something about the implementation, technology or user experience that wasn’t obvious in discovery, we still have some cycles to get in whatever aspect seems to offer the most significant value.
If we don’t start with an elementary version that we can get in quickly, we risk building aspects of the design that in the end don’t contribute to the value stream, or perhaps aren’t even used at all.
MVP can be a scary idea in organizations with low trust, where stakeholders may insist on every little feature that was ever mentioned out of fear that they won’t see anything after the first version. If indoctrinating stakeholders in Agile methodology is a bridge too far, try using a more reassuring term for MVP.
Gold Plating is building more features than needed, a particularly easy trap to fall into. SixSigma uses the classify of “Overprocessing” for this. Sometimes these “extras” are just misguided; something that shouldn’t have been done in the first place. Other times the feature is functionally appropriate, but non-essential, or at least not worth the cost of building and maintaining.
Every feature delivered has a carrying-cost of testing, maintenance, knowledge transfer, and user training, so even when a feature has a discernable value, it may not have a value higher than the cost of building and maintaining it. For a single configuration toggle, it may not seem like much, but add a hundred configuration details, and it begins to become a weight over time, to support, maintain and change the product.
Usually, there is no bright line indicating which detail is essential and which is unnecessary. Cultivating a sense for seeing value is an essential software development skill. The changes you make to your process to try to eliminate this type of Muda is an important Quality Assurance practice.
Unnecessary complexity can be introduced when a feature is made configurable late in the process, at the task level, by developers, only because the question about how something should work just never came up. The developer makes it configurable to avoid having the work become blocked waiting for an opportunity to discuss the feature. It costs next to nothing in the short term but transfers the cost of maintaining the configuration point for the life cycle of the product, a cost imposed on the customer because a conversation didn’t happen at the right time.
One approach making sure the right conversations happen at the right time is to add some formality to the story decomposition process, clarifying how team members should go about breaking down work from epic and story to task. The details of the feature will emerge somewhere in that process, sometimes earlier, in backlog refinement, and sometimes later, in technical planning. Getting this right is not simple, because the nature of the work and the composition of the team are often changing at the same time as we’re adapting the process to learn from past mistakes.
More subtle forms for Muda may be time spent planning for stories that are later abandoned. Sometimes that can be time well spent, where the planning led us to the conclusion that the feature wasn’t worth it; other times it can be wasted time, where, in retrospect, we can see that the story never had the priority to warrant planning in the first place.
Paying attention to detail allows us to classify different flavors of non-value adding activities, leading to a better understanding of the work, and the process enhancements needed to help get it done.
Let's agree to define productivity in terms of throughput. We can debate the meaning of productivity in terms of additional measurements of the business value of delivered work, but as Eliyahu Goldratt pointed out in his critique of the Balanced Scorecard, there is a virtue in simplicity. Throughput doesn’t answer all our questions about business value, but it is a sufficient metric for the context of evaluating the relationship of practices with productivity.