Agile at the Office of Personnel Management--a true story

Abstract

This white paper describes how agile methodologies transformed the Office of Personnel Management’s (OPM) Retirement Systems Modernization (RSM) program from its past difficulties to a program that has delivered published specifications and working software. Whereas previous RSM attempts involved vendors gathering requirements and implementing solutions for OPM businesses that achieved limited success, the current agile approach has created a collaborative effort with the RSM team and OPM Subject Matter Experts (SMEs) to ensure that requirements and solutions developed for OPM are used for OPM. This case study will explain what agile methodologies are and how they can be applied to federal programs; more specifically, how these agile methodologies helped create a collaborative environment for building the RSM program. We will examine how using short iterative development cycles allowed the RSM team to quickly develop specifications and working software that the SMEs could inspect and provide feedback on. This rapid feedback has allowed the RSM team to adjust the product to ensure SME vision. This report examines how to implement an agile program while still meeting government reporting and oversight needs. The report will also examine the major challenges for agile in the government sector and provide ideas for addressing these challenges.

The RSM Back-story

OPM’s Retirement Systems Modernization (RSM) program has had difficulties in its past. The program was designed to convert the current paper-based federal retirement system and infrastructure to an electronic online system, called RetireEZ, and originally used traditional requirements, design, implementation, and test cycles to develop the system.

During the testing phases, serious issues became evident. These issues eventually resulted in a mutual agreement by OPM and the vendor to terminate the RetireEZ contract (Rosenberg, 2009).

A New Solution

“After failing three times to modernize the federal retirement system with the big bang approach, the Office of Personnel Management is taking a new tack that focuses on incremental changes.” (Miller, 2010, ¶2)

Coming off the RSM contract termination, the program was presented with a new solution that addressed the issues that had previously troubled the RSM program. First, this new solution tried to understand the business and program needs; to do this, a strong relationship and collaborative effort had to be established between the program team, stakeholders, and subject matter experts (SMEs). This would help the program build a solution with OPM for OPM, instead of trying to fit the OPM problem into a template solution.

With a collaborative relationship in place, the program works with the SMEs to identify and prioritize the needs for the Retirement Systems Modernization efforts. Whereas in the past there were shifts in focus and effort, the program now creates focus and vision by identifying the highest priority items and working to deliver these high value targets first.

With the priorities in place, the program ensures that correct solutions are implemented by delivering results early and often. By incrementally delivering results for review and inspection, the program is able to ensure this accuracy. This incremental process also provides an infrastructure that supports changes in features or scope by ensuring that all features and requests are prioritized to a master priority list. Thus, rather than attempting to minimize change, the process embraces change as part of the workflow.

By implementing a solution that focuses on collaborating with the stakeholders and SMEs, creating a prioritized feature list, and incrementally delivering value while managing change, the new process is actually an agile process.

An Agile Solution

“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.” (Agile Manifesto, 2001)

Agile refers to a set of software and technology development methodologies that often use an iterative development cycle—a system in which goals, requirements, and solutions are adapted throughout the development process. Agile aims to deliver software and technology solutions tailored to customers’ specific needs rapidly, yet it is flexible enough to meet changing and varied conditions.

Agile also encourages agencies to follow a disciplined approach to project management, one that fosters the core concepts of inspection and adaptation throughout the process. Other key principles include teamwork, self-organization, and accountability. In contrast to the strict waterfall project management methodologies, the agile process values the client and their needs over processes and specific tools, the development of working software over comprehensive documentation, collaboration with customers over contract negotiations, and responding to potential changes in goals or tools over strict adherence to a structured plan.

Agile in itself is not a methodology or process; rather, it is an overall guiding philosophy. The core concepts of Agile are defined in the Agile Manifesto (Agile Manifesto, 2001) and the Principles behind the Agile Manifesto (see http://www.Agilemanifesto.org/principles.html), also known as the Twelve Agile Principals. With that said, an agile process often refers to a process based on agile concepts and principles.

Of the agile frameworks and methodologies, scrum is arguably the most widely used agile methodology (Ramel, 2010). Scrum provides a process that allows a team to iteratively and incrementally build software (or deliver value).

Scrum Overview

The scrum process was developed around iterations, also known as sprints. An iteration is of set length (1 to 6 weeks), in which all work begins and ends on the iteration cycles. At the start of the iteration, the team reviews the prioritized product backlog, which is the list of all the features to be implemented for the project. During the iteration, there is a daily stand-up meeting, also known as the daily scrum. The meeting is limited to 15 minutes and each team member announces four things:

  1. What they have done since the last daily scrum
  2. What they are doing today
  3. Any impediments in their way
  4. Any work that they need reviewed

At the end of the iteration, the team presents the completed work for the iteration. This work is reviewed, and any updates based on the review are captured and prioritized back into the product backlog.

Additionally, a sprint retrospective is held at the end of each iteration, which allows the team to identify what has been working well and what process improvements can be made.

Whereas the waterfall methodology is based on a predictability model that attempts to know all the facts up front and minimize change, the scrum methodology is based on an adaptability model that course corrects and optimizes throughout the process. In delivering the highest value and priority items early, and through frequent and continuous inspections, scrum serves to minimize the risk by exposing and addressing the highest risks early in the process timeline.

For more information on scrum, refer to Ken Schwaber’s Agile Project Management with Scrum (Schwaber, 2004).

Implementing Agile at RSM

Collaboration

The new RSM program team began by building relationships with the various stakeholders and SMEs. In leveraging these relationships, the team created regular Tuesday and Thursday meetings with the SMEs to gather their needs and demonstrate results to date. During these meetings, the team was able to demonstrate a focus to creating program vision and delivering stakeholder needs, which excited the stakeholders and SMEs. This approach was critical in transforming the group’s mindset from that of being suspicious and pessimistic of the program, to one that embraced the solution that the program team and the SMEs were collaboratively working on to develop.

In these collaboration sessions, the team and SMEs identified the data feed specifications as the top priority item to be completed, which was no small task because the specifications were very detailed and exacting. These specifications required collaboration and agreement across a coalition of all agencies, not just OPM. On the heels of the data feed specifications was a data cleansing system that needed to be built.

Concurrently, a program team that focused on delivering based on the scrum model, was created. Key personnel, experienced in agile and scrum, were assigned to the team. Development environments were created and optimized for agile engineering. Agile project management tools were put in place to track the scrum team’s work and progress.

The team’s business analysts and developers worked together to create the data feed specifications and to develop the data cleansing system. The program team used the bi-weekly SME meetings as an opportunity to perform field-by-field walkthroughs of the data feed elements and rules to ensure accuracy and proper understanding. The team also used these meetings to present and review the data cleansing system to the SMEs. It was in these meetings that the SMEs became excited because they could see that the team was not only listening to their needs, but also actively producing results, which brought value to the agency and the SMEs’ daily work.

Governance

The scrum process inherently has governance measures in place via the daily scrum and the end of sprint review meetings. Scrum also provides a series of useful metrics that can be used to track performance and for project governance. See http://www.onemoreagileblog.com/2009/07/common-Agile-metrics.html (Cheng, 2009), for more details on agile metrics.

There are federal governance measures that the program must also meet. Fortunately, for the RSM program, the RSM program team had a good relationship with the RSM project management office team, and the two groups were able to collaborate to meet the program’s governance requirements. The most critical items from a governance standpoint were the monthly status reports and the EVM updates.

The monthly status reports were actually fairly simple to create. Because the team was already tracking a backlog of features in the team tracking system, the team was able to translate the backlog to the status report. The EVM updates were slightly more complicated. EVM and agile are not mutually exclusive, and there have been publications on Agile EVM (Sulaiman, 2007). Many EVM implementations assume a waterfall model, which can be a challenge for an agile project because the work is not sequenced to matching a waterfall model. If the line items are written in the waterfall SDLC, then the best solution is to negotiate with the project management office or governing body to update the line items to reflect an iterative development approach. Additional challenges arise in that EVM generally tracks value based on sequencing of work. This is fine, assuming the EVM system allows for changes and reprioritization of the feature line items. If this is not in place, the agile project cannot assume it should sequence work based on EVM entries; this too should be negotiated, so that the EVM line items can be updated and moved based on product backlog updates.

Challenges for Agile in the Federal Government

There are a number of challenges that one encounters in the government sector and these challenges are even further pronounced when implementing agile in the federal government.

At its core, agile is built around delivering results, whereas the government tends to focus on managing risks. Let us look at the Agile Manifesto (Agile Manifesto, 2001):

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

The agile world focuses on the statements on the left side over those on the right. However, the federal government largely operates based on the statements on the right side; thus, the key issues include:

  1. Reporting of value. As already noted, the government largely uses EVM methods for reporting of value. Although EVM is not necessarily incompatible with an agile model, most government organizations use EVM in a waterfall type model, which causes problems when mapped to an agile program.
  2. Governance. Organizations such as GAO and OMB provide oversight to government projects. There used to be an old theory that the more paper you provided to these organizations, the better your program looked. Although this attitude is changing, there are still issues with governance personnel understanding the agile model and being able to translate it into what they traditionally have required from projects. As noted earlier, the RSM PMO team was very helpful in assisting the RSM program to navigate this issue.
  3. Funding and Procurement. The funding of government programs can have substantial lead time, which creates challenges to programs. In addition, government contracts are generally not written to support agile methods. This, combined with the limited knowledge of the agile methodology by program contracting officers, creates challenges for implementing agile.
  4. Misconceptions. Many government employees are accustomed to running programs in a traditional way and often believe that if a program fails, it is not because the traditional process is flawed but because it wasn’t implemented correctly; thus, even more process is added to the program. Additionally, agile is still new to many in the federal government and misconceptions and misunderstandings of agile have slowed its acceptance.
  5. Agendas. In the federal government there are multiple vendors, contractors, and organizational groups working on different programs. Because these groups ultimately do not report to the same leaders and do not always share the same vision, this can cause conflicts and political issues that can create a strain on programs.

As stated in Cohn’s The Art of Compromise: Scrum and Project Governance (Cohn, 2009), the keys to integrating scrum and project governance are:

  1. Negotiate and set expectations up front
  2. Fit your reporting to current expectations
  3. Invite them to your process
  4. Reference a success

Generally, these techniques can generally be applied when addressing the issues above. These techniques, combined with top down government support and continued outreach and education regarding agile in the federal government, are the key pieces in increasing the success of agile implementation on federal programs.

Conclusions

As noted earlier, the first priority item for the RSM program was to create the retirement data feed specifications. The great news for the program is that retirement data feed specifications have been published in the form of OPM’s Guide to Retirement Data Reporting (OPM, 2009), also known as the GRDR. The program is gathering feedback and test results from the GRDR and continues to iteratively produce updates to the GRDR.

The team has also demonstrated working data cleansing software to the SMEs and continues to define and develop business rules for the system—all of this is considered great progress, considering the program’s status in 2008.

The RSM program was not truly designed to be an agile pilot program for OPM; rather, it was a program that looked at using agile to create traction and results. In 2010, OPM’s Office of the CIO (OCIO) created an agile pilot for a short-term project. For this new pilot, the OCIO has brought in several of the key agile personnel from the RSM program team to leverage their experience and expertise in implementing agile at OPM. The OCIO is looking at the results and lessons learned from this pilot to help develop future agile strategies at OPM.

Agile Manifesto (2001). Manifesto for Agile Software Development. Retrieved on July 19, 2010 from http://www.Agilemanifesto.org/.

Cheng, R. (2009, July 3). Common agile metrics. Retrieved on July 19, 2010 from http://www.onemoreagileblog.com/2009/07/common-Agile-metrics.html.

Cohn, M. (2009, December). The art of compromise: Scrum and project governance. Retrieved on July 19, 2010 from http://www.ebizq.net/blogs/tai/2009/12/the-art-of-compromise-scrum-and-project-governance.php.

Miller, J. (2010, April 14). OPM takes smaller steps to modernize retirement processes. Retrieved on July 19, 2010 from http://www.federalnewsradio.com/?sid=1933852&nid=35.

OPM (2009, November 3). Guide to Retirement Data Reporting. Retrieved on July 19, 2010 from http://www.opm.gov/feddata/grdr/index.asp.

Ramel, D. (2010, June 17). Eclipse Survey Says Scrum Most Popular Methodology. Retrieved on July 19, 2010 from http://adtmag.com/articles/2010/06/17/eclipse-user-survey-scrum-most-popular.aspx.

Rosenberg, R. (2009, February 9). OPM and Hewitt Make Nice on RetirEZ. Retrieved on July 19, 2010 from http://blogs.govexec.com/fedblog/2009/02/opm_and_hewitt_make_nice_on_re.php.

Schwaber, K. (2004). Agile project management with scrum. Redmond, WA: Microsoft Press

Sulaiman, T. (2007, October 5). AgileEVM: Measuring Cost Efficiency Across the Product Lifecycle. Retrieved on July 19, 2010 from http://www.infoq.com/articles/Agile-evm

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI or any listed author.

© 2010, Richard K. Cheng
Originally published as a part of 2010 PMI Global Congress Proceedings – Washington, DC

Advertisement

Advertisement

Related Content

Advertisement

Publishing or acceptance of an advertisement is neither a guarantee nor endorsement of the advertiser's product or service. View advertising policy.