The document discusses how the London School of Economics (LSE) used Kanban principles to improve their web operations processes. It provides background on the issues they faced with high workload variability and dependencies. It then describes how they designed and implemented a Kanban system using a board to visualize workflow and limit work-in-progress. The system involved categorizing requests, tracking dependencies, and metrics to identify bottlenecks. This approach helped improve flow, reduce queue times, and collaboratively refine their processes.
4. Complex workload mix
Wide range of skills
Short deadlines
Lots of intangibles
(hard to track)
(hard to manage & improve)
Lots of external parties
LSE Kanban Case Study
Nov 2012 4
Lingaraj G J
5. The Spiral of Death
People can’t see &
understand workload
Low confidence
Make noise
(status reports, etc)
Reduced capacity
to deliver Add work
“just in case”
Context switching
Large backlog
Effort to manage
Effort to prioritise
Rework
LSE Kanban Case Study Queuing delay
Nov 2012 5
6. Kanban
Literally “signal card”
“Pull” system using signal cards to
manage the flow of work
5 Principles
Visualise the workflow
Limit WIP
Manage flow
Make process policies explicit
Improve collaboratively (using models
and experiments)
LSE Kanban Case Study
Nov 2012 6
8. Best Practice
No such thing as the perfect kanban system
Mindset:
Start where you are
Make bottlenecks visible
Evolve through experiments to eliminate bottlenecks
Kaizen
LSE Kanban Case Study
Nov 2012 8
9. Reasons for managing WIP
Surface flow issues (dependencies, capacity
limits, etc)rapidly & resolve them by:
Swarming
Adjusting policies
Raising an issue
…
Reduce queuing delays and hence:
Speed up feedback loops, so we learn and refine faster
Reduce time wasted on context switches, requirements decay, etc
Improve speed of response to requests
Kill the spiral of death
LSE Kanban Case Study
Nov 2012 9
11. Backlog Input Queue Work in Progress Output
Displaced
Done
External Analysing Ready Doing In Production Usage
Requests WIP = 3 + WIP = 1 anal. WIP = Team size + 1 + Reviewed
expedite + 2 inter-team Expedite
High WIP=3 In-House
Expedit
e
Management & Governance
Medium WIP=3 Analysis Interteam
Expedit
e
Interteam
Operations
Low
Production
Expedit
Analysis Interteam e
Interteam
Operations
Internal Design
Expedit
e
Strategy & Analysis Interteam
Interteam
Capacity Operations
Improvements Editorial
Expedit
High WIP=3 e
Analysis Interteam
Interteam
Medium Operations
WIP=3
Rich Media
Expedit
Analysis Interteam e
Low
Interteam
Operations
Agency Issues
LSE Kanban Case Study IT
Nov 2012
Client
12. Name Deadline
ID
Ownership
Originator Worker / Internal Owner
Interdependencies
Related Items
Systems / Components
Description & Notes
Also use
• Colour (Originator)
• Size (Effort estimate)
• Rotation (Blockage)
14
13. Name
Done
Doing
Timing
Ready
Stage
Backlog
Analysis
Displaced
In Production
Date &
Team
Usage Reviewed
Date
Date
Date / Team 1
Date / Team 1
Date / Team 2
15
Date / Team 2
Date / Team 2
Date / Team 1
Date / Team 1
Date / Team 1
ID
Date
Deadline
Date
14. Backlog Input Queue Work in Progress2) Finish item
Output
Displaced
Done
External Analysing Ready Doing In Production Usage
Requests WIP = 3 + WIP = 1 anal. WIP = Team size + 1 + Reviewed
expedite + 2 inter-team Expedite
High WIP=3 In-House
Expedit
e
Management & Governance
Medium WIP=3 Analysis Interteam
Expedit
e
Interteam
Operations
Low
Production
Expedit
Analysis Interteam e
Interteam
Operations
Internal Design
Expedit
e
Strategy & Analysis Interteam
Interteam
Capacity Operations
Improvements Editorial
Expedit
High WIP=3 e
Analysis Interteam
Interteam
Medium Operations
WIP=3
Rich Media
Expedit
Analysis Interteam e
Low
Interteam
Operations
Agency Issues
LSE Kanban Case Study IT
Nov 2012
Client
15. Backlog Input Queue Work in Progress4) Internal depend
Output
Displaced
Done
External Analysing Ready Doing In Production Usage
Requests WIP = 3 + WIP = 1 anal. WIP = Team size + 1 + Reviewed
expedite + 2 inter-team Expedite
High WIP=3 In-House
Expedit
e
Management & Governance
Medium WIP=3 Analysis Interteam
Expedit
e
Interteam
Operations
Low
Production
Expedit
Analysis Interteam e
Interteam
Operations
Internal Design
Expedit
e
Strategy & Analysis Interteam
Interteam
Capacity Operations
Improvements Editorial
Expedit
High WIP=3 e
Analysis Interteam
Interteam
Medium Operations
WIP=3
Rich Media
Expedit
Analysis Interteam e
Low
Interteam
Operations
Agency Issues
LSE Kanban Case Study IT
Nov 2012
Client
16. Name Deadline
ID
Timing
Date &
Team
Date / Team 2
Date / Team 2
Date / Team 1
Date / Team 1
Date / Team 1
Date / Team 2
Date / Team 1
Date / Team 1
Date
Date
Date
Date
Stage
Backlog
Awaiting Resource
Analysis
Analysis
Ready
Sign Off
Displaced
Doing
Done
In Production Working
Usage Reviewed 26
17. Metrics & Reporting
Backlog Cycle
Analysis Await Resource External Working Sign Off
Size of backlog
No of items; rough estimate of time to complete them
Cycle time versus size of work item
Min, max, average, distribution
Percent of cycle time item is
In Analysis (Ready-Analysis time)
Awaiting resources (Doing-Ready + Doing-Displaced time, across internal teams)
Being worked on internally (Done-Doing time across all internal teams)
Being worked on by external team (Done-Ready time for external teams)
Awaiting sign-off (In Production-Done time)
Throughput
No of items completed over a period, and hence average throughput
Usage
Actuals (usage statistics, satisfaction) versus targets in PD
LSE Kanban Case Study
Nov 2012 29
19. Graham Oakes Ltd
Making sense of technology…
Many organisations are caught up in the
complexity of technology and systems.
This complexity may be inherent to the
technology itself. It may be created by the pace of technology change. Or it may arise from
the surrounding process, people and governance structures.
We help untangle this complexity and define business strategies that both can be
implemented and will be adopted by people throughout the organisation and its partner
network. We then help assure delivery of implementation projects.
Clients…
Cisco Worldwide Education – Architecture and research for e-learning and educational systems
Council of Europe – Systems for monitoring compliance with international treaties; e-learning systems
Dover Harbour Board – Systems and architecture review
MessageLabs – Architecture and assurance for partner management portal
National Savings & Investments – Helped NS&I and BPO partner develop joint IS strategy
The Open University – Enterprise architecture, CRM and product development strategies
Oxfam – Content management, CRM, e-Commerce
Thames Valley Police – Internet Consultancy
Sony Computer Entertainment – Global process definition
Amnesty International, Endemol, tsoosayLabs, Vodafone, …
LSE Kanban Case Study
Nov 2012 37
Hinweis der Redaktion
Web OperationsWho here has spare capacity?
Visualize the WorkflowSo typically, we are looking for state changes in the work, that generally reflect changes in the activity used to generate new information about that work, for example, analysis (an activity) generates information, and when it reaches a point of diminishing returns, we tend to refer to the work as “analyzed” and change to a different activity to generate further information such as design or test development. It is this process of punctuated information arrival that we seek to model when I ask us to Visualize the Workflow.Make it visible so we can manage & improve itLimit WIPLimiting WIP implies that we implement a pull system on part or all of the workflow. The pull system can be a kanban system, a CONWIP system, a DBR system, or some other variant. The critical elements are that work-in-progress at each state in the workflow is limited and that new work in “pulled” into the new information discovery activity when there is available capacity within the local WIP limit.This is central, so I’ll come back to it in next slideManage FlowThe flow of work items through each state in the workflow should be monitored and reported - often referred to as Measuring Flow. By flow we mean movement. We are interested in the speed of movement and the smoothness of that movement. Ideally we want fast smooth flow. Fast smooth flow means our system is both creating value quickly, which is minimizing risk and avoiding (opportunity) cost of delay, and is also doing so in a predictable fashion.We often manage static stuff (status, size of queues) – subconscious incentive to start a lot of stuff; switch the mindset towards movement & getting things finishedFlow feels good; it lets us get a lot done – efficient & high morale state: create a positive loop of increasing throughputMake Process Policies ExplicitUntil the mechanism of software development or IT operations process is made explicit it is often hard or impossible to hold a discussion about improving it. Without an explicit understanding of how things work and how work is actually done, any discussion of problems tends to be emotional, anecdotal and subjective. With an explicit understanding it is possible to move to a more rational, empirical, objective discussion of issues. This is more likely to facilitate consensus around improvement suggestions.Again, about making it visible so we can manage and improve it – a lot of policies are hidden / don’t even realise we have themImprove Collaboratively (using models/scientific method)It is the WIP limit that ultimately stimulates conversations about process problems. Things which impede flow, or introduce perturbations that mean flow is inconsistent or ragged, often result in a challenge to the WIP limit. The team has the option to break the limit, ignore the problem and carry on, or to face up to the issue, discuss it and suggest a change.Continuous improvement; with an emphasis on measuring so we don’t fool ourselves