“That Agile Crap”

I have recently started a new job. In my experience, I usually drive home from my first day thinking one of two things: either I am wondering how I landed such a great job, and just can’t wait to get to work tomorrow to gert started on some of the challenges ahead, or I am asking myself if I made a huge mistake and what can I do now to fix it. For me, there is usually not much middle ground here.

Having been such an advocate of Agile Methodologies, I was very interested to see how (if at all) agile processes had been implemented here, and what my role would be in either implementing or improving them. My first day was full of one-on-one meetings, where I was able to meet some of the key decision makers in my new organization. As I like to do when starting a new job, I asked each of them what I could do to be successful in this role in their eyes. One answer evoked a surprising comment about agile development – which was a real surprise, since I didn’t mention agile or development practices at all (I try not to reveal my feelings on the subject yet, as I don’t want to taint the well, so to speak).

I was told that a particular project was in disarray. As we talked about the reasons, he said something like “the development team keeps re-working things, and they keep doing the same thing over and over. You know, its because of all that agile crap”.

Once again, it seems that Agile is being blamed for bad development practices. Either that, or the development team is using Agile as an excuse for not delivering – I guess I will have to figure out which it is. Either way, it seems that Agile development is always an easy scapegoat for projects gone bad.

While it is true that an agile approach leads to some re-work, it is also a key agile principle that the output of the agile team must meet the customers needs, and re-work should only occur if it is in direct response to a real customer need, not a perceived future benefit that has not yet been requested by the customer.

It seems that the real problem here is that the customers requirements are not understood by the developers working to solve their problems. Where the source of that breakdown is I don’t yet know, but the failure certainly is not because of the “agile crap” – it is more likely that either the development team doesn’t understand the customers real needs, or they are not practicing true agile principles.

So, on my long drive home, I found myself thinking about my day, and I did indeed fall squarely into one of the two camps I mentioned above. Which one it was should be quite obvious to anyone who knows me…