dmi

Section 508

September 16th, 2016

How to Do Agile Development on a Fixed Budget

Still believe in waterfall software development? You’re probably alone. Prefer agile but want to know what you’re getting for your budget and when? So does everybody else.

Fixed Budget and Timeline Agile Projects?

For many CIOs and business leaders agile has become an excuse for budget overruns, not writing proper specifications and lack of planning. Our experience is that agile principles applied successfully in development can be combined with budget discipline, a clear scope and time plan, but there is a need for higher discipline.

In mobile development, agility is especially important as it’s difficult to anticipate how a service will work across various mobile devices until you’ve tried it out. So here’s the short version of how we do mobile agile development with a fixed budget, scope and timeline while still getting all the advantages of agile.

1. Scope
Software development is always about solving one or multiple problems whether it is customer facing, a backend algorithm or machines talking to machines. In most cases, the problem and solution can be tested and refined without a single line of code being written. Start with a sketch or low fidelity prototype of the use cases and test and improve until you’ve found a solution that works. Make sure to start with the most important features so you get validation on these first.

The best specification for successful delivery of software development is a prototype of what you want combined with the use cases and non-functional requirements. This is the starting point of the scope you will get delivered within the agreed budget and timeline. While the detailed requirements may change later, the core use case should remain the same.

2. Timeline
With an agreed scope, the delivery team can estimate the effort and time it will take to deliver the solution. Estimation of software development is not an exact science. If you ask three different developers, you will get three different estimates, but as long as the scope is clear you can get a commitment based on the estimators’ experience. The keyword here is credibility. If the developer has a history of reliable delivery of projects based on scope, timeline and expectations then the chances are pretty good that they will do it again. And if they don’t, then there’s your answer.

Another key thing to consider is that the bigger the scope and the longer the lead time, the greater the uncertainty. Therefore, make sure you break down projects in phases of maximum 3-5 months.

Now the timeline is fixed with assumptions on external dependencies and iterative deliverables (sprints). This means that there is a good chance of getting the project delivered on time.

Still, changes to the scope and failure to meet milestones may lead to either:

  • a change which has no impact on time or resources which is simply accepted as a change;
  • a change replacing an existing part of the scope and thereby substituting the scope for the project;
  • a reduction in scope if an external dependency is not met, e.g. an external API not ready in time;
  • a change to the timeline if both parties agree that the change has higher priority than the timeline of the project.

In our experience, most projects experience up to 40% of changes in scope as the project progresses as an effect of a combination of the above.

3. Budget
The time and effort required to deliver the scope provides the basis for the budget, but with agile development we embrace change and therefore there needs to be a buffer for this in the project budget. The buffer depends on how flexible the scope is and your willingness to embrace change. Normally between 10-30% gives significant room for change. Finally, add a risk margin based on experience. If the team always delivers on time it will be small whereas if they have a history of always being late then it will be greater.

What’s Agile about a Fixed Budget and Timeline with a Fairly Well Established Scope?

The starting point is a scope, timeline and budget, but the scope is expected to change throughout the project. Despite prototyping and user testing prior to starting development we can never anticipate exactly what will happen during the technical implementation and when the service gets tested with users. The only thing we know is that we should expect things to change.

There are typically four things that may impact the budget:

  • Changes to the project which adds additional resource requirements, e.g. changing the user experience, adding additional functionality or a change to existing functionality late in the project.
  • External dependencies not met, e.g. late deliverables, issues with external APIs and changes in business rules.
  • The complexity of one or several parts of the scope was underestimated and thus will take longer than planned to deliver.
  • The development team made one of several mistakes that either slowed down the work or meant that part of the development needs to be redone. Development teams are composed of human beings and today’s software systems are very complex. Errors will arise during the course of the project and need to be found and dealt with.

The first one should be embraced and planned for while the others are a part of risk management.

Conclusion

Agile projects can be delivered on a fixed budget and timeline with a scope that will change during the course of the project. The rest is about discipline so that any change is managed within the resource and time constraints.

Magnus Jern, President DMI International

Tags: agile development cost

Connect with us

Job Openings

Want to be part of our growing team?

View More
Work with us

Learn how DMI can help you grow, or launch your business.

Get In Touch
Offices

See all of our locations around the world

View Locations