For instance, embedded systems designers need to specifically tailor agile methods to their particular industry to make them work efficiently, according to Douglass, otherwise failure is a looming problem that can sour an organization on the whole agile methodology.
"Often when embedded designers start out with agile methods, they have this ballistic notion that everything thing they do can become agile immediately," said Douglass. "But there is a lot of tweaking necessary to make agile methods work successful. Tweaks for the industry, the people involved, the metrics used to measure success and the instruments you need to make those measurements. All these have to be tailored to your application--a process that takes time--it can't be done overnight. And it you don't do it, the chances of failure are very high."
Thus as a project proceeds, many small tweaks are typically made to the project plan, based on the results measured by the instruments put in place. For instance, the velocity of the project might be measured by how many requirements get done per day, whereas quality improvements might be measured by defect rate--all of which are constantly being compared to project goals, which in turn can lead to tweaks in the project plan.
"For instance, if your metrics show the current plan is not improving quality enough, then perhaps you'll decide to change how test-driven-development is done--to make it more thorough," said Douglass.
According to Douglass, the embedded system designers of the world are one of the last hold-outs regarding agile development methods, which have already been widely adopted and proven out in the IT world. To find out how to adopt agile methods to your next embedded systems project--without breaking what is already working in your methodology--attend the DESIGN West 2013 session Top Ten Mistakes of Agile Embedded Projects (and how you can avoid them) on Thursday, April 25 at 2:00-to-2:45 pm.
From my 15 years of experience in high reliability embedded software, I find the assertion "The primary reason that designers move to agile methods, is to improve quality" hard to believe and very confusing.
Agile methods promote 'working software' over documentation.
Secondly, agile methods have shorter release cycles.
While this allows teams to better adapt to changing requirements, it does not improve quality.
By focusing on working software and shorter release cycles, one usually sacrifices quality (eg: less investment in long term architecture and less thought spent fully defining system requirements). While this may work well for fast pace projects with uncertain requirements, it can be fatal for complex software projects.
I don't have anything against agile methods, but to say that the primary reason teams move to them is to increase quality just doesn't make sense to me.
Join our online Radio Show on Friday 11th July starting at 2:00pm Eastern, when EETimes editor of all things fun and interesting, Max Maxfield, and embedded systems expert, Jack Ganssle, will debate as to just what is, and is not, and embedded system.