download scaling agile – productivity versus utilisation margaret

Margaret MorganHelen Meek

Utilisation v Productivity – who gets the gold medal?

CONFIDENTIALDocument Name

About us

• Very experienced (over 25 years!) IT practitioner across all aspects of the systems lifecycle

• Over the last decade successfully using Agile to deliver business value in large and complex organisations

• Most recently with a number of large organisations to explore how they can accommodate and embrace Agile working with distributed teams

• Interested in how practices within Agile and Scrum are linked with Lean thinking and systems thinking, and in particular how these theories can influence the behaviours in large and complex organisations.

- 1 -

Margaret Morgan Helen Meek

• Experienced Project Manager with over 10 years of IT experience

• 2+ years experience in Agile organisational transformation

• Proudly a Certified Scrum Professional

• Passionate about delivering high quality outcomes, and overcoming the challenges organisations face


About us………..

Margaret Helen


Exploring the link between productivity and utilisation

The challenge of scaling up Agile in big organisations

Using the lean thinking idea of a relay race and baton to learn about the effects of focussing on utilisation

Exploring the learning from the relay race and applying it back to the challenge


Working With Large Organisations

Identify opportunities

for Agile implementation

Identify the scrum feature

team

set up the team or teams to

deliverBuild the vision

Start the product

backlog with User Stories


The Practice Model is based on local optimisation

• Many big organisations employ a practice model where specialists are managed by their practice manager

• Practice managers will not want to provide ring-fenced resources to delivery teams

• E.g. A solutions architect may be expected to work on 5 projects simultaneously

• Why does this happen?


You can’t manage what you can’t measure

Who in the audience measures productivity?

How do you measure it?

How does your organisation use this measure?

How would you measure the productivity of a design architect?


So What Really is the Problem?

Large organisations encourage local optimisation and that makes the formation of a dedicated Scrum team very difficult

Productivity is not measured effectively and so cannot be managed


Experience the challenge?

• Examples of where the utilisation problem has manifested itself– Skill shortages force sharing of SMEs across projects

– Projects don’t get off the ground because resource is not available

– Scrum Master ‘owns’ the product backlog because the BA is only 25%

– Scrum teams can’t plan effectively because key people are missing from planning sessions

– A large programme of work has decided not to scale up Agile working, citing the reason that they cannot afford to supply a full time scrum master to each scrum team.

– Have you experienced this?


Experience the challenge?

• More examples of where the utilisation problem has manifested itself

– People trying to measure Agile projects the same way on a score card - doesn't work.

– Misconception that dedicated is more expensive

– Much work in progress as Portfolio push rather than pull

– Torn priorities

– People are rewarded for individual productivity and not the team e.g. I have an 80% utilisation target set now!

– Organisation encourages specialism so people are not multi-skilled. This leads to a shortage of SMEs who then have to support many projects


The relay race – delivering the baton

What’s important, the % working time of Usain Bolt or the cycle time for the baton?

- 10 -


The relay game

• Rules• 4 person team• Equally spaced around the perimeter of the room• Be stationary when handing over the baton• You can only handle 1 baton at a time• Product owner measures start time to end time - CYCLE TIME - for each baton

delivered• Resource manager measures working time – UTILISATION – for person A – the

business analyst

• Definitions• Productivity = cycle time• Cycle time = arrival time of baton at start point to delivery at end • Utilisation = time carrying a baton/total cycle time


Results

Scenario

Baton cycle time

Average cycle time

Util-isation

Observations

1

2 B1B2B3B4

3 B1B2B3B4

4


Sample Results

Scenario

Baton cycle time

Average cycle time

Util-isation

Observations

1

2 B1B2B3B4

3 B1B2B3B4

4

Scenario

Baton cycle time

Average cycle time

Util-isation

Observations

1 60s 60s 15/60=25%

1 baton in 60s

2 B1 60s 60s 60/150=40%

but 4 batons in 2 min 30sB2 60s B3 60sB4 60s

3 B1 60s 420/4=105s

=40% 4 batons in 2 min 30sB2 90sB3 120sB4 150s

4


The Relay Game – What did we learn?

• Does it explain WHY resource managers may not be willing to provide dedicated resources to scrum teams?

• What is the effect of local optimisation?

• Is matrix management the best way to manage utilisation of people?

• What are the repercussions of a core team member working on more than one project?

• If you are working on 2 projects can you spend 50% of your time on each?

• What does this tell us about productivity and utilisation?


The Scrum Exercise


Scrum scenario

• 4 person team• Team members can only move around the room together• They have to collect and assemble a jigsaw.• Each person can only handle their own piece of jigsaw• The jigsaw should be assembled as the team progresses around the room• Start point = end point

• Product owner measures start time to end time - CYCLE TIME - for the jigsaw• Resource manager measures working time – UTILISATION – for person D – the

test analyst


Results

Scenario # Delivery timefor jigsaw

Utilisation ofTest analyst

Observations

1

2

3

4

5


The Scrum Exercise - What Did We Learn?

• What effect does local optimisation have on cycle times?

• What is the impact of local optimisation on Scrum?

• How does it compare with the impact on traditional delivery modes?

• Scrum scenario involving collaboration throughout delivery demonstrates that utilisation targets need to be about the whole scrum team, not individuals because individual (or local) optimisation has a negative effect on productivity

• What about transaction switching time?


So How Does This Help With Our Challenges?

Large organisations encourage local optimisation and that makes the formation of a dedicated Scrum team very difficult

Productivity is not measured effectively and so cannot be managed


Scaling Agile in large organisations

• The Scrum scenario demonstrated that single point utilisation is detrimental to team productivity

• What’s the impact of a missing team member from

– Daily Scrum– Sprint planning– Sprint review– Sprint retrospective

• Scrum and other Agile practices have a scientific basis for the rules laid down

• It’s important to understand why the rules are there otherwise people will break them

• As Scrum Masters and Agile coaches we must be able to explain the rationale behind the Scrum framework


More benefits from changing the utilisation model

Sustainable pace Scalability

Removal of single point

of failure

Encourage generalizing specialists

Wisdom of the team

Importance of thinking

time


Thinking time

Agile, Scrum, XP all build in thinking time

User story workshops –

iterating round the problem

Vision, themes, epics, stories

The ritual of collaborative

sprint planning Retrospective

We need thinking time to be creative and

innovative

How do you build in thinking

time to your day?


Summary

Focussing on utilisation can be a barrier to Agile working

High utilisation targets have a negative impact on team productivity

Managing utilisation is not a substitute for managing productivity

Allocating to multiple projects is detrimental to Scrum productivity

There are other benefits from having dedicated scrum teams

Thinking time is built into the Scrum framework


Q&A

Have you been thinking of any

questions?

Thank You

download scaling agile – productivity versus utilisation margaret

Documents