CHAPTER 5: THE AGILE BUDGET

Funding models

Image

‘Costs do not exist to be calculated. Costs exist to be reduced.’

Taiichi Ohno, 1988

Aim of this chapter: To define the associated financial models and processes that support your Agile organisation. We will look at Agile budgeting and delegation options, as well as how to manage budgets, quotes and costings, alongside changing Customer Requirements.

Most organisations plan funding by financial year, and allocate it to Departments for business-as-usual activities, or temporary projects for a specific outcome. This, in turn, is generally broken into capital, and operational, expenditure. However, a lot can happen in a year. Teams with long-term fixed budgets may not be in a position to take advantage of new opportunities, or adapt to meet changing Customer Requirements.

Where possible, Agile organisations should adopt the following three major changes to funding models to ensure Teams, Departments, and projects, remain adaptable.

1  Monthly or quarterly budgets: By reducing the duration of each budget, organisations can tailor funding to meet the current needs of a Team, or Department. As most budget proposals will be identical, or nearly identical, to previous months, there is negligible overhead in managing multiple, short, budgets. Teams and Departments are encouraged (and in some cases incentivised) to be innovative with their existing budgets, and, where possible, reduce outgoing expenditure.

Image

Example budget change request

The Sales and Marketing Team (the Customer) approach the Communications Team (the Team) to deliver a new, social media advertising campaign, to take advantage of a new opportunity. The Communications Team does not have the skills for this, and so puts forward a new budget proposal that includes a social media communications strategist. The Finance Team, in charge of the budgets, examine the proposal, and approves it based on the expected benefits, allowing the Communications Team to recruit within two weeks.

2  Team level contingency: As part of their monthly budget, allocate each Team a contingency budget (usually ∼20%) to spend at their discretion, either in the delivery of Customer Requirements, or as a mechanism to innovate change within the organisation. Unused contingency should carry over, to encourage sensible spending, rather than the traditional ‘use it or lose it’ approach.

Image

Example uses of contingency:

•  The R&D Team use their contingency budget to replace a defective stress-test machine (the replacement cost was low enough that they did not need to increase their budget proposal).

•  The ICT Support Team uses their contingency to subscribe to an IT journal (after checking that no one else had already subscribed).

•  The HR Team, having recently had a large turnover in staff, use their contingency on team-building exercises.

•  A Delivery Team uses their contingency to outsource a specific, and unique, Customer Requirement, to a specialist firm.

3  Staff welfare: Departmental and Team budgets are planned around ensuring delivery of the Customer Requirements, while maintaining a sustainable workload for each Team. From a budget planning perspective, it can help to visualise your Agile Team as a pipeline, as shown in Figure 48. The width of the pipe is your Team size, and the length is the time available to deliver. If a new, high priority, Requirement comes into the pipe, and as an Agile Team this is encouraged, the lowest priority Requirement will fall out the end. In Agile terms, the Velocity of each Team doesn’t change just because you give them more work. New research actually suggests that sustained overtime can lead to a significant reduction in productivity1,2,3,4. If your Customer wants you to deliver the new Requirement, as well as all the older Requirements, then the pipe will need to be widened (new staff added), or lengthened (additional time given), both of which will have an impact on the quote and/or budget for the Customer.

Image

Figure 48: Team pipeline

Image

Remember Agile principle #8: Agile processes D promote sustainable development. The sponsors, developers [Team Members], and users, should be able to maintain a constant pace indefinitely.

Whilst the above changes are recommended, funding models are often outside of the Team, Department, or even organisation’s control. In those cases, traditional funding models can be effective, provided there is some flexibility to adapt to changing circumstances.

Regardless of the funding models, legislative and commercial disclosure rules will always apply, whether to shareholders, government regulators, or other stakeholders. Being an Agile organisation, the financial controls for each Team or Department must promote probity, integrity, and financial transparency. A transparent financial system will streamline both internal and independent audits, and reduce the impact on operational Teams. This will also simplify the development of operational budgets, balance sheets, profit and loss statements, etc.

Quoting for Customers

Image

‘There are so many men who can figure costs, and so few who can measure values.’

Anonymous

Most Customers, regardless of whether they are internal or external, will ask the same questions. As an Agile Manager, your answers may look something like this:

‘How much is this going to cost?’ – ‘As much as you’re willing to spend.’

‘How long is this going to take?’ – ‘As long as it takes to deliver what you ask.’

‘What am I going to get?’ – ‘Whatever you tell us you want.’

Because of the regular Releases, and a constantly changing set of Requirements, it is best to quote Agile work under a time and materials model. This is where work will continue, until your Customer is satisfied, and stops funding the Team, without a fixed end date. Unfortunately, this funding model is not always possible, or appropriate, especially when there is significant capital costs associated with the Requirements. In these situations, providing fixed quotes is possible, but needs careful attention, to ensure they are accurate.

Fixed cost

Where your Customer asks for a fixed price quote, prior to agreeing work commencement, but is flexible on the scope of delivery, and how long it takes.

How to quote: Identify, and estimate, the approximate Requirements, as per Chapter 4: Work, the Agile Way. Use this to calculate the cost to deliver.

How to deliver:

•  Work in absolute Customer priority order. Reducing the time spent on technical support Tasks will help meet short-term budget constraints, at the cost of long-term efficiency.

•  Monitor Velocity and burn rate, as these are your key indicators of cost.

•  For Incremental Delivery, release in short (one-two week) Iterations. Longer Iterations have a tendency to cost overruns, similar to waterfall projects.

Image

Example fixed cost scenario:

Customer: External Not-For-Profit Customer

Team: Production and Operations/Delivery Team

Requirement: As an office worker in the Customer’s organisation/I need our office support managed/So that I can focus on my core responsibilities.

Work: Supply administration support services for a not-for-profit external client, with significant budgetary constraints.

Fixed time

Where your Customer asks for final delivery by a specific date, but is flexible in scope and cost.

How to estimate: Using historical Velocity data, each Team can estimate how many Story Points they can deliver by the due date.

How to deliver:

•  For Requirements with equivalent priorities, work in Story Point order (from smallest to largest). This increases the total number of Requirements the Team can complete by the due date.

•  Enforce Iteration duration for Incremental Delivery. The duration is defined by a fixed number of Iterations, and extending an Iteration will push out your final date.

Image

Example fixed time scenario:

Customer: Sales and Marketing

Team: Media and Communications

Requirement: As a marketing manager/I need marketing material with our new corporate branding/So that I can ensure a consistent message to our external Customers.

Work: Design, and print, new marketing material for a product launch.

Fixed scope

Where your Customer has a fixed set of Requirements, but is flexible in the time it takes to deliver, and the cost of delivery. This is sometimes known as ‘heavy Agile’.

How to plan: Focus on Requirements Backlog definition and estimation before commencing any Requirement, to ensure accurate scope definition.

How to deliver:

•  Work in predefined, and agreed, Requirements Backlog priority order.

Image

Example fixed scope scenario:

Customer: External Customer

Team: Finance and Accounting

Requirement: As a small business owner/I need my annual tax return completed/So that I can fulfil my requirements to the taxation office.

Work: Complete annual tax returns in-line with legislative requirements.

Fixed cost and time

This is where your Customer asks for a fixed price quote, with final delivery due by a specified date. In this situation, the exact set of features, or scope, is flexible.

How to quote and estimate: Calculate total cost as cost per week, or cost per Iteration.

How to deliver:

•  See Fixed Cost

•  See Fixed Time

•  Update Requirements Backlog as required.

Image

Example fixed cost and time scenario:

Customer: External Customer

Team: Production and Operations/Delivery Team

Requirement: As a SRO/I need contracted three project managers/So that our new projects are managed in-line with industry best practices.

Work: Supply agreed services by the end of the financial year.

Fixed cost and scope

This is where your Customer asks for a fixed price quote, for a pre-defined set of Requirements. In this situation, the final date for delivery is flexible.

How to quote and plan: Increase the estimate risk during planning, to ensure your quote allows for unexpected delays that would affect your cost to deliver.

How to deliver:

•  See Fixed Cost

•  See Fixed Scope

•  Update delivery date as required.

Image

Example fixed cost and scope scenario:

Customer: External Customer

Team: Production and Operations/Delivery Team

Requirement: As a building site manager/I need 13x pre-cast concrete slabs, based on our architect’s designs/So that we can construct the landscape of a new building.

Work: Build and deliver to architectural specifications.

Fixed time and scope

This is where your Customer asks for a fixed set of Requirements, with final delivery due by a specified date. In this situation, the total cost to the Customer is flexible.

How to estimate and plan: Pre-assign Requirements by week, or Iteration, during planning, to define the scope delivery timetable. Pad the schedule with extra time, to cater for unexpected defects, or technical debt.

How to deliver:

•  See Fixed Time

•  See Fixed Scope

•  Increase the size of the Team prior to completing all the Requirements (e.g. three-four Iterations for Incremental Delivery), if required, to ensure the scope is completed on time.

Image

Example fixed time and scope scenario:

Customer: Product and Operations Manager

Team: Human Resources Team

Requirement: As a Team/We need two new graphic designers, with mobile design skills/So that we can deliver our Customers’ Requirements.

Work: Recruit required staff prior to a new project commencing.

Fixed cost, time and scope

In this final scenario, your Customer gives you no flexibility in the Requirements, from budget, schedule, or scope.

Cancel the work. This is not suitable for Agile, and should be run using a traditional framework. However, even then it is likely to fail, without some flexibility.

1 Better Work Discussion, Seo, Paper Series No. 2 (2011).

2 Overtime Work and Incident Coronary Heart Disease: the Whitehall II Prospective Cohort Study, Virtanen, et al (2010).

3 Effect of Overtime Work on Cognitive Function in Automotive Workers, Proctor, et al (1996).

4 Effects of Workload and 8- Versus 12-h Workday Duration on Test Battery Performance, MacDonald and Bendak (2000).

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset