Working to some kind of Agile methodology can be a great way to deliver web development projects but it can also be a complete nightmare if not done properly. Most people will be familiar with the standard waterfall approach of design, build test and may have heard about the possible benefits of Agile…

1) Agile is a way to avoid documentation

Not quite. No one like documentation. Least of all me, its probably at the top of my list of most boring things to produce. Working away on formal prose that nobody is likely to read is very demoralising. Agile does not remove the need for documentation, but it can simplify the process since you do not need to produce some kind of 200 page functional or technical design up front. Instead specific functional areas can be broken down into stories that should detail key aspects of development but these can change over time. Status reports can be avoided through regular updates with the team and project plans can be simplified by using cards.

2) Agile means complicated projects can be delivered in less time than using more traditional approaches

Hardly. Agile processes sometimes seem like they streamline development to the point that more can be delivered in set timescales. This is not necessarily the case. The real benefit is that changes can be absorbed throughout development at the beginning of each sprint so that the final product is far closer to business expectations, rather than developing something that matches the design but is no longer relevant by the time is is finished. Clearly the kind of change that can be dealt with through agile is not free. Some features and functionality that is initially asked for will fall into the backlog and not delivered if more things are added along the way.

3) Business representatives have no place in Agile since developers can make decisions for themselves

No. When developing using Agile there needs to be closer ties between the business and the technology departments because there is far less documented objectives. Work produced needs to be regularly reviewed, functionality demoed as soon as its ready and clarifications fetched from stakeholders at every opportunity. Without this contact developers will make decisions and get on with things, but this can waste valuable time when it turns out to be wrong.

4) Agile works with offshore development

As long as everyone is offshore. The problem with integrating an offshore team is that often they will require more detailed requirements and design than is available at the beginnings of an Agile project. Without detailed instructions the productivity of an offshore team will be low and projects will not get finished in time. Communication is a real problem here. Although you can have teleconferences, video conferences, IM chats and all the rest of it, there just isn’t the ability to empower developers when they cannot just shout over the office to answer a question or clarify a requirement.

5) Agile give you detailed project plans

Although it can inspire confidence by planning a project in detail from beginning to end, this is a fruitless and pointless task. Changes that come about over the course of development and through discussions with the business will mean that any initial plan gets blown to pieces in no time. Buy a huge white board, hundreds of brightly coloured cards, multitudes of stickers and plan out the first few sprints and then let everyone get on with things. Soon it will be clear what the velocity of the team will be and the speed at which things are getting done and then it will be easier to estimate the rest of the project.

6) Developers do not need to be involved in project planning

Developers are the most important resources in the Agile approach to development. They understand the scope of changes, the can break down the complexity of business requirements, they know best how long things will actually take, and they know better than anyone else what they like and indeed want to do. When planning sprints, developers should volunteer for tasks, they should estimate and not only will they be more engaged with the project but will have then invested more in its success. If developers cannot do any of these things they should be replaced with ones that can. Project managers who take too much of this responsibility away from developers should also be replaced.