It is exciting to see more and more organizations adopting Agile development processes.  Agile helps organizations speed time to market, lower project risk and improve relations between business and IT.  Unfortunately, there is still a lot of misinformation or myths about what Agile is and isn’t.  These myths keeps organizations from adopting Agile processes.  This blog series will address the top 5 myths about Agile development to help organizations know the simple and practical facts regarding the costs and benefits of Agile.

Myth #1: Agile does not work in large organizations because there is not enough planning to support the budget process.

I am surprised how many people assume Agile is a series of sprints with little upfront planning and an indeterminate end date.   While it is true that Agile development starts sooner, this is not at the expense of planning.  Planning in Agile is an iterative process that begins with high level objectives that are decomposed during a series of iterations often called sprints.

A proper Agile project begins with a Product Vision and Product Roadmap.  The Product Vision documents the goals of the project and defines how the product aligns with company strategy. The Product Roadmap is a high level description of the features and functions that make up the desired product.  These high level artifacts ensure that everyone involved in the project has a common understanding of project goals.  A well written Product Vision and Roadmap, along with the original business case, also provides management with enough information to develop a project budget and allocate people to the project without delaying the project start or wasting time and effort.  As you can see planning is done, it is just not overdone.

While it is exciting to start projects sooner and to have a clear concise vision as to what needs to be done, the real value of agile from a planning standpoint is the early feedback loop.  Agile projects begin sprints as soon as possible.  The project velocity (the amount of work that can be completed in each sprint) is measured at the end of each sprint.  As the team completes the first 3-4 sprints they should have a good sense of their project velocity (the amount of work that can be completed in each sprint).  Based on this information the product owner and scrum master can give senior management an updated estimate as to when the project will deliver and how much it will cost.  This new estimate comes early in the project lifecycle and is based on lessons learned and course corrections from actual development.

Compare this to a project that uses a traditional waterfall methodology.  While the Agile team is showing working code and providing updated timelines and cost estimates; the waterfall team is still developing or refining requirements.  Most waterfall projects realize they are behind schedule near the end of the project (during development or testing).  By this time, there are significant sunk costs and management is forced to cut scope or spend more money with little warning.  Agile’s iterative approach gives the team and management feedback on project issues much earlier in the process.

As you can see, true agile projects make project planning easier.  Agile organizations have the information they need to initiate projects and the early warning they are looking for when a project is going to be more expensive than originally estimated.   Companies looking to improve their planning capabilities and lower risk should look to adopt Agile rather than exclude it.