The Agile methodology has been widely accepted and implemented in many organizations for various goals. Most use Agile for project execution and product development. We even advocate using an Agile-based iterative engagement model for vendor management to minimize the risk of getting locked into long, inflexible contracts, and to prioritize outcomes over arbitrary task lists.
Many executives still think an Agile methodology would never work in their organization. Some have even attempted to implement Agile and were not happy with the results. Agile flops tend to fall into one of two categories: The organization either did not implement the actual Agile methodology, or was not ready for it.
Culprit #1: It Wasn’t Really Agile
In the first category are those that have misunderstood Agile as being so flexible that you can pick and choose what aspects to implement, as if ordering from an a-la-carte menu in a restaurant.
Everyone loves the “no documentation” clause of Agile. “Requirements are flexible; change is inevitable. Therefore, there’s no need to plan anything. We will adjust on the fly.” Some organizations focus too much on Agile ceremonies: they assign roles and diligently execute daily 15-minute scrum meetings.
These are symptoms of a superficial reading of Agile concepts which do not address core aspects of behavior that must take root.
Culprit #2: The Organization Wasn’t Ready
The Agile framework requires a specific mindset, governance structure, decision-making process, and ownership culture that a lot of companies lack:
- Bulky approval processes for change management.
- Middle managers lack the ability to make certain decisions.
- Ownership and responsibility are foreign concepts to employees.
In these scenarios, the successful adoption of Agile will require significant changes to how things are done, and how employees think about their work.
A False Dichotomy: Forecasting vs Flexibility
There is a real need for financial projections to allocate budget for a project. Most executives want to know how much a project will cost, and they want that number to be as exact as possible. They want a price tag for the service or product they expect to receive, especially when engaging with a third party. Completing “on time and on budget” is a constant and uncompromising goal for any project.
The Agile approach takes reality into account: the start of the project is when the least is known about how the details will play out. Budget adjustments are expected throughout the life of an Agile project. As the project progresses, more information becomes available, and forecasts become more accurate. But this flexibility does not address the need to have an accurate budget up front.
One way to address this conflict is to define high-level business outcomes, estimate a cost range for each, and prioritize them. This allows the team to scope the MVP and ensure the minimum required budget will be there to see it through to completion. In addition, if a known set of resources will contribute work toward the project, their burn rates and productivity projections will help narrow the budget range and pinpoint a more accurate forecast. This still requires SME input, clear understanding of the business goals, and adequate attention during initial project iterations.
Likewise, in the case of an iterative vendor engagement, the first sprint should be used to produce a projected roadmap for the entire engagement, to identify the budget, and determine resource needs. Once these are in place, short work periods can be executed with focus on outcomes and concrete deliverables at the end of each phase.
3 Key Takeaways for Agile Project Financial Management
1. “Planning” & “being Agile” aren’t mutually exclusive
Allocate appropriate time and effort to plan Agile projects and iterative vendor engagements. Outside of pure experimentation with completely unknown entities, or certain types of innovation initiatives, most Agile projects allow for calendarized roadmaps with key milestones. These forecasts allow the organization to produce more accurate budgets and support the project with adequate resources.
2. Incorporate contingency and risk.
Too many plans only consider the best-case scenarios and identify the minimum required time and resources to complete the work. The reality is almost always reverse – worst-case scenarios play themselves out very often; everything that could possibly go wrong on the project frequently does. Risk planning should be done in such a way, where there is understanding and visibility into how risks will impact budget, timeline, and resources. Adequate contingencies for budget and time should be allocated to each project.
3. Allow for more frequent financial adjustments.
Whenever possible, financial planning and forecasting should allow for changes, and should occur frequently. It’s hard for organizations to acknowledge the reality that once a project starts, many variables will change, and that initial projections are often based on very little concrete information. All of this can cause projects to run over budget and for everyone to feel like they have failed somehow. Set up a flexible financial forecasting process that allows for changes over time. With each sprint, the backlog adjusts, burn rate estimates get more accurate, and budget visibility improves.
The Agile approach, whether for vendor management or for project execution, works much better when the focus is on prioritizing business outcomes and establishing a continuous feedback loop. Successful adoption of Agile requires a behavior change that goes deeper than following prescribed ceremonies. An organization improves its chances of successfully adopting Agile if expectations for detailed project plans are considered carefully.