By Steve Kelman

Forward with the dialogue on agile development

I want to thank the blog readers who took the time to engage in a dialogue on blog post I wrote first about agile development in general and then about contracting for agile development in particular. This was a conversation at its best, long on dialogue, substance, and listening, short on vitriol and name-calling. (If only American politics could be like this…) I also want especially to thank Mark Schwartz, the Citizenship and Immigration Services CIO about whom I wrote, for joining in the dialogue and responding to comments.

There are two issues I see coming out of the dialogue that I think continue to need discussion: They are "requirements” and “integration.”

On requirements: As a person coming out of contracting, I agree that the demand for “all requirements up front” is unrealistic, time-consuming, and ultimately fruitless since requirements will inevitably change over the life of a big project. It also fosters lengthy project development cycles to attain all these requirements, a system that has not worked well for agencies or taxpayers. So I have no problem with getting away from that.

But contracting people, not irrationally, want the contractor to know what they are expected to achieve, aka some form of “requirement.” I would have thought that one of the virtues of these really short development cycles (“sprints”) was that what you were trying to do was so controllable and short-term that it would become easier to develop something like “requirements” for the short sprint, and not have to change them (or at least very much).

In one of his comments, Schwartz wrote: “The contractor's performance can be assessed better because they frequently deliver finished product that can be assessed by the government.” I agree. But I can’t get away from the idea that to assess you need to assess against a standard or standards, and these are what “requirements” are. Brent Bushey from ICE wrote in a comment: “We agree to a fixed sprint schedule (currently adhering to 4 week sprints) and we expect our vendor to complete 80% of the story points assigned to a given sprint. Our hope is that this allows us to tie contractor performance to pay yet doesn't tie our hands on the requirements up front.” I’m possibly confused (it wouldn’t be the first time), but isn’t a “story point” some kind of requirement, though maybe not the traditional kind? And when Brent says the contractor is paid based on how much of the “story points” they achieve in a month, sounds like a kind of performance-based contracting to me.

Another issue is integration. I think, though I’m not certain, that the integration issue comes up mostly in the context of Mark Schwartz’s idea that agile sprints be done by several different contractors and that the government contract for big agile projects using a multiple-award IDIQ contract vehicle, with a small number (say 3 or 4) vendors in competition for individual modules. This approach maybe is especially suited for agile – and it has real potential virtues as a way to keep vendors on their toes and to keep pricing aggressive -- but as I understand it, agile could be done using a single vendor for all stages.

An idea developed by a number of the commentators, including Schwartz, seems to be to do integration itself on a gradual, ongoing basis, rather than some big integration activity at the end of a long development project. “The idea is to integrate frequently (preferably through continuous integration) throughout the development process, and then run a suite of automated tests ... Integration is performed by a government team (supported by a contractor) in my model, and that team can work with the contractors to solve any integration issues that arise.”

I feel slightly worried that “continuous integration” will produce a lot of rework, where integration at one stage doesn’t work when a new stage comes on, requiring the integration to start again. However, I suspect that under the current system, big integration efforts also need to be redone (or recede into the indefinite future) as requirements change and start dates keep moving outward. I also wonder whether the government is likely to be good at taking integration responsibility, but perhaps an agency using agile could simply have an integrator on board constantly to work on these small-scale integrations.

I don’t know if I’ve summarized the discussion well or posed my questions clearly. Can we continue the dialogue? This is important stuff, and it’s great to see some dedicated civil servants engaging this.

FCW investigated efforts by the departments of Defense and Veterans Affairs to improve a joint data repository on military and veteran suicides. Something as impersonal and mundane as incomplete datasets could be exacerbating a national tragedy.

The National Information Exchange Model's usefulness extends far beyond its origins in justice and law enforcement.

Reader comments

Mon, Oct 8, 2012
Brent Bushey

To echo Mark's comments, while Mark and I have described different approaches to procuring IT services, I think the critical factors we're both considering as we move forward with procurements are 1) How do we incentivize vendors to build and deliver quickly and in smaller increments? 2) How do we provide "on-ramps" for new vendors and "off-ramps" for vendors that aren't providing value? Our ultimate goal is to provide value to our customers/end users as quickly as possible. To me-- this approach sounds like common sense but when we consider the government's historical approach of purchasing IT services via large contracts... some may find this approach to be revolutionary. Mark-- as always, feel free to clarify/differentiate the approach you're taking.

Fri, Oct 5, 2012
Mark Schwartz

Brent - on your question about SDLC. We are of course dealing with the same framework, as components of DHS. Lots of ideas for you, but I don't know if they'd mean so much to others reading this blog, so I'll email you directly.

Fri, Oct 5, 2012
Mark Schwartz

Alan - yes, I think your questions are the heart of the matter. Let me throw out a few ideas for you. First of all, oversight shouldn't really be determining whether the contractor did a good job, but whether the *program* did. The approach I'm describing I think really makes it clear that the program is taking responsibility and risk. Now, of course, the program needs to decide whether the contractor is delivering good value. We use many other kinds of contractors besides the development contractors, and for many of them we decide whether they are delivering good value without using an "iron triangle" (fixed scope, fixed cost, fixed schedule) approach. I think it's possible. Our advantage in this scenario is the small increments and risks. In a 4-month release cycle, we can keep adjusting course and with the IDIQ approach I've talked about, adjusting contractors. As for how the program makes sure it can deliver on expectations, I think the key is to distinguish high level "capabilities" from low-level requirements. The program, and the contractor, can typically deliver the high-level capabilities (which are what oversight is concerned with) even while allowing the low-level requirements to vary. In fact, there is a good incentive to simplify those low-level requirements in order to stay within the timebox. That is important since studies show that 2/3 of features are rarely or never used. Does that help?

Thu, Oct 4, 2012
alan

Hi, Mark- As long as only a finite number of billable hours fits into a timebox (which I had to google), that should effectively constrain what shows up on the invoice. The objection to labor-hour contracts is that they incentiviaze inefficiency by paying X% profit per hour. If the scope is not completed, then your contractor becomes vulnerable to that charge in an oversight setting. Have you had any circumstances when a scope was not completed? If so, is there documentation you can create to describe the circumstances and why you think you are still getting the contractor's best efforts? Thanks so much for the insight- this topic is of great interest to me because we are always dealing with software procurements . . .

Thu, Oct 4, 2012
Brent Bushey

Following up to Alan and Mark's comments-- the critical piece that is required to manage the "contractual risk" is a strong government involvement with the agile development team. If the government prescribes to an agile development approach but isn't directly involved from both the business and IT project management side... then you're not really doing agile and the contract will likely result in poor products. However, if the government embraces agile and is directly involved, and is also buying services in smaller pieces... then that's essentially the best way to mitigate the contractual risks.