Undermining Agile

I have seen the Agile development process at a couple places now. If I had Ward Cunningham on my docket I’m sure my implementation would be a lot more sincere than if not. It has been a frustrating few months since I’ve come to embrace these encouraging tenants. Self organization, incremental release; on and on they work – or can work for most development teams. Unfortunately any development methodologies are akin to civic laws. Enact things you can’t enforce and they are just a joke. Here are some reasons why something like Agile may be a futile endeavor:

No or Partial Company Buy-In

It doesn’t matter how blue in the face you get about how awesome Agile or any development process is. If people can’t stick to it or the rules put in place it doesn’t matter. Don’t fool yourself into believing that someone can be made exempt of the process. Or that only the project manager or department-head down matters because everyone matters. If someone higher or next to you has enough clout or whatever to stomp your process with higher priority tasks then you have a huge challenge ahead of you. I would say it will always be a struggle between maintaining the process and pushing back on business ignorance or impatience.

Fortunately, I believe this may be easier to realize in smaller companies in that there are fewer people to sell the ideas on. The determent to those small companies, however, is that there tends to be some executive or founder or someone of authority who can override much more easily than in a larger organization. Win some, lose some.

Ulterior Motive Agile

You’ll get this one day: the manager who is full of Agile catch phrases (and probably himself). He will discuss the benefits of an Agile shop versus “traditional” waterfall approaches which will probably leave you with a premature sense of victory because most developers want Agile and view waterfall as the devil. I don’t share this opinion because I’ve seen it implemented in a way where teams, developers, and project managers interacted in ways based on mutual respect. A side note I suppose.

You will then eventually realize that people like this use the ideas of Agile to relinquish themselves of any sort of planning, discussion, design, or requirements. Some companies or managers need waterfall or whatever strict rule set to approach development by because they simply do not have the capacity to make those sorts of deliverables in the first place. They look at Agile as some sort of relaxed free-for-all where the management makes things up without any sort of decisions or requirements ahead of a project. This ends with the development team going around in circles not quite sure when or what the goals are because nobody really knows.

Agile suggests that late changes in requirements are welcomed which is true. There should be close, daily cooperation between business people and developers so that things can flow smoothly and change quickly. Unfortunately, some companies will try and use these Agile tenants to maintain a lack of decisiveness as long as possible. Business people who know too much about Agile will use it against you.

This entry was posted in Programming and tagged , . Bookmark the permalink.

Comments are closed.