GAO Agile Assessment Guide: Government Accountability Office best practices on Agile software development

What is the GAO Agile Assessment Guide? What are the Agile Best practices in this Government Accountability Office guide on software development?

GAO Agile Assessment Guide context

The federal government of the United States of America invests more than $90 billion annually in Information Technology. No less!

This is the reason why, in 2014, the Congress voted the IT acquisition reform legislation. This reforms is the Federal Information Technology Acquisition Reform Act, or FITARA.

Indeed, the purpose of this legislation is to improve agencies’ acquisitions of IT (contracting and managing IT projects). In addition to enforce accountability of agencies to reduce costs and duplication, Chief Information Officers (CIOs) at covered agencies were requested to start to implement incremental development, aka Agile approaches, and to support delivery of functionalities to users at least every six months.

So, let’s review these Agile best practices, connecting them with Agile, Craftsmanship and DevOps and highlighting points that go further the Agile and Continuous Delivery foundations. Note that we will not remind the Agile foundations. Therefore, please review my posts about Agile and Scrum if you need to get them. Also check my post on Craftsmanship and DevOps.

GAO agile assessment guide covers 3 areas of best practices for Agile: Team dynamics and activities, Program operations, and Organizational environment.

GAO Agile Assessment Guide: Agile foundations

A. Team composition supports Agile methods:
– Teams are self-organizing.
– The role of the product owner is defined to support Agile methods.
B. Work is prioritized to maximize value for the customer:
– Agile teams use user stories to define work.
– They estimate the relative complexity of user stories.
– Requirements are prioritized in a backlog based on value.
C. Repeatable processes are in place:
– Agile programs employ continuous integration.
– Mechanisms are in place to ensure the quality of the code being developed.
– Agile teams meet daily to review progress and discuss impediments.
– They observe end-iteration demonstrations.
– Agile teams observe end-iteration retrospectives.
Extract from GAO Agile Assessment Guide, Agile Adoption Best Practices (Part 1: Team dynamics and activities)

A. Team composition supports Agile methods

First point is about having a Product Owner (PO) carrying the Voice of the Customers. Indeed, the PO takes care of the prioritization and clarifies customer needs including with acceptance criteria. In order to legitimately and properly represents the needs of the customers they should interact with them on a frequent basis. At last, the GAO Agile Assessment Guide warns that the PO should have a reasonable number of teams to secure their availability to customers and teams.

Second, the Agile Team should be self-organized. In other words, this means that you empower the team on how to meet the needs. Truly, the PO provides the “why” and “what”, then the Agile Team takes care of the “how”. Moreover, the team should have all the skills to deliver the features for the product. At last, the GAO Agile Assessment Guide stresses that the team should be stable to support efficiency.

B. PO prioritizes the work to maximize value for the customer

First, the Agile Team should use User Stories to describe the work to be done, with who needs the requirement and why. Further, the GAO Agile Assessment Guide recommends to use the INVEST approach as guideline to properly shape User Stories. And the User Stories come with acceptance criteria.

Second, the GAO Agile Assessment Guide proposes that Agile Team estimates User Stories with relative estimates. Really, this typical approach in Agile makes it possible to have an holistic view on tasks to deliver for a feature and to be agnostic on who is going to build the feature regardless the level of seniority.

At last, the Agile Teams should have a backlog collecting all the requirements. In addition, the PO should prioritize these requirements regarding value, risks, learning and other criteria if needed. In fact, it is interesting to see that the guide propose 2 additional approaches quite common in Agile for backlog management:

  • First, the Moscow prioritization of feature in 3 categories, “Must have“, “Should have” and “Could have“.
  • Second, the Story Mapping from Jeff Patton.

C. Repeatable processes are in place

First part here is about Craftsmanship and DevOps practices to support continuous integration and code quality. Definitively, full automation is necessary to support effort less and error free code building, merging and testing. In addition to automation, coding standard and Craftsmanship practices enforce code quality. To illustrate, examples of practices are: Test Driven Development, Pair programming, Refactoring or Code Peer Review. Besides that, see my post on Craftsmanship for more on technical practices supporting Agile.

Second, all Scrum ceremonies are up and running with a Daily Meeting, a Demonstration and a Retrospective. But the GAO Agile Assessment Guide does not explicitly mention Sprint Planning here. In addition, see my post on Scrum for more on Agile ceremonies.

GAO Agile Assessment Guide: Agile training, tooling, modular and runaway architecture, and at last Program backlog

D. Staff are appropriately trained in Agile methods:
– All program staff have appropriate training since the techniques used are different from those used for Waterfall development programs.
– Developers and all other supporting team members have the appropriate technical expertise needed to perform their roles.
E. Technical environment enables Agile development:
– System design supports iterative delivery.
– Technical and program tools support Agile.
F. Program controls are compatible with Agile:
– Critical features are defined and incorporated in development.
– Non-functional requirements are defined and incorporated in development.
– Agile teams maintain a sustainable development pace.
Extract from GAO Agile Assessment Guide, Agile Adoption Best Practices (Part 2: Program Operations)

D. Staff are appropriately trained in Agile methods

You should properly train the staff in the Agile Team both on Agile and on the technical skills for coding and managing code. Moreover, purpose of the training is ideally also to develop multi-skilling. If an Agile Team should have all the skills to build and test the product, it is even more efficient when there is some multi-skilling.

E. Technical environment enables Agile development

First, the Agile teams should adapt the code development and management tooling to support the Agile iterative approach and the needs for Continuous Delivery. Actually, the guide even quotes some tools for the software factory (Jenkins) or to manage the backlog (Jira).

Second and more interesting, the architecture is a lever to support Agile. Actually, the GAO Agile Assessment Guide presents the concept of Modular Architecture: it enables a loose coupling of components. This type of architecture supports Agile approach. Surely, this allows Agile Teams to build code at each iteration without impacting the larger system. In addition, testing is also simpler. Furthermore, it makes it easier to grant a team with responsibility over a module.

Then the GAO Agile Assessment Guide introduces the notion of runaway architecture that continually extends to meet new and evolving needs up front of development. Indeed, Agile refines and builds out the architecture over time as it learns more, but also in order to limit future complexity.

F. Program controls are compatible with Agile

First, to support a key mission of the backlog and prioritization, the PO should identify as such critical features. Indeed, these features may be critical as essential features, for security or compliance reasons, or because of dependencies.

Second, the GAO Agile Assessment Guide reminds that non functional requirements are part of the backlog. Even if most of the developments are related to functional needs, non-functional requirements should not be forgotten like security or privacy. Furthermore, some industries are particularly sensitive to non functional requirements like healthcare and financial services.

At last, the GAO Agile Assessment Guide points out that Agile Teams should have a sustainable pace. Indeed, many time, Agile is selected because the product needs to be developed quickly. Undoubtedly, the risk not having a sustainable pace, is to burn out the team and to go for even more delay.

Additionally, sustainable pace also enforces predictability over development. Indeed, the GAO Agile Assessment Guide finishes with pace, highlighting that the Agile Team’s Velocity, the speed this team develops features, is not to be compared with other teams. Truly, in addition to the level of seniority of the team members, technical context of the scope and other parameters make this comparison irrelevant and highly frustrating for the teams involved.

GAO Agile Assessment Guide: Agile way of working, workspace, culture and contract management

G. Organization activities support Agile methods:
– Organization has established appropriate life cycle activities.
– Goals and objectives are clearly aligned.
H. Organizational culture supports Agile methods:
– Sponsorship for Agile development cascades throughout the organization.
– Sponsors understand Agile development.
– Organization has established an environment supportive of Agile development.
– Incentives and rewards are aligned to Agile development methods.
I. Organizational acquisition policies and procedures support Agile methods:
– Guidance is appropriate for Agile acquisition strategies.
Extract from GAO Agile Assessment Guide, Agile Adoption Best Practices (Part 3: Organization environment)

This third part covers many heterogeneous topics. In fact, it is more about how the organization supports Agile in term of way of working, workspace, culture and contract management called here Acquisition Strategy. Actually, the GAO Agile Assessment Guide reviews quickly here some of these items and develops them further in other sections: requirement management, contract design and monitoring.

G. Organization activities support Agile methods.

First, you should adapt the life cycle of programs applying Agile to match Agile cadence and way of working. For instance, reviews and programs’ artifacts should match Agile iterations. Another example is the progressive refining of requirements. Still, there should be a guiding vision defined at the beginning and enforcing consistency of small increments. Indeed, prioritization secures that the Agile teams deliver the most valuable features first.

Second, if a given program has to interact with other departments like QA, then these departments also should adapt to Agile way of working.

Third, the PO should clearly define and communicate the goals. Definitively, this is the only way to enable delegation of decision at the lowest level enforcing at the same time alignment. In addition, to support Agile fast response to change, the PO should communicate on these goals each time they move.

H. Organizational culture supports Agile methods

First, there should be an Agile sponsorship through all levels of the organization. Including at the top with Agile Champions. Of course, this comes with training: sponsors must understand Agile in order to support it.

Second, the GAO Agile Assessment Guide stresses the importance of adapting the work environment to support Agile best practices. Truly, you should push collocation of the teams as far as possible. If not possible, you should do everything to mitigate distributed locations with all modern communication tools.

Third, mindset should evolved to more trust coming with empowerment of teams, more collaboration cross-organization and program transparency.

At last, you should adapt incentives and rewards. Indeed, team practicing Agile should be rewarded to support the move. Besides that, rewards should also evolve from individual to team rewards based on outcomes. In addition, you can leverage non monetary rewards like success sharing, networking events or certification programs.

I. Organizational acquisition policies and procedures support Agile methods

You should also should adapt the way programs are contracted. To illustrate, this impacts the milestones of the program and contractual deliverables. In a point of fact, the contract has to mirror the changes driven by Agile on the related Program.

What’s next? Learn more about Agile at Scale

Check my other posts about Agile at Scale:

Find here the sources of this post

Leave a Comment

Your email address will not be published. Required fields are marked *

4 × 5 =

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Scroll to Top