Thursday, October 20, 2011

When Agile becomes an excuse

Agile as a term is so overused it has become almost meaningless. Especially after being hijacked by corporate-speak manager types. It has joined the pantheon of Great Meaningless Corporate Buzzwords That Formerly Meant Something in the Tech Community. It has gotten to the stage where I almost physically flinch when I hear it being used in open conversation. I hate what it has become.

Now, as a software engineer I of course recognise the value and revolution agile development and project management practices have brought us over the last 5 - 10 years. But in my experience I have been scarred by its misuse. I have been burned, baby! Many people (I'm one of them) would say if you are doing agile right, it will always be valuable. I just haven't had good experiences in reality. For example, I worked on a team managed by an engineer who professed to believe in the agile manifesto. A few of us knew the truth of course - that this particular engineer was a cowboy-coder and agile was just the excuse needed to ditch every process and standard and start hacking away - "it says it right in the manifesto!".  The sad reality was the delusion that we were now agile was being used to excuse lack of proper consideration for design and poor coding standards. In fact, the main outcome of "being agile" in this team was bad and wildly differently styled code as everybody rushed to get poorly-defined and incorrectly-sized tasks done in two-week sprints. So the customer ultimately suffered. Not to mention the move to scrum happened right in the middle of a 6 month project wasting ridiculous amounts of time in meetings etc. without proper consideration of availability of product owners and decision-makers. The result was developers filling in the gaps in tasks due to the lack of availability and buy-in of product managers. The product bombed with many customers returning it. I remember seeing a comment on a customer forum along the lines of "it looks like it was designed by a bunch of engineers without a clue how we use the product" How right you were sir!

One of the other frustrating outcomes was that this environment allowed cowboy coders to flourish in the team. I think programmers are like people (almost...) in that it is too easy to label a programmer as being a certain type. We all have different characteristics and personalities and of course some key characteristics shine through stronger than others. It is too easy to just label somebody a "cowboy coder" and move on. All programmers probably have some part of them that just wants to check in some code they hacked together but what separates us from the cowboys, is we recognise a professional responsibility of working in a team and recognise that in the long-term that code is going to be of poorer quality and cost more than code that is properly designed, tested and reviewed. I would like to think that coders who don't really care about the code-base and quality and standard of their work, who don't consider proper design and ultimately (let's not sugar-coat it here) don't give a flying fuck about the customer would cease to exist in a modern development team. Unfortunately I have witnessed the opposite! Cowboys can actually flourish under bad leadership and the guise of being agile. Beware!

Another time, I found myself working on a project with no spec or plan (at least none visible to me anyway) and no structure in terms of project management, everything being drip-fed from the ideas in one persons head. I was told this was an agile way to work when I highlighted some of my concerns to my manager. Working like this is demoralizing. I actually dreaded coming to work but it gradually improved and the project was eventually completed. I have tended to move on when I have come across environments like this and there are no shortage of places looking for engineers these days. The problems are that it is difficult to grasp the culture of a place without experiencing it yourself for a few months and of course the grass is always greener as they you can't move around too much, it looks bad. So the other option is to try to change the culture of a place from the inside, bottom-up. I believe that is one of the hardest things to do in professional life. Another option is to just rant on your blog! It's good to vent.


  1. I cannot agree more, and so I think:

    It is high time to replace the Agile Manifesto by a definition of Agility that cannot be so thoroughly misunderstood by far too many young software developers.

    The new definition I suggest is Best Practice Agile.

    1. @gebhard, That looks really good. Very interesting read.