How to transition to Agile delivery in the public sector

According to an ICF survey of federal full-time employees, 51% of digital transformation efforts fail due to cultural resistance. Is a transition to Agile the answer?

Information technology (IT) leaders and chief information officers (CIOs) in the public sector are often asked, “Why hasn’t your organization transitioned to Agile delivery?” It may seem like a simple question, given that Agile is a well-known method, but those with experience in the government understand how complicated the answer truly is.

Changing the delivery approach for any organization is complex and daunting—yet even more so within the federal government. Deeply embedded organizational policies, unique budgeting requirements, and a lack of flexibility in organizational structure are just a few of the reasons why making a transition to Agile delivery is taking longer in the public sector. To get there, IT leaders must understand the core concepts behind Agile and the steps for navigating this change within the government.

What is Agile?

Agile methods in business are not new. Many of the techniques used in Agile delivery originate from the lean management practices pioneered by Toyota’s Just-In-Time (JIT) production system, developed during the 1960s and 1970s. Leveraging these lean delivery best practices and customizing them for the needs of software delivery, a team of innovators established the Manifesto for Agile Software Development in 2001.

The Manifesto is a collection of beliefs that teams can use to develop better software, and do it faster. Rather than the step-based waterfall method, Agile allows organizations to improve software by valuing individuals and interactions over processes and tools. It prioritizes functional products over comprehensive documentation and puts collaboration at the center of decision-making. Most importantly, Agile promotes a continuous adoption of change instead of following prescribed plans, while prioritizing people's needs over the financial bottom line.

Why one size does not fit all

Many IT leaders and CIOs are understandably intrigued by the ways leading-edge product companies operate with agility. These companies have the ability to rapidly change direction based on quickly evolving market tends, fund initiatives without clear scope, allot significant time for experimentation, and accept failure as part of the process.

As enticing as this way of working is, it’s challenging to apply many of these highly Agile characteristics to the federal government. Unfortunately, for well over a decade now, many federal organizations have attempted to mimic the Agile transformation strategy used by private sector companies with little success. Time and time again, the same ‘one size fits all’ Agile delivery framework used in private companies has failed to overcome challenges and constraints in the federal space. In many of these cases, public-sector organizations made false starts due to a lack of understanding around their specific needs.

So, how can organizations avoid repeating these same mistakes?

The key lies in an adaptive approach to the Agile transformation journey. Leaders should not think of the Agile transformation as a fixed goal or target. Instead, it should be viewed as an investment of time and resources to ensure the organization is continuously improving efficiency in its delivery of value to end users.

When developing with an Agile mindset, iteration evolves and matures the product based on learnings throughout the process. In the same way, an Agile transformation must adapt to the needs of the organization rather than forcing a methodology that doesn’t account for constraints and challenges. There shouldn’t be a final fixed destination to reach in the Agile transformation journey. Organizations should continuously learn and adapt throughout the rollout with the primary purpose of optimizing efficiency.

Plan with an Agile mindset

Before planning an Agile transformation, it’s crucial to start with an Agile mindset—to break old, confining habits. These eight steps can help.

Step 1: Be honest about the current situation

It’s easy to prematurely buy into the benefits of having a large-scale Agile framework with many teams synchronizing in unison. The reality is that it takes a great deal of effort to get there. In fact, a full-scale Agile transformation in the federal space is often an unrealistic goal. It can take years for government organizations with deeply embedded policies and fundamental differences in their structure to transform ways of working. That’s ok, though, because a full-scale Agile delivery process does not need to be identical to a private sector ‘product’ company. It’s important to acknowledge and respect these differences before setting unrealistic Agile transformation goals.

Step 2: Plan the transformation with agility

CIOs and IT leaders should identify top-level goals first, then rank them in order of the value they can provide. Next, they can design a notional Agile transformation roadmap. Like any Agile roadmap, accept that it will likely change over time as the team learns more. Be prepared to embrace this value-added change in your transformation plan by adapting quickly.

Step 3: Get buy-in from senior leadership

When drafting an initial transformation roadmap, establish an Agile transformation charter in collaboration with senior leadership. A charter describes the transformation vision, who will benefit from it, and how it’s achieved. Don’t get too specific with the vision statement; the key is to leave some room for the plan to evolve. Remember, this is Agile and it’s supposed to be adaptable. When the transformation roadmap and charter are agreed upon, work closely with senior leadership to have regular feedback loops for continuous value-added change.

Step 4: Work closely with your organization’s governance group

In most federal organizations, IT governance support comes from the project management office (PMO), office of the chief information officer (OCIO), or similar groups. Proper governance support can be your team’s greatest ally or its worst enemy during transformation efforts. Ensure work happens closely with your governance office early in the transformation effort so that they provide the necessary resources. If the governance group is hesitant to invest time and resources in an Agile transformation effort, start small with a pilot Agile team that will help inform the long-term delivery strategy. This way, they get to see the benefits of Agile delivery on a smaller scale before supporting a larger initiative.

Step 5: Adapt your contracting methods to support Agile delivery

Unlike traditional waterfall delivery methods, Agile allows for flexibility in scope with an emphasis on early return on investment (ROI). In order to have early ROI, Agile delivery continuously evaluates and prioritizes the product backlog to give users quick demonstrations of capabilities—allowing them to offer valuable feedback—rather than waiting until the end of the project. This means that an Agile delivery contract should have built-in flexibility to allow for iterative improvement based on early customer feedback loops. Establishing ROI requirements that measure value in concert with delivering capabilities also ensures faster gains on the investment.

Step 6: Invest in Agile training for key stakeholders

Federal stakeholders often play the role of product owner (PO) in an Agile delivery team. But more often than not, the same government stakeholders who are assigned the PO roles also have existing federal job responsibilities. As a result, the lack of availability to fully dedicate time to PO responsibilities leads to issues in Agile delivery because the PO role is so crucial to its success.

Early investment in PO training for designated federal stakeholders allows them to understand the time and effort required to support an Agile project. If the organization determines, after training, that it cannot invest in full-time federal PO involvement, then it’s essential to find alternative ways to manage the product delivery.

A good alternative solution is to invest in the help of PO proxies, which are usually contractors who are certified POs on an Agile scrum team and serve as the bridge between the federal product manager and Agile delivery team. With the help of PO proxies, IT leaders can find the right balance of involvement in the delivery process without impacting other key responsibilities for the organization.

Step 7: Be flexible when determining your custom Agile delivery approach

Think of an organization as a home that needs renovations. Not all homes are built the same way, have the same features, or share the same history. When planning a renovation—or, in this case, a transformation effort—one cannot expect to use the same Agile tools for each situation because every organization brings a unique set of challenges. Prescribing the right tool set within the Agile toolbox is key to determining the right-fit transformation approach.

If one transformation goal, for example, is to improve the efficiency of operations and maintenance (O&M) support for a legacy system in production, then design the right-fit Agile Kanban process that leverages Lean principles but also has a customized workflow that meets the needs of the delivery team. Or, if the transformation goal is to incorporate security controls in iterative capability development, then customize the right-fit scrum process incorporating DevSecOps with your Agile delivery, so the definition of “sprint done” includes automated security validations. There are a vast array of unique examples that may come up within each organization. To plan with an Agile mindset, it’s important to be flexible when determining a custom delivery approach.

Step 8: Be practical with your short-term goals

Just like in Agile product delivery, IT leaders need to create short-term transformation goals based on value-first implementation. With the long-term vision already drafted (see Step 3), the team can now identify short-term practical goals that link up to the broader vision. Just like when decomposing requirements, teams can use the same process to break down each goal into measurable tasks and prioritize them into an Agile transformation product backlog. Create a simple transformation Kanban board to follow the progress of each goal to its completion. As the team moves forward, they will iteratively learn and adopt transformation goals—and the tasks underneath them—with agility.

Embrace your Agile transformation journey as a mindset

Regardless of the approach agencies use to deliver capability to end-users, the ultimate goal is always to provide value in an efficient, high-quality, secure, and cost-effective way. The long-term success should not be measured by the purity of the Agile process, but rather the ability to use Agile to deliver value in a sustainable way. The Agile methodology provides many of the techniques needed to improve the way an organization works, but an out-of-the-box framework does not work for many unique situations—especially in the federal government. To realize the benefits of the Agile transformation, teams must adapt as they transform.

Embrace the Agile mindset from the beginning, and it can usher in the right-fit delivery approach for continuous improvement and sustainable success.