Agile in government is alive (and well?)
A recent link on Twitter pointed me to a report on agile software development for government called Agile in the Federal Government: Improving Execution, written by a small consulting firm called CCpace. I had never heard of CCpace before, but the firm apparently has one line of business that provides training in agile development -- delivered by agile programmers rather than professional trainers, and now available in the federal marketplace. (I should note that I am a recent Twitter convert, and am finding on the service a large number of links to interesting articles and reports I otherwise wouldn't have seen!)
Agile seems to be alive -- and maybe even well, I don't know enough to judge -- in the federal government. A quick search of the key words "agile development" on FCW.com showed no fewer than 61 references in the last 30 days. One FCW story, on HHS's RFP for a contract for further development of Healthcare.gov, stated that "agile is a key requirement," with the HHS statement of work specifying that the contractor "shall use an iterative methodology to system development that provides the best opportunity to incrementally build and test software functionality."
So it is a good sign that this commercial company offering agile training has entered the federal marketplace.
As a non-techie, I got one big message from the report, repeated in many ways in different places. From one passage:
[Agile uses] iterations of batched work called sprints so that we can receive feedback on that work immediately after it is completed versus waiting for a large User Acceptance Test effort at the end of the project. In sequential waterfall development, each phase provides feedback to the previous phases. For example, the development phase may enlighten the team about a problem coming from the design phase. This may occur many weeks or months after the design phase is completed. The rework that occurs at this point can be very expensive as the cost curve increases over time. Thus it is highly desirable to receive feedback about work as early as possible. This is why all phases of software development (analysis, design, development, testing) happen during the sprint.
Incidentally, the agile approach to software development also corresponds to an approach to managing anything new an organization is doing. Don't try to plan everything in advance. Get started doing something, let users react to what you've done, correct quickly and often.
The report noted that many feds are going for brief agile training sessions, but worried that courses by themselves will not create agile development: "there is a large difference between what was discussed in their training and what is actually occurring during the projects. This is the realization that understanding Agile is easy; whereas, practicing it is difficult."
As the report notes, the culture of waterfall development took decades to become entrenched. Those working on agile in the government need to share notes and learn from each other in order to give this method the chance to do the same.
Posted by Steve Kelman on Aug 08, 2014 at 7:25 AM