Agile Contracts

Contracting for agile software development is fundamentally different from traditional project contracting. Using traditional contracts for an agile development project can endanger the project execution and causes the company to fail to get the potential benefits of agile development. In case, there is a fix in Agile contracts, the supplier, and the customer together define their common assumptions in terms of the business value, implementation risks, expenses (effort) and costs. On the basis of these assumptions, an indicative fixed price scope is agreed upon which is not yet contractually binding.

This is followed by the test phase (checkpoint phase), during which the actual implementation begins. At the end of this phase, both parties compare the empirical findings with their initial assumptions together, they then decide on the implementation of the entire project and fix the conditions under which changes are allowed to happen. Another common contract is the Time and Materials (T & M) contract, but while this style of contract protects the supplier it doesn’t provide any protection for the customer. The customer is fully exposed to the entire risk while the supplier shares none of that risk. So, a common extension of T & M contracts is a Capped T & M contract. These are contracts that are T & M up until a fixed agreed upon upper bounds (or cap).

Capped T & M contracts provide benefit to the supplier early on by fully covering their expense; but also provide benefits to the customer towards the end of the project by providing a limit to the total exposure. It’s in both parties interest to deliver high-value functionality as early as possible and to avoid cost overruns. Incrementally, Delivery or Progressive contracts are structured with regular inspection points, and at each inspection point the customer makes a decision; they can continue with the development of the product or they can stop development.

In stopping development, the customer can push the product into production and save the remaining balance of the contract. This style of contract works quite naturally for agile teams because they simply work in an iterative fashion until the point of inspection.

For example, consider a year-long contract that has inspections points every quarter; a team working with two-week sprints would work for six sprints and then present their work to the customer, who then decides to either continue the contract or not. We can adjust the interval between inspection points to allow for how aggressive the customer wishes. If they wish to inspect more often, then monthly inspection points can be written into the contract. Capped T & M contracts and Incremental Delivery contracts are more successful with agile projects.

Time-Boxing

A time-box is a previously agreed period of time during which a person or a team works steadily towards completion of some goal. Rather than allow work to continue until the goal is reached, and evaluate the time taken, the time-box approach consists of stopping work when the time limit is reached and evaluating what was accomplished.

The critical rule of time-boxed work is that work should stop at the end of the time box, and review progress: has the goal been met, or partially met if it included multiple tasks. Agile teams prefer to have a time-boxed project since it offers a fixed schedule and a fixed team size. With these project constraints, the team can better work with customers to maintain a laser focus on value, which ensures the team is building and delivering the most valuable work as soon as possible—leaving the less critical tasks to the end.

Time boxing also helps to prevent a common problem in software development called “feature creep,” where teams incrementally add features to software without scrutinizing relevance or need.

Feature creep leads to an unnecessary effort in both the development and maintenance of code, and can significantly impact quality and timelines on a project. In an agile project, everything is time boxed from meeting to iterations. Using guidance from the release plan, Product and Product Managers determine the approximate priority of themes and epics to meet release goals. Stories are initially created by the Product Manager and shared with the team in story workshops.