It feels like we’ve been talking about Agile for ages. Leon Tranter (the founder of Extreme Uncertainty) describes the difference between Agile and Waterfall in culinary terms, trying to cook a new dish that nobody has ever cooked before.
In a Waterfall, you might be seeking the perfect answer before you start, reading a hundred cookbooks, then writing out a long and complex recipe, cooking it for hours and hours, and then without tasting it, presenting it to your friends.
With Agile, you have a rough idea of what you are making, but maintain flexibility; you start by throwing a couple of things together and see how they are looking. Taste a little, add a bit of this, a bit of that. Taste it again to see how it has changed. Ask your friends to taste a little and see what they think. Add a bit more of this, a bit more of that, taste it again, see how it is going, adjust the seasoning, and when everyone agrees, it’s time to serve the dish (Agile style).
Agile vs. Waterfall – the main development models
These are the two primary development models being used by IT functions today; Waterfall and Agile. Agile is actually an umbrella term for several different development techniques, the most widely used of which is Scrum. But for the purposes of this blog, it’s grouped as Agile.
Waterfall development is a structured linear approach, with all requirements being clearly defined upfront, frequently in detail. The project phases commonly include planning, design, development, testing, and deployment. The approach also lends itself to structured payments against completed phases or value received at gated milestones.
With Agile, generally the planning, design, development, testing, deployment is completed in short bursts. These are known as sprints, typically lasting between 2-4 weeks. The number of sprints required for a project will depend upon the complexity and volume of requirements (known as Epics and User Stories).
Given that requirements will evolve over the course of sprints. The goal is to deliver early functionality and, thus, the ability to pivot and change requirements as you learn. Supporters would claim that this encourages a more collaborative approach between developers and business teams.
Agile is widely adopted and supported by the technology community. However, it is not without its detractors, most notably for this blog, a traditional Finance, and Procurement approach which is geared much more towards Waterfall (i.e., guaranteed deliverables for a fixed price supports planning and reduces risk).
And this is where a lot of the debate is; Agile may go against what we have (historically) considered as “best practice” in Finance and Procurement, but in the right context it offers a lot of benefits;
- Does Waterfall stifle innovation? With technology moving so fast, it can be challenging to define and lock down requirements upfront. Agile allows for innovation and new ideas during a project, also giving you something you can touch, feel, and interact with.
- Does guaranteed costs equal a guaranteed outcome? While Agile budgeting is not without its complications for planning, it is also true that many technology projects conducted under Waterfall principles see scope creep at later stages, adding both complexity and cost to projects.
- Does the sprint approach allow for better prioritization? Agile allows for evolving and ongoing prioritization of business needs and requirements. These are captured in the Product Back Log and in Epics (subsets of overall functionality of the platform/software) and Users Stories (subset functionality or individual tasks contained within Epics). By delivering incrementally, Agile ensures the business receives as much value as possible in the shortest timescales.
So Agile sounds great what’s the issue?
The main commercial challenge is that Vendors can not commit to a fixed price for a fixed set of development deliverables as the development scope/requirements is not available (in detail) pre-contract.
With so much flexibility, Agile has to be done well to turn out well. A poorly run Agile team can lack direction, struggle to articulate sprint requirements, and poorly identify outcomes and endpoints. This, in turn, leads to scope creep, late delivery, and cost overruns. An Agile project needs strong leadership and commercial oversight.
Contracting for Agile
Generally, contracting models include a sliding scale of risk, whereby the majority of risk sits with the organization, the vendor/partner, or somewhere shared in-between.
Choosing the right approach will mean weighing up the internal capability to work to Agile principles;
- The most basic form of contracting is staff augmentation, hiring people with the right skillsets for the development needs on a time and materials basis. This puts the onus on the organization to manage the overall program and agile process. Organizations who have little experience of running agile should not undertake this model.
- Cost per sprint guarantees a number of sprints are completed by a certain sized scrum team. This does not guarantee what is delivered at the end of the sprints. Again it requires tight management of the agile process to stop scope creep and ensure deliverables.
- Fixed price for fixed number of high-level User Stories. The vendor guarantees that they will deliver the User Stories. This puts the most risk on the vendor as the requirements will not have not been fully developed. In this model, it is highly likely that the vendor will instigate change control, and both parties will not obtain what they envisaged in the commercial agreement.
- Fixed Price for Fixed Deliverables. This model is most akin to the waterfall approach while allowing for the more dynamic Agile delivery style. It is most used between an organization and development partner who have been working together and understand how each organization operates.
It requires that an agreed sizing methodology is developed; it’s not appropriate to use Story Points as this has different meanings and values to different organizations and vendors. A clear understanding must be developed between the parties for sizing requirements and development efforts. A basic model could include small, medium, and large, where development efforts and number of sprints are attached to each size with appropriate commercials.
The parties also need a sizing methodology to allow for reprioritization of user stories within the overall Small, Medium, Large structure to enable flexibility for evolving business needs but ensuring commercial certainty.
Ultimately it comes down to good management
The critical consideration for an organization deciding to use Agile methodology (whatever model you use), is to ensure that there is strong program/project management. Particular attention should be paid to corralling internal resources and approvers as and when needed, having a clear definition of acceptance and defining change control procedures and any dispute resolution.
More buyers and suppliers are adopting agile, but it does need specific skills to get it right, and a certain level of understanding and commitment from Finance and Procurement, as well as Technology stakeholders. It’s essential to weigh up the pro’s and con’s of Agile and Waterfall for each specific organization before committing to one model or another, but in this day and age, any organization should be prepared to, and skill to do both.
