Agile for procurement

ZXm recognise that a new procurement and contractual framework was needed, one that would:

• Decrease the handovers between project management, finance and legal
• Reduce the time to engage a vendor to maximise the time given to delivery.
• Reduce upfront work needed to define the requirements.
• Create clear instructions to the vendor regarding delivery expectations.
• Be as rigorous, robust and low-risk as the current approach.

Scrum as a contractual framework

ZXM recognised that the organisation used agile to deliver and support many of its IT products and felt their familiarity with Scrum could be leveraged.

A new contractual framework was written around Scrum’s events, artefacts and roles. This detailed how the organisation and the vendor would collaborate to deliver the outcome without needing to be explicit as to the detail of the requirements.

A cross-functional, agile procurement team

ZXM brought project management, procurement and legal together with the business area and IT leadership in a Daily Scrum to assess progress toward defining the contract and impediments that were slowing things down.

We set goals each week, planned them and then reviewed the outcome at the end of the Sprint. This gave the team the following benefits:

• Identified key areas of the contract that needed to be produced as we worked.
• Worked through smaller batches of work and not only saw results faster but also gained feedback from others in the team faster.
• People had greater transparency of what was missing in the contract to form a minimal viable product – high quality, robust and low risk, but minimal and sufficient to go to market.
• Sign-off didn’t result in handovers and delays as those responsible for sign-off were part of the team.

Contracted Sprint Goals and the Product Backlog

The contract specified the wider scope and vision of the project, and used the Product Backlog as the backbone of the project with explicit statements that this would evolve over time. Sprint Planning and Sprint Goals formed the mechanism to produce a Statement of Work each Sprint. This was signed-off by the organisation’s Product Owner as representing value and the Development Team would then start delivering.

This turned each Sprint into a small contract with the focus on an outcome and Goal within a fixed timeframe (2-weeks). Throughout the Sprint, the vendor was expected to refine the items in the Product Backlog so that they were ready to be delivered in the following Sprint.

Contracted Quality

The Definition of Done provided a contracted level of quality from the vendor, outlining what documentation was needed each Sprint, what kinds of testing was required, architectural standards to adhere to, non-functional requirements including accessibility and usability, and what level of defects were acceptable. Annexes to the contract provided specific detail regarding defect definition

Costing Sprints and the Outcome

In terms of responding to the tender, a cost per Sprint was requested with an outline of the people, their skills and capability, brought to the Development Team. People responding to the tender were asked to use specification by example as the basis for their costing and time forecasts. That is, vendors were asked to compare the outcomes the organisation sought to previous projects the vendor had delivered in the past.