Government projects are not agile enough

Agile is increasingly the standard way software development organizations deliver software. In a recent survey by TechBeacon, two-thirds of organizations said they are using "pure agile" or "leaning toward agile."

For the majority of government projects, however, agile is still a dream, and waterfall methodology continues to be used, with large amounts of process governance and control.

That lack of agility is highlighted in high-profile failures such as the Universal Credit project in the United Kingdom and the disastrous launch of HealthCare.gov in the United States. Agile alone would not have solved many of the problems that plagued those projects, but it would have made them more visible, thereby enabling the right decisions to be made earlier.

Government seems to be a place where agile would not only help but is truly necessary. Consider that:

* Large projects are always a risk but less so with agile. Government projects always seem large and complex, and that dramatically reduces the likelihood of success, according to the Standish Group's Chaos report. The report cites success rates of 5 percent to 12 percent for "grand" and "large" projects. But it also states that the likelihood of success increases four or five times when one uses an agile approach.

* Digital is a necessity, not a "nice to have" technology. When he described the future of business innovation, Marc Andreessen is quoted as saying, "Software is eating the world." But that is not true just of business; government is also looking to software to deliver improved services, connect with citizens and make better decisions. And digital is synonymous with agile. In fact, the U.K. government insists that all digital programs follow an 18-point service standard. Point 4 describes the need for projects to "build the service using the agile, iterative and user-centered methods."

* The world is full of change, and that is only going to increase. The combination of globalization and shifts in socioeconomic power is leading to a much less stable world. Software delivery processes that encourage long-term projects with time horizons of three to five years have limited value in this environment. Agile by its very nature encourages teams to deliver software, systems and products faster, and break down large problems into manageable chunks.

Scrum is the answer

When we say agile, for the majority of organizations that means "scrum." In a recent agile survey, scrum was cited as being most closely used 68 percent of the time. Scrum provides a lightweight framework that teams can easily adopt, but the sheer number of people who know the methodology lowers the challenge of finding qualified team members.

Many organizations, therefore, look to Scrum as a key part of agile adoption because:

* Scrum is popular. A quick Google search will provide you with hundreds of books and thousands of web pages describing adoption practices, examples and case studies. The sheer volume of material and the ability to demonstrate your knowledge with professional certification build demand for Scrum and provide a market for it. Unlike many agile approaches, Scrum provides clear guidance on what the bare minimum for adoption is and what additions to the framework are needed to maximize the chances of success.

* Scrum is being used at scale. From the very beginning, scrum was applied to complex, large projects, usually as an antidote to the challenges of waterfall methodology. But many of the ideas for applying scrum at scale were left to the scrum team to solve. With the introduction of the Nexus framework and other agile scaling approaches, there are now codified extensions to scrum that support more complex situations.

* The FBI's Sentinel project paved the way for success. Much has been written about this program, but the highlights describe how a $450 million project was stopped after an investment of four-plus years and $421 million. The resulting reboot relied on scrum and a studio approach, which delivered a successful project in a year at a cost of $30 million. That project and others like it provide a great foundation for government agencies looking to adopt scrum.

And it is time to start

Many software developers have been watching the agile movement from the sidelines, saying, "This is great, but I work in the government." It is now time to get off the sidelines. Agile is real and is making inroads into many parts of the government today. In fact, TechFAR highlights flexibilities in the Federal Acquisition Regulation that allow for agile projects, and the Office of Management and Budget is increasingly turning to agile approaches to solve very public challenges with large IT projects.

Here are some tips for getting started:

* Immerse yourself in the ideas. Perhaps because of the sheer volume of materials, it is hard to decide where to begin. "The Scrum Guide" is the definitive description and provides a great place to begin, followed by Ken Schwaber and Mike Beedle's groundbreaking book "Agile Software Development with Scrum."

* Take a class and prove your knowledge. Reading about scrum is great, but talking about the ideas of empirical process and agile practices benefit from spending some time in the classroom. Validating that learning with assessment and certification ensures that you stay focused and prove you have the foundational knowledge.

* Start using Scrum in your team. There will never be a perfect time to get started, and it is always possible to find reasons to not do it. But even within the confines of water-scrum-fall, applying scrum at the team level can still provide value and experience.