Agile Development Projects: Harder to Estimate, But More Cost Effective

Projects managed in this way are dynamic. There are often multiple routes a project could take. Priorities and business objectives for the client can change from month to month. Agile allows us to adjust our approach after every iteration, adding small pieces to the software, like building blocks.
Due to their dynamic nature, agile projects can be difficult to estimate in terms of time and budget. Since priorities can change, the estimates will often change as well. From a clientâs perspective, however, this is challenging because you need a good estimate to understand whether the software is worth the investment. A project with an unlimited budget and timeline would be an unlimited liability.
Itâs worth doing agile development, however, because the result is often a more effective piece of software. Since we can tailor our approach to changing needs in the clientâs company, we can offer a better end product. That said, we have to find a way to make good guesses about how much agile projects will cost.
Faster/Cheaper vs. Responsive
It used to be that all software projects were developed using a waterfall methodology. Waterfall projects started with a big list of specifications needed for a final piece of software. As consultants, weâd look at the list of all the features needed, try to estimate the time/cost it would take us to build them, and once agreed, weâd work for many months or even a year on a project until it was completed.
Often, however, the final result of waterfall development fell short. Perhaps the software didnât really solve the right problem for the client or the clientâs business needs had shifted over the course of the months it took us to build the software. The result was a disappointed client and a frustrated development team. No one wins in that scenario.
Agile helps us identify the core functionality the client needs early in the development process. Then, we can build added features based on the clientâs feedback as we go along. Agile projects can be faster and cheaper than their waterfall counterparts, but theyâre not necessarily guaranteed to be. The real aim of agile is responsive development that creates a better end product. Most clients understand and appreciate that getting the right product is much more important than getting the fastest/cheapest one. In many cases, however, clients get the best of both worlds from agile development: a better product, quicker, and cheaper than waterfall.
Solving the Right Problem
A key consideration for an agile development project is âWhat problem are we solving?â This is a more difficult question than it seems at first. For clients, there are near-term, medium-term, and long-term needs for their software. Some business groups within the clientâs company may want different functionalities from other groups.
The great thing about agile development is it allows us to test out potential solutions without committing to them long term. We can build a minimum viable product and present it to the client within a few weeks. From there, we have something concrete that we can test and gather feedback on. If that prototype promises to be successful, then great. Weâll add more features and functionality to it (in similar quick sprints and feedback cycles) to get it ready for deployment. If the early prototype misses the mark for exactly what the client needs, we only spent a few weeks on it and we can easily re-tool our solution based on feedback.
This ability to solve the right problem is the biggest advantage of agile development. Itâs also what makes estimation so hard. Often, the problem weâre solving can change. So how do we create good estimates for our clients?
Estimates Are Collaborative
Agile budget and timeline estimates first and foremost have to be collaborative. Gone are the days when you could simply put a sticker price on a specific piece of software. Instead, everyone from developers, managers, executives, and the clientâs concerned business units need to be involved.
The great thing about agile is itâs flexible. In most cases, we can tailor the project specifications to fit the clientâs budget and timeline. We can estimate out the first MVP, see if it works for the client, and then create a continuing estimate for new features. If we agreed on one feature, but now the client wants to swap it out for another, we can often do that (provided itâs another feature of similar complexity and doesnât create new work for our developers).
The key here is communication and regular review. By releasing early and often, we actually reduce risk for our clients, since itâs simple to track progress and make changes.
Conclusion
Hopefully, you can see how agile addresses business needs better than waterfall projects. That said, there is still room for waterfall development when software projects are well-defined and straightforward. The reality is a middle road between waterfall and agile.
While agile development projects are more difficult to estimate because of their dynamic nature, they are more effective at identifying and solving the right problems. Agile can respond to changing business needs, and with collaboration, good agile estimation can reduce risk.
Learn more about our agile consulting practice, and get in touch to find out how agile methodology can help you meet your technology goals.