Don’t Ask for Permission to Use Agile. Just Start Doing It.

Robert L. Read is a computer scientist, author, consultant and inventor, currently attempting to meld the Maker movement, open source and hardware invention into a movement for invention in the public interest called public invention. He was a Presidential Innovation Fellow in 2013 and co-­founded 18F and 18F Consulting. Twitter: @RobertLeeRead

Government program managers who want to pass on to the taxpayers the benefits of agile software development face some challenges that stem from noble intentions to avoid waste, fraud and abuse or the accusation thereof:

● To avoid waste, government workers tend to be very risk­ averse. This tends to favor “big design up front," which ironically leads to much greater risk.

● Government workers tend not to invite the customers to see the sausage being made, but wait until the silver platter is ready. All too often, that means the customer never gets to eat at all.

● To avoid the appearance of impartiality, governments workers tend to avoid informal interaction with their customers. These attitudes are specifically opposed to the agile manifesto.

Government workers are under some pressure to do the wrong thing. Such as:

● To value processes over individuals to be able to justify choices;

● To value comprehensive documentation over working software because it is hard to explain that an unreleased prototype is valuably mitigating risk;

● To value contract negotiation over customer collaboration because it seems to place all the risk of non­performance on the vendor, and:

● To follow a plan rather than responding to change because of a risk-­averse culture.

In attempting to move your program to agile methods, you may encounter a number of challenges that are more common for government PMs than for commercial firms.

Firm ­Fixed ­Price Attitude that Insists on Lengthy Requirements Upfront

It is officially implied that firm ­fixed ­price is the “least risky” means of procurement. In fact, the opposite is true, at least so far as software development is concerned.

Firmed fixed price, or FFP, is inimical to agile development because it demands all requirements be known (and captured in a document) before work is done. This is the same as saying there will be no learning and change during the execution of the contract, which is directly opposed to the agile manifesto.

Firm fixed price enshrines the idea of contraction negotiation rather than communication, when in actuality it is communication that speeds and de­risks software development.

Government knowledge workers and procurement officers must avoid these traps to get the benefits of agile development. Just don’t use FFP.​

Not Knowing How to Procure Product ­Building Services Rather Than Products

It is easy to say “Just don’t use FFP”­­­ but what, constructively, is the government project manager and procurement professional to do instead?

The conclusion that some of us at 18F came to was to use a strategy first articulated by Mark Schwartz, chief information officer of the U.S. Citizenship and Immigration Services: “Buy competent teams, rather than buying a product​.”

The basic approach is to write a contract saying the team will do whatever you tell them to do communicated via an agile process, such as SCRUM. This allows you to have great flexibility and avoids the terrible problem of having to write a huge, perfect requirements document ahead of time before you really know what you need.

Inertia and Inexperience

The government has been late to adopt agile methods. A would­-be instigator now finds herself in a lonely place surrounded by habits and ways of thinking not easily changed.

Experience teaches the best way to convince people is to show them an artifact. ​A picture is worth a thousand words, a demo is worth a million and project delivered on time worth 10 million.

You must educate yourself and then find a way to succeed with a tiny agile project to build support for larger projects. If this has to be a one-­person, one-­week project, so be it.

Accountability Seen as Opposing Experimentation

Experiments sometimes fail. The media tends to looks on failure as waste. But experimentation is critical to effective learning and agile methods. Use agile methods to keep experimental failures small​. Agile allows you to fail several times each week. You cannot be accused of self­-serving dishonesty if everybody can see your backlog and your burndown chart.

Inability to Adjust Existing Policies

To follow an agile process, government habits may have to change, and formal policies may have to be re-­interpreted.

In general, don’t seek anybody’s permission to use agile. Just start doing it. But there may be times when you have to get your boss to adjust policies for you. That is their job.

Executives support agile when they see it decreases the risk of them looking bad and increases their ability to predictably get work done on time.​ Show them the money.

Keeping Customer at Arm’s Length

Many government organizations have a tradition and even rules about communicating with the end-­user.

There is a secret key to agile development: Magic happens when you get customers and developers in the same room. Do whatever it takes ​to get a customer in the same room with your development team.

The best interaction with the customer occurs both during story ­writing and at the time of demos during sprints. If at all possible, have customers present during both these activities​.

Misusing Cybersecurity Concerns

Cybersecurity concerns are a heavy club to be wielded on any side of an argument. Agile methods allow you to build more secure software than traditional methods so long as proper weight is given to cybersecurity. Ironically, cybersecurity concerns can cause one to develop waterfall­-driven systems that are fragile and hard to update and keep secure.

The best argument against this is to point out that agility lets you respond more quickly to evolving security threats.

Attitudes that Open Source Software is Dangerous

Using open source makes one both more secure and able to prototype more rapidly. An organization that doesn’t use open source is fighting with one hand tied behind its back. You may be able to use arguments presented in this article to convince people of this.

Not Using Rapid Prototypes

Something has changed in the last decade, and you may not have noticed it. Modern open ­source software stacks have shrunk drastically the time to produce valuable, informative demos. At 18F Consulting, we often made a demo in three hours, in a process we called proto-sketching.

Even if you don’t use an agile process such as SCRUM, do yourself a favor and beg, borrow or steal someone who can produce a rapid prototype quickly, i​n the presence of the customer​. Examples of this have been described here and here.

Fear of Looking Stupid or Worse in a FOIA Request

The sad truth is, the Freedom of Information Act has a chilling effect on email communication of federal workers. Similar regulation may apply to workers in other governments. It is fairly common for federal workers to inefficiently try to discuss things in person or by phone rather than email so their communications will not be subject to a FOIA request.

I recommend a radical approach to dealing with this problem: Send more email​. Communicate as transparently as possible. This will not protect you from a casual attack, but it will be your best defense against a serious questioning of your work.

Fear of Hiring Consultants

A private firm can hire any consultant or coach it wants and nobody cares or even knows. This is not the case for government workers.

Because the government worker must fear more than just wasted money if he or she happens to hire a consultant for a few days that produces non­stellar results, the channel of using outside consultants may be artificially constrained for government projects. This is true even of consultants working for the federal government, such as those working for 18F and/or 18F Consulting and U.S. Digital Service.

Cultivate a risk-­taking attitude by documenting your successes and your failures. ​Treat “exercises” and “workshops” as absolutely essential to your process.

Not Following Agile Process Rigorously

Kent Beck back in 2000 answered the question, “Do we need to do all of the extreme programming practices?” by saying, “Be agile in your agile processes.” It’s OK to adjust your processes to match your situation.

But “agile” does not mean “lax."  When in doubt, stick to the process, or the “ceremony." More attempts to move to agile fail because of not following a process than because of slavishly misusing a process.

Which process should you use? Any process followed rigorously will work. Personally, I prefer XP, but SCRUM is now considered the lingua franca of agile, so beginners should start there.

Paperwork Reduction Act Dullness

The Paperwork Reduction Act  is a federal statute, but other governments may have similar provisions. On the surface, it impedes the ability to get important information from the customer.

However, there are almost always creative ways to deal with this problem, ​such as:

● Asking only open-­ended questions rather than metric survey questions

● Using A/B testing

● Surveying at most nine users

● Using in-­person interviews

● Restricting your question to only federal employees.

“Everybody can say no" -- it does seem that everyone in the organization has the power to say “no,"  and nobody “yes." Keep working to change things. Each of your efforts is meaningful, even if unrecognized. Don’t be discouraged!

(Image via graja/Shutterstock.com)