How to Run an Agile Project in Government

For a seminar organized by DigitalGov University, Robert Read, the Managing Director at 18F, gave a presentation on agile methodologies in the federal government.

Risk mitigation is a big advantage of using the agile methodology. The methodology deals with risk through the use of multiple iterations or “sprints” that ultimately lead to the development of a better product. “Sprints” involve the release of software that is functional and will allow for testing. You do not need to deliver software to the customer. This is simply a chance to see a viable product and create a backlog for the changes and improvements you deem necessary.

The agile methodology is an alternative to the traditional project management process. This methodology is important to project managers because the current method, waterfall development, only accounts for failure at the very end of the process, when it is too late to make any changes.

You can watch the full presentation for more information on the agile methodology.

During the webinar, Robert received a multitude of questions. He answered many questions during the webinar, but in order to answer as many questions as possible, he answered a few questions offline as well. Robert’s answers to those questions are below.

Incorporating Customers

Q. Can you talk about incorporating our customers into these discussions? I often feel like folks are not interested in seeing “beta” tools. How do we get our customers on board with this approach too?

A. By customer, I almost always mean the end-user, not the boss, and not the other stakeholders, although sometimes there is overlap. From Agile methodology and my own experience, have “the customers in the room” is critically important. Often this cannot really be achieved entirely, but the more the better. In a government context, I’ve seen two agencies, the Wage and Hour Division of the Department of Labor and the Social Security Administration actually bring end-users in physically, which is truly great. I encourage any agency that can to duplicate those great examples.

I think people may be jaded about seeing “beta” tools if their experience has generally been that whatever they say is not included in the final product. I think the best antidote to this is building trust by being responsive. In a perfect Agile world, the customer sees their comments immediately responded to in terms of a change to the product. One way to make this happen is in a “protosketching” or Agile Workshop setting in which you are explicitly coding things in a throw-away mode just for evaluation. This allows you to compress the usual development cycle down to one to three hours, but it requires getting developers and customers in the room together.

Never-Ending Agile

Q. There is no concept of “end” in Agile. How do you suggest we handle that?

A. Good point. Software is never “done.” But investments are done, and software announcements are made, and sometimes there are laws which say a capability must be offered by a certain date. Two-week sprints themselves are artificial—but highly useful!

I think the best thing to do is to recognize that the natural evolution of software should have a gentle ramp-up and a gentle ramp-down. In the context of the Federal Acquisition Regulations, this may be hard to achieve, but we can still strive for it. I think we would get great benefit if we treated federal systems like major commercial systems, which constantly get new major revisions and get new minor revisions and security patches on a weekly, and now even daily, basis.