Agile: Doing the Wrong Thing Righter
[From the Archive: Originally posted at Amplify.com Jul 19, 2010]
Undoubtedly we’ve come a long way since Snowbird (http://martinfowler.com/articles/agileStory.html, http://agilemanifesto.org/history.html). And Agile seeds – when planted in fertile ground, at least – can grow successful, productive teams. Even hyper-productive teams (http://gojko.net/2010/04/20/jeff-sutherland-how-to-make-your-team-hyperproductive/).
Several conference announcements recently have trailed John Seddon’s upcoming polemic against Agile: “doing the wrong thing, faster”. Neither knowing exactly what John’s going to say on the subject, nor wishing to steal his thunder, I’m writing this piece to present my own views on why Agile has, more often that not, been doing the wrong thing righter.
One thing John and I are likely to share, though, is a Systems Thinking perspective on the subject. Hence the notion of Agile as “the wrong thing”.
Systems Thinking, in a nutshell, encourages us to take a look at wholes, not parts, and judge the worth of a system on its end-to-end effectiveness, rather than on how well individual parts operate (aka their efficiencies).
We can choose to regard any business as a system, with software development being just one part of such systems. No matter how well-run the software development team or department, the system within which it exists can still be dysfunctional and perform poorly. The introduction of Agile to a development group often only helps to enhance that one (relatively small) part of the whole system.
Some people note that Agile, and Scrum in particular, drives the discovery of these dysfunctional system behaviours e.g. throughout a business. And while I have seen that happen, few businesses have the will or insight to act on the messages coming from the agile teams. NB @dpjoyce has just tweeted about the “Red Pill / Blue Pill moment” (http://twitter.com/dpjoyce/status/18901380780).
This highlighting of dysfunctional behaviours often leads, in turn, to significantly increased friction between the Agile folks and the rest of the folks they work with. Ultimately, the friction can become sufficiently uncomfortable to threaten the Agile initiative itself, improved software development outcomes notwithstanding.
I could write more (much more) on this topic, but – not least because this post was prompted by various folks wanting to talk about this question – I’m going to park my keyboard now and invite you to contribute (below)… 🙂