Software development projects require correct implementation and ultimately good management. Agile budgets are difficult to explain. As with most tasks, if you get the ‘working-out’ wrong, this could impede progress, but fail to calculate the costings correctly… and you will attract unwanted profit loss.
Naturally, an essential part of the management process is conducting research, calculating the cost and also justifying that technology cost to stakeholders. Are you confident your method is the best one?
It is unlikely that will be approving the budget, however, you will potentially be in the driving seat for informing the budget, which if done with precision should increase the likelihood of approval and maximize the results.
Agile Budgets – Less Variable
Stakeholders will want to know some critical criteria for putting approval into a project, which in it’s purest form will typically involve: What is it going to cost? When will we need to raise the money? How much effort will be required measured in time and money?
As a general rule, stakeholders and decision-makers aren’t keen on the idea of you either not knowing what a project will cost, or that you can only guess the overall cost. We try and pretend this doesn’t exist but estimating software costs can become unreliable. This happens because it relies on the judgment and opinion of the software developer.
Agile Budgets – When the CFO is not Agile
Estimating software typically involves stripping back the decomposition of the system which forms the basis for a requirements document, which usually has a different understanding to your customer, which means it becomes a ‘best guess’ scenario of what the system will need. Then a programmer will consider how long each component of that system will take to build, and then finally we add some contingency. Agile budgets are often padded. This can be hidden under different names such as ‘project-based complexities’ or ‘risk assessment,’ but can typically range +/- 150%.
The result is often an estimation that can vary +/- approximately 50% of the final cost, and this kind of variation makes CFOs and other stakeholders somewhat uneasy, no decision maker is comfortable with such a large variable project margin for error.
So where does that leave your project?
While it isn’t easy to predict project costs from the outset, no matter the method, if you are working within an Agile environment, this can facilitate teams being able to estimate more accurately, and you are sure to get more streamlined results.
There still, however, seems to be some misinterpretation regarding implementing Agile into practice and even more so when we discuss agile budgets and estimation.
The objective in reading this article is to highlight the benefits and possibly even pitfalls of using this approach, along with offer some practical day-to-day tips on how to keep your software development project on the straight and narrow.
Let’s Start with Perception.
What would you say are the perceived critical “must haves” when negotiating project success? Hopefully, your list will include Expectation management, Customer-Buy in and Communication. Unless you have an unlimited financial resource and no constraints on time, you will have to be prepared to show the consequences that are put on both cost and schedule when (not so much if) either development requirements or conditions change.
Another essential aspect to consider is the sizing unit. It is a rather basic principle that has become best practice in most industries, yet still categorically ignored. For example, if you were building your own home, would you negotiate with the contractor on the terms of $10,000 dollar-an-hour scheme? No. It’s too ambiguous and doesn’t offer a framework that reasonably reflects the invoice. Therefore, you negotiate in terms that are understood on both sides of the table, such as a fixed price per square foot.
Now there are many already made ‘models’ that facilitate Agile budget estimation; however, there is no such model that is the perfect example of Agile estimation, each area has its positives and negatives to consider, that are especially relevant potentially to your project. Methods of evaluation are vast in number; however, a lot of the principles are the same….no one approach can be defined by a technique or specific approach. Each team must research and adopt the method that works for them. Some of the more familiar Agile methods are Story Points, Planning Poker, Ordering Protocol, Dot Voting, Bucket System, Affinity Mapping and T-Shirt Sizing. The list of methods is actually exhaustive.
So now we have a good understanding and approach, what is the best way to integrate into our teams and ultimately see the reflection in our efficiencies? Our top 12 tips are a collection of proven considerations for your approach.
Top 12 Agile Budgeting Tips
- Your highest priority is always to satisfy the customer with continuous (and preferably early) delivery of software.
- Changing requirements when managed effectively, is not a bad thing in itself even when presented later on in the development stages. Agile process is in place to increase the customer’s advantage over competitors.
- Always try and deliver a preference to a shorter timescale. However, continuous delivery of working software (be it a few weeks or months) is still preferable from the customer’s viewpoint.
- No lone wolves. Developers and Business people alike have to work together on a regular, if not daily basis for the duration of the project. Communication is key.
- Build your projects around individuals that are motivated and allow them the environment that lends itself to progress, both in support and trust to get the work done.
- Be personable. The most effective way (despite the amount of technology at our disposal) to communicate on a project, always has been and still will be above face-to-face communication. There is no substitute!
- The primary measure of both progress and success is working software.
- Sustainable development is achieved with Agile processes. The developers, sponsors and even users should be able to maintain a constant pace, indefinitely.
- Technical excellence and good design requires continuous attention and enhances agility.
- Simplicity is key. An essential approach is maximizing the quantity of work that isn’t done and is in itself an artform. Work smarter, not harder.
- Self-organizing teams, when operating to full potential, are the very hub of recognizing requirements, facilitating designs, and creating the best Architectures.
- Stop, look and listen. Take periodic ‘step-backs’ and reflect on how to be more efficient, and then adjust and tune your approach accordingly.
