Photo courtesy of Robert Read

Photo courtesy of Robert Read

Agile Profile is a regular feature profiling leaders in agile government.

Who?

Robert Read
Managing Director, 18F Consulting

What does Agile mean to you?

One of our teammates at 18F, Justin Grevich, says “Agile is just the scientific method applied to software development.”

In other words, Agile is about learning as efficiently as you can in order to mitigate risk. But you really can’t do better than to quote the Agile Manifesto, which is just one sentence: “Emphasize:

  • Individuals and interactions over processes and tools,
  • Working software over comprehensive documentation,
  • Customer collaboration over contract negotiation, and
  • Responding to change over following a plan.”

What lead you to adopting Agile?

Kent Beck’s book “Extreme Programming Explained” set me on fire in 2000 because it was clearly a far more effective way to run software projects than the Waterfall approach that was prevalent at the time, even in startups. I immediately starting trying to bring Agile to the startup I was working for at the time. Luckily, my boss at the time knew Kent personally, and was able to bring him in as a consultant, so I learned from a master.

What did you do to get buy-in from your department?

I’ve instigated Agile in two private companies. When I entered government service as a Presidential Innovation Fellow (PIF) in 2013, I didn’t have to—all the PIFs were doing it already. At 18F it is our basic way of doing things, and in fact 18F Consulting now exports this to other agencies through workshops, coaching, and technical advice, including advice on Agile contracting. The main way we convince agencies is by pointing out how often Waterfall leads to disasters, and explaining how Agile mitigates that.

Did you see positive results immediately or did it take time?

Any one project will be immediately de-risked by working in an Agile manner. Producing a prototype quickly as I did in my Presidential Innovation Fellowship (http://www.nextgov.com/cio-briefing/2013/07/how-hack-system-change-government/67448/) is a powerful way to avoid making mistaken investments. At 18F Consulting we take this even further and often produce prototypes in a 3-hour brainstorming meeting. This is an Agile process known as a “spike” because it is deep, but not broad. Organizationally, it usually takes any organization about three months to see positive results, and it often takes 18 months for an entire organization to become convinced of the benefits of Agile. Once the executives really do see that they are getting software delivered faster and closer to their expectations, the whole organization usually becomes convinced.

What challenges did you face, and how did you overcome them?

Executives sometimes need to be convinced that not having a “Big Design Up Front” will actually increase the chance of a successful delivery. Many IT professionals have developed the habit of trying to write excellent requirements and then resisting change once the requirements are set. It is better to embrace change. Sometimes programmers are afraid of the transparency it provides into their progress, or lack of progress. You just need enough support at the beginning to show fast, positive results and people will be convinced.

What resources/assets do you have to support your Agile efforts?

There are certifications, books, classes, and workshops. Books are good, certifications mostly a waste of time, and nothing can take the place of practice and experience. That is why at 18F Consulting we offer short, hands-on workshops—because seeing is believing. Everyone should read about Agile, but every one, even executives and product owners, need to try to get some experience with it on small, short projects. Kent Beck once said “Wouldn’t it be wonderful if every executive had access to a small, Agile team that could try out ideas for them?” I would love to give every CIO in government that opportunity.

What problem does Agile solve for your organization?

The fundamental thing that Agile offers the federal government is decreased risk through accelerated learning. Agile projects fail, but they fail early and often and in a small ways that allow you to correct and to provide success in the end. Waterfall-based mega-launches lead to mushroom clouds.

What resources do you recommend to government leaders who want to get started with Agile?

Well, obviously, our workshops at 18F Consulting. But we’ve written about how to run your own one-afternoon workshop. There is no substitute for practice. I would advise any government leader who have the power, such as CIOs and program managers, to demand that in the next three months their staff undertake an Agile project. If you aren’t ready for this, start small, and just do a tiny fraction of your total portfolio as an Agile project. If you are a developer or a technologist, get yourself onto an Agile team. If you can’t do that in your job, then volunteer for an open-source project or a civic hacking project or a hackathon where you can meet other people who are doing Agile. We all learn best from the people sitting beside us.

What training do you recommend for other government agencies looking to adopt Agile?

Read a book. Pick a methodology—Scrum, Kanban, or XP—and run a tiny project with that methodology. Classes and seminars might be helpful, but they are not as good as a coach or a peer to learn from. At 18F Consulting we offer coaching on an at-cost basis.

Were there special procurement rules that were needed or modified for an Agile project?

This is too big a question to answer here, and to some extent all of the government, including 18F Consulting, is still learning how to do this. But the basic principle is to keep projects small, fast, and modular. These techniques are completely supported by policy, as laid out by the White House in Contracting Guidance to Support Modular Development, the The TechFAR Handbook for Procuring Digital Services Using Agile Processes, and The Digital Services Playbook.

Do you follow a specific framework like Scrum or Kanban?

Personally I prefer XP, but most people use Scrum. Agile has always emphasized guidelines over hard-and-fast rules—rather like the pirate character, Captain Jack Sparrow. I don’t think it is particularly important.

Has your adoption of Agile led to adoption with any of your colleagues in different departments?

When I was in private industry, I dragged them kicking and screaming into it. 18F as a whole is trying to lead by example in the use of Agile. 18F Consulting in particular is currently coaching the Wage and Hour Division of the Department of Labor, as well as the GSA, our parent agency.

Do you have a designated product owner?

On any project, you need to get as close to the customer, by which we mean the end-user, as you possibly can. Ideally, you want the customer in the room with the team and treated as team member. I’m happy to say the Department of Labor has done a great job doing just that. In other cases, you may have to designate a product owner to act as a proxy for the end-user. The product owner is not the person in charge or necessarily even a prestigious position—except in so far as Agile emphasizes direct communication with the customer, and as the old aphorism goes “The Customer is Always Right.”

Are your product owners dedicated full-time, part-time, or some combination depending on the project? What length were your sprints when you were initially implementing agile?

I always use two weeks. One week is too stressful, and three weeks has too much inertia. But I would rather see a project iterate in an Agile way with one-month or even one-quarter sprints than have it use pure Waterfall.

What size are your development teams?

Personally, I think five designers and developers is the best size. If you have eight, you should probably have two teams. There is nothing wrong with many teams—I think Scrum in particular lets you organize teams around a single project goal.

What, if any, type of agile training did you offer your employees?

For 18F and for the Presidential Innovation Fellows, we have run workshops that offer hands-on experience.

What aspect of Agile have you either gotten better at with time or has been the most valuable to your team?

People often struggle with writing stories and estimating them, but I believe the most challenging issue is usually how to do testing most effectively. I am a huge fan of Test-Driven Development TDD (another innovation articulated by Kent Beck) but it takes a lot of judgement to know how and when to use TDD, unit tests, automated GUI tests, and/or manual testing. Most projects will a mix of all of these. Properly using Continuous Integration of the automated tests is often critical to the velocity of a team.