Agile for Embedded Software Development

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.

The Anti Agile Manifesto

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!

Searching for the signal of open standards amid the growing noise of agile

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.

Agile stories, architecture, and religious processes

In his article titled “Stop Telling Stories“, Jim Bird highlights many points that have always made me uncomfortable about agile user stories, as well as describing how their usage came about. For those who are not aware, user stories are intentionally short description of what a user needs out of a system and why it is needed. Instead of detailed requirements for a system’s feature, they are often a short sentence that is then used to elicit more detailed information from a user (or product owner, but there are some concerns about “product owners” as well).

The section about “Don’t Get Hung Up on User Stories – Do Whatever Works“, addresses a particular case of one my generic pet peeves: blindly following what some experts/process tells you is the right thing to do as part of your process (see my blog entry “Culture eats process for breakfast“). I especially liked the quote in the referenced blog entry:

“stories are not enough. They are just one tool, a usage view. There are so many more options”
(Scott Ambler, Agile 2013 conference)

A process is not a religion, you are allowed to adapt it to your own culture and environment, and it must be subject to constant validation, just like it is stated in the last agile principle (which I still think Wikipedia got slightly wrong…) – regardless of what your guru/consultant/spiritual adviser tells you!

The other undertone of that blog entry is about the completeness of the product requirement if one only looks at user stories. Users stories can help you elicit the users’ needs (although you still have to be careful to differentiate their needs from their wants…), but it is not the whole story. How do you address non-functional requirements in user stories? How do you address existing architectural constraints? Note that these are not limited to user stories, but many of the agile (or “Agile”) processes, except for the Scaled Agile Framework, sometimes seem to ignore this. I would also recommend you read Philippe Kruchten’s take on Agile Architecture for a very opinion on that topic!

It’s good to see that in these cases of quasi-religious adoption of processes, there are still some critical thinkers out there!