BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Contracting to Enable Agile Behaviour

Contracting to Enable Agile Behaviour

Bookmarks

Martin Kearns gave a talk about agile contracting at 1st conference in Melbourne, Australia. InfoQ interviewed him about how agile contracts differ from contracts for waterfall projects, how contracts can deal with scope changes, major disturbances or delays during development, what you can do to ensure that contracts enable agile behaviour and help all those involved to work together based on an agile mindset, the role that lawyers can have when organizations want to use contracts with agile software development, and what organizations have to do themselves to be able to use agile contracts.

InfoQ: Why do you consider contracts to be important for software development?

Kearns: Whenever an organisation needs to engage with a 3rd party to deliver an outcome, provide support, augment roles and a financial transaction is part of the deal then contracts are fundamental to success. The most important thing is that the contract represents the intention, expected behaviours and accountability to the approach.

InfoQ: In which way do contracts for agile development differ from contracts for waterfall projects?

Kearns: The most important difference is that with waterfall projects variance is attempted to be removed in the supported documentation and a lot of expense and focus lies in the subsequent variations (i.e. Scope Creep) which are inevitable no matter how much planning is done up front. This naturally creates an adverse relationship with two parties trying to focus on their own best interests.

Agile contracts begin with a construct that allows projects to fail as the contract structure must allow for both parties to leave a contract constructed on a poor business idea for example. Too often projects have continued due to self interests of one party. There is also a need to have continuous exit clauses, as once the value delivered is less that the cost of an iteration there is no reason to continue. On the other side of the fence (the supplier) if the clients behaviour and mindset are not supportive of an agile approach the ability to exit without incurring loss is essential. Collective responsibility to an agile contract is a necessity, and cannot be demeaned to a single transaction.

InfoQ: In most "traditional contracts" the scope that must be delivered is agreed up front. With agile you want to embrace change and adapt scope along the way. How can agile contracts support that?

Kearns: One of the things I try to identify within the first 2-4 iterations of work is a degree of confidence in the backlog and the cycle time of user stories, For an agile contract to succeed we need to have a much better handle on cost of delivery incorporating project constraints into our calculations. To achieve this I normally like to engage for the initial sprints in a Time and Materials construct.

Once we have an acceptable level of confidence I like to work to define the number of features and/or story points that can be achieve for a fixed cost. Once this is considered "viable" I like to enter into my night club analogy, "1 in 1 out". My approach to change is always to say "yes", the client can either raise the ceiling on the project or remove a story / feature of equal size. Obviously when ceilings raise on project so does the cost and more probable time.

InfoQ: Can you give an example of how an agile contract can deal with major disturbances or delays during development?

Kearns: One of my favourite ways is to create a bubble up chart on impediments, where I trace the trajectory of delays over time. Once a bubble appears on the diagram it will begin to move to the right the longer the impediment remains. As the associated impact due to inaction becomes more significant to delivery we "Bubble Up". Once the bubble leaves the tolerance boundary the associated costs (size of the bubble) is converted into a change request.

When the impacts to project delay can no longer be absorbed within the current contract, then it must be addressed via a contractual amendment. This can occur by reducing story point ceilings, or more often than not an increase on project spend. As we see the bubble drift every day away from project tolerance we provide the maximum lead time to address issues before they become a financial implication.

Bubbling Chart Impediments Agile

InfoQ: In you talk you mentioned that agile contracts should enable agile behaviour, help all those involved to work together based on a agile mindset. Can you elaborate on this?

Kearns: One of the things I like to see in my contracts is that it is safe to fail early. If I as a vendor have proven that your project hypothesis is wrong and the expectations cannot be met, it is important that I get remunerated and my clients sees the value of being able to reallocate project funds elsewhere. This alone generates a different focus in initial discussions and the early iterations becoming far more focused as a result.

Another thing about an agile contract, as the scope cannot be defined to a high degree of certainty up front. Traditional vendor deliverables are designed to be incubated and delivered independently from other elements of a projects to protect vendor interest. Unfortunately project outcomes are interdependently related and require agile contract clauses to be re-designed. One way this can be addressed, a way which can design the right behaviours, is the necessity for all parties to "work to principle". The responsibility must be shared across both organisations. This for me has been something I have really learned to appreciate in collaboration with lawyers who were so amenable to this form of contract arrangement. As the principles are shared it provides a level playing field in how we must engage with one another. An example of such a principle would be to explicitly state the response rates required by a vendor team on business decisions to achieve the target release date or a continuous delivery speed to market.

There are many advantages to having an agile mindset embedded in the contact style, the last thing I would like to mention is the role of vendor management in such circumstances. As we have much faster cadences in contract review (2-4 weeks) there is a continued focus on the outcomes and how the deliverables from iterations add value and/or knowledge. Through recalibrating the relationship regularly through formal feedback loops, the transparency encourages all parties to focus on the outcome and reciprocity flourishes as success is shared.

InfoQ: Which role do you see for lawyers when organizations want to use contracts with agile software development?

Kearns: Lawyers have the same responsibility which is to insure that the project terms reflect the nature of the work to be delivered and that clients interests are protected. I don’t see this changing. The iterations within an agile contract are there to mitigate risk through the use of more granular information and a regular review cadence.

InfoQ: What do organizations have to do themselves to be able to use agile contracts?

Kearns: For me it begins with being open to a new way of working and realising that any contract has a two way responsibility for a successful implementation. There is a lot more cooperation within an agile contract and a honest desire for a win-win scenario to be achieved. People need to be proactively involved, I always know things are working when it is hard to identify vendors / clients on the office floor.

Rate this Article

Adoption
Style

BT