lean lens game scenes handout v1
Post on 14-Sep-2014
70 views
DESCRIPTION
LEAN LENS is a game developed by Andrea Darabos and Bazil Arden, and shared under Creative Commons license (attribution, non-commerial re-use). The purpose of the game is to help organizations internalize different types of lean office wastes, that are there in their operations but not value-adding to their customers. The game helps to build skills in recognizing different types of wastes, to share and track waste visually and to get teams into a problem-solving mode to reduce waste eventually.TRANSCRIPT
“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
“Finding waste in your system with a Lean Lens” Agile Coaching Exchange - London 23rd July 2014
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)
“Finding waste in your system with a Lean Lens” Agile Coaching Exchange - London 23rd July 2014
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
“Finding waste in your system with a Lean Lens” Agile Coaching Exchange - London 23rd July 2014
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
Observers: all of you not acting, observe for waste.
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
● Which of the 8 wastes did you see?
● What improvements would you suggest?
(Discuss with your team)
“Finding waste in your system with a Lean Lens” Agile Coaching Exchange - London 23rd July 2014
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
“Finding waste in your system with a Lean Lens” Agile Coaching Exchange - London 23rd July 2014
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
Observers: all of you not acting, observe for waste.
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
● Which of the 8 wastes did you see?
● What improvements would you suggest?
(Discuss with your team)
“Finding waste in your system with a Lean Lens” Agile Coaching Exchange - London 23rd July 2014
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,
“Finding waste in your system with a Lean Lens” Agile Coaching Exchange - London 23rd July 2014
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
● Which of the 8 wastes did you see?
● What improvements would you suggest?
“Finding waste in your system with a Lean Lens” Agile Coaching Exchange - London 23rd July 2014
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
“Finding waste in your system with a Lean Lens” Agile Coaching Exchange - London 23rd July 2014
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
● Which of the 8 wastes did you see?
● What improvements would you suggest?
“Finding waste in your system with a Lean Lens” Agile Coaching Exchange - London 23rd July 2014
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
“Finding waste in your system with a Lean Lens” Agile Coaching Exchange - London 23rd July 2014
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
● Which of the 8 wastes did you see?
● What improvements would you suggest?
“Finding waste in your system with a Lean Lens” Agile Coaching Exchange - London 23rd July 2014
Page: 13
“Finding waste in your system with a Lean Lens” Agile Coaching Exchange - London 23rd July 2014
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,
“Finding waste in your system with a Lean Lens” Agile Coaching Exchange - London 23rd July 2014
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
● Which of the 8 wastes did you see?
● What improvements would you suggest?
“Finding waste in your system with a Lean Lens” Agile Coaching Exchange - London 23rd July 2014
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
“Finding waste in your system with a Lean Lens” Agile Coaching Exchange - London 23rd July 2014
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
● Which of the 8 wastes did you see?
● What improvements would you suggest?
“Finding waste in your system with a Lean Lens” Agile Coaching Exchange - London 23rd July 2014
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
“Finding waste in your system with a Lean Lens” Agile Coaching Exchange - London 23rd July 2014
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
“Finding waste in your system with a Lean Lens” Agile Coaching Exchange - London 23rd July 2014
Page: 20
● Which of the 8 wastes did you see?
● What improvements would you suggest?
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