Agile in the Federal Government

At the April APLN DC meeting, I had the honor of being on a panel for a round table discussion in regards to Agile in the Federal government.
The members of the panel included:

• Nate Carpenter of Pyxis Engineering
• Myself
• Thad Scheer owner of Sphere of Influence
• Dr. David Rico of Boeing

(Thanks to Jesse Fewell for the picture. See his blog entry for his thoughts on this session)
Overall, it was a good time. I use to work for Thad’s company (kind of, it’s a bit complicated) and it was great seeing Thad again. It is entirely possible that we may have closed down a bar or two back when we were working together.

Implementing Agile in the government space is tough. Obstacles include the existing oversight, budgeting and funding cycles and processes, general lack of Agile understanding on the Federal side, and conflicts of interest from the various consulting companies, prime and sub contractors, and government agencies. Agile helps you as a company or organization identify your goals and values and execute towards that end. Similarly, Agile does not solve your problems but rather exposes them. In government organizations, identification of clearly stated goals and values combined with exposing problems is something that will generally be met with obstacles.

However, it’s not all gloom and doom for Agile in the Federal government. In an August 2008 interview with CIO magazine, CIA CIO Al Tarasiuk stated “His team has also moved completely to agile project management methodologies…” Additionally, Dr. David Rico stated during our panel discussion that Boeing has standardized on Scrum.

At the team implementation level, Agile has a good chance of success and I am seeing that at my current client site. Since we control the team and with team acceptance of Agile, the Scrum Master / PM can shield the team from much of the organizational issues that may affect the team’s Agile implementation and performance. This will require more work from the Scrum Master. Many of the reports that will be asked to be generated and given may not naturally seem to fall within Agile practices. It will be up to the Scrum Master to identify the key metrics such reports want to capture and translate the Agile team metrics to metrics more familiar to others in the organization. Examples include translating burn up and burn down charts into EVM reports, iteration and product backlog can translate into Gantt charts, and end of iteration reviews and retrospectives and feed into status reports.

At the executive levels, expressing the values of Agile can be quite convincing to a sympathetic executive. The key is identifying and gaining access to an executive who is ready to hear a message about empowered, optimizing, evolving, value based delivery.

The middle tiers is the most difficult. The oversight and middle management levels can be heavy and if leaning an organization, this would most likely be spotlighted as places where leaning can take place. That combined with the conflicts of interest and personal interest that exists at these levels can make these layers quite problematic. Probably the most effective way to deal with this is for organizational support at higher level to effect certain Agile changes to take place at these layers.

For working Agile in the Federal government, I recommend the following:

• Choose your battles. There will be a lot that you will want to change and you will not be able to do it all overnight, so start small and pick your battles.
• Create creditability collateral. Demonstrate a pattern of success so that when the big battles do come, you will have the pattern of success to strengthen your position.
• Identify what is being asked. You may be asked to provide many reports, presentations, briefings, etc that may seem to be a lot of overhead or waste. I recommend identifying that the goals of these requests are and identifying if there is an Agile translation to the nuggets that these requests are trying to achieve.
• Lastly, good luck, you’re going to need it!