Before I get beaten to death by the Agile Evangelists, I want to say that I do believe in Agile. I am open minded, and I think Agile methodologies are a breath of fresh air in the software development community. But I'm as skeptical as I am open minded, which I think is a Good Thing. And being skeptical as I am, I think there are some fundamental problems in the way that Agile is 'sold' by some evangelists, and 'bought' by the general public. I will talk about those flaws during a series of posts.
Before I expose my first criticism I would like to quote here the Agile Manifesto. At the first time I read it, I was surprised by how short it was. I was probably waiting for something as long as the Communist Manifesto, but the Agile one is surprisingly shorter:
Manifesto for Agile Software Development
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
That´s it. 10 lines. It almost feel like they wrote it in a napking over a cup of coffee, but it does the job. In a world of verbose meaninglessness, those guys are able to cut the crap and go straight to the point. They get grade A for conciseness.
I can't disagree with what it says. But what stands out to me is the following: while there is value in the items on the right, we value the items on the left more.
Great! They don't dismiss processes, tools, documentation, contract negotiation and following a plan. Hell, I like these guys! This Agile Manifesto thing seems off to a good start! But I feel that many people got it wrong, because what I often see is total dismissal of these items in favor of the agile principles. It is like everything that was ever tried in the 50 years history of software development was wrong.
This is my criticism: Agile is often seen as a 'one size fits all' solution. Also, it is seen as a replacement for everything that came before.
This is a movement that is seen very often in the software industry. Some new idea comes up, usually with a catchy name, and before you notice everybody is talking about it and using it. But most of the people don't get it right, so it is implemented 'by the book' or it is overused. At some point, people get disappointed when they find out the idea is not the holy grail of computing, then many get it wrong for a second time and start saying the idea that would solve all problems is completely useless.
The problem in the process above is that people don't understand the basic principles that drove the development of the new idea. If they did, they would most likely apply it only when it is supposed to be applied, and not everywhere as it often happens.
In the case of Agile methodologies, they came to replace traditional methodologies in the situations where they are misused. The good thing is that this describes the situation of most software projects that try to use some kind of methodology (the most common case is to have no methodology at all, in which case Agile also fits). But even then, if people don't understand the principles, they won't get Agile to work. The smart people will get it and turn Agile into a success case.
So I finish this with two advices. First, understand the principles behind Agile. Read the Manifesto. If you are using any Agile methodology, make sure you understand the reason of EVERY SINGLE PRACTICE the methodology proposes. Then see if it applies to your situation. If so, fine. If not, discard that one and use the rest.
This takes me to my second advice: be skeptical and try to understand the reasoning behind *any* new idea. Use your intelligence and feel free to question what seems to be common sense. It will make you a much better developer.
More information:
Tim High has a great post where he questions: Is Agile for everyone?
Posts
Transactional Hardware on x86
2 days ago
5 comentários:
"In the case of Agile methodologies, they came to replace traditional methodologies in the situations where they are misused."
Can't agree more but there's something very odd about misuse. I've never been in a project where traditional (i.e. bureaucratic) methos are NOT misused.
McBreen says in Software Craftmanship that the place those techniques would be useful are extremely spec-oriented projects, like those from NATO that originated the term ' Software Engineering'.
I never worked in such environment so i can't say much about those but I really think that ' misuse' for 'traditional techniques' means pretty much 'applying to non-military environments'.
cheers
I've just quit a very well-paid contract where the Agile methodology was being misused as a way of managing with a rod of steel and charging contractors £1 a minute if their WORK MEETINGS (not lunch, not breaks) overran. My new line manager whilst trying to give a good impression of my new working environment could not get over the fact that she'd had to pay a £30 cash fine for this. Everyone worked under a cloud of fear and someone ws fired on my second day. I couldn't comprehend this empowerment of management egos and productivity driven by pure anxiety rather than pure adrenelin. An IT sweatshop.
Interesting, I cam across a PDF online from an unrelated consultancy, who have interpretted the Agile manifesto thus: http://bit.ly/crXVod
Note on page 2, sub-header 1, para 3, "Individuals and interactions over processes and tools" becomes "individualism and competition have no place in an agile work environment". Is this a good thing? Are we sure? I'm certain it's not what the Agile Creator intended by the 1st Commandment.
I've had the opportunity to be a "chicken" in the Agile process. I guess that's the term for someone who isn't actually involved in developing the software, but participates in providing input on what we need.
Having a "manifesto" can lock a team in to thinking that maybe there is another way of handling the process.
While I think it's a great way of developing software, the people at my workplace got bogged down in the process. The scrum master & the whatever you call it argued about what should go first & wasted valuable time. Just get the freakin info & do it. If the step gets in the way, remove it. If you need a step for another part of the development process, you can add it in. It was a bit amusing.
Excellently stated. I wish there are more reasonable voices out there. I have often said the same thing about Agile. It was, as you noted, simply a course correction, as the pendulum had swung too far in favor of processes. However, in my own experience, those who often promote Agile do so because they know nothing of any other project management methodology. In fact, the Project Management Institute has little comment on Agile development; which is not surprising because there really is nothing NEW about Agile (other than applying different nomenclatures and selling it as something new). The concepts of iterative development have long been known and, as you know, the best methodology to use depends on the kind of project. Unfortunately, when a project is mismanaged now, and there are no requirements, bad managers just chalk it up to "Agile"! As Phillip noted above, while many people abused traditional methods, I now see more abuses of the Agile methodologies. Nothing really new though; it's all just ways to excuse the lack of project management. People need to forget the fancy lingo from slick PowerPoint presentations and just implement good project management practices.
I find it quite amusing as to how the agile silver-bullet is now suffering from the exact same causes that they say the waterfall methods failed. Ignoring the 'big upfront design' claims of the waterfall methodology often shouted by the agile evangelist (waterfall was always intended to be iterative, but was just not done right - sound familiar?) agile is now failing to deal with all the exact same complexities associated with software development as waterfall projects.
Thanks to agile however, and particularly the political spin surrounding the agile methodologists, software development has not progressed any further, they simply attacked the software development problem coming from a different direction, but got stuck at the exact same place as traditional developments.
Mitch Lacey's dissection of a failed agile project (see: http://www.infoq.com/presentations/A-Story-of-Project-Failure-Mitch-Lacey) is telling and I can see almost identical similarities to a project I was on that failed. Cries of 'the customer doesn't get it, didn't do this right, didn't do that right' echo many of the cries on my project - the difference here of course is being a Software Engineer I know better than to declare that all of the agile methodologies are a failure.
Where agile has failed, and it is a major, major failing in my opinion, is in introducing politics and the politicisation of the software development processes, instead of learning objectively from and improving on those areas where failings occurred in the traditional methods, they simply used political-spin to alienate people away from traditional methods and reinvented the same wheel to make the same mistakes again.
Post a Comment