Michael Bolton took me a little by surprise this week when he tweeted a link to my blog with the #agile hash tag: I consider myself about as agile as a two-by-four.
That’s not to say that I am an agile virgin: I have tested on a few agile projects, and managed testing teams supporting iterative development. I don’t however consider myself an expert, having cut my teeth on the waterfall test crunch of doom.
The best way that I can think of to characterize my experiences with agile is with one word: bipolar.
Let’s take the good first (call it Project 1), and describe it in terms of the Agile Manifesto:
- Individuals and interactions (constant BA/dev/test interaction) over processes and tools (lots of emphasis on process and tools, constantly being tweaked and improved, more than I’ve ever witnessed elsewhere – is this some kind of agile paradox?).
- Working software (every iteration gave us something that worked) over comprehensive documentation (minimal, but that which existed was both useful and used – i.e. no dust gatherers).
- Customer collaboration (frequent engagement in refining requirements, defining acceptance criteria and acceptance testing) over contract negotiation (minimal).
- Responding to change (effectively managed through backlog) over following a plan (burn down estimation).
This was a positive experience, the team gelled, the software hung together nicely and the customer left happy.
Now let’s consider the polar opposite (Project 2):
- Individuals and interactions (none) over processes and tools (none).
- Working software (take a guess…) over comprehensive documentation (what documentation?).
- Customer collaboration (who?) over contract negotiation (what?).
- Responding to change (hourly) over following a plan (plan is a four letter word).
This project called itself agile, assumed that meant “Process – Pah! Documentation, we don’t need no stinking documentation!” and put nothing in their place. In short, the lunatics were running the asylum – and I’m not talking developers here – this was the whole team approach to insanity.
The funny thing is, I’ve been on waterfall projects that strongly resembled Project 1: good interaction, sharing of information, useful documentation, and customer collaboration. I’ve also been on waterfall projects that could easily have been confused with Project 2: madness personified. The common denominator is not the label, it is the team dynamics.
Software engineering is, when all things are said and done, a social activity. We’re not making widgets here, there is no physical product being passed from A to B: our products are information, ideas and words – and these are like the wind. Without good collaboration the moment is lost and the information along with it. Process and documentation can at least provide some base level of information sharing. Rip these out without replacing them with people talking to one another and the baby has gone out with the bathwater. Regardless of methodology and other labels: effective sharing of information helps teams to succeed.
Whatever your methodological preferences, please look after your babies.