Fat to Fit: Lean Journey (What's in the Metrics: Part 3)
Fat to Fit: Lean Journey (What's in the Metrics: Part 3)
What and where are the blockers in your value stream?
Join the DZone community and get the full member experience.Join For Free
In the article “Let’s Lean on Lean” we discussed how to identify the value-add, value enablers, and non-value add elements in the flow through value stream mapping. Understanding different types of waste helps in taking actions to eliminate them in expediting the value delivery to the stakeholder.
The below doodle depicts the various wastes in the system.
While the focus seems to be more for the manufacturing or production systems, this can be applied to any flow that aims to deliver value faster and better.
To be able to understand this in Lean Software Development context, Mary and Tom Poppendieck came up with 7 wastes: Extra Features, Handovers, Defects, Technical Debt, Work in Progress, Task Switching, and Delays.
In the world of converting concept to cash in the minimal predictable time through product development lifecycle, let us explore how the 8 wastes can be identified and eliminated.
Defect removal efficiency is one of the well-known metrics in the industry that help in identifying and fixing defects before releasing product to the customer. In the competitive world, it’s vital not just to remove but to prevent defects as the product is being built. As stated earlier, if we have understood the requirements and building aligning to them will yield to the right product being built in the right way. While code reviews and regression tests are good add-ons, we need to explore effective ways of building quality through practices like pair programming.
This can be related to both people and process. The self-organized teams usually take a longer time to move from forming to norming to performing. Moving people due to whatsoever reason within the product team or across teams will impact the velocity and throughput.
If there are too many handovers or handoffs, it triggers another waste of "waiting" along with longer cycle time. We need to ensure the teams are self-sufficient to be able to complete a functionality inclusive of reviews and validations. The need for depending other teams or people needs to be analyzed and mitigated to limit the unnecessary moves.
"Time is money" in every aspect, and delay impacts overall value delivery. Delays are everywhere, let it be teams waiting for a decision from leadership, developers waiting for code review, testers waiting for the proper build to validate. While some delays may look insignificant in overall value flow, the contribution is big enough holistically. Not just in the retrospection, but even during the daily stand-up, the teams need to identify and seek help from the leadership team to ensure the delay is minimized.
Customer satisfaction is important but it’s equally important to understand what customer really want and deliver the same not just in time but also just right. There are numerous lines of code being written, test cases being executed to ensure product quality, but the question to ask ourselves is, are they really needed? While the methodologies such as Behavior-Driven Development and Test-Driven Development help to focus on the requirements, it’s important to deliver just what customer requested, no matter what methodology we have chosen to build.
When the product teams work on longer releases (9-12 months), usually all the features are delivered together at the time of release. While this may be inevitable for various reasons, it will be a great idea not just to show the demo but also involve customers in early validation once the features are complete. This helps in reducing risks and uncertainties as soon as possible in the delivery cycle. If there is a possibility of bundling completed features together and releasing early, we achieve the return on investment quickly while controlling the inventory. There is a higher probability of changes and resistance to adopting along with the possibility of losing to competitors if we keep the functionalities in a longer development queue.
User experience is an important aspect to gain customers and retain them. Let it be new installations or upgrades, it’s critical to ensure customers don’t have to switch between different applications or steps. The non-functional (also known as foundational) requirements demand equal attention as new functional requirements. All of us expect a seamless experience and too many steps and movements cause distractions and frustration.
“I am not sure if this validation is required.”
“Well, I have added it just in case.”
“But there is no way the user will get into this scenario.”
“You never know.”
The usual conversation we keep hearing during the development cycle. While there is no harm in adding extra steps, let us not forget about the wasted time that could have been leveraged for value-add items.
For example, transaction logs that we assume to help in troubleshooting but end up taking up space and at times even causing performance challenges to customers.
Well, it’s not the responsibility of leadership alone to ensure the required training is provided and the skill of individuals are effectively utilized. Each team member needs to understand the business purpose, be willing to learn, acquire the required knowledge, and demonstrate how their learning can help the organization. The individuals own their career and leadership needs to ensure team members are motivated through value-add work that is aligned to the passion and career growth of team members.
In a nutshell, though the eight types of waste seem to be different conceptually, it’s all about understanding purpose and needs, optimizing the flow and movement through skilled individuals. It’s everyone’s responsibility to aim for continuous improvement by identifying non-value add in the flow and eliminate them.
Opinions expressed by DZone contributors are their own.