Maine CIO Jim Smith has managed software development projects for 35 years, mostly in Fortune 500 companies. For much of that time, he wanted a better approach.
“We have always struggled with finding the most efficient way to be predictive and consistent in our project delivery,” he said. “I came from a world where you spent three years doing a project: a year doing the requirements, a year with the design and a year with coding. And what came out was often not what you were looking for.”
Then, as vice president of IT at insurance giant Unum a few years ago, Smith changed course. He implemented agile development, in which software projects are broken into short “sprints” of a few weeks and business officials and IT teams work closely on refinements. (This framework for iterative change is called “scrum,” and the person leading the collaborative effort is called the “scrum master.” The traditional and linear software development approach is referred to as “waterfall.” Each phase of a project is completed before moving to the next.)
With agile, users can “kick the tires” on a project earlier, Smith said. You get transparency and the ability to test and to change things.
Smith was quickly sold on the new method, and when he took the Maine CIO position in 2012, he was determined to bring that agile approach to state government. “I saw we were doing a strictly waterfall methodology. I would argue it is not OK for anything anymore. We want more project success. But agile requires more transparency and user involvement, and that is a cultural challenge for people.”
Speaking the Language
Agile: An iterative development approach in which projects are broken into short sprints of a few weeks and business officials and IT teams work closely on refinements throughout the process.
Scrum master: In agile development, the person leading the collaborative effort.
Waterfall: A traditional, linear software development approach in which each phase of a project is completed before moving to the next.
One key tenet of agile is that internal customers must devote considerable time to the project. For that to happen, you need customers who can actually commit the time. “In state government, that can be difficult, because they are already doing a full-time job,” said Jim Hogan, a general manager supporting the Department of Human Services in the Michigan Department of Technology, Management and Budget, which has adopted agile methodology on many projects. “We need the complete and total commitment from the customer and their management.” That factor may determine whether an agile approach is used or not. “We look at duration and scope,” he said. “If there are a lot of external dependencies — that is, working with entities outside the state of Michigan, that might not lend itself to an agile approach. So if we have a project that is self-contained, without a lot of external partners, we consider it. It is easier to do a smaller project with agile than a super-large project.”
Wanted: Agile Government Leaders
Both Salt Lake City’s Bill Haight and CivicActions’ Elizabeth Raley are on the steering committee of a new group seeking to bring together public-sector IT professionals around the principles of agile development. The Agile Government Leadership group has created a website (agileforgov.org) and is seeking to create a community to share best practices and case studies. ”We want to spread the word of agile and how it can be of value to governmental organizations that typically tend to use a waterfall approach for project management,” Haight said. ”We also want to create a network of agile professionals who can draw on each others’ experiences of successes and failures around agile.”
Michael Cockrill, CIO of Washington state, has set up an Innovation Lab in his office, and one of its goals is introducing and supporting agile practices in state agencies. The state is working through how to purchase software and services with agile in mind. “Procurement is a pretty big barrier,” said Ben Vaught, senior program manager. “We are working on getting agile contracting templates built.”
Vaught said most government procurement requires you to specify exactly what you are building three years out. “No sane company would operate that way,” he added. “We are trying to get some best practices for agile contracts, so if you choose to buy a piece of technology from a vendor in an agile way, we can specify the business value we want out of it, and provide reasonable checks and balances to make sure we are building something that satisfies that business value without trying to define every little thing.” Washington has created an agile master contract for purchasing training and coaching services. That was a barrier, he said, because agile expertise didn’t fit any standard model contract. “We have solved that, which is great,” he said.
The biggest barrier to agile in the public sector is that government agency contracting offices want to know everything that will get created for a specific amount of money, said Elizabeth Raley, an agile project manager and certified scrum master for CivicActions, a San Francisco professional services firm that works with government agencies.
Raley said her firm has only worked in the government space for a few years. One recent project involved Web development for the San Francisco Human Services Agency’s EatFresh program. “From what I have seen, it comes down to the relationship between people who want work done and people in the contracting office,” she said. “When there is a respectful relationship and you can explain why agile makes sense, change can happen.”
There are times when it makes sense to assert that a software vendor take an agile approach, said Doug Birgfeld, director of Maine’s project management office. “You may not get them to be great at it, but if we have a failing vendor and their contract is on the line, it is perfectly appropriate to assert that we are doing it this way now,” he said. “You may get a failure, but at least you will have exposed what the problems are so that when you argue for the contract cancellation, you have actual data and metrics you can use to support that case.”
Bill Haight, CIO of Salt Lake City, said he wanted to address the problem of agency requirements changing during a project and therefore increasing timelines and associated costs. He’s experimenting with agile, hoping to find a more fluid approach to software development. Yet Haight sees some barriers. “Most governments still work very much in a siloed fashion, where agencies have their business systems and IT supports them,” he said. “We are trying to break down those silos as much as we can and foster collaboration across departments.”
He said the public sector in general likes to have everything about a software project spelled out from beginning to end. “We like to know what we are going to end up with before we even start. In agile, it is a much more fluid process in between,” he said. “That leaves a lot of public-sector people a little bit nervous. They are more comfortable with developing a full set of requirements and a time length and a traditional waterfall approach. I think it is just a comfort thing. We did bring in a consultant who put on half-day classes with folks about agile and how it works. That was a really positive step for us.”
White House Pushes Agility
One impact of HealthCare.gov’s high-profile launch failure last year is a push by the White House to change how the federal government approaches technology projects.
A 90-member team of software developers and other specialists dubbed 18F was created earlier this year within the General Services Administration to bring the startup model to federal government IT projects. The White House also launched an internal IT consulting group known as the U.S. Digital Service (USDS) led by former Google engineer and HealthCare.gov salvage team member Mikey Dickerson, which is intended to transform the conservative bureaucratic approach. And the selection of Google’s Megan Smith as chief technology officer further solidified the White House’s commitment to modernizing project management.
These moves are widely seen as well intentioned, but it’s unclear if they can produce lasting change — especially with only two years remaining for the current administration.
Tim O’Reilly, founder of O’Reilly Media, said formation of the new groups shows that the White House recognizes there’s a problem and wants to fix it. But focusing on innovation may miss the point.”
When people in Silicon Valley looked at the amount of traffic on HealthCare.gov, they said it’s kind of like a mid-sized dating site,” O’Reilly said. ”It’s not that complicated. It’s not that hard. The whole idea that innovation will solve this is wrong. These guys are not doing the basics.”
One problem is a misguided belief that the government has unique needs that couldn’t possibly be met by using what everyone else uses, he said, a view that’s perpetuated by some existing federal contractors. O’Reilly said that once there are a few examples of agencies launching projects cheaply and effectively, a precedent of low-cost success will work its way into the milieu.
Dickerson sees his task as helping to change how federal agencies view project risk.
"In government, they tend to feel that if they do things the way they’ve always been done, then that’s a low-risk approach. And they still feel that even though the way they’ve done things in the past has led to bad outcomes again and again,” Dickerson said. ”Risk and reward looks different if you’re looking at it through the eyes of your customer.” USDS is now the first stop for many agencies planning new technology projects.
USDS recommends things like using agile development and not committing "a humungous” amount of money at a project’s outset, Dickerson explained.
”Before we get ourselves into that hole where it feels like the only way out is to spend more money, you need to measure your trajectory all along and make sure that if you have a team that isn’t working, or a contract arrangement that isn’t working, or something isn’t leading you to a successful outcome, that you have a way of detecting that and course correcting before years and billions of dollars have gone by,” he said. — Colin Wood
Smith recalled that when they rolled agile out at insurance giant Unum, the company trained more than 2,000 people on three continents. “We sent trainers everywhere and said, ‘Let’s make sure everyone is drinking from the same cup and talking the same language,’” he said. “And we just don’t have those dollars here in state government. We have to do it more incrementally.” Indeed, the executives we interviewed all talked about the importance of training existing staff and hiring people with agile experience.
Washington has an agile community of practice and offers its IT employees “Agile Fridays,” one-hour webinars on agile best practices led by experienced practitioners in the private and public sectors. Vaught said it really starts with “pre-agile” training so people can focus on deciding what to build in the first place. “If you launch right into agile, you could be building the wrong thing super well,” he said.
Before starting any engagement, Michigan’s IT leaders put both the technology and business staff members through agile training — either onsite or in a classroom. “That is a non-negotiable mandatory first step,” Hogan said. “It gets everyone acclimated in what to expect and everybody understands their roles.”
IT professionals with agile experience are highly sought after. “We only hire agile project managers and agile business process analysts,” said Maine’s Birgfeld. “Even if we have to put them in a waterfall environment, they can bring things to that waterfall environment to tune up those processes.” He admitted that agile developers are scarce in northern Maine. “It can be tough, but we find them. And if we can’t find them, we train them up.”
Do agile projects produce better results than more traditional approaches like waterfall? The executives we interviewed said they struggle with quantifying the difference. Salt Lake City’s Haight said that short of going down parallel paths on the same project, it would be difficult to compare the approaches exactly. One of the biggest questions Birgfeld faces in the Maine project management office is how to measure portfolio performance in the agile context. Project to project, the deliverables are coming in or they are not, he said, “but we also have to measure against business’s expressed objectives and missions. So it becomes an exercise in clarifying those objectives and missions.” That has changed the way the state initiates projects from an arduous process of filling out forms to a one-hour meeting where they talk about mission, roles and objectives. “From there we continue to iterate to get more and more clarity until we are ready to engage in the framework of agile,” Birgfeld said.
But IT executives do have anecdotal examples of success. Salt Lake City is using agile processes on an internally developed citation and collections tracking system, said Haight. “Under a traditional model, it would take approximately 24 to 36 months. We expect to complete it in half that time.”
The first business process management project in Maine involved a Department of Labor unemployment insurance claims project. “They had two systems that didn’t talk to one another all that well and processes were very manual,” Maine’s Averill said. An agile project went from nothing to completion in seven weeks, he added. The Maine Department of Education runs five concurrent agile teams for its suite of project work. “Their claim to fame,” he said, “is that they haven’t missed a delivery in 18 months.”