The definition of "Adequate Incremental Development" needs work, and at this point its definition should be delegated down to the agencies to define on their own.
"Adequate Incremental Development - For development of software or services, planned and actual delivery of new or modified technical functionality to users occurs at least every six months."
Some issues with this definition:
1) The "... or services" portion should be dropped because the definition of services is usually labor-based, not technical functionality based. I'm not sure what I would tell the desktop support service staff regarding how to satisfy this requirement.
2) Not all systems increments should be published to the users. Think about the F-35 flight control software, Healthcare.gov that had a mandated go-live date that was more than 6 months away, or large COTS replacement projects that would require lots of expensive scaffolding to integrate the new with the inefficient old systems if the minimum viable product (and hardware installation) takes more than 6 months to develop.
3) Alternately, all programmers have experienced pure hacking environments where you inadvisable do software development on your production systems. We don't want to equate uncontrolled deployment processes with fulfillment of the "adequate incremental development" requirement.
4) Similarly, we don't want to push all projects into a situation where they are neither required to do the big design up front waterfall lifecycle nor the "we sit in the same cube as the business owners" customer intimacy requirements that good agile guidance should include.
Instead, I would recommend a definition more akin to:
"Adequate Incremental Development - In general, delivery of a fully tested and releasable increment of software to the business owners every six months or less. Agency and Bureau CIOs should establish working definitions within their organizations that address the various types of development projects present within their environment and train their staff to ensure contracts meet those requirements."
I would also recommend removing or modifying element I1. If the only reason for reviewing all "cost estimates" is to satisfy the CIO's certification that they are "adequately implementing incremental development" requirement, we should defer to agencies to determine their best process for achieving that. Since every single tiny ODC purchase requires three separate cost estimates, I would much rather have the CIOs establish clear definitions, add standard contract provisions, train the key personnel and use some form of audit to meet that requirement rather than review 130 cost estimates every hour of the year. I would recommend an alternative to I1, but it appears G1 has already captured my thoughts on that.
The definition of "Adequate Incremental Development" needs work, and at this point its definition should be delegated down to the agencies to define on their own.
"Adequate Incremental Development - For development of software or services, planned and actual delivery of new or modified technical functionality to users occurs at least every six months."
Some issues with this definition: 1) The "... or services" portion should be dropped because the definition of services is usually labor-based, not technical functionality based. I'm not sure what I would tell the desktop support service staff regarding how to satisfy this requirement. 2) Not all systems increments should be published to the users. Think about the F-35 flight control software, Healthcare.gov that had a mandated go-live date that was more than 6 months away, or large COTS replacement projects that would require lots of expensive scaffolding to integrate the new with the inefficient old systems if the minimum viable product (and hardware installation) takes more than 6 months to develop.
3) Alternately, all programmers have experienced pure hacking environments where you inadvisable do software development on your production systems. We don't want to equate uncontrolled deployment processes with fulfillment of the "adequate incremental development" requirement.
4) Similarly, we don't want to push all projects into a situation where they are neither required to do the big design up front waterfall lifecycle nor the "we sit in the same cube as the business owners" customer intimacy requirements that good agile guidance should include.
Instead, I would recommend a definition more akin to: "Adequate Incremental Development - In general, delivery of a fully tested and releasable increment of software to the business owners every six months or less. Agency and Bureau CIOs should establish working definitions within their organizations that address the various types of development projects present within their environment and train their staff to ensure contracts meet those requirements."
I would also recommend removing or modifying element I1. If the only reason for reviewing all "cost estimates" is to satisfy the CIO's certification that they are "adequately implementing incremental development" requirement, we should defer to agencies to determine their best process for achieving that. Since every single tiny ODC purchase requires three separate cost estimates, I would much rather have the CIOs establish clear definitions, add standard contract provisions, train the key personnel and use some form of audit to meet that requirement rather than review 130 cost estimates every hour of the year. I would recommend an alternative to I1, but it appears G1 has already captured my thoughts on that.