Are you an Agile pretender?
1) Firstly I’d ask you what ‘ Agile ‘ actually is? It sounds like a simple question but I would bet that a very many people would struggle to give an answer that didn’t sound far from waffle.
2) Secondly I’d ask you why do we want it? Again this should be a simple question to answer, and I think that an adequate answer could be given in roughly 3 short sentences.
3) Lastly I’d ask you why & how ‘ doing Agile ‘ is beneficial to your particular project?
‘ Agile ‘, as mentioned previously, is meaningless. Unfortunately the word has been entirely destroyed and I fear will never be recovered (although reluctantly I still have to use it when talking to agents, etc). Dave Thomas (one of the original signatories of the manifesto) wrote a blog post recently on the topic here:
Having felt enormously frustrated for the last couple of years, seeing Dave’s post has made it clear to me once and for all that I’m not imagining the whole thing. The software development community is unfortunately easy prey for a whole cottage industry of snake-oil salesman that has sprung up around ‘Agile’, and the hidden – even if unintended – payload of destruction is that a whole generation of developers (the guys at the fake agile coalface) is emerging comprised of men & women who feel jaded towards the whole idea of ‘ Agile ‘.
For a thoughtful developer, working on a real agile project will fill them with joy – the joy a professional experiences in the efficient delivery of quality software, and the joy they experience in seeing their own productivity and professionalism grow from beginning to end. Big ‘ A ‘ Agile, or voodoo, robs people of this opportunity to enjoy their work.
The reality is that the ideas and mechanisms to develop software with agility are very simple. They are simple because they make logical sense and don’t come in the form of complicated & prescriptive tasks, but can be summarised in a general sense by saying:
‘ Only do what adds value. Don’t do what costs more than the value it adds.
Agility is valuable, so a present cost may be worth future agility.
Embrace collaboration in order to leverage the agility you’ve built into your engineering processes. ‘
Am I an agile pretender?
– What is ‘Agile’ ?
As I’ve already suggested, ‘Agile’ is the process by which software development is done with agility in mind. The agility to change direction as quickly as possible, and as cheaply as possible. The agility to fail fast and fail cheap. The agility to continuously adapt and improve our own processes and techniques in order to deliver maximum value over a given period of time.
– Why do we want it ?
We want agility because it increases our chances of success. It often reduces costs. It increases the chances of the customer getting the product they wanted, even if it’s not necessarily the product they asked for. In a dynamic global market things change fast and we need the agility to change the product during development according to market forces.
Human beings aren’t always great at knowing or articulating what it is that they actually need. We want the agility to draw those developing requirements out during the course of development, and we want the agility such that our product’s design can be emergent according to the feedback that we get from both the customer and our own processes.
We want the agility to fail fast, because to fail fast is to fail cheap.
– Why & how is ‘ doing Agile ‘ beneficial to your particular project ?
This one can often be the slam-dunk signal that you don’t know what you’re doing. I’ve worked on projects labelled ‘Agile’ which would have experienced absolutely no benefit from any agility, other than those associated with the good engineering practises which are a prerequisite for any successful agile project. Those projects were fake ‘Agile’. We followed a Scrum paradigm which supposedly made us agile, yet none of the reasons to adopt Scrum were of any benefit to us. Our projects sometimes consisted of what was essentially a very well defined list of discrete alterations/fixes which are required for regulatory reasons, and The implementation of one of those fixes very rarely has any bearing on the implementation of any of the others. What’s more, those kinds of project had a fixed and very specific scope (and a fixed deadline too!). With this being the case there was absolutely no benefit to having the notional 2 week sprints that we did. There was very little benefit to the sprint retrospectives. Sprint reviews were pretty pointless when a task was so well defined, trivial & discrete from all others. In the daily scrum/standup we essentially tried not to bore each other too much as we explained what we did yesterday, and intended to do today; no one cared because what I did today had no bearing on what anyone else would do tomorrow – there was no sprint goal.
- ScrumMaster certifications do not make your teams ‘Agile’.
- Wilful ignorance of cause & effect will not make your teams ‘Agile’.
- You will not see the seismic shift in productivity and quality associated with ‘Agile’ just because you stood on one leg with a chicken foot in your pocket, chanting ‘Umbungo, umbungo, they drink it in the Congo…’
Agile is for losers, and these posts are my attempt, for the time being, to be a thinking, ‘real’ man, who instead chooses to seek agility in software development.