- Let's talk about budget capacity
and risk management in agile.
Let us start with budgeting.
The fundamental business question
how much will it cost applies equally
to agile, waterfall,
or any other project management framework.
However, budget management as we do it in agile
is fundamentally different from traditional
or waterfall project management.
In agile, budgeting is happening within sprints,
either monthly or quarterly.
Based on the team composition
and compensation by role and location,
the cost of each sprint is calculated per team
and multiplied by the number of teams in the organization
with all the necessary adjustments.
Those can include loaded compensation
including benefits and other expenses,
any hardware costs, software costs, licenses, supplies,
and anything else required to complete the deliverables.
This is monitored as part of the overall budget.
In waterfall, a project budget is defined
as the total projected cost that is needed
to complete the project.
And usually, it is allocated over a defined period of time.
It's used to estimate what is the cost of the project
phase by phase.
The most fundamental difference
between agile and waterfall is that in waterfall,
the budget is fully allocated
at the beginning of the project.
And during each phase, budget is released step by step.
And at any time,
project manager can say are we on budget,
are we below budget, or do we exceed the budget.
And if we do,
that requires an immediate course correction.
In waterfall, it is hard to estimate
whether a project is on budget during the analysis,
design, and even sometimes coding
because none of the features have been tested
or delivered to users for their feedback.
This is usually the reason why waterfall project managers
need to add a significant contingency margin,
usually starting at 20, 25%,
and sometimes reaching even 40% for complex deliverables.
But in both instances, agile and waterfall,
the following five sources of information are considered
when performing estimations.
One is high level estimation from the people doing the work.
Second is historical data
from similar deliverables and goals.
Third one is lessons learned from prior initiatives.
Fourth is expert opinion from subject matter experts
known within the organization
and sometimes within the field.
And baseline, organizational and industry wise.
Agile puts the emphasis on
decomposing the work to be done into features
and then performing high level feature estimation.
In addition, in agile,
the validation of deliverables
is performed throughout the process.
And it's easy because teams are delivering working software
to the customer,
and then they do re-planning
based on customer and business feedback.
If additional features are requested,
the team does a high level estimation of the work
that is required to deliver these features.
And then the team provides an estimate
to the sponsor or the requester.
At this point, the sponsor can make an informed decision
whether it is worth investing in more sprints
or additional functionality
based on cost per sprint and duration,
or sometimes they prefer to descope
if this is a less important functionality
if they want to stay
within the originally allocated budgets.
So this makes all calculations in agile very simple
compared to the complexity of budget calculations
in waterfall.
In waterfall, the phase of the project
defines the value that is being delivered.
And in agile, there are just two major parameters.
First, stable, dedicated agile teams,
and the second is time boxed iterations.
That's all you need to know.
So let us review an example.
Four team members of a scrum team
are allocated to deliver an application
that has a set number of features.
Once they do high level estimation,
the team forecasted that they would need six sprints
to deliver all the features.
Each team has nine team members.
Based on the organizational data,
the average loaded rate,
and loaded means a blended rate per employee,
is $150 per hour.
The total cost calculation becomes very simple.
First, we'll look at employees per sprint.
We have 10 full-time team members and four teams,
which gives us 40 employees per sprint.
Then, we'll look at cost per employee per a two week sprint.
$150 per hour by 80 hours, which gives us 12,000.
We refer to it as the fixed burn rate per person per sprint.
This gives us cost per sprint of $480,000.
Then, we'll look at six sprints
and 480,000 multiplied by six is $2,880,000.
Then, we'll look at any additional costs,
licenses, equipment, not including vendor costs.
In our case, it's $120,000.
So the total estimated cost is
$2,880,000 per people and labor
and then 120,000
and total of 3,000,000 for this project.
It is important to understand that in agile,
an estimate is not a commitment.
It is a forecast which will be adjusted sprint by sprint.
It's adjusted by validation with the customers,
with the business,
and it is based on incremental deliverables,
and overall, fast feedback loop.
The comparison of agile and waterfall cost management
is presented on this slide.
Once the budget is established,
the following strategies allow agile teams
to continuously refine the budget.
First, high quality product backlog
that reflects MVP, minimum viable product
and subsequent feature list.
The second one is continuous product backlog refinement
that happens along with the consistent estimation.
The third is short feedback loops that happen through demos
and sprint reviews with the customers.
The fourth one is agile planning
to implement the value of iterative delivery.
There is also an ultimate approach to agile budgeting,
the principle of beyond budgeting.
It has been implemented in some agile organizations,
but very few due to its revolutionary nature.
This approach represents a new management philosophy
that is more agile and adaptable,
aiming at eliminating bureaucracy
and rigid control mechanisms
that happen in most of the organization.
It empowers people.
So instead of focusing on long term complex budgets,
which become obsolete as soon as they're published frankly,
beyond budgeting organizations focus their budgets
on short term financial performance sprint by sprint,
very similar to agile delivery.
Now, let's move to the agile risk management.
A risk is anything that could prevent
or marginalize project success.
When a risk materializes, it becomes an issue.
Agile practices provides a built-in mechanism
to manage a wide range of risks.
And those risks are frequently encountered
in software development and overall in business.
Agile doesn't offer a universal definitional of risk.
It doesn't provide a standard approach to risk management
because risk management in agile
is built into the cadence
in such a way that agile provides a framework
to manage risk early and proactively.
For example, agile has continued improvement
based on the short feedback cycle,
so all the potential issues are exposed very early
and triaged within a short time frame.
In addition, the transparency of agile culture
with retrospectives, feedback, and so forth
contributes to exposing risks early.
And once you expose risks,
you are able to address them without blame
in a very efficient way.
So as an example, in daily scrum meetings,
team members have to answer the question,
which impediments am I having?
And then the whole team gets engaged
in unblocking their peers.
In waterfall projects,
team members are mostly focused on their individual tasks,
so there are no similar mechanisms to expose the risk daily
and to triage them immediately.
This way, waterfall has to manage risks
in a very consistent and heavy way.
Agile doesn't have to.
The built-in mechanisms are the reason
why most agile frameworks do not really specify
how they have to manage risks.
Risks are managed via early feedback,
collaboration between business and technology,
test driven development
where the quality is built into the delivery process,
and many other mechanisms that mitigate risks upfront.
For external risks and dependencies that happen in agile,
there are still multiple mechanisms
and tools available for risk management.
For example, some agile practitioners
still maintain a list of risks for their teams.
And those include external dependencies
and especially the ones outside of IT
that could be vendor, legal, compliance issues,
regulatory licensing, and many other risks.
And those risks need to be assessed
and mitigated similar to any other company
irrespective of their framework,
agile or waterfall.