Agile Myth #8: Agile Will Prevent Problems

A lot of managers expect that when they adopt Agile, they'd hear less problems. But then the exact opposite happens - they actually hear more problems. What's going on?

Normally in projects, management doesn't hear about problems until late in the project, or only when the system has been put into production. When Agile practices, such as iterative development, are done correctly, the organization uncovers problems earlier in a project.

Agile practices expose problems earlier, while there's more time and budget left to fix the problems. In traditional projects, you only find out about problems towards the end, when there is little time and money left to fix the problems.

This is actually what you want, because if you find out about problems earlier, you'll still have plenty of time and budget to fix the problems. Or if the problems are not economically feasible to fix, you can terminate the project early and invest the money, time and other resources in something more profitable.

Here are some examples of problems that you'd rather learn of earlier, than later:

• Stakeholders see early iterations of the system and argue over their interpretations of requirements.
• This is good. It's better that stakeholders learn that they don't have a common understanding of requirements early on, and try to resolve it early on, rather than waste time & money building something that's unacceptable to many stakeholders, and having to invest more time & money to resolve the deficiencies.
• Dev team builds the wrong thing.
• Again, it's great to learn early that the dev team doesn't understand the requirements. What can be done to fix this? Maybe the stakeholders need to spend more time with the dev team. Maybe the dev team needs to take more effort understanding the requirements.
• Iterative builds fail.
• Iterative development isn't about regular check points. It's about delivering something stable enough at the end of each iteration, that in can be deployed to production by the stakeholders should they choose. Not being able to deliver something stable at the end of each iteration reveals possible skills gaps in the team. Stakeholders can either decide to invest filling the team's skills gaps, such as through training, or decide that the team is not a fit for the project and choose a different team.
• Stakeholders are not available to personally drive the project.
• Agile does not work unless stakeholders are invest a significant part of their own time in the project. Many activities cannot be delegated. If stakeholders are not available, more formal and rigid processes would be more appropriate. The project will likely still fail, but there would be documentation that would protect team members from blame.

This is my ninth post in my 13-part series, "Agile Myths and Misconceptions", It's based on the talk I gave at the first PSIA Softech Philippine Software Engineering Conference. I am striving to correct 12 common misconceptions about Agile Software Development.