Thursday, June 7, 2012

Agile and US Federal Government

During one of my recent agile project management classes, a student contributed this posting:
[For acquistions sponsored by the] Federal Government, all systems--especially if they deal with life or death or classified data--have to receive an Authority To Operate (ATO) signed by a Designated Approval Authority (DAA)......

 
  
The National Institute of Standards and Technology (NIST) establishes the cyber security guidelines that all federal agencies have to follow. Each agency then tailors these guidelines to meet their particular needs. There is an extensive amount of documentation that is reviewed during the C&A process including the results of security testing.

 
  
• System Security Plan
• Risk Assessment
• Security Test & Evaluation Plan
• Security Test & Evaluation Report
• Continuity of Operations Plans
• Business Impact Analysis
• Privacy Threshold Analysis (PTA) and/or Privacy Impact Analysis (PIA)
• Rules of Behavior (privileged)
• Rules of Behavior (end-user)
• Security Assessment Report (SAR)
• Configuration Management Plan

 
  
.... The way this is handled within my customer’s agency is:
Sprints are generally 4-6 weeks long and produce a package of functionality, multiple sprints create an iteration, and multiple iterations create a release.
  • The release can take anywhere from 3-6 months. The release goes from the product development organization to a separate release management organization which is responsible for coordinating the release of the product into production.
  • The release management organization coordinates the C&A activities with the security organization.
  • All these organizations are under the CIO but operate pretty independent.

 
Most of the actual development is outsourced to private industry so there is a varied role of the government staff in the Agile process. Since a lot of what the government staff does is contract oversight, the most likely role is as Product Owner Representative.
  • The actual Product Owner is outside the CIO organization in one of the agencies business areas.
  • For each project, the agency has created an Integrated Product Team (IPT) which has agency representatives from the business area, security, release management, architecture, etc. The project manager generally leads the IPT.
  • I see the government project manager being heavily involved in developing the Product Backlog and to a overseeing the development of the Sprint Backlog but it is really up to the contractor to manage each Sprint.
[....]

 
It is a really interesting challenge to figure out how to take this agency to a more Agile environment. Not only is it helping them with the technical issues of implementing Agile but also with the biggest challenge which is the culture and organization change issues. Agile will have to be implemented incrementally over time and the agency may never reach a full Agile state. We are working with them to identify and implement those pieces of Agile that will provide the most benefits first and then continue the improvements.

 
[... ] The areas of the life cycle that I am trying to better understand are in
(1) project definition and approval,
(2) establishing the system architecture, interfaces to other systems, and data base architecture, and
(3) system level testing during a formal release cycle especially when there are major cyber security concerns (classified data, life or death considerations, financial data).
Much of the Agile training assumes that the project has been approved and is ready for coding; does not address a formal release cycle; and focuses at the team level.

 
I have started to review “Agile Software Requirements” by Dean Leffingwell which discusses the Agile Enterprise Big Picture and presents a scaled Agile delivery model at the team level, program level, and portfolio level which provides additional background.