I am a big fan of Agile Development. I believe it leads to software that does what customers want (as opposed to what they ask for…not necessarily the same thing). Agile is not a silver bullet, and many gurus have expounded on this point. Agile is hard! It takes discipline and a buy in from management to implement a reasonable process. In fact, some of the tech blogosphere gods are not sold on all agile practices, but that is a debate for another forum.
Agile is becoming mainstream in the world of Web and Application development. However, in my experience, it is not used much in the embedded world. This is my feeble attempt at exploring the possible reasons.

One of the major reason embedded software tends to use Big Design Up Front (BDUF) is that the embedded software process is tied to the hardware process; and the hardware process is inherently BDUF. Hardware reworks costs can be significant. You better nail down the desired functionality early in the process. Rarely will the software team have the luxury of waiting for the hardware before starting work. Most of the time, you have parallel development. Since the hardware team follows BDUF, it is only natural that the software team follow suit.

Another reason Agile can be difficult to implement is that when you get the first hardware prototypes, you will inherently have a big bang intergration. This is the first time you see the hardware platform, and now you have to make it work. This will really set an agilist on edge. Sometimes, there are ways to mitigate this; using a commercial hardware board which ressemble the hardware platform is a favorite approach. Sometimes though, the hardware is so unique that it is not an option.

A third area of difficulty concerns the whole testing aspect; both unit and acceptance tests. I alread wrote about embedded unit testing, so lets talk about acceptance tests. I have observed that regardless of your development methodology - BDUF or Agile - with embedded devices, you need acceptance tests. In fact, you really need 2 levels of testing. The company I cut my teeth in used to have a “Design Verification” phase. This is where the hardware engineer ensures that all the bits & bobs of the hardware platform work. It might involve writing a minimal amount of code to drive a few pins, and insure that from a hardware perspective things work. This would be your first level of testing. Note that once it is performed, it is rarely revisited. The second level of testing is your typical functional/acceptance testing, where you will be performing testing the functionality of your device as a whole. From an agile perspective, the trouble is the difficulty of automating this type of testing. It could cost more to engineer a fixture to automate the testing than designing the product in the first place.

There are other reasons why Agile is not more prevalent in embedded circles, but I believe those 3 factors account much of the inertia. What do you think?