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.
Start by coming up with a lightweight risk review process. Figure out where in your development planning process to insert it. As you go forward, failures will inevitably sneak through to your public-facing product. When this happens, take the time to evaluate the failure mode behind it and develop mitigation tactics to include in your risk assessments going forward. This way, you can incrementally improve your risk assessment process based on experience.
There’s no point in adding steps in your process to mitigate less likely risks unless those risks have dire consequences. Also, look for opportunities to build risk mitigation into your everyday workflow rather than adding checkpoints -- another lesson from manufacturing. Create extra steps if you must but avoid them if you can without compromise.
It doesn’t matter whether you’re building software, hardware, or services. Evaluating risks to your customers, stakeholders, and team members is always a good idea.