Agile embedded
The Agile methodology has been talked about for some years. To be frank, I have given the matter very little attention – I just had a basic idea of what it was all about. I suppose I had a feeling that the approach was rather chaotic and disorganized, which is at odds with my view of what programming should be like. However, I attended a talk at a conference recently which changed my mind. The presenter was, in essence, trying to sell some project management tools that support the Agile methodology. But he also described the philosophy in terms that I could appreciate. I realized that what was being proposed was very similar to the approach that I have espoused for many years …
Broadly speaking, Agile is an alternative to the traditional “waterfall” methodology, where development proceeds through a design phase, then coding and lastly debug and testing. With Agile, the process is accelerated. The project is progressed as a series of short cycles – typically 2 weeks duration. At the end of each cycle, working software is delivered. Each delivery includes bug fixes and additional functionality.
There are two separate reasons why I believe this may make sense for many embedded projects:
Firstly, embedded devices are often black boxes. They have plenty of internal functionality, but little, if any, is immediately visible from the outside world. This contrasts with desktop software, most of which has some kind of user interface. I have always felt that there is a psychological benefit to be gained by getting a system to show signs of life as early as possible. With Agile, you need to deliver working software, so it is logical to include some interaction with the world to make that functionality manifest. This might mean producing some result on a display, flashing some lights or responding to a communications interface.
Second, embedded systems always have some kind of limitation on resources – typically both memory and CPU power are bounded in some way. However, most systems have performance criteria that need to be met. With the “waterfall” approach, a shortage of memory or reduced execution speed may not be apparent until very near the end of the project. With Agile, as functionality is added incrementally, the use of resources can be carefully monitored. If there is a sudden increase in memory usage, for example, its cause can immediately be identified.
Clearly the Agile movement has gained a lot of supporters in recent years and I suspect that support is very strong in the embedded community. This is a topic to which I am sure that I will return. I would be interested to hear about your experiences with Agile by comment or email.
We’ve been using various agile methods for a number of years, both in Flomerics and now in the Mentor Graphics ‘Mechanical Analysis Division’ for the development of FloTHERM and FloTHERM.PCB. Ignoring the actual mechanics of the process itself (SCRUM, FDD etc.) the real benefits imho are as follows:
-A ‘ready for release’ mentality where incremental feature additions are tested, documented and accepted before the next feature or task is addressed
-Not biting off more than you can chew. Breaking a feature down into a series of implementation tasks taking say no more than 3 days each enables a focus for the whole team that results in an overall improvement in quality
-Visibility for all stakeholders. Breaking down the cubical and over the wall approach between the various software development disciplines, little tasks that the whole team acknowledges works on as concurrently as possible
Main issues against are the inability to predict at the start of the project the exact release date but at least by looking at your feet during the process you don’t trip up in your rush to reach the horizon.