W
hen 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 leadto a nightmare of unmet expectations, long delays, and cost overruns. A new approach to analytical project manage-ment can drive achievemanage-ment 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
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 environgovern-ment. 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 Planning Scrum Team Product Backlog Daily Scrum Product Owner Sprint Backlog Sprint Review
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
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 befund-ing 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.
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
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 Audiaudi-tors 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.
