Introduction
Last week I was listening to the new Thoughtwork's podcasts and I bumped with Sriram Narayan talking about Anti-Patterns of Agile Software Development.
By anti-pattern, he means common mistakes made by teams while adopting agile software development methods. According to him, due to the not-so-rigid way of defining agile development methods (that is a good thing) there are a lot of spaces for interpretation, which can lead to misunderstanding and then to practices more harmful than the traditional software development methods.
While I was listening to the podcast I remembered of a post at IBM's DeveloperWorks blog written by Paul Gorans at early 2012. In this post Paul talks about three pitfalls on agile software development and how to avoid them.
In this post, I'll try to address those three pitfalls pointed by Paul and correlate them with the anti-patterns that Sriram talked about. This is going to be an initial discussion on the topic. Please feel free to complement it the in the comments.
Pitfall 1: Lack of experience
Since 2001, when the Agile Manifesto was written, the world of software development has been adopting those principles hoping that they will vanish with all the problems that exists in the waterfall software development model.
It's true that the agile model is very effective and has a lot of advantages on the waterfall model, but when I see development teams rushing to adopt all revolutionary and miraculous technics of the agile model, they forget that, when we are talking about software development, there is no silver bullet. Everything has its upsides and downsides.
Constantly, the lack of experience of team adopting the agile model leads to bad practices that can be very harmful to the development process. One of the worst practices that I observed is the team that, lovesick for the agile methods, forgets to analyse which methods fit well in the team's needs and what don't. They read that team need to work in the same room and fill a 5 square meters room with twenty developers, hoping that the communication will be strong. Or they read that meetings can decrease productivity and, to be more agile, they stop reading emails and cut off meetings once for all.
Be smart when adopting agile methods and don't think about then as state-of-the-art techniques.
Pitfall 2: Be prepared to fail
Sometimes when we thought about agile software development we have a tendency to think about it as if it is the holy grail of the software development methods. But it is not.
As any project, an agile-driven project has as much chances of failure that an classical software development project. A bad idea won't turn in a good idea just because it has been developed guided by agile principles. It will be a bad idea anyway.
The question is: ok, all projects are susceptible to failure, but how can we try to notice that? How can we avoid spending a lot of money in a project that won't bring any value to our clients?
That's where the agile model excels. One of the pillars of the agile model is the communication. Communication between the team members INCLUDING the client. With fast cycles of feedback it is possible to mitigate risks earlier and be more certain when making decisions.
Another thing that is a little tricky is our concept about success. When we talk about software development, we must agree that, for a project that is fated to fail the earlier we end it the better. And this can't be considered a fail. With the customer being part of the team, all team members want the same output and, if he decides to end the project, it will be a decision made conciously and that was the best for everyone.
The definition of a failed project is one: a project that delivery something that the customer doesn't want. Don't let unfinished projects let you down. Know that if the end of the project was a decision considered best for everyone, it was the best thing to do. Risk mitigation is a talent.
Pitfall 3: Trust your team
Another core concept when talking about agile methods is the trust in the team. This is one of the biggest difficulties that a new agile development team bumps into. Especially when it comes to the company's executive office trust.
It can be hard to explain to a company director that two developers will code together, in one computer. He'll probably see that as a waste of resources. Or even when we think about continuous delivery, the marketing department of the company may be afraid to know that the team will start to delivery "part" of the software that the client bought.
That's why trust is so important to agile development and, without it, there are some changes that must be made in the agile methods to avoid conflicts within the company.
One of the most common mistakes that I see development teams doing is trying to force the agile methods down the executive's throats causing more distrust on the team. Start with baby steps and try to show to them the value of the agile techniques in small pieces.
Your company doesn't like the idea of pair programming? don't do it! Remember the core concept behind pair programming and look for other ways to strengthen communication. For every one of the agile techniques there are a meaning and, knowing them, you can try to find other ways to pursue then and do better software development.