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.