Agencies will have to start breaking some IT eggs to build a better IT omelet.
The move to agile system development is forcing agencies to get away from the decades-old concept of trying to build an entire system over three-to-five years and toward iterative segments.
“You ensure that as you go through that environment you put each of those chunks in front of the customer and so they know that what you are developing is what they are looking for. They can redirect what you are doing as the project goes along,” said Tyler Bond, a senior IT specialist and project manager in the Agriculture Department’s application service office. “It’s a way of incorporating project management that is not afraid of change but really embraces change and allows you to incorporate change into your process.”
The Office of Management and Budget has been pushing for the use of agile development over the last two years. Former federal chief information officer Vivek Kundra made agile development a central piece of the administration’s 25-point IT reform plan released last December.
OMB also has strongly encouraged the use of agile development through its TechStat sessions to help fix troubled projects.
But only in the past year have agencies begun understanding how this new approach works. And now as many are starting to put agile in place, they are realizing it changes nearly every construct they have followed over the past two decades when buying and developing technology systems.
“There are significant differences in how we traditionally do the waterfall approach,” said Robert White, a supervisor engineer in the FBI’s chief information officer’s office. “Usually, it is a linear approach where you go through design, test and other parts separately. You have to throw that all out the window. There are multiple-design, multiple-test and multiple-review phases as you put each phase into production. It’s a more trigger-based approach.”
Bond, White and others discussed how their agency is using agile development during a panel discussion sponsored by AFFIRM in Washington Friday.
The use of agile development changes the role of program managers, contracting officers and the business-line owners because traditional project management approaches are used much differently.
“We take our concepts of production and engineering from the 1970s and speculate on what value we want to have at this point of time and measure our progress against what we guessed. It just doesn’t work. Earned Value Management has got to be thrown out,” said Rob Vietmeyer, cloud computing portfolio manager for the Defense Department. “It changes. If you are fielding to production every two weeks, literally going through every step necessary to field a new system to production, system upgrades and enhancements every two weeks, the level of documentation, the level of conversation you are having is completely different than if you are planning for release every six months, 12 months and 18 months. To do this you really have to automate.”
The automated reports help show the progress of the system and cuts down the time it takes to do the necessary steps to field the new functionality, he added.
The widely-used waterfall approach is problematic because agencies end up guessing what their long-term needs are or will be and buying systems based on those ideas, Vietmeyer said.
He said this is why so many large programs from the Homeland Security Department’s Secure Border Initiative-Net to DoD’s
“If you take a big project and say, ‘We’re going to set these objectives,’ but then break those objectives down into modular pieces, then you can roll either in parallel or roll incrementally,” Vietmeyer said. “It’s not to say you can’t take a big large challenge and approach it that way. We need to start to separate the engineering governance with our financial governance. What we have done in the past is we’ve tried to link the financial governance and the engineering governance to a single set of milestones. And it’s held back the engineering teams from actually moving forward when they can because we haven’t hit this milestone yet so we can’t make this next step. So we have built in, in my opinion, these unnecessary links between program financial governance and the technical engineering governance. If we can break those links, let the engineering teams move faster, but then still have the necessary financial oversight necessary on top of that but not directly linked to a single set of decision points then we can succeed with these bigger programs.”
Agile also means breaking away from having one team that does the testing, one team that does the developing and other teams that do one function, he added, and toward having one team that brings together its piece of the puzzle for each iteration of the development.
Several agencies already are using agile development for IT systems. The FBI implemented agile for Sentinel after struggling to get useful functionality.
White said beyond Sentinel the agile approach is catching on across the bureau.
“We were actually putting out a campaign of training,” he said. “We were going before different groups and helping them understand what agile will buy for them, how it will save them those precious dollar resources as they try and move forward with any new initiative they have.”
White said the reaction has been positive, and many offices have asked for more training.
“I’ve even gone to other DoJ components and provided some of the training,” he said.
Vietmeyer said DoD agencies also are adjusting to this new approach for IT projects. He said much of the change is happening because people realize its value.
He said this attempt to change how the government buys and develops projects will be different than other attempts because of budget concerns, a better understanding of what needs to be done and, of course, a change in culture.
For example, Amazon uses a “two-pizzas” approach to developing software, and Vietmeyer said it also makes sense for the government.
“None of their development teams can be larger than what you can feed comfortably with two pizzas,” he said. “You get to these smaller teams and you can get to a point where the requirements, the capabilities are something you can deal with rather than trying to fully comprehend what some large massive system is going to be. The whole goal of getting it out there and get it in the hands of users and continue to evolve this capability quickly.”