Can You be Agile in Your Acquisitions?
This is one of the most common issues facing organization choosing to switch to Agile. Can you acquire goods and services in an Agile fashion? Can you contract with vendors to deliver in an Agile fashion?
A decade ago, if you asked that question of a Scrum Master, the answer was no. One of the most notable Scrum books from that time stated that acquisitions could not be performed in an agile fashion, especially in the federal government. Well, for those of you that have done this, you realize it is possible.
In 2009, the DoD presented an iterative acquisition model that was instrumental in changing how the federal government approached acquisition. They were not pursuing an iterative model to align with the Agile community, they had their own reasons. There were too many risks and too many project failures due to the typical federal acquisition process. Some of the risks they mitigated through their proposed approach were:
- Rapidly changing technology: Previously a “buy” decision during the budgeting process may have been performed years in advance of the use of a technology that was obsolete by the time it was needed for the project
- Changing requirements: As with any project, requirements change during the project lifecycle due to changes in the organization, regulatory changes, or just as new information becomes available
- Flexibility and Responsiveness: The military needs to be responsive in its solutions based upon the nature of the needs of the organization. The ability to deliver more frequently is important to maintaining its position as a military leader.
Their approach to acquisition is identical to what we consider when performing iterative software development. Here is their approach; note how similar it is to the typical Agile Software Development practices:
- Early and continual involvement of the user
- Multiple, rapidly executed increments/releases of capability
- Well defined objectives but not over defined requirements for the initial increment
- Evolving requirements for subsequent increments/releases
- Mature technologies (often with short half-life that require periodic refresh)
- Early, successive prototyping to support an evolutionary approach
- Early operational release of capability from within an increment
- Modular, open-systems approach—designed for ease of updates
- Available full funding of initial increment(s); solid funding stream for next
- Overlapping upgrade increment(s)
- Making schedule the priority for releasing available capability and not requiring (or expecting) a “yes” vote from every functional organization prior to decision milestones
- Making sure that users are trained and prepared to receive the new capability
The DoD’s adherence to The Agile Manifesto is clear. By following these practices which were originally developed to reduce risk on software development projects, the risk in acquisition projects can also be reduced.
For further information, see the full Department of Defense report at https://www.acq.osd.mil/dsb/reports/ADA498375.pdf
Management Concepts Inc. covers this topic throughout its Agile Project Management for the Federal Environment course. It also addresses other acquisition topics such as what types of contracts are common with vendors in an Agile environment and how to include vendors on your Agile project team.
About the author
Dan Tousignant, PMP, PMI-ACP is a project manager on Agile projects. He provides Agile Coaching and Training for Management Concepts, Inc. and is one of their instructors delivering the Agile Project Management for the Federal Environment course.
It was my first interaction with your work and i must say this article is greatly insightful