I have worked on quite a number of Agile projects (+100) over the past few years – usually taking on the role of either Scrum Master or Product Owner.

I have worked on projects being delivered by a single team with one 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 i.e. ‘Doing Scrum’ (See: Doing Agile is a Sign of Incompetence):

Thing is… it was *so* much easier to ‘do Scrum properly’ when I had fewer products, fewer product owners and fewer commercial dependencies/constraints and no BAU to worry about.

With over 80 active products, over 80 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 remembered the words of Ken Schwaber … hoping to achieve some sense of reassurance – “A dead sheepdog is a useless sheepdog”* ().

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 (and shouldn’t) be puritanical about a process – Scrum offers guidelines, it’s a framework not a law – pick the practices that work for you and modify them / combine them with other Agile practices so as to optimise output.

First and foremost, being Agile is all about delivering the highest value product(s) in the most efficient way possible.

The challenge:

How do you maximise output and reliability within a highly unpredictable, multi-purpose* team environment with multiple product owners?

The answer:

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

Subscribe to the Agile101 RSS to be notified when I upload new Articles, Videos, Templates and Tips.