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.
David Patterson, known for his pioneering research that led to RAID, clusters and more, is part of a team at UC Berkeley that recently made its RISC-V processor architecture an open source hardware offering. We talk with Patterson and one of his colleagues behind the effort about the opportunities they see, what new kinds of designs they hope to enable and what it means for today’s commercial processor giants such as Intel, ARM and Imagination Technologies.