The document discusses Kanban and Kanban boards. It explains that Kanban boards help visualize work, limit work-in-progress, manage flow, make process policies explicit, and facilitate collaborative improvement. This contrasts with traditional project management approaches where tasks often slip and new work is unplanned and causes stress. Kanban principles aim to provide faster value to customers through continual improvement habits and early feedback from demonstrations.

1. KANBAN !=
KANBAN BOARD
22/11/2014 Sudipta Lahiri
1

2. 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

3. Kanban Boards have become
common..
22/11/2014
3

4. 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

5. 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

6. 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

7. 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

8. But… why are we doing all this?
Make Continuous
Improvement a
Habit!
• Never by happy
with where you
are!
22/11/2014
8
Faster Value to
Customer
• We exist for the
customer!
Early Feedback
• Requirements
have been weak!
• Frequent and
regular demos
 The same “drivers” for anyone wanting to do
Agile!

9. Faster value to Customer!
22/11/2014
9
 Measured by Cycle Time/Throughput

10. 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

11. 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

12. Flow
22/11/2014
12

13. 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!

14. 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!

15. 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

16. 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!

17. Early feedback/demos
22/11/2014
17
 Make this part of the value stream
Functional
Demo to
Customer

18. 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...

19. 22/11/2014
19
Sample template...

20. 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

21. KRAs to encourage “lean”
behaviour...
22/11/2014
21

22. KRAs to encourage “lean”
behaviour...
22/11/2014
22

23. 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?

24. Depth of Kanban
An approach to gradually measure and
improve your “lean” behaviour...
22/11/2014
24

25. Measuring Kanban
Implementations
 Use of “Kiveat” diagrams (Excel calls as
“radar”)
25
22/11/2014

26. 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

27. 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

28. Defining scales for
standardization
 For “Feedback Loops”
 For “Improve collaboratively, evolve
 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
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

29. SWIFT-Kanban Dev Team (Jan 2013)
29
5
8
2.5 3.5
22/11/2014

30. 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

31.  Reach me at:
@sudiptal
 slahiri@digite.com
 sudiptalahiri.wordpress.co
m
22/11/2014
31