LEAN LENS Game Scenes Handout v1

“Finding waste in your system with a Lean Lens” Agile Coaching Exchange - London 23rd July 2014

Page: 1

Finding Waste in Your System With a Lean Lens

A game developed by Bazil Arden and Andrea Darabos,

CC Creative Commons 2014.

Act 1: Planning - Scene 1: Budgeting

Act 1: Planning - Scene 1: Budgeting - Hints

Act 1: Planning - Scene 2: Stakeholders who can’t agree

Act 1: Planning - Scene 2: Stakeholders who can’t agree - Hints

Act 1: Planning - Scene 3: Large batch sizes of features

Act 1: Planning - Scene 3: Large batch sizes of features - Hints

Act 2: Development - Scene 1: Delegating to the development team

Act 2: Development - Scene 1: Delegating to the development team - Hints

Act 2: Development - Scene 2: Developers and testers working separately

Act 2: Development - Scene 2: Developers and testers working separately - Hints

Act 2: Development - Scene 3: Finding bugs manually - work queuing for the tester

Act 2: Development - Act.2: Work queuing for the tester - Hints

Act 3 - Deployment - Scene 1: Batching up a release

Act 3 - Deployment - Scene 1: Batching up a release - Hints

Act 3 - Deployment - Scene 2: The Deployment Process

Act 3 - Deployment - Scene 2: The Deployment Process - Hints

Act 3 - Deployment - Scene 3: Unpredictable support demand

Act 3 - Deployment - Scene 3: Unpredictable support demand - Hints


Page: 2

Act 1: Planning - Scene 1: Budgeting

Characters:

3 decision makers: CFO, CMO, CTO

Observers: all of you not acting, observe for waste.

Scenario Set-up:

A meeting room - the annual budgeting discussions are under way... there are business cases

strewn across the table..

● CMO has some new products and features that need to go to market

● CTO has to try and get some money to invest in environments and automation (non-

functional work)

● CFO will only provide money to ‘well structured’ business plans - with a net present

value (NPV) calculation going up to 2019.

○ The budgeting process is carefully choreographed and takes 5 months to

conclude

○ Has to keep a lid on the £5 million spend, this is 5% lower than last year.

● There is some quizzical comments and jokes about assumptions and how a few of the

business plans appear wildly optimistic.

Observers

● Which of the 8 wastes did you see?

● What improvements would you suggest? (Discuss with your entire team)


Page: 3

Act 1: Planning - Scene 1: Budgeting - Hints

Messages:

● Project-centric approach leads to early decisions on scope and priority.

● Creates too much organisational WIP - for example once the organisation has ‘green

lighted’ 5 projects - they all begin to consume attention, whilst keen stakeholders want

their project started ASAP

● Reference 'Beyond Budgeting' by Bjarte Bogsnes see http://www.bbrt.co.uk/

Waste

● WIP > Partially done work and

● Budgeting requires business cases and a form of contracting > fixed scope and Extra

features

● Budgeting requires documentation >

● Done ahead of time - with little ability to change direction > Extra features


Page: 4

Act 1: Planning - Scene 2: Stakeholders who can’t agree

Characters:

● Three product managers:

○ A) has new search and navigation to add to the site

○ B) want to gather more analytics on which parts of the site are actually being

used

○ C) Insists that a new couponing process is needed to match the competition

● An embattled Project manager

● A technical lead


Scenario

● Stakeholders have gathered to discuss how much of the fixed budget they are going to

get… After some discussion, Each of them leaves with a green light for their project.

● But they still can’t decide how to prioritise the projects

Discussion:

● Each argues for their project… and why it should go first.. Their stakeholders won’t

accept anything less - and the market conditions mean that they each have a good case

for their project

● The PM and tech lead effectively have to arbitrate between which project goes first…

they ask all the sorts of questions you’d expect… but eventually decide to start all three

projects… even though it involves ‘sharing’ a key technical ‘resource’ (aka person)

across the three projects.

● Each project is allocated an ‘effective’ PM - who knows how to get the work done… and

is determined not to tarnish their reputation now.

Observers


● What improvements would you suggest?

(Discuss with your team)


Page: 5

Act 1: Planning - Scene 2: Stakeholders who can’t agree - Hints

Messages

● The wrong people (technical and PMs) are having to decide which project goes first -

not because they want to.. but because ‘the business’ couldn’t decide amongst

themselves and therefore passed the decision down to the person who couldn’t pass it

any further

● The business is not working on the highest cost of delay functionality

● There is lots of unnecessary WIP created in the system

● The technical specialist is task switching, it’s difficult to hold him accountable as he

always has the ideal ‘excuse’ - “I was working on the other project”

Waste

● Too much WIP Is created by green-lighting each of the projects > Task Switching,

Partially done work.

● The single specialist resource shuttles between projects > Delays, Task Switching

● Having argued hard for the project, stakeholders feel obliged to deliver every feature in

the business case > Extra Features

● Time is wasted horse-trading between the Product Managers > Delays, Extra

processes, Handoffs


Page: 6

Act 1: Planning - Scene 3: Large batch sizes of features

Characters:

● Product Manager for the new couponing project

● The tech lead,

● The project manager and

● A solutions architect


Scenario set-up:

● The medium/large ‘couponing’ project is being presented to the team by the product

manager - who is full of ideas and keeps bouncing between one set of couponing

options and the other..

● The team are asking clarification questions - and are pushing back a little, trying to get

some guidance on what is priority.

● The Product manager, is very reluctant to say that one piece is less important than

another - in case the less important bit doesn’t get done. He has trouble seeing the

benefits of slicing the project down and focusing on the highest value slices.

Scenario Discussion

● The product manager talks through 4 different coupon types, and which competitor is

using them, these include:

○ Buy one get one free (BOGOF), 3 for the price of 2, this month’s featured recipe

and the Mother’s day voucher

● The solution architect wants to know all the details of each couponing type - so that he

can design the ‘right’ architecture, that’s ‘future proof’

● The assumption amongst everyone at the meeting is that the whole project has been

signed off by the governance board - and so it must all be delivered asap… even though

Mother’s day isn’t for another 10 months

Observers



(Discuss with your team)


Page: 7

Act 1: Planning - Scene 3: Large batch sizes of features - Hints

Messages:

● By treating projects as monolithic we artificially make high-value elements dependent on

other features that are of lower value.

● Our projects contain many assumptions about how those coupons will drive traffic.

These ‘unvalidated assumptions’ contain both risk and cost - we should validate them

ASAP (Lean Startup)

● By kicking off the whole project - rather than just the highest priority slice - we have

delayed when the value will be delivered to users. We have also delayed learning from

actual users, which we might have been able to incorporate into later slices of our

solution.

● We have also delayed possible alternative higher priority work somewhere else.

● Large batchsizes of work can clog up the system, generating high WIP and slowing

throughput

Waste

● Building features we may not need… and then having to maintain them > Extra features

● Have delayed delivering value to users - and so have lost money - the ‘cost of delay’ >

Delay

● Created elements of architecture that we might not need - or may prove to be wrong

when we come to use them. > Defects

● We were not able to learn from the first slice of functionality and improve the subsequent

architecture > Delay,


Page: 8

Act 2: Development - Scene 1: Delegating to the development

team

Scenario:

● A developer is working busily - he has several pieces of work on the go for one of the

PMs - when another PM sidles up and asks for a ‘favour’ to try and fix some integration

problem that has emerged overnight..

● A developer sits in the corner - working quietly on something he was given a few days

ago.. he’s not convinced it’s the most valuable use of his time - but he’s learned to keep

his head down and do what he’s been ‘told to do’

● The developer has also done some work that is waiting to be tested - he told this to the

PM yesterday - but he notices it still hasn’t been any testing done on it - he wonders

vaguely when it will be tested and by who.. if he knew he might be able to tell them

about a quirk he found whilst coding.

Characters:

● Two PMs

● A specialist developer of one of the underlying 3rd Party systems

Discussion

● PM_1 asks the developer to do some work on a couple of requirements in his project.

● The developer points out that he already has more than enough work for this week

● PM_1 has little visibility of what’s the WIP and lead time in the development team

● PM_2 checks in to see when his work is likely to be finished.

● PM_1 asks PM_2 aside for a quick private chat about priorities

● The developer realises he doesn’t have any acceptance criteria for the task he’s working

on and asks PM_1 to ask the stakeholder a question

Observers




Page: 9

Act 2: Development - Scene 1: Delegating to the development team - Hints

Messages:

● The complexity of software development is best addressed through self-organising

teams, close to the work and able to adapt to the dynamic situation. Sending decisions

up and down a PM hierarchy delays things and is too rigid

● Communicating with the business via a PM adds delay and necessitates documentation

and unnecessary handoffs

● Having PMs and their reputations at stake leads to significant sub-optimal behaviour - as

very few can see, or care about,the system-level behaviours.

Waste

● Longer communication lines, require more documentation> Delay, Handoffs and

Relearning

● Waiting for decisions and the next package of work > Delays

● Responding to multiple Project Managers > Task switching

● Delegating work packages to different people > Handoffs and delays


Page: 10

Act 2: Development - Scene 2: Developers and testers working

separately

Scenario:

The developers and testers regard themselves as separate teams, performing different roles

within the software development process. This has lead to typical behaviours of untested code

being handed over the wall, testers incentivised to find bugs - the two groups don’t often

socialise together and actually have quite a low opinion of the other group.

Characters:

● 2 x developers

● 2 x testers

● 1 x project manager

Discussion

● Developers are working hard creating code. The documentation doesn’t always appear

to be correct - so they only really code to the requirements and acceptance criteria that

they understand.

● Meanwhile the testers are trying to work out how to test the elements of the software.

Because they are in different teams they are not always working on the same pieces of

work.

● Testers are finding ‘bugs’ - but they can’t always convince the developers that these are

indeed bugs - because the documentation is open to interpretation.

● Meanwhile the PM is shuttling to and fro between the two groups. The morning bug

triaging session often rambles on and can get quite tetchy - with the PM having to act as

decision maker

● The PM also has to keep the bug tracker metrics up-to-date and so keeps asking the

testers to update the tool

Observers




Page: 11

Act 2: Development - Scene 2: Developers and testers working separately -

Hints

Messages:

● Anything that leads developers to believe that quality is someone else’s responsibility is

going to create delay and problems of accountability

● Finding bugs quickly, preferably with automation, has a huge impact on the cost it takes

to fix the bugs

● If both developers are testers are having to derive their understanding from reading the

documentation, rather than through conversation and clear acceptance criteria - then

they are often going to be working towards slightly different goals.

Waste

● Delays in finding bugs > Delay

● Moving work between elements of the same value adding process > Extra processes,

Delay, Defects, Handoffs

● Distance between developers and testers can easily lead to ‘gold plating’ the

development > Extra features

● Not knowing for sure whether the work that has just been coded is good enough >

Partially done work


Page: 12

Act 2: Development - Scene 3: Finding bugs manually - work

queuing for the tester

Scenario:

● The tester is sitting a little away from the developers.

● She doesn’t have much automated test experience and is trying to keep up with the

developers.

● She has some clarification questions about the tests she is supposed to be doing. It

turns out that not all the acceptance criteria were completed in the requirements that

were taken into the last phase of development. It’s not clear which project she should be

working on.. as she’s got work to test from two separate streams of work.

● The developers don’t appear to care too much about her predicament - they’re too busy

coding

Characters:

● The tester and her more junior colleague

● A business person who has a monthly status meeting to update

● A developer - who can’t finish something until another developer’s work has been tested.

Discussion

● Tester looks up from her desk to see the business person, wanting to know when a

piece of work will be in UAT so she can see it on her machine

● Whilst talking - the tester asks her for some clarity on a test she’s about to start - but the

business person says she doesn’t have time to answer that at the moment

● Finally it’s clear to the tester that she needs to work on a different piece of work than she

was planning on today - and she finally gets down to it

● Just as the first tester starts to work, a developer comes over and asks the junior

colleague a question - which she can’t answer. She interrupts the senior tester with a

question..

● The business person returns to ask how much testing is left to do… the tester doesn’t

know.. because ….

● The scene continues from there…

Observers




Page: 13


Page: 14

Act 2: Development - Act.2: Work queuing for the tester - Hints

Messages:

● Manual testing can never keep up with the pace of Agile development.

● It’s difficult to see the work waiting for testing - unless it can be visualised or somehow

shared within the team

● Not being able to see the queue of work means that it’s difficult to improve the way the

system is behaving - and we end up trying to improve at a suboptimal level

●

Waste

● Delay in getting feedback to developers > Delay

● Too much testing in the queue with questions from stakeholders > Task switching,

Extra process

● Doing repetitive work manually, rather than automated > Extra process, Defects, Delay

● Waiting for clarification of acceptance criteria from the business > Delay

● Moving work from developers to testers and back again > Handoffs

● Testers could be focusing on their higher value adding work, and not the repeated

running of scripts > Unused skills

● Not knowing whether work is ‘done, done’ - i.e can be shipped and deliver value to end

users.. > Partially done work,


Page: 15

Act 3 - Deployment - Scene 1: Batching up a release

Scenario:

● Releases are costly and a little risky - so operations have agreed to do them once a

quarter.. As a result developers and the business need to try and group their

functionality into releases. There is some debate between stakeholders about what

should go into a release, as it will be quite a while to the next one.

Characters:

● Release manager, - runs the daily release planning meetings to decide which

requirements are deemed ready enough to go live.

● Operations manager - responsible for the final UAT environment and the gatekeeper on

what can go live - as his team have to support it

● Stakeholder who has been promised two minor but important fixes to a live issue.

Discussion

● One of the elements of the release has a dependency on another element that has fallen

behind - and so there is real debate about whether it can go live. (This is mainly due to

the component-team, rather than feature-team approach that the company has

adopted…

● There is some contention in the UAT environment, with two streams of work needing

their time in there in order to be able to make the release - however, the stream of work

that got into UAT first has not got stuck, trying to fix a particularly gnarly issue

● Meanwhile, a couple of smallish but important fixes are stuck in the integration

environment - behind both of the larger projects.

● The release manager is becoming a little stressed..

Observers




Page: 16

Act 3 - Deployment - Scene 1: Batching up a release - Hints

Messages:

● A tension existed between two parts of the organisation with very disparate aims for

many years..

○ Developers (and the business) want to get as much new stuff into live as

possible - whilst operations (and the business!) want the production

environments to be as reliable and available as possible.

● Releases have meant risk and expense - businesses have naturally wanted to reduce

the cost and risk of multiple releases.

● It’s more difficult for them to see the waste and risk of having masses of undeployed and

/ or untested code in the pipeline.

● The ‘cost of delay’ is a useful way to begin to quantify the cost to the business of

infrequent batched releases.

● Paradoxically, more frequent releases combined with automation, reduces both the risk

and the cost of releasing - which is why companies like Amazon, Facebook and Flickr

deploy to production many times a day.

Waste

● Batching releases means that software, that could be in the hands of users, delivering

value and feedback to the organisation, just sits on the shelf > Delay, Extra Processes,

Partially Done work (where ‘done’ means live and being used)

● Small, possibly higher value functionality, gets stuck behind bigger projects > Delays,

Extra processes

● Bigger batches tend to need more process, documentation >Extra process, Handoffs


Page: 17

Act 3 - Deployment - Scene 2: The Deployment Process

Scenario:

● Releasing into production has become an overnight process, with many manual scripts

and configuration changes.

● The ‘like-live’ environment has been allowed to get slightly out of date and no longer has

the same architecture as the production environment.

● It’s looking like another long weekend ahead of them..

Characters:

● Operations lead

● Configuration and deployment engineer.

● Developer (at the end of a phone)

● Project Manager

Discussion

● The two operations engineers are trying to read the hastily typed release notes that were

emailed through at 6:30, just before the lead Developer left for a camping weekend.

● There is a reference to a port setting that they don’t recognise or appear to have the

rights to change.

● They decide to call the tech lead at his home. 45 minutes of screen sharing and phone

call and the developer decides it’s necessary for him to go back into the office

● The engineers review the settings in the like-life environment to see what they can learn.

● Meanwhile they start on the laborious process of making changes to the live system in

readiness for the deployment. It’s all a bit tense.

● The ‘go or no-go’ meeting is approaching… and they know they’ll need lots of evidence if

they are to convince the unhappy project manager to not go live…

● Even with the with the evidence they gathered - they can’t postpone the deployment -

and they continue working with the Developer - and doing their manual deployment.

Observers




Page: 18

Act 3 - Deployment - Scene 2: The Deployment Process - Hints

Messages:

● Manual deployments are expensive and risky - and so companies try to do them less

frequently…

● The handoff between developers and operations is often one of the biggest

organisational chasms, down which much knowledge is lost

● The DevOps ‘movement’ is trying to address this problem from a ways of working, and

tooling

●

Waste

● Waiting until a suitable deployment window >Delay, Extra process

● Reading the manually written instructions > Extra process, Handoffs,

● Calling up the developer and getting him in > Delay, Extra process

● Doing everything manually >Delay, Unused skills

● Gathering data for the ‘go no-go’ meeting > Extra process

● It’s difficult to get dull manual processes perfect every time > Defects


Page: 19

Act 3 - Deployment - Scene 3: Unpredictable support demand

Scenario:

● A few level 3 support engineers sit at their desks, many with headphones on. It’s been

another frustrating week as, on top of the regular work, a new deployment has just gone

live and is generating a lot of support calls.

● The team is increasingly convinced that most of these support calls should have been

picked up by the Level 2 support, and not even come through to them as Level 3

● The incident-tracking system is rarely filled in completely - and the acceptance criteria

field on the bugs is almost always blank.

● The developers have moved onto the next project and it’s difficult to get their time, even

though they’re only on the floor above.

● In the absence of any objective prioritising process the team is left at the mercy of

Project Managers coming over and asking whether they’ve started work on their

particular bug, and when it will be fixed.

● Fixing the bug turns is just the first part of the problem - getting it re-tested and then

deployed appears to be the real problem - it’s not clear who is responsible for that bit.

Characters:

● Two support engineers

● A Project manager

● A tester

Discussion

● One of the support engineers sits staring at a bug report - not knowing where to start.

When he asks his colleague they are both left wondering who to contact in the

development team to understand how the system is supposed to work.

● Whilst in their discussion - the PM comes over and asks very politely, when they think it

will be done. They ask him for help to find out what ‘done’ actually means in this case. …

he says he’ll get back to them - as he doesn’t really know more than this is a P2 severity

bug in the system.

● The PM attends a bi-weekly triage meeting and finds himself often debating with othes

whether this is a L2 or L3 support issue.

● L3 issues are often taken straight to the developers - where they have some sort of

special ‘bug’ status requiring developers to stop what they are working on and help. This

is largely driven by the 3 day SLA (Service Level Agreement) on L3 bugs..

Observers


Page: 20



Act 3 - Deployment - Scene 3: Unpredictable support demand - Hints

Messages:

● Support issues often disrupt any software development processes - the solutions will be

situation-specific. Whether to have separate teams or allocate capacity of development

teams

● Having developers wash the hands of a deployment once it goes live - and not feel the

responsibility (pain) of supporting it for a few weeks, means they may not care as much

as they should about quality

● Separate support teams often sit away from developers and don’t share the detailed

information on a project.

Waste

● Interruption of L3 > Task switching

● L2 & L3 debates and lack of clarity > Extra processes

● Having a separate support team > Handoffs, Delays (waiting for developers to answer

questions) and Defects

LEAN LENS Game Scenes Handout v1

Business

Transcript of LEAN LENS Game Scenes Handout v1