Why Agile Projects Fail: 8 Common Mistakes
We would like to present you 8 important mistakes you should avoid to make your Agile project successful.
1. Allocating a big budget for the initial project.
The idea of agile development is to enable self-management between software engineers – to decide what they will work on, instead of somebody to push decisions through a committee and describe them in a big document. Teams are small and tight.
In contrast, initial projects that put all the resources in at the start don’t let anybody think or plan. In the agile development, programmers often commute their code several times a day, asking frequent builds of it, additional configuration and testing environments. If you have an initial project, you should start it with a small team of architects and developers who’ve worked together successfully before and add team members only if they ask for them.
2. Defining clear requirements, data dictionaries and following standards.
Agile management approach is not suitable for hardware projects or imposing software applications, such as an application for a network routing system, and these are not the kind of projects where agile shines. Agile approach means incremental development and integrations with existing functionality.
The supporters of a clean code take will not want any comments in the code, maybe because comments are often wrong, and because commenting is an invitation for people who don’t really understand development but try improving it.
3. Asking for fixed price and schedule.
There are the same 4 project success factors in agile development: price, schedule, features and quality. You can not satisfy all of them. Agile means a fundamentally different way – that’s user-centered development, conducting tests regularly and constantly negotiating and re-prioritizing requirements. Agile dramatically reduces wasted time, because only team members are in the main roles.
An agile project with a fixed set of goals, but with an inflexible budget and static schedule, is a mission impossible. The only behavior you’ll get out of the team is a conflict.
4. Asking for monthly waterfall metrics.
Agile has a unique style of management, which is fairly inbound-oriented. It’s more focused on the iterative development, instead on producing management reports. Also, since outside managers don’t follow what’s happening on hour basis, there isn’t a lot of value they can add to the efficiency or effectiveness of the agile project.
In cases when you are planning the budget, you want to see reports and flowcharts. Try to avoid that; preparing those translations of Agile basic project mechanisms – cards, stories, integrations and burn-down charts – will not make the team efficient anymore. In reality, making these demands will just prolong the project.
5. Not involving the client until the final phase.
Agile project is a success when there is a direct, permanent contact between the developers and the client. It’s not just user-centered design – it’s the direct communication with the business processes, and permanent user testing that help resolve the bugs and the real-world problems that affect many software projects.
Some managers think that they should not put the client in the team, and doing so is like building a house without actually visiting the site during construction. No one will do that with his own house. You should not allow this in your IT project.
6. Not starting testing until the Beta version.
Testing takes time and a continuous building and change of the agile software – makes testing an effort for the client and a bore for the developers. Besides, testing department may not be available all the time.
These types of arguments are always present and you have to avoid them. You should understand the importance and the economics of software defects: if you catch them early – you will fix them cheaply. Agile approach suggests – if you test throughout the project, you won’t need beta at all. The software will just migrate into production when it’s ready.
7. Not involving the best team members.
The creators of The Agile Manifesto have considered all the aspects of the software development in details. Agile will work best when you have clients who are determined and know their business processes. Effective agile developers are usually nasty smart.
The team members should respect each other, and if they do – the communication will be quick and smooth. The location of the team members is also important. The best situation is when team members are within walking distance, if not in the same room, since it’s impossible to have great productivity if the team is spread across multiple time zones.
8. Using the element of surprise.
Agile effect can be obtained by trust between team members, as well as by close communication and rigorous focus on the highest-priority goals. If you surprise the team with new roles, unstated top priorities, an uncertain budget, or by a simple lack of trust – it will completely damage both: their attitude and productivity.