Primary tabs

In the shifting world of federal IT, complicated recently by the global pandemic, federal agency IT shops are pressed to re-imagine processes and methodologies to maintain the performance standards of in-person operations and then to improve service delivery.

For decades, agencies have invested heavily in methodical Software Development Life Cycles (SDLCs) and complex testing processes that emphasize up-front requirements development and structured reviews to build quality into a system. These approaches may be appropriate for some situations, but typically they make it harder to adapt to requirements changes. Adhering to process at the expense of customer needs and delaying testing until the end of development pose a serious risk of missing expectations and timelines, and can significantly increase project costs.

As tools and technologies change, it is natural to wonder whether the pain to unravel and rebuild the underlying processes is worth the trouble. Getting maximum value out of any methodology takes work and due diligence to re-examine processes, conduct system analyses and get stakeholder buy-in. However, agencies that make the commitment to change smartly are seeing real benefits and not looking back. The initial effort does indeed pay off.

Why make a change?

Demonstrating the federal government’s interest, the Government Accountability Office (GAO) recently highlighted in a new report the need for agencies to embrace Agile as a new way of working and of saving the federal government billions of dollars.

“Speed to market,” often enabled by an Agile software development methodology, means a lot in today's software development world. It means users see system features delivered at a faster pace to improve day-to-day operations and increase the effectiveness of job performance. It also allows users to provide feedback faster, accelerating the entire value chain.

By shortening the cycle, teams spend more time on development, system hardening, validation and other value-add activities. Walls and silos disappear in the new DevSecOps world. Teams deliver frequent, incremental changes rather than major releases or upgrades a year or more apart.  The result is a more secure, useful and feature-rich product in the hands of end users within weeks rather than months or even longer.

Making the mental leap from recognizing an organization's current state to committing to an idealized future is the first step. The next sections will help you reimagine your organization and provide the starting point for your journey.

Getting started

Once you’ve made the decision to move towards DevSecOps—sometimes called SecDevOps to highlight security—begin with the end in mind: delivering higher quality code at a faster rate. Avoid the temptation to settle on a specific methodology too quickly. I recommend the following actions:

  • Communicate early and often to ensure that everyone likely to be affected by coming changes is aware of what is happening—and why—to better support the effort. Resistance among agency employees, lack of support from top leaders and poor communications will slow or stop a project more certainly than anything else.
  • Establish a Technology Advisory Review board to support rapid decision-making and champion the change effort. This board should involve business and IT leaders with decision-making authority and respect across the organization. Include acquisition professionals on the board to develop procurement strategies that match the transformation goals.
  • Start with a “clearing session” to discuss known pain points and uncover other hidden challenges. Pull together representatives from development and production teams, end users, and product owners to discuss their pain points. Assure them the goal is not to find a quick and easy solution, but to produce genuine, fundamental change. Force healthy disagreement so that the real issues will bubble to the surface. This builds buy-in across all levels of the organization.
  • Determine why those pain points exist and how they should be addressed. Within this discussion, consider value-stream mapping and affinity diagraming to support your analysis of the priorities and existing pain points. Be careful not to preserve activities or policies that do not fit the organizational objectives or may be perceived as too difficult to change.
  • Start experimenting with small changes to see what works. Now that you have the necessary buy-in and an understanding of processes, you can start to look into the technical aspects. The plan here isn’t to fully architect out the future of your tools and processes, but rather to tinker with what’s available now. You will learn what works and what doesn’t more effectively by trying than by planning. Be the model for your organization by adapting the core tents of an Agile methodology in your process implementation.

Now is the time to evaluate how you deliver quality code to your end user communities. Keep in mind that moving too quickly to specific methodologies or technologies won’t fix things and, in the end, may scare your organization away from actually making a positive change. Conversely, spending excessive time on planning could lead to paralysis for your organization.

To avoid either extreme, start small. Set near-term goals and measure your progress against them.  You will see how a seemingly overwhelming challenge becomes achievable through a series of smaller steps. As an added bonus, if you manage the shift this way, you’ll be living by the tenets you want your development and operations teams to live by.

For more insight into the world of DevOps, download the CGI white paper, “Finding the on-ramp to the SecDevOps highway.”

Download the GAO report.

About this author

Bryan Hall CGI Federal

Bryan Hall

Vice-President Consulting Services

Bryan serves as the portfolio manager for financial management and IT transformation projects at a large civilian federal agency.

Add new comment

Comment editor

  • No HTML tags allowed.
  • Lines and paragraphs break automatically.
Blog moderation guidelines and term of use