You can’t be agile in a rigid environment

The federal agency drive towards IT modernization and a new level of customer experience has hit its stride. You can see it in agency budget submissions or in the level of applications for Technology Modernization Fund dollars. You can also see it in initiatives that agencies are engaged in right now.

Application development lies at the center of these initiatives. Here, agencies are taking a variety of approaches. These include refactoring legacy applications for cloud hosting or using low-code tools to preserve logic in modernized applications while adding new functions. In some cases, they are coding all-new applications.

Why Agile isn’t enough

In any of these approaches, agency IT professionals often try to adopt Agile as a methodology or way of working to deliver value to their users. In many cases, in-house development teams are, in fact, moving towards the Agile approaches and DevSecOps models. That is, they’re scheduling regular releases of incremental functionality upgrades and additions, rather than relying on the old-school “waterfall” development paradigm in which improvements come in infrequent major updates.

Yet, the overall success rate of federal IT projects hasn’t risen appreciably, even with the embrace of Agile. Why is that? I believe it’s because, even with agencies applying an Agile approach, the coding takes place in a decidedly non-agile environment.

Finding the breakdown

Think of projects as having three basic phases.

Phase one: Planning. This entails figuring out what needs to be done, getting approvals from multiple people and functions, establishing a budget and securing funding. Then, of course, comes the whole process of acquisition and contracting. On the military side of government, these steps equate to the PPB part of PPBE – Planning, Programming, Budgeting and Execution.

All of this has to happen before anyone writes a line of code. While some agencies have adopted Agile acquisition, procurement, and contracting frameworks others are still follow very traditional practices.

Phase two: Development. Here is where Agile methodologies actually take hold. Whether in the various digital service operations at GSA and several other agencies, or in regular in-house, hybrid or contracted development operations, the Agile style of software coding has become the norm.

Additionally, the Department of Homeland Security (DHS), has made Agile the formal standard for software development. In fact, in 2017, 80% of US federal IT projects were Agile or iterative, as compared with 10% in 2002 according to the State of Agile Report.

Phase three: User Acceptance (UA). This is where IT staff and developers implement the results of their work and hope for user acceptance. Historically, the UA phase has operated in a traditional waterfall approach, similar to the first planning phase.

However, this presents a problem: although the development stage is Agile, the program management processes around it are characteristically waterfall in fashion for the planning, budgeting and acquisition of projects and then in user acceptance.

Avoiding prescriptivism

In particular, we see a lot of projects fail with overly prescriptive UA requirements and acceptance criteria as opposed to the more Agile approach of meeting user objectives and solving user challenges. Establishing a long list of pre-determined specifications simply doesn’t mesh well with the Agile approach in which users weigh in on the usefulness of each incremental delivery.

When the accumulated set of software functions, each given the go-ahead by users who will live with the system, reaches the acceptance phase, the package may look very different from that original list of requirements and specifications.

This is why it is important to engage the user community up front, as early and often as possible, and design the system around the needs and challenges of the user. This is commonly known as customer centricity. Including the user (or a representative of the user) in the development process can validate the approach early in the process and ensure alignment with expectations and requirements.

Historically, this has provoked pushback from the contracting staff or those who supervise the program, regardless of whether the delivered system does what users want and what the program actually requires. This reflects back to Phase 1. We need to ensure we are procuring and contracting work with these Agile methods and principles in mind. Rather than contracting a huge list of requirements, contract or procure the program management processes used to develop and deploy a solution. Contract management, not the contract itself, is the key to success.

Time for a change

With modernization such an urgent priority, along with the equally urgent need to move to a new generation of customer experience, it is time to bring true agility to all three phases.

An Agile program management approach to an Agile solution development process will ensure user acceptance and adoption by all stakeholders. This is the true measure of success.