The moment of epiphany came at OOPSLA ’97 when I went to Ward and Kent’s Pair Programming BoF. Here I saw in practice the things I’d heard Ward, Kent and others talk about: TDD, Pairing, Refactoring, Doing the Simplest Thing, User Stories, System Metaphor and more. I went back to work, full of fire, and managed to convince a sceptical manager that there was a better way of delivering software than what we were currently doing. Since then I’ve been an eXtreme Programmer.
In 1999 I started my first consultancy business and XP was at the heart of our development process and some of our business practices too. But we didn’t talk about it … we couldn’t because the “extreme” word worried people and the mention of such outlandish practices as Programming in Pairs and Writing the Tests First merely confirmed their view we were mad. In other words we did’t sell XP, we sold the outcome of an eXtreme approach to software delivery.
In 2001 the announcement of the Agile Manifesto left me bemused. By this point we were talking about XP and using it with big teams on big projects. Even though there were still customers who thought what we said we could do was “impossible”, that Pairing was “two people doing one person’s job” and so on we had enough of a track record to point to, as well as the experience of others, to overcome the scepticism. I could see where the Agile Manifesto was coming from, and had no doubts about the good intentions of the authors, I just couldn’t really relate the set of value statements to what we were doing: selling the delivery of software in a way that out-performed other projects by every measure. And to be clear, we were selling the delivery of software, not training people, not offering qualifications, not consulting, delivering software.
By 2004 the “Agile” word was in common usage. It was useful to short-cut a lot of the explanation about what we did by talking about an “Agile process”. It was easier to gain acceptance of what we did because this nice fuzzy word was a synonym for good software delivery. But this was also the time that the bigger consultancies started to rebrand what they did as “Agile”, that I started to meet people who described themselves as “coaches”, that I heard about the idea of being certified as a practitioner (I knew people who thought I was certifiable as a practitioner but that was a different thing altogether).
Now in 2010 I can’t help but hope this whole Agile thing has run its course. It was always a somewhat meaningless word anyway (as Mark Stringer once tweeted, “… ask people if their company’s Agile, nobody’s gonna say – oh no, we’re lethargic and arthritic”) but now the people who seem to be talking about it most are those that make money by selling the process, not the outcome. They sell coaching, process improvement, training, certification, tools, people, ‘value’, blah, blah, blah, but very rarely do they actually sell software delivery. You know, as in “we’ll deliver this software” as opposed to “we’ll help you deliver software”.
And that’s okay. I have nothing against people peddling Agile as a way of making money (and, mea culpa, for a brief period in 2008 I did a bit of this too). It’s just that it no longer has anything to do with what I do. I recently sat in front of a customer’s project manager – a very smart and reasonable person – and accidentally used the A-word when describing how we were going to deliver our product and required customisations to them, and they sneered.
They actually snorted in disgust.
When I then explained we would get them live and using the base product quickly, followed by weekly incremental improvements with regular reviews and plenty of opportunity for rework they were very happy.
But they didn’t see any connection between the two things.
Many years ago I tried to explain the concept of small-a architecture in software to a conference in Manchester. This was the idea (from Bruce Anderson) that every software system has an architecture than needs to be understood and cared for. Which is very different from what was considered Software Architecture at the time: people who hadn’t written a line of code in many years drawing lots of boxes and connecting them up in ininteresting ways to hand over to the poor schmucks who actually have to implement the thing.
It’s tempting to champion the concept of small-a agile: achieving agility rather than being Agile. But, do you know what? I can’t be arsed. Because its not about being agile/Agile or achieving agility, or being lean/Lean and efficient , its about delivering software. And I figure the best way to champion that is actually just to get better at doing it.
So, with a nod to Mr Stringer, I’d like to say “I’m not Agile” … I just deliver software.