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
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
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!
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...
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
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
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
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
Editor's Notes
Visualize: 8 (we don’t do Inter Workflow Dependency) and Other Risk Dimensions
Limit WIP: 4 (we don’t do Person WIP; else, we do everything)
Manage Flow: 3.5 (While we get all the data, we have typically not focussed beyond Lead Time). We should add reduction in Wait Time and Block Time by 20% as BSC Criteria
Explicit Policies: 2.5 (We have documented policies against the project, using comments at the project level) – more for operation rules! However, these are not visible and we should add a feature to do so
Feedback Loops: 1 (only at Team level)
Improvements: Not there yet!
