7.4: Budget, Capacity, and Risk Management in Agile - Video Tutorials & Practice Problems

<v ->Let's talk about budget capacity</v> 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.