I am a big fan of the agile philosophy of software development as summarized by the Agile Manifesto. The agile approach fits well with my pragmatic mindset, and I consider myself an agile practitioner, despite currently working in a bureaucratic environment providing application development and maintenance services to a large, process-heavy government client.
But then I read an interview with Alastair Cockburn in which he talked about what it means to be agile. Cockburn provided a top ten list of indicators that you are not agile. As I read this list, I realized with a sinking feeling that most of these applied to my current team. I went back through the list and recorded my team's score out of 10 for the indicators for which we were agile. I even gave us half a point for those items for which we were partially agile. Our final score was a measly 3 out of 10 (10 being fully agile). Clearly we are not agile.
Would I have to revoke my agile membership? I still believed in the agile approach, so how could I not be agile? Or was I mistaken? I re-read the Agile Manifesto, and still agreed with what it said. What about the principles of agile software? I re-read those as well, and again found myself in agreement. There were a few principles that are difficult or impossible to apply in my current environment, but that has not stopped me from trying to do what I can.
I agree with the agile values and principles and try to apply them within my work environment. I believe this is the fundamental indicator of whether you as an individual are agile or not, rather than a list of specific practices. Therefore I am agile.
A separate question is whether I, as part of a team, am doing agile software development. Despite the flaws with Cockburn's top ten list, it does help evaluate this second question. The answer for myself is no. I am an agile software developer doing non-agile software development. The distinction may be subtle, but it is significant. To help you see it, imagine the opposite case of a non-agile developer working on an agile software development process. They may be following the team's agile processes while pushing for more formal documentation and more detailed processes. Your team's approach does not necessarily reflect the beliefs and values of each team member. Another way of viewing this distinction is that agile can be thought of as both a philosophy consisting of a set of values and principles, and as a set of practices which implement and uphold these principles and values. I am unable to follow all of the practices at work, but I still subscribe to and apply the values and principles.
If you find this article helpful, please make a donation.
Share this article:
Related Posts
- No related posts
Nice article - Ironically, we are not doing Agile development, but score fairly well (7/10) on Cockburn’s quiz.
That raises an interesting point. Can you score 10/10 but not be doing Agile? From the article, Cockburn seems to imply the answer is no.
Either way, I personally would prefer to be scoring higher than lower.
It _is_ a tricky point…
The agile manifesto is incredibly vague, and so in a way we are probably doing (small “a”) agile, but not any particular methodology.
The second thing is that Cockburns list more describes a work environment. You could do strict waterfall and still score 10/10 for his pop quiz.
being the quiz about things that tell you you are NOT doing agile, scoring high means exactly that you are NOT doing agile ;-)
the agile manifesto + the principles behind it are far from vague! The manifesto on its own, being a manifesto, must be short though and that’s why e need the principles: to fill the gap between values and practices.
The article seems pretty clear to me that the quiz is to identify if one is agile - i.e. the items listed represent agile practice.
However, I agree that the manifesto itself I would not call vague. It is quite specific in intent. But since it doesn’t provide any details in how to value X over Y, I can see how some could find that vague.