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.
