Agile Transformation at a Large Federal Agency

Agile transformation is crucial for navigating the complexities of today’s rapidly evolving landscape. In an era of dynamic challenges and change, the ability to adapt swiftly and effectively is essential. Agile methodology empowers federal agencies to have a culture of innovation, collaboration and responsiveness, allowing them to deliver value to citizens more efficiently and effectively. By embracing Agile principles, agencies can streamline processes and create a mindset of continuous improvement.

In today’s blog, we go through an exclusive Q&A session with RELI expert Bill Pratt. With a wealth of insights to share, Bill discusses the intricacies of Agile implementation, shedding light on its challenges, triumphs and the power it holds, as well as his personal experiences and vision for the future of Agile transformation within federal agencies.

What are the initial approaches to Agile transformation?

Around 2010, we began looking at Agile in a piecemeal fashion, with certain programs taking a stab at it. This organic, bottom-up approach led to some pockets of Agile adoption, but the level of maturity and the methodologies were scattered all over the place for those who attempted it.

Most of the IT programs remained firmly entrenched in the decades-old Waterfall method of software development. I bear more responsibility than most, as I was the person managing that process at the agency. Back then, we had a group of seasoned IT program managers who had been in the field for ages. They were adept at handling cost, schedule, performance and budgeting, all within the confines of the Waterfall model. Everything revolved around allocating a fixed amount of time for planning the overall effort and determining requirements, often an uncertain endeavor. Once approval was secured for these requirements, ranging from a few hundred to a few thousand, design work commenced. Such practices seem antiquated today, with modern IT developers possibly never having encountered this methodology.

After the requirements were approved, design work commenced, starting with the preliminary design. Following this, a stage for the final design added an extra layer of importance. Once the design phase was complete, coding began. The entire system design, including all interfaces to other systems, was constructed before the building phase commenced. Subsequently, developers tested the system, after which it was handed over to independent testers – a process that often took several months. Once testing was completed, we brought in users, treating them to coffee and donuts and sitting them in front of the system. Typically, their initial feedback included requests like, “Why is this button here? It should be there.” Consequently, if it was, say, release 10.0, changes were made, and release 10.1 ensued. This practice of conducting user acceptance testing after comprehensive testing of the entire system was a flawed approach, yet it persisted.

So, once the final version is ready for deployment, it’s released to production all at once, often leading to oversights due to the inevitable differences between environments. Testing environments could never replicate real-world conditions accurately, lacking the scalability required. Nowadays, with cloud technology, we compartmentalize components, allowing testing and development in dedicated environments. This streamlined process ensures consistency across patches, security measures, and configurations, because each environment is a part of the same holistic setup. Contrastingly, in the past, the challenge lay in maintaining synchronicity among disparate development, test, staging, and production environments, with test environments often unable to match the scale of real-world production scenarios.

Our initial approach to Agile, which we now acknowledge as an anti-pattern, involved trying to overlay our Waterfall gates, including planning, requirements gathering and design, onto Agile practices. We attempted to retrofit our existing Waterfall process into an Agile mindset, but inevitably, it proved unsuccessful. While I wouldn’t characterize our attempt as an utter failure, it certainly wasn’t the optimal path forward. However, upon reaching a critical juncture, we swiftly abandoned this approach. Instead, we embraced Agile as a distinct development methodology, committing to a holistic Agile transformation. Securing leadership buy-in was pivotal, marking the true commencement of our Agile journey.

How did you tailor this approach to fit within the existing ecosystem?

The first Agile Instruction, created in 2014, had to be carefully tailored to not only meet the OMB’s 2012 Modular Development Policy, but also to work within the agency’s Acquisition Lifecycle Framework, the guiding governance for all acquisition. We underwent a lengthy agency clearance process for the policy that took two years. Though prolonged, this period allowed for an extensive roadshow of the concept. When the policy was finally published in the summer of 2016, we had communicated the Agile concepts to the entire agency. The IT programs were prepared to begin complying with it.

Communication is often a challenge in large transformations. How did you handle this?

Communication was pivotal. We made visits to every component’s Chief Information Officer and most Chief Acquisition Executives to seek their buy-in and support. There was no way to manage this level of change with a completely top-down process. As a heavily federated agency, the partnership of each component was crucial to success. This outreach was complemented by the publication of additional guidance and set the stage for us to begin monitoring the adoption of Agile across the agency.

There seems to have been some confusion about Agile initially. How did you address this?

When Agile first emerged, it introduced an entirely new vocabulary that left many bewildered. Agile coaches spoke a language that seemed foreign, aiming to break away from traditional development methods. However, the challenge lay in the fact that agency IT program managers were still firmly rooted in the language of Waterfall. They found themselves scratching their heads, wondering what these individuals were talking about. One particularly amusing anecdote occurred during a meeting with IT professionals from a law enforcement agency and a forward-thinking Agile coach. The coach enthusiastically proposed a visualization exercise involving a sailing ship and colored sticky notes representing requirements. As the sails of the ship filled with sticky notes, the idea was to crystallize the project’s objectives. Yet, the law enforcement officers looked utterly perplexed, signaling a significant disconnect in perspectives on approaching work.

To bridge this gap, we introduced a concept known as Agile building blocks. It provided a simplified framework for translating key Agile principles to the agency, enabling us to bypass the need for mastering an entirely new vocabulary from the outset. Our approach prioritized simplicity and accessibility, ensuring that even lay IT personnel could grasp the concepts without being overwhelmed by Agile terminology. Initially straightforward, the Agile building blocks gradually evolved into more nuanced components as we delved deeper into explanations.

One crucial building block centered on engaging the product owner early in the process. Traditionally, after obtaining approval for hundreds or thousands of requirements, the product owner would essentially disappear until the project’s completion, resurfacing only to assess the final product. This often led to disappointment and frustration when the delivered product failed to meet expectations. Despite viewing wireframes and mock-ups, the disconnect between developers and business owners persisted, increasing the likelihood of design changes that deviated from the business’ vision. Recognizing the importance of continuous collaboration, we instituted regular retrospective sessions with product owners, fostering a culture of ongoing feedback and iteration. This shift marked a significant departure for the enterprise but proved instrumental in aligning development efforts with business objectives.

Getting your requirements out of a book and into a tool was also an essential step. Individuals used to write these large documents with thousands of requirements on Excel files that you would go through and check off by testing. As noted, these would all be built before designing the system or writing the first line of code. We transitioned everyone to Jira from the Atlassian Suite to manage all their requirements within a dynamic backlog. This platform enabled the product owner to extract requirements as needed, facilitating incremental work for the team.

Another crucial building block involved ensuring that contracts were aligned with Agile principles. We collaborated closely with the Chief Procurement Officer’s staff to develop their own Procurement Innovation Lab, dedicated to embracing Agile contracting. Additionally, we sought to eliminate the traditional handoff from developers to independent testers. To kickstart this transition, we initiated a practice where the test team worked alongside developers, testing the code in real-time as it was being built. This adjustment significantly reduced development time, paving the way for a smoother transition to the full Agile sprint process.

Two other pivotal building blocks were DevOps and Scaling, leveraging frameworks like SAFe and other methodologies. While these concepts initially seemed aspirational, we included them in our roadmap to ensure ongoing planning and preparation. Over time, we successfully implemented these practices, achieving our objectives and further enhancing our Agile capabilities.

These building blocks formed the foundation of a maturity matrix implemented across the agency. We applied these ten concepts to each project, program and component, aggregating them to assess the agency’s overall maturity level. While the process was rudimentary, it provided an excellent starting point. By establishing these building blocks, we not only pinpointed areas of weakness for targeted improvement but also rudimentarily measured adoption across the enterprise.

We didn’t delve into assigning specific weights to each building block; instead, we adopted a pragmatic approach. We simply gauged progress by the number of building blocks implemented: achieving five out of ten meant reaching 50 percent progress, while accomplishing seven out of ten equated to 70 percent progress. This simplified method proved effective for our needs at the time and aligned well with a key Agile principle: don’t wait for perfection before taking action!

Moving onto IT acquisition – how was the transformation process handled?

The IT acquisition process—from product concept to deployment—was completely rewritten and successfully completed in 2019. This required strong partnerships with each Chief Executive Officer at headquarters. Each signed off on the plan and offered staff members to support the working group. This effort significantly streamlined agency IT acquisition processes, drawing attention from Congress and the GAO, which prompted congressional staff testimony and an audit to learn how the agency was doing it.

What role did executive support play in maintaining the momentum of the transformation?

This type of transformation does not happen overnight. It took well over a decade, and it is still ongoing. In fact, you are never finished. But federal executives are only there for three to four years, often less. As a result, we had to brief and gain buy-in from several high-level stakeholders. This included three Deputy Under Secretaries, perhaps eight CIOs, and five CTOs. Each came in with their own agendas and goals, and it was a continual negotiation to keep the effort going in the face of competing priorities. All stakeholders required regular briefings on the transformation efforts to maintain executive buy-in. One of the key takeaways was the assignment of staff from each of these leaders so that they had their own folks directly involved in the transformation efforts and looking out for their specific equities. That partnership occurs to this day in a monthly meeting.

Can you talk about the broadening of the Agile and DevOps implementation?

The agency has continued to improve after meeting its initial transformation goals. They constructed a shared DevOps Continuous Integration/Continuous Delivery pipeline to integrate smaller components and offices more effectively into the Agile framework. They are also now reimagining Agile to escape the confines of the rigid acquisition lifecycle framework. They are shifting Agile metrics away from a compliance model to better measure value aligned with business needs and mission objectives. They have continued the ongoing assessment of Agile and DevOps adoption across the enterprise to ensure that transformations are not just implemented, but sustained.

How are you expanding Agile beyond just software development?

Agile methodologies are being expanded beyond software development, as exemplified by the creation of a Jira-based performance work plan model that aligns everyone’s goals to those of their supervisor, their executive and their senior executives. This is a perfect way to show alignment with and progress toward organizational goals. In my former position, I ran our entire division as an Agile team. Although we wrote, promoted and measured compliance with policy and procedures, the combined output of our work after each sprint followed the same rules for completing the “definition of done.” For instance, simply publishing a new policy manual was not the end state. It also had to be advertised and, in many cases, presented via video and live briefings before we would consider that task completed.

With AI becoming more prominent, how do you see it impacting Agile practices?

AI will infuse everything. We’ve spent over two decades teaching folks how to write user stories and other Agile techniques. These are known entities now. AI is demonstrating its potential to automate these processes, freeing up users for more valuable tasks. Recently I used GPT-4 to see if it could create user stories and acceptance criteria just by asking for the end state of a program. It immediately generated robust user stories and acceptance criteria in a perfect format. Humans will always have to verify the output, but this showcases the potential for AI to replace the more mundane aspects of Agile tasks, reducing timelines and enhancing efficiency. I can see where AI could help manage the entire backlog of user stories based on the historical criteria of former successful development efforts. It is very exciting and something I would like to continue to investigate.

Do you have any final thoughts on where this journey is heading?

The journey of Agile transformation illustrates a shift from traditional methods to a dynamic, integrated approach. It highlights the importance of executive support, continual adaptation and leveraging technology to enhance efficiency and effectiveness across IT operations. As we move forward, the focus will be on ensuring these methodologies are not only adopted but also perpetually improved and integrated into the fabric of agencies. I look forward to taking these successes to many more agencies with the RELI Group!

 

Following this Q&A session, you might find yourself intrigued by the prospects of Agile transformation within your own agency. Take a moment to reflect on the insights shared and how they could apply to your organization’s unique context.

We’d love to know what aspect of Agile transformation resonated with you the most and sparked your interest! Your thoughts and reflections can serve as valuable contributions to the ongoing dialogue surrounding Agile methodologies and their potential impact on agency operations.