The following Slideshare presentation contains a case study that shows that agile can work within an embedded software / system development environment.
Agile Embedded Software Development, what’s wrong with it?.
At some point in the presentation, it makes a statement that agile is not method but a paradigm. In my mind, this needs to be qualified in that the agile manifesto and principles do represent a paradigm, but the formalised agile approaches (e.g., XP, Scrum) are methods. I believe that distinction is important.
In the tradition of agile bashing (like in the Manifesto for Half-Arsed Agile Software Development), here is an interesting posting: The Anti Agile Manifesto.
I like the principles behind this posting. It does reflect what I’ve always seen in the software/system delivery world: the so-called “paradigm shifts” are just formalisation of best practices, using different words. This certainly helps the new “gurus” differentiate themselves from the previous gurus, but it also can (and usually does) induce dogmatic fever…
One part of the post of which I am not too fond is the use of “weakly defined” in the last sentence. That is, perhaps, true, but it may not apply to all flavours of “agile”. Also, in many cases, the items on the left are just “kinds of” items on the right, a specialisation, which is the point of the evolution of these new methods. Since I wrote about dogma above, I could mention that these new “methods” are indeed evolutionary and not creationist… ;-).
Still, worth a look, if only to remember where it all comes from!
Thanks to éminence grise for pointing out the following:
Searching for the signal of open standards amid the growing noise of agile.
Although the article is aimed at government, some of the conclusions are interesting. However, I do not agree that the “open standards” signal is being eclipse in general. There are many open initiatives still going strong (e.g., OSLC) in the IT world, but yes, agile is everywhere these days.
I also agree that in certain areas of IT, the best approach would be a merge of open standards and open source, being careful that the end users of those technologies are well represented within the respective development efforts, i.e., not just the companies offering tools and services for open standards and open source projects!
I also liked the following quote from the article:
Unfortunately, for all its undeniable strengths, agile is in danger of becoming a fetish, something imbued with additional symbolic charge over and above its actual meaning.
That is actually something I have started to see in some forums. Some agile gurus (“religious fanatics”) are often polarised and polarising in their approach, often conveniently forgetting some of the agile principles and part of the manifesto in order to further their cause. In all honesty, various process gurus over the years have done the same thing (e.g., some RUP gurus…) and the same kind of backlash may be happening to that agile community (and to the Lean community to a lesser extent).
Note that I am not against agile – I firmly believe it has its place – but I also believe that culture has an important part to play.
Tommy (someone for whom I have the greatest respect) made some very interesting comments in his posting: Corporate mass & inertia prevents agility.
Now, I have also had some experience sailing and that certainly helps me relate to the metaphor he uses. Sometimes I like the slow boat and sometimes the fast one – it really depends on what you want to accomplish. However, in this age where “internet time” is what companies have to worry about, agility is what is needed for the complete delivery of products. There has already been a lot of talk about agile development for quite a while – and that is certainly a great thing for the software industry, but development is just a part of the product delivery, one has to embrace the complete lifecycle and think about agile product management (check out the front end of SAFe) and agile DevOps.
But then, there’s also some benefits to sometimes take a slow boat to China…just not when you need to deliver a product to your clients!