What getting to agile looks like from the trenches

Last week an email arrived in my inbox from somebody I hadn't heard from in 20 years. It was John Inman, a contracting officer at U.S. Citizenship and Immigration Services, the same agency where Mark Schwartz, whom I have been writing about recently in the context of agile management, is the CIO.

In a classic small-world example, I last knew John when he was a young contract specialist who was the Air Force's representative on the original Frontline Procurement Professionals Forum. I established that forum in 1995, while serving as Office of Federal Procurement Policy administrator, to listen to non-supervisory contracting folks. (This was one of my proudest achievements, which I wrote about in a blog post two years ago. After having been put on ice during the eight years of the Bush administration, it has been revived under President Obama's two OFPP administrators.) From the Air Force Inman went to the Forest Service, then landed at USCIS in 2015, working on IT contracting.

Inman is now in the midst of trying to make agile happen in the trenches at USCIS. He awarded one of the agency's two task order contracts for agile, which he is managing along with re-competing the second.

We spoke about two distinct challenges to getting contracting officers and program managers to embrace agile. One involves culture, and is somewhat different for contracting and program people. The other involves the impact of agile on an employee's workload, which Inman feels are actually more of an issue for program than contracting people.

The cultural challenge for contracting professionals is the way agile breaks with the strong preference for specifications that are developed upfront, for which the contractor is then held responsible. The contracting culture, as a general matter, is not crazy, and contracting folks have been socialized in the view that program people like to underspecify out of laziness, and must in some sense be kept at bay by contracting folks watching out for the government's interest. In my recent blog on contracting for agile, I discussed why that general preference for upfront specification applies poorly to agile software projects, and also how the Federal Acquisition Regulation allows for considerably less upfront spec development in a way that still protects the government's interests.

Inman agreed that the TechFAR gives top cover for doing agile, but he said he would have preferred that contracting officers use the provision in FAR Part 1 -- which declares that anything not explicitly prohibited, and that is in the government/taxpayer interest, is allowed. He fears that the spirit of Part 1 is less strong today than in the past, so contracting folks feel they need the top cover more.

The cultural challenge for program managers is different, and actually may be harder to overcome. In agile, the "product owner" (agilese for the program manager) works together with the contractor rather than just throwing a requirement over the fence and asking for periodic reports and deliverables.

In waterfall, the government can blame the contractor when an effort fails. Given the product owner's close and ongoing involvement with the contractor during the many sprints into which a task order (or contract) is divided, failure becomes much more shared -- much more on the government's shoulders. Even if agile reduces the risk of failure, program managers may well not want to take increased risk, even on a lower probability.

Inman and I had an interesting back and forth on the workload implications of agile. Perhaps surprisingly, agile is likely to lower the overall workload for contracting officers, both because they have less to do during development of the spec and less to do post-award because contract modifications essentially disappear with short sprints. For product owners, however, the balance may go the other way.

Product owners have less work to do developing the original spec, because they don't have to worry about trying to think about everything and get it all on paper. But they have a lot more work to do post-award, as the essential feature of agile is that they are in constant interaction, often daily, with the contractor, both reacting to work product and approving the many new mini-requirements that get iterated during agile. And, at least at USCIS, product owners also do monthly past performance feedback to contractors, in addition to once or twice yearly CPARS reports, in which the contracting officer is not involved.

Finally, as Inman emphasized during our conversation, workload costs for both contracting and program staff are considerably higher at the beginning, just because everything is new and people need to figure things out on the fly the first few times around. Those costs eventually go down, but if folks get discouraged, they might abandon the effort before they have made it down the learning curve.

(Incidentally, this problem exists for almost any change an organization introduces. The immediate effect of a process change on productivity is almost always negative, even when the longer-term effect is positive, because people in the organization have optimized doing the ineffective practice and haven't yet learned the new one. For this reason, potentially valuable changes for organizations are often abandoned too soon.)

Taking risk and workload considerations into account, I suggested to Inman that officials concerned only with their personal well-being might well regard agile as a bad deal. "Yes," Inman answered, "This is all about asking the program manager and the contracting officer to take a higher workload and more risk in exchange for the greater good." Keeping the greater good – more successful contracting, more benefits to the government – front and center in people's minds is part of the job of a visionary, and Inman sees Schwartz as playing that role.

I asked Inman whether agile training had helped him understand agile better and hence helped him overcome objections he or other staff had had. "We had no training on the contracting side – it was seat-of-the-pants for the two of us involved in originally awarding these contracts," he said. "We did get a class after the fact, and I encouraged others to attend in hopes of learning. But it was of no value. Universally, people here will say they learn agile from me."

He added: "Training without practical experience is hard to do. Rather than trying to do official training telling people the official way to do contracts for agile, I wish the instructors would plan classes that teach correct principles and encourage people to experiment."

In concluding, Inman said that his "biggest message to fellow contracting officers is to look for an agile opportunity -- even though there isn't much guidance yet, look at it as a professional challenge. I hope we will allow for experimentation and that we will accept some risk."

Spoken like a true one-time member of the Procurement Professionals Frontline Forum.