6 Steps for Fast Government Project Deployment Using Agile Development

Speed and accessibility to digital services are everything today and 85 percent of U.S. citizens expect “the same or more from government digital services compared to commercial digital services.”

For many enterprises, and a growing number of local, state and federal agencies, project managers are realizing that the fastest way to get their digital projects off the ground is through agile development. That has certainly been the case for the U.S. Forest Service’s rapid development of an interactive Visitors Map and the Bureau of Ocean Energy Management and the National Oceanic and Atmospheric Administration’s prototype development of an ocean reporting tool, which provides rich content about the southeastern coastal areas from Virginia to Florida.

Agile development is not new; its roots can be traced back almost 50 years. But agile development adoption in the government ranks is. According to the Deloitte Center for Government Insight, “fewer than 10 percent of major federal IT projects described themselves as ‘agile’ or ‘iterative’ in 2011.” However, the last seven years have seen a jump in the number of federal agile projects and that’s not surprising considering the findings of the 11 Annual State of Agile Report. Respondents reported that the top benefits of implementing agile were “accelerated delivery, better project visibility, improved team productivity and management of changing priorities.” If these benefits make sense to you for your next government project, here are six important steps for adopting agile development: 

1. Select a dedicated product owner who can be a determined advocate.

The selection of the right product owner is critical because that individual needs to truly own the vision of the product. Generally, on a government project the product owner is a contracting officer representative. The owner needs to be someone who readily understands the business requirements of what is being developed and also has enough technical knowledge to follow all of the conversations that will take place.

2. Get buy-in to implement agile development.

Before beginning, it is important that the contracting officer representative be fully on board with agile development since it will require a lot of his or her time. Early on, there may be concerns that agile development seems too time intensive and complicated, but once underway, the team will see that agile development is a framework for engaging the entire team and delivering value.

3. Create a cross-functional team composed of testers, designers and programmers.

The project manager should be tasked with developing the cross-functional team comprised of members who are both responsible for their individual roles but are also capable of working together to share progress, ideas and follow through on all aspects of the project.

4. Involve IT, as well as the business unit of the organization.

IT needs a seat at the table from the very beginning and is one of the most important stakeholders in any agile development project. Without IT’s support and engagement, your project will be doomed. It is important that both the project manager and the product owner make sure that all of IT’s processes and procedures are followed. Similarly, make sure to keep communication open with IT so they understand all of the technical requirements that will be required from them in order to implement your project.

The business unit is the main client and ultimately the reason the software is being developed. Their needs come first. Be sure to regularly review and prioritize the backlog with stakeholders from the business unit. The backlog is owned by the product owner who is a representative of the business unit.

5. Conduct frequent retrospectives of progress to date.

Before commencing, the project manager must define how frequently to hold agile retrospective with all the members of the cross-functional team, IT, business unit and stakeholders. An agile retrospective is a recurring meeting that is held with the project team every two or four weeks, and concentrates on how to be more effective. During the agile retrospective, the team needs to review the backlog that they were responsible to complete during each sprint—the two- to four-week length of time between each retrospective. In addition, the team will also demonstrate the work they have completed during the sprint. Retrospective reviews should include discussions about every aspect of the project so adjustments can be made before moving forward with the next set of deliverables.

6. Manage stakeholder engagement.

All of the stakeholders should be at each sprint review. In order to be successful, you will need stakeholders’ feedback to ensure they understand the progress throughout the project and are on the same page as the entire team. The stakeholders are the business unit’s end users of the system being developed, as well as their supervisors, IT and any members of the organization who depend on the products of the system you are developing.