Several weeks ago I had crafted a presentation for a government agency on Agile training. During this presentation, a Federal Computer Week article came into the discussion. The article is titled Does 'early and often' work for software?
As agile development gains steam, some experts question whether it's right for government (http://fcw.com/articles/2009/10/19/feat-agile-development-government.aspx?sc_lang=en). Fortunately, I was familiar with this article from October of 2009 and I was able to speak on the points addressed in the article.
Overall, the article makes some good points. It promotes the following benefits of Agile:
- "allows for quick reactions to technology innovations and shifting requirements"
- "It reduces a lot of risk, and you get capabilities into the users' hands much faster"
- "DISA used agile techniques to deliver initial capabilities for Forge.mil in just three months, a third of the time it would have taken using traditional methods … Early testing also helped DISA spot security gaps months before they would have surfaced otherwise."
However, it is the arguments against Agile that are a bit misplaced. Certainly there are challenges to Agile in the Federal government, as I noted in my last blog entry (http://www.onemoreagileblog.com/2010/03/challenges-to-agile-in-federal.html), however the points that Agile detractor Michael Daconta call out can easily be argued against. Below are the key points against Agile in the FCW article and my thoughts on these points:
1. Subject Matter Experts (SMEs) don't have the bandwidth to meet with team
On my last program at OPM, the previous efforts were nearly killed due to a stop work order placed on the program. One of the root causes was that the vendor at that time creating a solution that the vendor perceived to be correct. However, SME input into this solution was a bit limited due to a perception on how to use the time with the SMEs. In the end the effort did not go far past the requirement stages because the solutions proposed were not acceptable to the SMEs.
Using a collaborative Agile effort, the program was able to re-gain the interest of the SMEs. The program met with them twice a week for the length of the effort to discuss program needs and display working product. This produced engaged SMEs and quality product that resulted in published retirement data feed standards and working software.
2. Program Managers don't have time to help design an application on the fly
For the vast majority of projects, Program Managers should NOT be in the critical path of application design. On a cross functional team, that role is done by the team. The Program Manager can ensure the team has what it needs to perform the design and that there is sufficient bi-directional transparency between program needs and program design.
3. Pace can result in interdepartmental strain
I believe that this says that Agile allows you to go to fast. I don't see how this is a problem. In many ways the government pace should be challenged and Agile provides a great infrastructure for a responsible implementation of accelerated delivery. If the argument is that the pace is not sustainable, it should be noted that one of the key principles behind Agile is "Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely." (http://agilemanifesto.org/principles.html).
4. Pair anything will produce higher quality, but are you willing to pay double the cost
I believe this is referring to the practice of pair programming. It should be noted that though there are many in the Agile community that believe in the value of pair programming, it actually is an engineering technique and arguable not one of the key implementation points Agile on a program. I have seen many successful operations where pair programming is not mandated. I suggest that the program allow the teams to try pair programming as a team technique and let the team decide on its usefulness. With that said, a simple Google search will provide a vast library of information on the value and advantages of pair programming.
5. Agile development schedules bump into government budget and acquisition processes – DOD requires acquisition programs to meet a host of checklist items
This last point is very interesting. This statement actually calls out a problem that the DOD faces today. From a recent presentation by Don Johnson (OASD(NII)/DoD CIO) stated:
"As defined in the March 2009 Report of the Defense Science Board (DSB) Task Force on Department of Defense (DoD) Policies and Procedures for the Acquisition of Information Technology, the fundamental problem DoD faces is the deliberate processes through which weapon systems and IT are acquired does not match the speed at which new IT capabilities are being introduced in today's information age. The DSB report highlighted that not only is an agile model more appropriate for IT programs, but it serves as a basis for changes to the larger acquisition model cross-cutting major weapon systems. "
The DSB report highlighted that not only is an agile model more appropriate for IT programs, but it serves as a basis for changes to the larger acquisition model cross-cutting major weapon systems. "
Mr. Johnson and the DOD CIO department are making a strong push for an adaptable Agile model for IT acquisition. To that end, on 10/28/09, the President signed the 2010 National Defense Authorization Act (2010 NDAA) that included a mandate to implement the agile acquisition model for all DoD IT acquisitions. Congratulations and good luck to Mr. Johnson on the presidential sign-off and implementation of this new model!