Author: Dr Sara Cullen, Managing Director | The Cullen Group
Agile is everywhere now, having long ago escaped the domain of IT projects. We want to be agile organisations and have agile providers to meet the demands of today’s agile businesses. We want things done fast, we want flexibility and collaboration with providers, and we want costs controlled. Agile is increasingly becoming an important method of choice to deliver these.
An agile approach works when there is uncertainty and embraces requirements volatility (clients and customers changing their minds or evolving their understanding of their requirements). This is the opposite of what most organisational contract templates are designed for. These are designed for pre-specified requirements, guaranteed dates, and to a large extent, at a fixed price. This is despite the degree of uncertainty inherent in almost all projects. As a result, variations are the norm and far too much time is wasted on fixing the blame when reality interferes with the illusion of certainty.
If that is the case in your organisation, you may want to consider a different approach. First, you must understand that many projects face so much uncertainty or likelihood of requirement evolution that traditional methods are counterproductive at best and fatal at worst.
Then you have to understand the nature of agile methods, and how the contract acts as simple frame agreement for collaboration, rather than a contract designed to maximise advantage over the other party, transfer risk to them, and lock in a fixed price for a fixed specification.
Some of the main differences are:
- Specifications vs. sprints,
- Control vs. collaboration, and
- Variations and recourse vs. kill switches.
Specifications vs. Sprints
In many cases, the people writing specifications and developing budgets make something up to satisfy internal signoff requirements. Then they go and do what needs to be done. They need a provider that understands this game and will sign a contract that doesn’t reflect the actual nature of the work. I’ve seen many business functions pass around specifications that obtained relatively stress-free signoff by their legal, procurement, and finance people as the ‘winning’ template.
Rather than a specification, an agile approach has a goal. For example, “We want to onboard vendors in two days”. This is then broken down into smaller goals by the team in their early exploratory sprints.
A sprint is a timeboxed exercise (generally one to two weeks, but can be of any duration) with a specific goal. An agile project will have numerous sprints, each with its own objective and scope of work. Each sprint starts with a planning event and ends with a retrospective identifying what was accomplished, what held it back, and what could be changed to make the next sprint more productive. Productivity improvements are measured by velocity – the rate at which the teams deliver business value. Velocity starts slow, picks up speed, and then plateaus to a predictable level. The early exploratory sprints create velocity and the later sprints become delivery sprints as maximum speed is achieved.
Control vs Collaboration
An agile approach does not have deliverables that are checked off against a specification. It has a series of gates. Each gate determines the next series of sprints or kills the project. The first gate is always a discovery one. Its sole purpose is to do exploratory sprints to reduce uncertainty – obtain information, test assumptions, identify major impediments, conduct proof-of-concept, etc.
Delivery sprints attack each bite-sized goal within a fixed timeframe. If it cannot be done due to discovered impediments, then further sprints are scheduled to address these impediments, the scope is changed because the impediment cannot be, or the project is killed – whichever delivers a better outcome/value for money.
It is this constant process of impediment discovery that really needs collaborative teams. Agile involves constant dialog, negotiations, tradeoffs, and decision making. Process excellence and ethics in both parties is imperative. So is courage to challenge the status quo, and the ability to communicate. Accordingly, having the right people from both parties is, without question, the most important success ingredient. Many early sprints identify ‘wrong’ people as an early impediment and both have to be willing to get the ‘right’ ones or take the time needed to help the people in place get ‘right’. This is why velocity can take a bit of time, and if any personnel are replaced after velocity speeds up, it will drop back down.
Variations and Recourse vs. Kill Switches
Contract templates tend to require certainty, and then have recourse when it isn’t achieved. It is also assumed that what is required, and what needs to be done to achieve that outcome, is known and can be locked-in through the contract.
Agile contracts have neither recourse nor variations. A project should be killed as early as possible if it is not going to work. Often this is the first gate – to test the kill switches. Fail fast is a mantra of an agile approach. If something might not work, this is explored in an early sprint. If the entire project might not work, the first sprints determine this. The project is then either re-imagined or killed before any large expenditure is made.
Conclusion
One thing is certain, we cannot force challenging times and volatile environments into a rigid template. But we can embrace the agile concepts and create appropriate framing contracts. Agile contracts are based on a flexible but driven mindset rather than a contract-driven, power-based one. The former can maximise results in fluid environments, the latter merely intensifies the potential for conflict and failure.
