I have worked on quite a number of Agile projects (+100) over the past few years – usually taking on the role of either Master or Product Owner. I have worked on projects being delivered by a single team with a clear product owner. I have also worked on projects being delivered by multiple teams, who are in turn working on multiple projects… with multiple product owners. Confession: The former example is becoming an increasingly infrequent occurence.
I used to measure the success of each project (delivery process) in terms of my ability to stick to the rules of Scrum:
- A self-organising, multi-skilled team(s) with common delivery objectives
- One product owner
- No mid-sprint interruptions (e.g. Business-critical fixes, Quick-response commercial deals)
- Barely-sufficient documentation (just enough – not too much/too little)
- The highest-priority/highest-value deliverables early on
Thing is… it was *so* much easier to ‘do Scrum properly’ when I had fewer products, fewer product owners and fewer commercial dependencies/constraints. With over 80 active products, over 100 product owners, over 800 internal stakeholders, a team of +/-70 and a product roadmap to boot… it is becoming increasingly impossible to ‘do Scrum properly’.
Unprepared to give up on Scrum, I have been mulling over the words of Ken Schwaber … hoping to achieve some sense of reassurance – “A dead sheepdog is a useless sheepdog”* (Agile Project Management with Scrum).
Ken describes a Scrum master as a sheepdog – someone who herds the team, protects the team and ‘the rules’ of Scrum. Despite being one of the founding fathers of Scrum, even Ken accepts that there are times when a compromise is the only logical/possible option.
You don’t need to *always* be puritanical about a process – Scrum offers guidelines – pick the practices that work for you and modify them / combine them with other Agile practices so as to optimise output. First and foremost, the priority is to deliver the highest value product(s) in the most efficient way possible.
How do you maximise output and reliability within a highly unpredictable, multi-purpose* team environment with multiple product owners?
Scrum + Lean + Agile Programme Management
How does this work in practice?
- The stories/projects/epics that can be delivered in line with ‘proper Scrum’ are delivered this way
- A differentiation between firm and stretch tasks manages expectations re: output and offers flexibility
- A percentage of sprint capacity (in story points) can be dedicated to JIT/Lean development
- All output is represented within one sprint burndown/burnup chart
- All output is estimated in points, allowing for velocity tracking
- Scrum task boards are used to track sprint progress
- Epic boards are used to track programme-level progress across sprints/teams
- Scrums take place in front of the task board(s)
- Scrum-of-scrums take place in front of the Epic board(s)
- Custom Agile Programme Management tools are used to produce burndowns, task cards, epic cards etc.
* Multi-purpose team – a team responsible for delivering Business-As-Usual (BAU) activities alongside Product Development activities
- Combining agile development with customer development (startuplessonslearned.blogspot.com)
- Scrum-It’s not about completing the sprint (devlicio.us)
- Book Review – Agile Project Management with Scrum (digital-constructions.com)