In the public sector, a change in standard processes and procedures requires significant effort and, often, approval from external vendors and elected officials as well as internal stakeholders. To get buy-in to become agile, you have to utilize all Scrum tools at your disposal to show the value of the proposed agile process.
Agile methodologies are easy to implement in newly formed organizations where processes and procedures are changed every month. But in mature organizations that have processes and methodologies with long histories of success, there likely will be reluctance to adopt a change unless they think they’ll be sure to see big benefits.
Before getting into agile models, I am going to share a small story of success regarding implementation of agile methodologies in the public sector. In 2001, the FBI launched an initiative to adopt a software case management system, with the goal of replacing paper processes with digital records and automated workflows during investigations. By 2005, after spending $170 million, the project had died; mismanaged requirement analysis, poor design, ineffective development, and flawed project management were declared the major causes of failure.
The next year, the FBI announced a plan to develop a a new electronic case management system known as Sentinel. The project was contracted out to Lockheed Martin and budgeted at $305 million for the first two phases. In 2010, the project was only half done and $100 million over budget. The FBI tapped its CIO (and veteran Wall Street tech executive) Chad Fulgham to oversee Sentinel, and he was given full control of project resources and development. He switched Sentinel to an iterative Scrum approach that leveraged two-week sprints.
Fulgham used plan-driven processes where they were mandatory by law. For example, Congress was expecting a quarterly briefing on the project’s progress. Before briefing, Fulgham’s team was required to submit a brief document that followed the guidelines of the Office of Management and Budget (OMB). The team got the project under control, came in under the revamped $451 million budget, and, though it missed its initial September 2011 deadline, credits agile for getting the project done.
Federal IT evaluation guidance, such as IT investment management instruction and OMB IT reporting requirements, specify evaluations at key milestones and annually, which more closely aligns with traditional development methods. For example, for major projects, the OMB requires a monthly comparison of actual and planned cost and schedules, risk status, and performance measures.
If I were given an opportunity to implement agile while keeping existing plan-driven methodologies, I would look into one of three waterfall-Scrum models: waterfall on demand, waterfall on top, or waterfall on the edge.
Waterfall on Demand
In this model, the waterfall process is implemented at the end, typically around release time. You use agile throughout the software development process to build the software and get it completely done, then hand off to the team who processes the release items to use waterfall for release to production for governance inspection or any other internal process. If you need to keep a plan-driven methodology for regulatory compliance, this model is a good choice.
Adopting this new methodology requires an operational support model. This model facilitates releases from the user acceptance testing environment to prestaging, staging, and, finally, production, and is used to push items between QA, staging, and production.