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.