The Agile Manifesto statement of “Customer Collaboration over Contract Negotiation” is less than helpful when it comes to writing contracts for projects to be worked in an Agile fashion. Contracting for Agile software development projects continues to be a major organizational impediment. Your legal department is trained to protect the firm from all the bad things that can happen when the unexpected occurs. Combine that tendency with management’s desire to protect their jobs when the bad things happen. Risk aversion should be the expected position, given the Standish Groups statistics showing the majority of IT projects are viewed as less than successful by their stakeholders. If you have been in the IT business for more than ten years, you have probably heard the line, “No one ever lost their job betting on IBM.”. I am willing to bet that no manager ever lost their job by embracing a contract provided by their legal department as well.
In an effort to allow for Agile Contracting, following are a few steps that you can take:
- Familiarize your legal department with the Scrum Framework and Agile Principles as well as with how they differ from Waterfall and other sequential project-based contracts that were authored in the past. It must be understood that the old contract models do not apply.
- These new Agile contracts must include the concept of a delivery cycle. At the end of each two to four-week time-boxed period, a potentially releasable product increment with useful features is the result. This delivery may not have enough useful features to warrant its deployment to the market, (that decision would be the Product Owner’s choice). The contract should call out the length of the iteration and this iteration length should remain constant for the duration of the project.
- Agile contracts should include project scope, but this scope may vary from highly specific with mechanisms for change to scope that is limited to the next iteration.
- Include a summary of the Product Vision to help frame the effort. Similar to a Sprint Goal, this Product Vision gives the team room to maneuver as new learning occurs. The Product Vision should be included in an appendix to the contract for reference with respect to questions on prioritization of the Product Backlog and updates to a Product Roadmap.
- Change Management is mostly covered in Agile with ordered product backlogs along with the inspect and adapt nature of the Scrum Events. Please do avoid creating change request processes or Change Management boards. These change processes and Change boards cause decision latency. Decision latency is a leading cause of project failure.[1] The Product Backlog is the Agile equivalent to Waterfall requirements. Unlike Waterfall requirements, it is understood that a Product Backlog will continually be updated and re-ordered or prioritized. The contract should be explicit with how/when the initial Product Backlog will be developed and estimated. The estimates should be provided by the Scrum Team. It is important not to set expectations based on expert estimation. The Product Owner may amend the Product Backlog but estimates would never be changed without consulting the Development Team.
- Contract termination in an Agile Project may actually be viewed as a positive. While early termination is often considered a failure event, with working software being delivered every iteration the client may obtain the desired market value before spending 100% of the allocated budget. Ideally, the client should be able to terminate the contract at the end of any iteration.
- The concept of Acceptance should be based on the client’s definition of DONE. Explicitly what does it mean to have potentially releasable software? Ideally, a library of automated Unit and Acceptance tests will be built each iteration. All of these tests would be rerun every iteration to validate that nothing previously delivered was broken by the new delivery. Practically, this means that Acceptance Testing should not be a huge manual effort at the end of the process. Are the right stakeholders involved each iteration and are they interacting with the development teams?
- How one communicates the desired (forecast) value or return on investment is very important. Typically, Finance and Project Management Organizations look for a specific minimum return to approve a project to move forward. What frequently happens is that a few experts get in a room and provide an Order of Magnitude estimate for a high-level vision which makes its way into a contract. Expert-based estimation that starts to look like project commitment would not be a problem if a capped-price variable-scope progressive contract was written.[2] In most environments, there will not be a trust level that allows for progressive contracts so many are looking at a fixed price per iteration with working software that meets the definition of DONE delivered each time. Either of these approaches is significantly better than trying to emulate Nostradamus by writing a fixed scope-fixed price contract based on the order of magnitude vision. How is the vendor to divine the unknown unknowns that were assumed when the order of magnitude estimate was produced?
- The contract should discuss the key agile roles. For example, the Product Owner is the representative of the customer and there is only one Product Owner. Ideally, the Product Owner would be appointed by the Customer. The Vendor may require assurance that the Product Owner is experienced with Scrum development. Additionally, the Product Owner key responsibilities related to development, ongoing revision, ordering of the Product Backlog and solicitation of Customer feedback each iteration. The Product Owner should not be removed from the project. From the Development Team perspective, the contract should call out the expectation that a cross-functional team will be supplied and that they are experienced with Scrum. The Customer should be allowed to confirm if the proposed Development Team is acceptable. The Vendor should be able to ensure that Development Team members will be dedicated to the project and not reassigned without prior written consent. The Scrum Master role should be carefully considered in the contract. If this development is being done on the Customer’s network and systems you may want the Scrum Master to be someone that is comfortable navigating the Customer’s organization with respect to helping to remove impediments related to producing a working product increment each Sprint. Similarly, to the Product Owner and Development Team, the Scrum Master should not be reassigned during the effort and ideally would be dedicated to this project.
- The Definition of Done should be carefully considered prior to awarding a contract along with dispute resolution between the Customer and the Vendor should there be a disagreement with respect to if the Definition of Done has been met for any given iteration.
- The contract should also call out the desired level of transparency. Are your stakeholders interested in Sprint Burndown charts and/or Release burn-up charts? What value metrics as described in Scrum.org’s Evidence-Based Management framework[3] will be captured?
- Consider if compliance with the Scrum Framework should be contractually mandated?
In summary, there is much work to do concerning educating finance and legal on how Agile Contracting significantly reduces the risk of bad outcomes. When one compares working software every iteration that can be measured against an evolving vision versus Waterfall delivery against fixed scope where working software is only available at the end of the delivery cycle the risk reduction becomes obvious.
[1] Chaos Report Series, Decision Latency Theory; It is all about the Interval page 26
[2] Agile Contracts Primer; by Tom Arbogast, Craig Larman, and Bas Vodde
[3] https://www.scrum.org/resources/evidence-based-management