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!

Advertisements

Culture eats process for breakfast

Éminence Grise has a great posting with the same subject line as this entry (in fact, he has a bunch of great posting…). I am taking the liberty to extend his discussion in my own forum.

This discussion relates to a keynote address  by Henrik Kniberg at the Paris Scrum Gathering (2013.09.23). I have not had the chance to see the keynote in person, but the presentation is very informative – I wished I could have been there in person.

Nevertheless, the content of the PDF presentation was very good and interesting. I would almost say that it should be required reading by process implementers, but they may not like the content (;-)!

My take on this is that people, especially process implementers (read: management) always forget that there is already a process in place, an undocumented (sometimes) one based on the culture of the organisation. Once you understand that, you also have to realise that there is a process to change the process, and forcing a process upon a cultured organisation is not the way to do it! What we need then is (dare I say it) measures and feedback (a.k.a., retrospectives).

I have been through a work situation where a decision to impose a development process led to a failed regulatory inspection – a failure that could have been avoided if we had started from what was there. Imposing a process into an existing culture (and there always is an existing culture) will only create problems,

The Agile Manifesto had it right, but even agilists have a tendency to push their formalised agile “process” (e.g., XP, Scrum) and you are not doing it right if you don’t follow the rules!

Many have a tendency to only look at the manifesto and to skip the underlying principles. But we especially can’t forget Agile principle #12: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” We must remember that this is the basis of any work going forward – that it is where we must start to document our culture (a.k.a., our process 😉 before any new process is considered.

The Agile Manifesto reworked for Systems Engineering

In her community on IBM developerWorks, Hazel Woodcock posted an excellent blog entry describing a rework of the Agile Manifesto (really a “Manifesto for Agile Software Development“) into something that is more relevant to system engineering and the development of large systems.

If you have any interest in systems engineering (or if you are a member of INCOSE, like me), you really should have a look and make your voice heard (you’ll have to join developerWorks to be able to comment)!

Manifesto for Half-Arsed Agile Software Development

By now, everyone doing software (or product) development has heard of the Agile Manifesto (if not, you need to get out of your cave more often).

Like most process, one needs to apply an interative, incremental approach to process adoption. This is why we get something like the Manifesto for Half-Arsed Agile Software Development.

It would be so funny if it were not so true…