TheLectern

By Steve Kelman

Blog archive

Unraveling the agile development knot

In my recent conversation with Mark Schwartz, CIO of Citizenship and Immigration Services, about transitioning the federal government to agile development, we also spoke about some issues for agile contracting.  It was an interesting conversation, with what I would call some good news and two challenges.

Mark is an advocate of using a multiple-award task order contact framework for contracting for agile development modules, with competition among a small group of contract holders for each module.  He agrees with the view that technical developments involving the underlying architecture for these projects makes it more possible than before to do individual agile development modules as “bolt ons” to the architecture, which undermines the traditional approach that says that you need one contractor for these projects because of the difficulty of integration.  He believes that the government should itself often be responsible for developing the architecture and for any integration issues, though when I said this might better be left in the hands of an architecture/integration contractor most of the time, he wasn’t dogmatic on the point.

This approach reflects in my view a real possibility for getting the government a better deal by keeping a small group of vendors in real-time competition for elements of an agile development.  This is also an approach that many contracting professionals in government are likely instinctively to identify with, so implementing it is mainly an educational challenge for contracting and IT folks, not a cultural challenge.

Another issue he raised is more complex.  Because requirements in agile are meant to change, and to be changed easily, Mark didn’t like the idea of putting any kinds of requirements in the task orders for agile projects, or of making the change order process complex in any way.  He also wanted the task orders to be priced on a time and materials basis.  Both, particularly the first, go against common views among contracting professionals – and to some extent of the oversight community – about having performance metrics and making sure a contract establishes what results a contractor is responsible to produce, so as to improve the likelihood that the contractor performs well.

Mark’s solution to this ties in with the ongoing competition for small task orders he envisions in the multiple-award model. The government should extensively use past performance in making future task order awards as a substitute for upfront performance or other requirements.

The problem then becomes how the government knows whether the vendor’s performance has been good or not absent performance requirements in the original task order. Mark argues that the government team will be observing the vendors as they are working on these short “sprints” and can see whether they are wasting time, or compare vendors in terms of production of usable code.

Well, maybe.  But what if the vendors are off-site with no government people present?  Or what if the sprints differ in how tough they are, so comparisons become more difficult?  I also wonder if, when what is being developed in each “sprint” is fairly small, it shouldn’t be easier to express performance requirements and whether there should need to be so many changes – indeed, isn’t one of the aims with agile to reduce changes by reducing the scope of a project?

I’m not a techie and am raising questions rather than giving answers.  I think what we really need is a dialogue among pro-agile IT people and contracting professionals about some of the ways we might deal with these issues.  Good contracting people, as they should, want performance, and that’s why they tend to want requirements – at least performance requirements.  Pro-agile IT folks want the same thing.  Is there a way to give performance requirements for an agile module?

It’s time for a collegial dialogue on these issues.  I would love to hear from blog readers about suggested approaches we could/should be trying – and I bet those working on these issues from both the IT and contracting sides would love to hear thoughts as well.

Posted on Sep 20, 2012 at 12:09 PM


Reader comments

Wed, Oct 3, 2012 Kelvin Armstrong Dallas, TX

The key to a successful project regardless of the methodology is having a clearly defined maturity model of not just how an agency plans to execute but how it actually go about implementing and validating. With a properly defend path to maturity of documenting what your agency does well and make it repeatable, integrating off the self-contractors is no different than the integration of off the self-software. Just as efficient use of a Software API requires an API guide on how to implement so does the integration of contractors and agile development modules.

The biggest obstacle is people and paper, producing paper for the sake of paper work and an aversion to continuous improvement. An aversion which arises through complacency “the cheese has moved “or those who fear loss of power/position due to a new favor or location of the cheese has changed. Define your “Capability”, make repeatable, “Mature” and Lean “Agility”. Having workers with systems level knowledge with oversight of what’s expected and how the system should function with purview, linkage and traceability across boundaries is key to successful agility.

Mon, Oct 1, 2012 Mark Schwartz

Harry - good point that switching contractors undermines CI. Best I can say on that is that the government integrators need to capture lessons learned, but there is definitely a trade-off here. As for the architecture, a government team owns it and participates with each of the agile teams, so I don't necessarily see that as a problem.

Wed, Sep 26, 2012 Harry Mauve DC

Good discussion. A key ingredient for building great software is continuous improvement (CI). Constantly switching teams and staff for different parts of the system (multi-award bpa) will undermine CI. And it ignores that architecture gets refactored too, based on evolving capability. Who owns the whole? In fact, fed procurement in general is anti-continuous improvement. And as such undermines software best practices. Take FAR Part 9.5 - OCI provisions. To separate the "specifiers" from the "builders" is to break a key accountability. This drives size, complexity, cost and risk through the roof. The following note does a better job of explaining this issue. http://www.softwareinsanity.com/2012/09/oci-nixes-ci.html

Wed, Sep 26, 2012 Greg Pfister

There are numerous items that are critical for success of an agile project in government, and several have been mentioned in this article and comments. Here are a few tactical, but key items we have found to be helpful: * Government/Customer committed involvement in the product backlog grooming is key. Requirements definition and understanding is evolutionary and the only way to evolve the most valuable solution for the customer is for the customer to be actively engaged. * Regarding multi-vendors supporting a larger project there are several items we have found useful: All the teams should be on the same sprint cadence. A common code repository, common backlog management tool (ALM), a common build pipeline (Continuous Integration) that includes automated build/compile, unit testing, smoke test, and promotes the solution to automated acceptance testing. It is critical that the solution is integrated early, frequently, and never is allowed to have modules diverge. Integration debt will derail you big-time! Many of the integration challenges can be identified in the early stages of a project by forcing the premature modules and solutions to integrate early. It is true that these early solutions is not very functional, but having these fledgling modules start to communicate with each other early is critical for transparency in what really is working. Over time, these modules continue to work together and mature together. This builds communications not only between the modules, but among the teams and the customer. * Typical supporting documentation deliverables should be iterative and maintained throughout the project, per sprint, and delivered at the end. Available for review at anytime. For a new project, the first 'release' is often the most difficult working through the deployment wickets. Consider either a very small release initially, or anticipate the first release will often be a bit longer (~6 months). The key is to create a repeatable model so that you can push product into production relatively quickly. This will also help to reduce the 'kitchen sink' syndrome where the traditional requirements process will not feel they need to throw everything into the list because they won't see a product for 18 months. * Consider shorter sprint lengths. I've spoke with many folks across government that are 'doing agile' and their sprint lengths are all over the place. I've heard sprints that are 3 months long (what is that?), I've heard of variable sprint lengths, but often hear of 1 month sprints. We typically use 2 week sprints. We have found that we can't actually plan in detail for a month's worth of work. If the release goal is every 4 months, only having 4 sprints to adjust the direction and understanding would make me nervous. Great discussion!

Mon, Sep 24, 2012 Brent Bushey

As far as contracting efforts are concerned, one approach we're piloting is articulating the solution architecture and business requirements in the RFP and then identifying the "deliverables" from the development vendors as successfuly completed sprints. Each sprint is defined in intensive planning sessions involving government representatives (both IT and business) as well as the systems development contractor. 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.

Show All Comments

Please post your comments here. Comments are moderated, so they may not appear immediately after submitting. We will not post comments that we consider abusive or off-topic.

Please type the letters/numbers you see above