I attended Agile 2007 last week in Washington DC. This annual gathering both celebrates agile software development and teaches agilists new tricks and techniques. The conference was completely sold out, hosting something like 1200 developers.
Interestingly, the conference itself was agile. Small, intimate, rooms used round tables to encourage interaction. Every class I attended had some sort of hands-on aspect that required dialog with other attendees, usually strangers. I was impressed by the thoughtful questions and comments from the crowd, and by everyone's palpable excitement.
There wasn't a lot of gray hair to be seen.
The vast majority of attendees are IT/PC types. Only a handful of embedded folks showed up, though there were a couple of sessions dedicated specifically to the unique needs of our industry. In one participants discussed barriers to the adoption of agile methods by firmware developers. It appears (though I have no hard numbers on this) that outside of embedded agile is rapidly gaining adherents. But a recent poll conducted on this site unscientifically suggests that only 16% of embedded developers use any agile method; half of those use eXtreme Programming.
I think one uniquely-embedded bottleneck is testing. All of the agile approaches demand frequent and automated tests. But that's tough in an embedded system when hardware might not be available, and where someone has to push buttons and watch displays. Some partial and useful solutions do exist, including mocking hardware and simulation.
Products exist as well: Virtutech sells rather amazing simulation environments into the embedded space, and open source programs like CATSrunner and CppUnit help mock non-existent hardware. But the use of these products requires a very different approach to building firmware than most of us use today.
Though the booth space was compact, the vendors were out in force. An astonishing number of them sell agile coaching services and/or consulting, rather than products. I had a chance to sit with both Agile Logic and SolutionsIQ, which both sometimes cater to our industry. The first primarily teaches any of a variety of agile methods to teams; the second specializes in using Scrum to create software for companies, embedded and otherwise.
I found two common themes in talking to the vendors. First, an agile approach gives management visibility into the project's status. Too many traditional development efforts wander for months before management realizes that the project is in peril. That's simply impossible on a properly-run agile development effort. Secondly, when something goes wrong, it's apparent early so it's possible to grasp the "steering wheel" (a phrase used by many at the conference) and steer the project back on track.
The zealotry displayed by some agile early adopters is gone. Everyone I talked to recognized that agile is not always the best way to run a project. That's a healthy development I was pleased to see.
What's your take on agile in the embedded world?
Jack G. Ganssle is a lecturer and consultant on embedded development issues. He conducts seminars on embedded systems and helps companies with their embedded challenges. Contact him at firstname.lastname@example.org. His website is www.ganssle.com.
I think embedded developers can learn from the agile development community and the larger software development community. Many of the problems that embedded developers face are the same problems desk top and web developers face. Late projects, missed expectations, poor quality and burn-out. Agile techniques like Extreme Programming are designed to address these problems. Modern software design techniques are used to keep software clean, flexible and well tested.
Just to name one practice, I think that Test Driven Development is one key Agile practice that embedded developers should relate to. It focuses on keeping software modular and testable. Just as in hardware, software can be made modular, known inputs can be injected and responses are measured. Boundary conditions are explored and their behavior is confirmed by automated tests.
A colleague of mine used TDD to build the control system for conveyor. He did not have hardware while he developed the software. He integrated his software in one day with no defects. Those that try TDD usually don't go back to Debug Later Development.
Sure, embedded has other challenges that the desktop developer does not have to be concerned with, but that does not mean that Agile practices won't work for embedded. They are working for the embedded teams that are using them.
The Model T owner comes to town. He stops by the blacksmiths.
Model T owner: "How do you like my automobile?"
Blacksmith: "Can it swim across a river?"
Model T owner: "Well, no"
Blacksmith: "We have rivers around here, get that thing out of here!"
New ideas are often dismissed when they challenge the status quo. But really there is nothing new in Agile. Agile is a amalgamation of tried and true practices refined over the last 50 years of software development. Jack, I am glad to see you looking at Agile with a serious and critical eye.
- James Grenning
Jack - It's great to see that you came to the Agile conference. Thanks for bringing agile to the attention of your embedded community. I think that the real low-level of embedded development (drivers, BSPs, and OSes) can be developed using the traditional design-code-test paradigm or Agile methods with similar effectivity. Where embedded and agile really hit their stride together is developing the higher level application: the behaviors and interactions that seem to be getting more and more complex for embedded devices. I've seen agile practices make a huge difference when it comes to this type of development.
- Doug Bradbury
Refreshing, it is, to read your observation of waning zealotry among Agile proponents. Having heard, over the years, one after another One True Way to survival and success in the industry (paralleling the divisive nature of more and more elements of modern culture at large), I enjoy seeing Agile presented as something that may work for me and something I ought to consider, as opposed to something I ignore at my obvious peril. Such an honest, believable, level-headed pitch bodes very well for Agile's long-term acceptance in any and all of our related software-development fields, and encourages me to follow its developments more closely.
That you saw few gray hairs there is surprising and mildly disappointing. Fading hair color provides no exemption from the need to open new books.
Thanks for the report, Jack!
- Daniel Daly
It is nice to know what happened in the conference with respect to embedded. I agree the key issue is testing and once testing bottlenecks in embedded are reduced, continuous testing and integration could gain more traction, they will give the same benefits as for PC/IT. An area which agile seems not to have addressed well is code inspection, which is very important besides testing to have a high quality maintainable software.
- Piyush Patel
As stated previously, Agile may be better for projects which are small AND non-complex AND non-critical. I am sure it was Kent Beck (XP) who admitted this.
- Martin Allen