By Cesar Tavares
Federal agencies are under increased pressure to deliver more with less and the only way they can meet such demands is by transforming themselves into more lean, flexible and responsive organizations. Meaning, federal agencies must adapt Agile principles and methods. Why then, given Agile’s proven track record, are federal agencies hesitant to make this jump?
This hesitancy is most often related to the rules and regulations that government agencies are forced to operate under. Rules and regulations are, by definition, not agile, particularly those enacted to acquire and manage waterfall development. As a result, these become constraints that make Agile implementation difficult. Such constraints explain why federal agencies have lower Agile adoption rates as compared to the commercial sector. Adoption by federal agencies is made even more difficult by the fact that the Agile community has not provided enough guidance to navigate these constraints. Therefore, the purpose of this article is to provide the Agile community with a starting point to overcoming these challenges through six major steps.
Step 1: Get commitment from leaders
The first and perhaps most important step in getting your federal agency to take advantage of what Agile has to offer is to get the commitment from your leading stakeholders. Without commitment from the top, transformation is not possible. If your agency is reluctant to adopt, try pointing them to the following tools: The Digital Services Playbook and The TechFar Handbook. These tools were created as a direct result of government failures (i.e. healthcare.gov) and will not only help you get buy-in for the Agile transformation, but it will also provide you with “plays” and other suggestions for success.
Step 2: Revise your acquisition process
The second step is to revise the acquisition process to support Agile deliverables. Agile-run programs that are executed under contracts meant for traditional software methods will most likely fail. This is because there are fundamental differences between Agile and traditional software development methods. This includes how work is procured, executed and monitored. Note, that in order to change something even as inherent as your RFI or RFP template, it will require the appropriate stakeholder commitment described in step one.
Step 3: Perform an assessment
The third step is to perform an assessment. The key here is to promote self-awareness and to establish a baseline from which to measure improvements. The assessment will also be the basis for establishing an Agile roadmap which will help determine your target future state. With the assessment and subsequent roadmap in place, the organization can begin to identify and acquire the resources needed to address challenges and to ensure a successful implementation.
Sept 4: Institute a Training Program
Perhaps the biggest challenge to an Agile transformation is culture. Federal agencies have deeply ingrained cultures that are very difficult to modify. Consequently, successful Agile implementations hinge upon a shift in culture. Thus, our fourth step deals with the most effective way to influence culture shift – training. Specifically, having Agile coaches embedded within the organization is the best way to provide the necessary training in order to foster change. The focus of the training is knowledge acquisition throughout the organization which will help align the Agile effort to the agency’s overall objective.
Step 5: Pilot your most difficult project
Now with everyone on board, the next logical step is to set-up a pilot project to help realize and refine your implementation. When piloting a new concept or capability it is common practice to pilot those projects that will present the least amount of risk. This is an acceptable approach; however, based on my experience, piloting a low risk project is not a successful driver of the Agile adoption effort. Low risk projects have less visibility, may not represent the overall organization, and do not foster overall engagement. Picking a low risk project may ultimately lead to failure at scale. A better and more effective approach is to pick the most difficult project available for your pilot. Doing so will ensure that major challenges are addressed and that success is scalable through the organization.
Step 6: Develop your DevOps solution
The sixth and final step, often the most challenging for the federal government, deals with your DevOps solution. DevOps means applying Agile principles to all stakeholders within the software supply chain. It is also the essential enterprise capability for ensuring continuous delivery. The speed of Agile is limited by the operations supporting it and, as a result, you must have an effective DevOps solution in place. I have found that the best approach to implementing a successful DevOps solution is to leverage your assessment (see step 3) and identify those DevOp areas or capabilities that need the most improvement. Next, create appropriate epics and/or features that address them and manage them within your Agile backlog.
Within the world of software development, federal agencies have a lower Agile adoption rate because of the increased constraints that they are forced to work under. This is further aggravated by the lack of available guidance. Thus, if your organization suffers from the aforementioned constraints and does not have guidance on where to begin, I recommend the mentioned Six Steps to Agility in the Federal Space.
About the Author:
Cesar Tavares is a Solutions Architect for Salient Commercial Solutions’ Agile Center of Excellence as well as a leading member of Salient Federal Solutions. Tavares has over 15 years of IT experience in both the Federal and Commercial sectors, serving as a lead technologist for QintetiQ North America. He speaks fluent English, Spanish, and Portuguese and is considered by some to be an expert in architecture, installation, implementation and training of application lifecycle management tools. Notably, Tavares was a co-speaker for IBM Innovate 2014.
