Yesterday I stumbled across a study by Carnegie Mellon University’s Software Engineering Institute that used one of my projects as an example.
I had done phone interviews with the authors, but didn’t realize any of my ideas were included in the final version until I saw it when I was searching for something else.
The paper is called “Update 2016: Considerations for Using Agile in DoD Acquisition.”
You can find it either on the CMU SEI site or on the official DoD holding at the Defense Technical Information Center.
From the abstract:
…Continuing with the 2010 report's theme, this report updates the exploration of the questions: Can Agile be used in the DoD environment? If so, how? It includes lessons learned from DoD programs that have employed Agile and information gleaned from myriad articles and books on Agile…. The intended audience is policy makers, program office staff, and software development contractors who are contemplating proposing the use of Agile methods. We hope this report stimulates new discussion about adopting Agile in the DoD world and equips practitioners with the information they need to make informed decisions.
Although Agile is more widely embraced today than it was when the report was published in Dec 2016, the lessons still hold. I would argue that many of the lessons would apply if "Agile" were replaced with the name of many sound ideas for delivering value that are commonplace in the commercial environment but not widely used in DoD. Many of the considerations are also useful outside of the DoD.
They called out the Coast Guard Logistics Information Management System (CG-LIMS) as an example Agile project. After sharing part of my August 2012 blog post, they concluded:
This is perhaps the most important lesson from CG-LIMS: Agile methods and practices can be implemented even within large government organizations that rely on the formal structures of a Waterfall process, given sufficient imagination, tailoring, and tenacity. That is, processes do not execute themselves. They require actual human beings to make decisions, use judgment, and take action. When confronted with a Waterfall-oriented process, the standard implementation and interpretation is not the only way to proceed. A dedicated leader who wants to use Agile can do so—and do so publicly—by following the Coast Guard’s compelling precedent.
Processes do not execute themselves. Not my words, but I sure like it. Human judgment—and action—from leaders is a key to success.
Agile project leaders should not expect to receive universal support and buy-in regarding this approach. However, the absence of unanimous support does not constitute an insurmountable barrier. As Captain Taylor wrote on his blog in July 2012:
If it causes you some distress to know that Agile values and the principles of the Agile Manifesto are not embraced within the Acquisition community, know you’re not alone. It saddens me too. But please don’t let it slow you down. I was explaining to one of my fellow PM’s ... that I’ve long since given up on getting everyone’s buy in on our approach. We’ll need to keep moving with just enough approval and just enough support for what we’re doing. As we deliver, we’ll continue to make believers one at a time by showing results in the form of working software.
The whole document is worth reading. Even though it's almost two years now, I think anyone involved in a transformative effort in government IT (whether that means Agile adoption, DevSecOps, or cloud migration) will find something they can put to use.
I'll leave you with two quick thoughts that resonated with me:
I love the focus on Users, Users, Users! From the Executive Summary:
Lack of relevant end-user interaction is one of the failure modes that we have seen that significantly reduces the effectiveness of an Agile approach.
Brooks is still right: There is no silver bullet:
There is no “one size fits all” Agile process. Just like any set of practices, implementation of Agile must be tailored to fit the situation and context. For example, Agile teams responsible for developing high-risk core components of the software architecture might apply less-aggressive release schedules than Agile teams developing less critical pieces of the software system. Some Agile teams might pick a two-week iteration cycle where others might determine their optimum iteration cycle is three weeks. Agile is not a silver bullet but rather another “lead bullet” for the Program Management Office’s (PMO’s) and contractor’s arsenal.