I’m interested in Agile methods for engineering work, including safety-critical applications. Some say iterative development is not practical where hardware is involved, and not wise for safety-critical products such as infusion pumps or pacemakers. I have a different view. - Nancy V.
Agile Iterative Development mitigates risk
Agile thinking is all about risk and how to mitigate it. Iteration is the primary risk mitigation strategy in Agile work. Regularly delivering tested, working features is the way we avoid having built components that cannot work together.
Agile Iterative Development mitigates risk
Agile thinking is all about risk and how to mitigate it. Iteration is the primary risk mitigation strategy in Agile work. Regularly delivering tested, working features is the way we avoid having built components that cannot work together.
Figure 1. Delivering Projects in Component Layers
But engineers are used to building products in component layers. It seems more efficient to focus on completing each component, from the lowest level hardware on up through firmware and application software layers. The problem is that there are always enough unknowns in development to make that a risky strategy. It’s risky because building a system this way means that most of the features cannot be exercised until late in the project. If we discover then that our customer’s needs have shifted, or that we misunderstood what they really need – there just isn’t much maneuvering room left!
All traditional projects run the risk that sub-systems won’t work after they’re put together in the integration phase of the project. Agile teams successfully deal with this by continuous integration – fully integrating each new feature as it’s completed. There is no big-bang integration phase to go wrong.
So far I’ve only talked about process risk. There is also product risk – the risk that some other device might mess with your implanted pacemaker, for example. I’ll address that risk too in this blog, but a solid product has to come from a solid process. How you get there matters. So first I want to discuss process risk in embedded systems work.
Staying in control of the work is paramount. For me, that has always meant being able to slice up the work and make the progress visible. What ways have you used to keep your work on target?
Nancy Van Schooenderwoert
All traditional projects run the risk that sub-systems won’t work after they’re put together in the integration phase of the project. Agile teams successfully deal with this by continuous integration – fully integrating each new feature as it’s completed. There is no big-bang integration phase to go wrong.
So far I’ve only talked about process risk. There is also product risk – the risk that some other device might mess with your implanted pacemaker, for example. I’ll address that risk too in this blog, but a solid product has to come from a solid process. How you get there matters. So first I want to discuss process risk in embedded systems work.
Staying in control of the work is paramount. For me, that has always meant being able to slice up the work and make the progress visible. What ways have you used to keep your work on target?
Nancy Van Schooenderwoert
RSS Feed