KANBAN != KANBAN BOARD Sudipta Lahiri 22/11/2014 1
KANBAN !=
KANBAN BOARD
Sudipta Lahiri22/11/2014
1
About me
25 years in the industry
Agile/Lean practitioner (75%)
Development of SwiftKanban and
SwiftALM products
Lean implementations of our products
Agile/Lean Coach (25%)
Run the LimitedWIP Societies in India
22/11/2014
2
Kanban Boards have become
common..
22/11/2014
3
Why? Lets see what happened
traditionally…
Project Managers do scope/work decomposition and assign tasks to people
Typically, done in a very deterministic manner
We make a MS Project schedule; gives a planned end date
Tasks start slipping
Multiple reasons: some in control of project team and some not...
Unscheduled tasks start coming in
Some anticipated and some unanticipated...
Defects: you don’t know how many will come and their flow
New RFPs/CRs that need to be estimated that may or may not ever fructify
Some visible to the Project manager and some not...
These get assigned to people who are already behind
Team members try to juggle between what is planned (and kept on schedule) + new arrivals!
In most cases, people avoid re-prioritization (you can’t do it for every incremental piece)
As a result:
Planned tasks start slipping
Quality drops because people multi-tasking and context switching
Management asks questions but very difficult to justify and show the problem!
Teams works in a reactive mode (as opposed to a planned proactive manner)
Team feels there is no time to breathe... the pressure seems endless!
4
22/11/2014
How a “Board” changes this?
Shows all work items, their current state of progress and the people who are on it
Work items move forward as they progress!
Brings out many “hidden” things that people are working on
Makes it obvious where work is getting piled up to everyone
You will see this when we show this in a fast simulation model
Colors help you visualize the pattern of work
For e.g., are you doing more value enhancement work or more rework?
Help collaborate between the project team:
Everyone knows what others are working on
If someone needs help, they can “block” without escalation/follow-up
If someone is overloaded, others in the team can respond
Provide for additional social tools to collaborate within project team
Chat/Threaded Discussions
All this can be done even for a Waterfall project!
5
22/11/2014
But... the board was just the
start!
22/11/2014
6
The 6 principles of Kanban: Visualize the Work
Map your value stream
Making invisible work, visible!
Limit Work in Process (WIP)
Manage Flow; Establish a Cadence Remove bottlenecks and improve the flow
Increase throughput
Make Process Policies Explicit
Improve Collaboratively, Evolve Experimentally (using models and scientific method) Implement Feedback Loops
Kanban’s objective:
Kanban is meant to be adaptive capability for
evolutionary change
Not a process definition or a framework to be
tailored
Drive to a culture of Continuous
Improvement
7
22/11/2014
But… why are we doing all this?
22/11/2014
8
The same “drivers” for anyone wanting to do
Agile!
Faster Value to Customer
• We exist for the customer!
Early Feedback
• Requirements have been weak!
• Frequent and regular demos
Make Continuous Improvement a
Habit!
• Never by happy with where you are!
Faster value to Customer!
22/11/2014
9
Measured by Cycle Time/Throughput
How to get there?
22/11/2014
10
With Kanban principles of Pull and WIP reduction
resulting in Flow
Defining Requirements that are small and
independent
Moving forward to make Regression testing faster
Let’s talk about these in the next few slides
Lean principles for “faster” value to
customer:
We don’t want to build features that nobody needs right now Write more specs than we
can code
Write more code than we can test
Test more code than we can deploy
Implemented with “buffer” lanes at hand-off points
Reduces multi-tasking Prevent context
switching Performing tasks one-
at-a-time yields results sooner
Maximizes throughput
Enhances teamwork Working together to
make things done Increase cross-
functionality 22/11/2014
11
Pull based execution Limit WIP
Flow
Flow
22/11/2014
12
Defining Requirements
22/11/2014
13
Agile teams that are used to User Stories (in the true spirit) don’t have this issue
For the rest of the community, defining Requirements using the “INVEST” model is a huge challenge:
We are used to a Scope Decomposition OR a Task Decomposition OR a combination of both
Sometimes, its a process drives work decomposition
Breaking them into small independent requirements is almost mission impossible!
User Story
22/11/2014
14
User story has a lot more context and significance than just small, independent requirements
If you have a well defined Requirement document from the customer, then trying to fit this in the User Story format is not most appropriate
However, you still do need to try and break this up into small independent requirements! Use methods like “User Story Mapping”
If you have decomposed the Requirement in a traditional manner, trying to decompose them as per the INVEST approach is near impossible! Start fresh!
Making regression faster!
Manual testing not an option!
TFIRSTDD is utopia...
The significance of “Testing” pyramid
Try hard not to land up with a “Inverted Testing” pyramid
22/11/2014
15
The key drivers... revisited
22/11/2014
16
Faster Value to Customer
• We exist for the customer!
Early Feedback
• Frequent and regular demos
Make Continuous Improvement a
Habit!
• Never by happy with where you are!
Early feedback/demos
22/11/2014
17
Make this part of the value stream
Functional
Demo to
Customer
Make Continuous Improvement a
habit!
22/11/2014
18
Involve the team; don’t make a Project
Manager only effort
Retrospectives, Retrospectives and
Retrospectives!
Templates abound...
22/11/2014
19
Sample template...
Our weakness
22/11/2014
20
Unfortunately, very little happens between
each retrospective
Slowly people lose faith in the retrospectives
Many causes are linked to organizational
issues and hence, beyond control
KRAs to encourage “lean”
behaviour...
22/11/2014
21
KRAs to encourage “lean”
behaviour...
22/11/2014
22
Having discussed the key
drivers...
22/11/2014
23
Faster Value to Customer
• We exist for the customer!
Early Feedback
• Frequent and regular demos
Make Continuous Improvement a
Habit!
• Never by happy with where you are!
... how do we figure where we are in this journey?
An approach to gradually measure and
improve your “lean” behaviour...
Depth of Kanban
22/11/2014
24
Measuring Kanban
Implementations
Use of “Kiveat” diagrams (Excel calls as
“radar”)
25
22/11/2014
Defining scales for
standardization For “Visualization”
Visualizing all Work elements
Of different Work Item Types
Workflow
Kanban Limits
Ready for pull ("done")
Blocking issues (special cause variations)
Capacity Allocation
Metrics-related aspects such as - lead time, local cycle time, SLA target
Inter-work item dependency (incl hierarchical, parent child dependency)
Inter-workflow dependency
Other risk dimensions - cost of delay (function shape & order of magnitude), technical risk, market risk
Score 1 for each aspect of visualization
For “Limit WIP:
Deferred commitment & dynamic staff assignment (no WIP limits) aka “last responsible moment”
Proto-kanban
Personal Kanban
WIP limit per person
workflow with infinite limits on "done" queues
Single workflow full pull system with WIP limits
Multiple interdependent workflows with pull system
Simple taxonomy of 4
26
22/11/2014
Defining scales for
standardization For “Manage Flow”
Daily meetings
Cumulative Flow Diagrams
Delivery rate (velocity/throughput)
control chart
SLA or lead time target
Flexible staff allocation or
swarming behaviour
Deferred pull decisions, or
dynamic prioritization
Metrics for assessing flow such as
number of days blocked, lead time
efficiency
Score 1 for each technique in
use
For “Make Policies
Explicit”
Workflow/Kanban System
policies explicit
Pull criteria (definition of
done, exit criteria)
Capacity allocation
Queue replenishment
Classes of service
Staff allocation / work
assignments
Score 1 for each aspect
made explicit
27
22/11/2014
Defining scales for
standardization For “Feedback Loops”
How many of the Kanban Kata are present?
Regular team meeting (typically daily) in front of
board or kanban system software
Mentor-mentee relationship between superior
and subordinate used to coach management
and
continuous improvement
Operations Review - business unit or
organization level, qualitative & quantitative
review of data from multiple kanban systems
to provide inter-workflow feedback
mechanism
Simple taxonomy of 3 (it is currently
assumed Ops Review does not exist without
a mentor-mentee relationship already
existing) Score 1 for each technique in use
For “Improve collaboratively, evolve
experimentally”
Evidence of local process evolution -
changes to workflow, policies, WIP limits
Evidence of increasing depth of Kanban
implementation on other 5 practices
Evidence that process evolution was model-
driven -use of metrics, identification of
bottlenecks, common/ special cause
variation, transaction/coordination costs,
other models not specified in current
literature
Evidence of process or management policy
evolution as a result of mentor-mentee
relationship
Evidence of inter-workflow process or
management policy evolution as a result of
operations review
Taxonomy of 5 (assumed there is an
adoption sequence & that 5 would not
happen before 4)
28
22/11/2014
SWIFT-Kanban Dev Team (Jan 2013)
29
5
3.52.5
8
22/11/2014
In closing...
22/11/2014
30
The benefits of Kanban don’t end with a Board
Use the Board to gain all the benefits of
transparency and visualization...
Continue the journey for simpler and “lean(er)”
execution
Reduce WIP, multi-tasking
Inducing pull and flow (vs) bottlenecks/working in
batches
Early feedback and faster value to customer
Reach me at:
@sudiptal
sudiptalahiri.wordpress.co
m
22/11/2014
31