Using the Spine Model to map the intended shape of the system

Context

A new pilot initiative was introduced by a senior company executive. It very quickly gridlocked as a fragmented discussion around tools. As consultants, we needed to pull people out of the detail and get them to agree on the purpose of the pilot. We got agreement on the Need and then went back down their Spine towards Tools.

Prototype Spine For Pilot

Level Description
Needs How can we measure and understand team productivity (instead of individual effort)?
  Can we satisfy the current charge-back accounting model whilst doing this?
Values Visibility
  Transparency
Principles Estimate in size, derive duration.
  Measure team throughput not individual input.
  Shared definition of “Done” across the whole team.
Practices Estimate story points before starting a story, and then again once it is completed.
  Team review of pre vs post point estimates to see what can be learned.
  Iteration + Backlog burn charts
Tools Jira (to track work items)
  Confluence Wiki (to record learnings)

Outcome

The team became more focused on the pilot’s Needs once they were made explicit, and began experimenting with different ways they could tweak the practices and tooling to make them more valuable to the team, whilst still satisfying the higher level need of management.

Their Spine Map became an artifact that was brought out at times where there was disagreement or confusion about the process.