Interesting paper and presentation (pdf) from Emmanuel Chenu at Thales Avionics that describes how they’re using several Agile concepts as part of their safety-critical avionics software projects. With the exception of pair programming, my read is that much of this is mapping activities that have been done in a safety-critical environment (e.g. test driven development) to several Agile principles, rather than the introduction of concepts that are foreign to safety-critical development. The other one that probably hasn’t been done in most safety-critical shops is continuous integration, but I’d argue that CI (or at least a “build early and often” philosophy), has transcended Agile and is just becoming “the way things are done”, regardless of whether you’re a “Big A Agile”, agile, or iterative development shop.

Either way, it’s interesting how even the most heavy, formal, process-driven development teams are looking at aspects of Agile they can embrace to make their development more flexible, responsive, while still producing highly reliable software. Of course, as he notes, there’s obviously a limit to how “Agile” an avionics development team can really become given the level of formal documentation required through all aspects of a DO-178B project. I’m pretty sure if you ever submitted this kind of documentation to a certification authority they’d probably not accept it:

As software managers you’re undoubtedly being asked to do more with less in this economy. With companies continuously being forced to cut costs, the first shoe to drop is when you are told you need to cut headcount.

The second shoe drops the day after the painful deed is done and you look into the eyes of the team members that are left behind and try to put a positive spin on your world – their world. And that is when reality really hits home.  Less people, same number of problems.  No one “downsized” the backlog of customer requests, the bugs, the schedule expectations or the previous team’s workload.

At this point two groups form; the group of managers that simply puts their head down and grinds it out until things turn around (hoping things don’t get worse…which is really a do nothing strategy and those rarely work)…or the group that decides to be bold and innovative.  The natural inclination is to say the latter approach is too risky but in reality it is actually less risky, just more visible and more likely to be positively received by your team and your management.

The dev organizations best positioned to come out of this economic downturn stronger, are the ones with dev leaders that are focused on how to do things differently.  Agile development and further process automation with advanced tools become the mechanism to strongly position these dev teams for the better days ahead.  Why? Because just like every bubble, every downturn eventually ends.  As a dev manager, your real focus needs to be on what you want your team and your company to look like coming out of the downturn – heads down, battered and bruised but glad to be alive -  or lean and mean supported by a finely automated dev infrastructure and ready to capitalize on new opportunities.

By focusing on new approaches and automation, you  are helping your team feel they can get in front of the workload they have been presented with during these very challenging economic times. Automation is critical.  Tools such as continuous integration, refactoring, and code analysis all help eliminate wasteful, demoralizing “redo’s” of stupid mistakes they probably would not have made if they were not so maxed out, or if they were more familiar with the latest project you had no choice but to drop on their lap.  They see a way to spend more time on interesting, and challenging, innovation rather than just constant debugging.

“Hunker down” seems to be the mantra of our times, but “hunker down smart” and you and your team will be more readily positioned for the better days ahead.