By KyMBER WALTMUNSON

A Tool from the

Software World

Can Improve

Analytical Project

Outcomes

SCRUM

August 2011 | Government Finance Review 25

When jurisdictions undertake analytical work

such as audits, budget analysis, program evalua-

tion, and special studies, they need to consider

the project management tools available and identify the

approach that is most likely to be successful. Successful

project management can mean stakeholders get exactly

what they hoped for, on time, and for the planned cost, while

poor project management can lead

to a nightmare of unmet expectations,

long delays, and cost overruns. A new

approach to analytical project manage-

ment can drive achievement and mini-

mize disappointing and costly results.

Applying a software development project

management tool — and tailoring it to fit

— allows governments to transform the

way we get analytical business done.

Scrum is a project management

approach that is widely used in the soft-

ware development industry, and it has

recently begun to expand beyond the borders of the technol-

ogy world. When traditional project management was used in

software development, it was often unable to effectively man-

age the complexities, ambiguity, and rapidly changing envi-

ronment software developers faced. A new set of software

development approaches was created, including Scrum.

Since many government analytical projects face similar

complexities, ambiguities, and changing environments,

Scrum can be a useful project management tool for the

public sector, as well.

ESTIMATING SCOPE, SCHEDULE, AND BUDGET

In the term’s original use, a scrum is a rugby formation

where players work as a team to get

possession of the ball. Scrum projects

emulate rugby teams, with team mem-

bers working collaboratively on a com-

mon goal. In contrast, traditional project

management can be envisioned as a

relay race, where players pass a baton in

sequential phases of handing off work.

Under the traditional approach (see

the left triangle in Exhibit 1), there is a

set scope that allows the schedule and

necessary resources to be estimated.

However, the resources and schedules of many government

analytical projects are fixed, as shown in the triangle on the

right. The element to estimate is how much scope can be

addressed, given those constraints. In other words, under

traditional project management, the plan drives cost and

schedule estimates. In Scrum, the project vision and desired

value drive estimates of scope.

Exhibit 1: How Scope Is Estimated

Source: Based on material from the DSDM Consortium

FIXED Scope Resources Schedule

ESTIMATED Resources Schedule Scope

Value Driven

Plan Driven

When project outputs such as

reports or plans aren’t avail-

able to stakeholders until the

project is finished, a project can

move too far off course before

corrections can be made.

26 Government Finance Review | August 2011

THE VALUE OF SCRUM

Government analytical projects need to be focused and

efficient. The Scrum approach delivers business value incre-

mentally, with the highest priority elements delivered first.

Scrum employs a continuous feedback loop to ensure that

the expected value of the project is realized, while incorpo-

rating emerging requirements of the ever-changing govern-

ment environment. The Scrum approach allows decision

makers to end the project when it makes sense to do so, while

still realizing the bulk of the value.

Scrum can increase project efficiency and staff productivity

in a number of ways. Work activities and requirements are

very explicit in Scrum, reducing the amount of time spent

eliminating ambiguity around expectations. Teams are self-

organizing, and they are empowered to estimate how long

it will take them to complete tasks and to control how much

work they commit to during each iteration of a project. The

resulting ownership drives accountability.

Government is full of uncertainty and complexity. Some project environments (e.g., budget changes, political priority adjustments, or the emergence of unexpected obsta-cles) can derail a project that relies heavily on front-end planning. Scrum can be a good fit because it thrives in multifaceted, ambiguous, and shifting environments. The approach relies on a system of progressive elaboration; embracing change.

SCRUM IN A NUTSHELL

Scrum practitioners use specific terminology. Using the specific Scrum terms may feel stilted at first, but the act of using this new terminology helps create a mental and opera-tional shift in one’s approach to project management. Exhibit 2 identifies key Scrum roles, tools, and processes that work together to become a Scrum practice.

The roles in Scrum are important in their responsibilities as well as their boundaries. ScrumMasters help the Scrum team give its best performance. ScrumMasters do not direct or assign tasks; instead, they focus the team and help resolve barriers to completing their commitments. The product owner articulates the vision for the project and communi-cates the value project outputs must embody. The Scrum team is self-organizing, and any team member may take on any task. The team determines how much work it can com-mit to completing in a given sprint — a regular, repeatable work cycle of one to four weeks. The product owners are the stakeholders who drive the project’s goals. The team’s manager is a product owner, and the role can also consider the perspectives of other interested parties such as elected officials, the public, or others who have an interest in the proj-ect. The product owner identifies the destination on the map, the team determines how they will get there and drives the car, and the ScrumMaster makes sure that they have enough gas and road snacks, and handles any mechanical problems along the way.

Exhibit 3 depicts the basic Scrum process and how Scrum processes and tools fit together. The stack of boxes on the far left is called a product backlog. The product backlog is a prioritized list of work needed to accomplish all the goals and priorities associated with a project. The product backlog is constantly reprioritized, and items can be added or elimi-nated as the project moves forward. The smaller stack next

Exhibit 2: Key Scrum Roles, Tools, and Processes

Scrum Roles Scrum Tools Scrum Processes

ScrumMaster Shippable Product Sprint PlanningScrum Team Product Backlog Daily ScrumProduct Owner Sprint Backlog Sprint Review Sprint Retrospective

August 2011 | Government Finance Review 27

to the product backlog is the sprint back-log. During sprint planning, the sprint backlog is selected from the highest-priority elements of the product backlog and expanded into specific tasks. This is a to-do list for a sprint.

The heart of Scrum is the sprint pro-cess, which is depicted by the larger cycle in Exhibit 3. Each Scrum project consists of a series equal-length sprints. The purpose of each sprint is to produce a fully formed, potentially shippable product, represented by the box on the right side. The smaller cycle is the daily Scrum, a daily meeting held to coordinate work, identify barriers, and help com-municate the team’s progress on the sprint backlog tasks to one another.

At the end of each sprint the team holds two meetings, the sprint review and the sprint retrospective. The sprint review is an informal meeting where the Scrum team demonstrates the shippable product for the product owner, verifying that the anticipated product benefits have been realized. Information from this meeting is then used to reassess the product back-log contents and prioritization. The sprint retrospective is

the opportunity for the Scrum team and the ScrumMaster to inspect the sprint process and develop approaches to improve the next sprint cycle.

PROGRESSIVE ELABORATION

A core concept of Scrum is its approach to project planning and execution: Is it better to plan a project and then execute it, or plan while the project is being executed? Fully planning activities at the outset might make sense for some projects; however, this approach can lead to a period of significant disruption when changes do occur. In analytical work, information is frequently uncov-

ered during the course of the work that changes the way the project should proceed. For example, discovering a major internal control weakness during a program review would lead a team to look more carefully at that area than they might have originally planned.

An alternative to the plan-then-execute model for government analytical projects is the progressive elaboration approach espoused in Scrum. This model includes some general planning as the project moves forward, identifying key areas of work —

Successful project management

can mean stakeholders get

exactly what they hoped for,

on time, and for the planned

cost, while poor project

management can lead

to a nightmare of unmet

expectations, long delays,

and cost overruns.

Exhibit 3: The Basic Scrum Process

Product Backlog Sprint Backlog Shippable Product

24 Hours

1-4 Weeks

Sprint

28 Government Finance Review | August 2011

the “what.” The Scrum team repeatedly cycles back to planning during their execution, adding detail and new insights to the “what.” At the same time, the team regularly breaks each project element into the tasks needed to accomplish it, the “how.”

In Scrum, change is a built-in part of the process. It is seen

as an opportunity to improve each iteration of planning and

implementation with new information and an accurate reflec-

tion of the current environment and needs. This flexibility is

seen as regular and appropriate project recalibration.

DELIVERING ON EXPECTATIONS

To ensure the ultimate quality and usability of the proj-

ect output, Scrum has adopted a process that creates “user

stories.” User stories describe the value of each piece of

a project from stakeholders’ perspectives. In government,

there is always a series of internal and external users. Users

can include elected officials, government managers, man-

agers inside the project’s organization,

employees who will be users of the deliv-

erables, or the public.

The outline for a user story is “As a

<user/stakeholder> I want <goal> so that

<value>.” In each story, the team should

work with stakeholders to define the spe-

cific person or group with interest in the

project and the desired characteristics

of the project outcome that are important to that user, and

describe what value they would derive from those goals. For

example, some user stories for a program evaluation might

include:

n As a taxpayer I want an efficient program so that my tax

dollars are well spent.

n As a manager I want acknowledgement of our positive

practices so that the report is balanced.

n As a councilmember, I want full description of the cause

of any problems so that I can use legislative authority to

resolve them.

Using these stories will help ensure that the project is consis-

tently guided by the qualities varying stakeholders demand.

As in most cases with a variety of interested parties, some of

these stories may not lead the project toward the same end.

For example, in the case of the hypothetical evaluation, the

manager might prefer to resolve problems out of the public

eye, whereas the public might want full transparency. These

competing interests should be weighed in the context of the

project’s guiding laws or standards and other aspects of the

environment, and prioritized accordingly.

INCREMENTAL DELIVERy

When project outputs such as reports or plans aren’t avail-

able to stakeholders until the project is finished, a project can

move too far off course before corrections can be made. In

some cases, the project could wholly miss the mark and need

to be redone completely. This wastes resources and gener-

ates a good deal of frustration.

The Scrum process requires rethinking the approach to

project outputs. At the end of each sprint — the one- to four-

week work iteration — a potentially shippable product incre-

ment is expected. A potentially shippa-

ble product is one that is functional and

complete, based on the criteria set forth

during planning. For example, if the

ultimate project output is an analytical

report, the potentially shippable prod-

uct could be a chapter, a section, or a

completed segment of analysis. Or if the

final product will be a jurisdiction-wide

budget, potentially shippable products

might include completed analysis of a segment of the bud-

get, a completed meeting during which budget questions or

concerns with management were discussed, or a draft budget

document.

Incremental delivery ensures that the product reflects

stakeholder requirements, but another key benefit of this

approach lies in the usable output increments. There are

more risks to bringing a project to completion than ever

before, not the least of which is the risk of loss of project fund-

ing as a result of the often-painful budget choices being made

by all levels of government. When usable product increments

are developed, there are two impacts. First, if the project is

terminated, the work has still led to some usable outcome.

Second, having usable segments of output demonstrates the

project’s concrete benefits, which can become a rationale for

fully implementing the project.

The Scrum approach delivers

business value incrementally,

with the highest priority

elements delivered first.

August 2011 | Government Finance Review 29

EFFICIENCy AND PRODUCTIVITy

Scrum helps an organization put the elements of effective

project management into operation. Most of the elements of

Scrum aren’t revolutionary; it is the way they move together

and the accounting for the work that is ground-breaking. The

specificity, transparency, and accountability built into Scrum

have positive effects on staff productivity and morale.

Overtly breaking out each work element into the specific

tasks needed to complete it drives the project forward. This

precision, together with daily coordination, identification of

barriers, and communication of progress, helps individuals

and teams manage their workflow.

The brief daily project meeting builds on the specific work

tasks to create transparency and accountability. The Scrum

team answers only these three questions at this 15-minute

meeting, called a daily Scrum:

1. What did you do yesterday?

2. What will you do today?

3. Are there any impediments to completing

the tasks to which you’ve committed?

Instead of going several days, or even weeks, before barri-

ers are identified or procrastination is confronted, the team

moves quickly through the tasks, promptly identifying impedi-

ments and using accountability as a motivating force.

The team’s ScrumMaster is responsible for resolving barri-

ers to task completion. The very existence of this role facili-

tates productivity. The ScrumMaster’s sole duty is to make

it as easy as possible for the team to complete its work. The

goal is to keep the team working on the critical elements of

the project while the ScrumMaster performs tasks such as

obtaining information from external sources that the team

needs, heading off external demands on team members, or

even bringing coffee to the team.

A final Scrum process that makes use of efficiency and productivity is the sprint retrospective. At the end of each sprint, the team comes together and reviews the sprint. It identifies what went well, what could have been better, and what changes will be implemented in the coming sprints. This frequent, cyclical identification of lessons learned allows the team to quickly improve its process and outputs.

WHEN SCRUM IS THE WRONG TOOL

Scrum will not solve pre-existing organizational problems; in fact, it is likely to magnify them. If there is a lack of commu-nication and collaboration within work teams, Scrum could fail. If key project stakeholders are typically not involved in or open to providing regular direction, Scrum teams might not have sufficient guidance. Poor performers will remain poor performers, and Scrum’s team accountability will bring insuf-ficient work efforts to the forefront.

Sometimes the characteristics of a project team aren’t ideal for a successful Scrum implementation. For instance, a project with relatively inexperienced staff isn’t ideal because teams must be able to work fairly autonomously during work iterations. If members of work teams do not typically have the authority to make decisions related to completing project work, this can also lead to Scrum failures.

Learning More about Scrum

Several books and Web sites dedicated to the practice of Scrum can provide further guidance for using the strategy. Examples include Ken Schwaber’s Agile Project Management with Scrum (2004, Microsoft Press) and the Scrum Alliance at www.Scrumalliance.org.

30 Government Finance Review | August 2011

Processes that are fixed and linear may not be the best

application of the Scrum approach. For example, regular

financial audits with sequential steps don’t require regular

reprioritization and evaluation. Projects that are regular and

repeated may function more effectively using other project

management approaches.

In any situation where Scrum is applied, work must be

done to ensure that the approach meshes with pre-existing

processes or procedures. A little bit of real-world common

sense goes a long way in the implementation of Scrum out-

side of the IT realm. Making some adjustments to the frame-

work can mean the difference between success and failure in

each unique environment. At the same time, watering down

Scrum too much will reduce its value.

CONCLUSIONS

Fully implementing Scrum can create remarkable project

success, especially in complex, dynamic environments. The

Scrum structure and processes work together to ensure that

the project delivers project benefits in a timely, efficient way.

Scrum provides a framework project teams can use to employ

key project management elements such as planning, meth-

odology, risk management, internal and external communi-

cation, time management, and output development. Scrum

provides an effective and even fun way to achieve success

with analytical projects. y

KymbeR WaltmunSon, MPA, CIA, is principal management audi-

tor at the King County Auditors Office in Seattle, Washington. She

is also a consultant at Waltmunson Performance Consulting and

a member of the board of directors for the Association of Local

Government Auditors and the Washington State Local Government

Auditors Association.

Scrum allows decision makers to end the project

when it makes sense to do so, while still realizing

the bulk of the value.