A crucial component of the acquisition strategy is a plan for intellectual property (IP). As the recently released intellectual property policy specified, IP plans emphasize “the criticality of long-term analysis and planning during the earliest phases of the program.” Long-term planning is required for IP so that specified terms and pricing can be set up front, for such things as who owns the data, whether third-parties can modify the code, and which interfaces will be used. But if used improperly, it could lock in technical plans at the expense of course correction.
The IP process may run against the stated intentions of the software pathway policy — that programs use agile development methods. Some of the values from the Agile Manifesto include: responding to change over following a plan; collaboration over contract negotiation; and working software over comprehensive documentation. The requirement of defining all IP needs upfront runs counter to the values of agile.
If software is supposed to be incrementally released, then the definition of IP needs and pricing should also be an iterative exercise. Otherwise, the Pentagon’s IP policy would in practice necessitate a waterfall planning process. Developers would have to execute within the constraints of the IP plan.
That was my piece in the Federal Times, “Obstacles and Opportunities in the Pentagon’s Software Acquisition Pathway.” Read the whole thing.
Not following your logic. Why do you think a particular software development model would inhibit the acquirer’s ability to identify its IP needs? Before a line of code has been written, the acquirer should know (or at least have some concepts) on what its requirements to operate, sustain and modernize the software are likely to be. The IP Strategy “merely” requires the acquirer to identify the IP deliverables and license rights necessary to perform these functions. This can be tough under all conditions, but I don’t see how it is more or less challenging because agile methodologies are being used.
Also, iterative IP pricing schemes do not generally end well for the Government. If the acquirer clearly lays out her intentions for using the IP pre-award, both parties can go into the relationship with their eyes wide open, and IP can be priced accordingly. In all cases, the Government’s leverage to obtain the IP and license rights that it requires at a fair price is at its zenith at this point, and I am not seeing how the use of agile disrupts this dynamic. If the acquirer’s IP needs change over time, the deal may need to be revisited, but these changes are going to be driven by something other than the development methodology.
Thanks for the comment. I don’t think an IP plan has to be bias against agile development, but if it invokes long/detailed requirements and lifecycle sustainment plans ahead of project start, then it may contribute to a process that is more like “water-agile-fall.” I don’t have a good resolution, but I think a fruitful direction is to what Oliver Williamson called “task partitioning.” Breaking contracts down into smaller tasks and incrementally making decisions. Ultimately, I’d like to see experimentation and would expect different strategies to succeed depending on the project-type involved.