Recently I heard a keynote of the ESE congress where a famous and experienced speaker claimed, that Agile would not be appropriate for Embedded Systems, and CMMI should be preferred instead. I remembered a very big company I once worked for. We subsequently rose our CMMI level – but noting, really not one single thing changed in the way, we developers programmed, designed or wrote the specs. CMMI can be just a fake – as everything that’s based on paper.
I’m tired of the discussion whether Agile should be used, or not at all. This is too dogmatic, it is not a yes or no topic. For me the key concept of Agile was historically the existence of iterative development and the absence of an a-priori fixed feature-set – just no big-bang releases and no BDUF (big design up front). Robert C. Martin describes in his famous book ‘Agile Software Development’ why the formerly popular analogy does not match, that creating the sourcecode is comparable to building a bridge and would therefore need BDUF. Instead he introduces model of the compiler being the one that ‘builds the bridge’, which is more appropriate and I totally agree to him. In order to understand where Agile comes from, one has to understand this change in the point of view.
Based on this model where building software is different to building a bridge, because of the varying effort for the build step, I want to define two oppositional poles: On one pole are projects where the process of building is tremendously expensive and not even one additional iteration is possible, which leads to an a-priori fixed featureset. On the other pole much iterations are possible and an a-priori feature-freeze, that would make the project clumsy and resistive to change, is counterprodutive. Embedded projects utilize different components that are between both poles. PCB, Mechanics, Software … every discipline has different cost/time/effort for the process of ‘building’, which makes it necessary to adjust the level of Agility individually for each discipline.
- Bridge: Not iterative at all, features are fixed from the very beginning.
- Formed parts: A few changes are acceptable, some adjustments can be made from one prototype to another. Not all, but most ‘features’ have to be defined a-priori.
- Rapidly prototyped parts (3-D Printer): Several iterations are possible, features tend to be changeable, only the subset of the features that is related to the interaction with other parts has to be frozen at the project start.
- Software: Very iterative, the compiler can build the software in a few minutes time. Only the basic plot has to be known in the project’s beginning. Changing the feature set is easy at every project stage.
Therefore the discussion about using ‘Agile or traditional’ in the whole organization leads to a wrong direction. Instead: Be as Agile as possible and as traditional as necessary in every particular discipline. This doesn’t make it less complicated at the interfaces between the particular departments/diciplines, off course, and demands more communication. E.g. some software features will be mandatory because of mandatory hardware features. I suggest that in this case the deparment that is more agile (software usually), accepts that they have to sacrifice some of their own agility in favor of the less agile (hardware usually) department. And vice versa that the hardware people take into account that they have to split up the software features they require into mandatory and optional ones.