The other day I wrote an article about diversity, and today I’d like to demonstrate the value by sharing some of my knowledge obtained from the manufacturing industry, within which I spent many years. Most Agile product development is software based. Software has certain advantages that hardware doesn’t enjoy. Primarily, teams can fix software issues and update every user in the field (usually) quickly and easily, whereas hardware must be right before you ship it.
The manufacturing industry spends billions of dollars on product recalls because “bugs” were shipped, but they take great precautions to minimize the impact of manufacturing risks. One such measure is called Failure Mode & Effects Analysis (FMEA). The FMEA process is well-defined, rigorous, and time-consuming. One might look at it and see an Agile anti-pattern.
Any reasonable product development effort includes steps to evaluate risk before building. While I’m not advocating for all product teams to use the FMEA process, we can learn from it to improve our current risk analysis efforts.
Each type of product carries different kinds of risk. Hardware can have mechanical failures that software can’t. However, there are two types of failures that every product can have:
Environmental
Human Error
These are called Failure Modes. The idea behind an FMEA is to identify every potential failure mode for your product and consider the effects of such a failure. Some effects may be so minor that they are not worth the effort to avoid the failure behind them -- others will require modifications to the product design or its operating environment to mitigate risk.
This is the part of the article where I would go into detail about implementing an Agile FMEA process. I’m not going to do that. There are far too many people being overly prescriptive about Agile practices. I share these ideas so you can implement them in how they work best for your team.
Agile processes are flexible and tailored to the team’s needs. Whether you should have a risk analysis process is not up for debate. It would be a mistake not to have one. You can still bring rigor to your analysis without it becoming as cumbersome as an FMEA.
Comments