By Steve Kelman

Agile development: A case in point

At a recent Kennedy School executive education program, I was lucky to have a chance to meet and talk with Mark Schwartz, CIO at the Homeland Security Department's Bureau of Citizenship and Immigration Services.

Mark has a great background, coming to government for the first time after a fascinating career in private-sector IT. He studied computer science at Yale, he went to film school, dropped out, and worked first at a film production company, then in software consulting, then lived abroad for five years. After all this, he went back to school to get an MBA at Wharton, and then became CIO of a company called Intrax Cultural Exchange, which sets up different kinds of exchange programs, including au pair jobs for foreigners working in US families.

“Then,” he says, “I got this idea that it would be interesting to work for government. My organization brought 60,000 people a year to come to the US. Citizenship and Immigration Services receives seven million applications a year to come. DHS seemed to have a lot of problems – I thought maybe I could help.”

And here's something that many will regard as amazing: He applied for the CIO job on USAJobs – and eventually got it (although six months passed before the agency acknowledged his application).

Since coming to CIS, Mark’s major challenge has been to take charge of the agency’s major IT transformation effort to digitize agency benefit application processes (including for visas). The project had been going on for several years, burned through hundreds of millions of dollars, and not yet produced any capabilities – in other words, a prototypical IT program in trouble.

With his private-sector experience, Mark has chosen to see if he can turn this program around through agile software development methods – under which software is developed in very small increments by small teams, rather than having complex and detailed requirements that take years to develop, and often never get developed, with the aim of getting incremental capabilities out much faster.

To Schwartz, the potential advantages of agile were fairly clear. When the software being developed is complicated, requirements changes (inevitable in large numbers in any major project) themselves become complicated because they involve rewriting more already-developed software. When problems are discovered during an old-fashioned “gate review” after a lot of work has been done, they similarly involve huge amounts of rework of already-developed code. The long lead time before any capability actually exists delays and complicates user feedback that is so essential for a new system.

I asked Schwartz what the problems he perceived in introducing agile into government and his approaches for dealing with them. One issue, he said, was that project overseers like to see well-developed requirements, which are not available early on for an agile project. His approach has been to present high-level system capabilities rather than more detailed requirements (which, it might be added, often significantly change anyway).

A similar problem involves the way the test and evaluation/independent verification and validation community do product testing at gateway reviews, in ways that are often time-consuming and contrary to the agile spirit of getting capabilities out fast. His approach has been to involve the testers in small tests while the software is being developed, rather than waiting for a formal gate review.

What’s his most difficult challenge? Agile involves development by small teams that are empowered to make decisions and even tradeoffs to move things forward fast. In government, with many stakeholders with different interests, and often less ability to have a common metric (such as return on investment) to judge tradeoffs, it is difficult to give as much authority to a small team as an agile effort in the private sector would typically have. He doesn’t feel he has solved this problem, but is toying with the idea of getting teams empowered to make tentative decisions, that are then – like elements of a new agile release in general – submitted to reaction from users, realizing that the smaller increments mean less rework costs if something doesn't go over well.

In May the new approach bore modest fruit as CIS debuted an online visa account form. Pretty modest when you think about it for a second – my reaction was “didn’t they have this already?” – but at least that the effort seems to be turning around. Better late than never, and hopefully there will be lessons learned here for expanding the role of agile development in the government.

Reader comments

Tue, Sep 25, 2012
Scott

What is the value of a barrier between the contractor and owner that you need to worry about it breaking down? I would say the contractor needs to provide value to the owner. Under Agile their is an expectation that the contractor would do that on an on going basis. It shouldn't be about making it easy to judge if someone is doing a good job, it should be about creating real business value. To do that you often need to be involved and not standing behind a "barrier". I think of "the operation was a success but the patient died".

Fri, Sep 21, 2012
Josh

Executing as part of the PMO for a level 2 agile project with DHS that is trying to execute some of the suggestions that Mark has brought through the DHS Agile development efforts. Particularly, I want to emphasize that we do have requirements, we do have tracking, we do have EVM even. But these are not fixed up front with no changes, they are not in the contract as required to be met. The government group is responsible for prioritizing and providing direction on what is needed to be delivered. The documentation is barely sufficient. The processes are flexible and fast. We do execute against an architecture, we do execute and generate DHS level services, but we go it in a collaborative way. We have been through ADE 2A, 2B, were a red program for a while and are now green. In order to make this work, it requires the program management to also work collaboratively with the oversight and governance boards, which we have done to educate and help simplify where possible. We have a vision, not detailed requirements, for what needs to be delivered for the end users and that is what drives development.

Thu, Sep 20, 2012
Mark Schwartz

(Continuing my last comment). One person commented "You'll never get away from being responsible and accountable" and others spoke about the need for documentation. I agree with all those thoughts. Agile approaches do not attempt to evade responsibility - quite the opposite - they emphasize accountability for delivering results, frequently, quickly, and with an eye toward adding mission value. The difference is in whether the requirements are fully defined up front or are somewhat discovered during the process. An agilist would argue that the waterfall approach "punishes learning", as change is considered bad.

Thu, Sep 20, 2012
Mark Schwartz

Thanks for all the comments! I thought I'd jump in and respond to a few of the points raised. First, I think Tim is on the right track - we're buying something different here - not execution against a set of requirements tossed over the wall to a contractor, but services in a process where the government continues to be involved and bear some responsibility. That's the nature of an agile approach.

Fri, Sep 14, 2012
Alan

Doesn't this conflict with the push to eliminate riskier contract types? If so, then, . . . fine by me! If this approach bears fruit, though, it may be more feasible to bring the work in house than continually worry about the contractor-owner barrier breaking down. When the contractor has such intimate and irreeplaceable knowledge of the system, I worry he can extract rents from the government.