In Agile We Trust: Understanding Agile Adoption Challenges

Agile is a hot topic in today’s federal IT market. Agencies understand the value of adopting agile but implementing it within an agency is easier said than done. Agile is not a technology and is more than just a process change.

Organizations need to shift their thinking from doing agile to being agile, which requires a shift in mindset and culture. Agile focuses on early and frequent delivery of value to users. Smaller pieces of a solution, rather than a large final product, are delivered into production for use and feedback. This rapid release cycle serves both to continually validate the value of the work being done and to allow for the quick release of fixes or updates if something is not working as expected.

So, if agile gets the right product in the hands of users sooner, why is it not already being used across government? The answer speaks to the overarching challenge to agile adoption: trust. Government traditionally is a centralized culture, built on a command and control (C2) reporting structure. Agile, on the other hand, advocates servant leadership; roles and responsibilities are flexible, and collaboration is critical to success.

The Culture Challenge

For government, the failure of a project is seen as a waste of time and money. Agile, by contrast, sees failure as a learning experience. In agile development, each effort, regardless of failure, is a small investment compared to traditional development models. If a feature developed with agile does not work as intended, the “loss” may be only two weeks of time and $20,000 rather than two years and $20 million in the traditional model.

To embrace agile “failure,” agencies need to start small. Begin with a single, specific project. Using a project as an agile experiment creates a “safe” place to share what is working and what is not.

For any agile project, management buy-in and team training are necessary. Teams need to learn agile terms and processes so everyone on an agile team shares a baseline understanding of this new language. Leaders also need to learn to be servant leaders not C2 leaders.

On the surface, this shift may make leaders feel like they are giving up some control and oversight. In reality, agile’s focus on constant feedback loops and check-ins build in transparency, giving leadership more and clearer insight into a project’s progress.

The Governance Challenge

In most agencies, current IT governance and oversight processes are linear. Government software development lifecycles are built around phase-based governance, where products reviews occur at rigid milestones. Similarly, contracts are written in C2 language: “We know what we need. Here’s what it is. Now build it.”

Agile places more value on customer collaboration than on contract negotiation. Accordingly, contracts should be more focused on the aspects of delivery rather than final products.

Similarly, the current review gate structure needs to shift to a cadence-based structure to align with agile’s delivery approach. For example, instead of having a development milestone trigger a gate review, plan reviews based on time: every two weeks, or two months, or quarterly. For greater decentralization, embed programs with a technical product owner who participates in team planning and reviews, shortening feedback cycles on technical design.

Adoption of agile in government hinges on trust. First, there is trust in the process – doing agile. Teams follow the process and leaders see that it works in small implementations. If agencies can begin trusting in the process and the team, IT development in government can evolve to adopt agile more and respond to user needs – by being agile.

Mark Byers is a senior manager and agile practice lead for Octo Consulting.