I recently spoke at Symbiosis University on how WCM (World Class Manufacturing) is being applied to the software industry.
World Class Manufacturing [WCM] is the collective term for the most effective methodologies and techniques to realize the objectives of: A) Products of consistent high quality B) Delivery on Time of the desired quantity and C) Product at the lowest cost. The commonly knows WCM methodologies and techniques are TPM, Kaizen, TQM, Six Sigma, JIT, and Lean Manufacturing.
This presentation shares how the software industry and been adopting many practices from the above techniques over the last decade.
4. Emergence of Agile
4
2001: Agile Manifesto
Individuals
and interactions over processes and
tools
Colocation/pair
programming
Working
software over comprehensive
documentation
Sprints:
deliverable software
Customer
collaboration over contract negotiation
Responding to change over following a plan
Plan/Scope
committed to the current Sprint
10/24/2013
11. Lean applied to Software
11
What is a “Lean” system? A system in which we:
Eliminate waste:
Focus on hand-offs, source of errors
Amplify learning; create knowledge
Defer commitment
Deliver as fast as possible
Respect people; Empower them
Build quality in; optimize whole
Improvements can happen when you can see what is
happening in the system => reduce waste
Focus on better economic outcome than better utilization
of resources
10/24/2013
12. Kanban
12
David Anderson formulated
the method
Kanban = kan ("visual") + ban
("card" or "board")
Coined by Toyota during the
late 1940s and early 1950s
and has spread to the
manufacturing industry all over
the world as a tool of Lean
Manufacturing
Kanban: signal
Used to support noncentralized "pull" production
control to gain visibility into
the process and execution
status, reduce waste (and
costs), and help
10/24/2013
13. 13
The Kanban Method:
Core Practices
Visualize the Work
Focus is on
creating a
continuously
Limit Work in Process (WIP)
improving system;
NOT on creating
Manage Flow; Establish a Cadence
the most optimal
Remove bottlenecks and improve the flow
system
Increase throughput
Map your value stream
Making invisible work, visible!
Make Process Policies Explicit
------------------------------------------------------ Improve Collaboratively, Evolve Experimentally (using
models and scientific method)
Implement Feedback Loops
10/24/2013
18. 18
The Kanban Method:
Establishing Pull (Just In Time)
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
Work on Tickets/ Transactions that are not
priority
10/24/2013
19. 19
The Kanban Method:
Limiting Work-In-Progress (WIP)
Reduce 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
10/24/2013
20. 20
The Kanban Method:
Making policies explicit
Policies are not evil
Defining policies vs QMS
A framework for common understanding across all team members
For example:
Process Flow
Input Cadence; Output Cadence
WIP Limits
Definition of “Done”
Entry and Exit Criteria (moving from one stage to another)
Handling rework
Should the card be send back on the work board OR stay in the same lane till it
is reworked?
Handling Class of Service
How to handle Expedite cards?
10/24/2013
21. 21
The Kanban Method:
Continuous Feedback with
Retrospectives
Appreciations
Let everyone write their own
points on a post-it and stick it
on the white board
What do they mean:
Puzzles
Risks
Risks: Future pitfalls that can
endanger the project,
represented by a bomb.
Actions
Puzzles: Questions for which you
have no answer, represented by
a question mark.
Appreciations: What you liked
during the previous iteration,
represented by a smiley face.
Wishes: Not improvements, but
ideas of your ideal project,
represented by a star.
Wishes
10/24/2013
23. Product Development
23
Consider keeping
WIP high here so
that you have a
large number of
options to play
with
Deferred
Commitme
nt!
Reject/
Discard
from this
lane
Don’t discard
once in this
stream!
10/24/2013
28. Kanban leading to Lean
execution
28
Goal 1: Optimize Existing Processes
Introduction of visualization and the
limiting of work-in-progress (WIP)
catalyzes change with minimal disruption
Limiting WIP and defining policies for
work prioritization brings greater focus on
quality
Policies can also address quality criteria
Keeps defect rates low.
Goal 7: Provide Transparency on the System
Design and Operation
Improved visibility builds trust with
customers/managers
Shows the effects of actions or inactions =>
improves collaboration
Limiting WIP makes lead times dependable
Goal 4: Improve Employee Satisfaction
Enables fast reprioritization to accommodate
changes in the market
Direct correlation between the WIP size,
lead time and defect rates
Creating slack in the value chain improves
responsiveness to urgent requests and bandwidth to
enable process improvement and quality
improvement
Goal 6: Simplify Prioritization
Goal 3: Improve Lead Time
Predictability
Goal 5: Provide Slack to Enable Improvement
Goal 2: Deliver with Higher Quality
Goal 8: Enables Emergence of a “High-Maturity”
Organization
Kanban reduces context switching and
pulls work at the rate the team can
complete it.
Working at a more even, predictable
As improvements are implemented, organizational
maturity improves leading to better decision making
and improved risk management
10/24/2013
Risk, managed appropriately, brings predictable
29. 29
Applying Lean to Software:
Reducing Muri and Muda
Muri (overburdening)
Overload
Overburden
Congestion
Perversity
Mura (variability in flow)
Unevenness
Imbalance
Fluctuation
Irregularity
Deviation
“Stop Starting Start
Finishing” reduces
inventory, overproduction
Focus on reducing WIP
reduces Context Switching
You don’t get the specialist
resource when you need it
People or infrastructure
Waiting for critical
information to come so that
you can start
Hidden or abrupt “new”
work
Too much variety of work
10/24/2013
(size and complexity)
35. Thank you for your time today...
35
For any questions or
clarifications, you can
reach me at:
@sudiptal
slahiri@digite.com
Join: Limited WIP Society
Bangalore/Pune Chapters
I share my experiences at:
http://www.swiftkanban.com/
blog/sudipta-lahiri
http://sudithoughts.blogspot.in/
10/24/2013
Editor's Notes
1945 to 1965: The Origins – late 1950/early 1960s - the use of “engineering” to software1965 to 1985: The Software Crisis – Cost and Budget overruns (The Mythical Man Month; OS/360 project of over 1000 people)/Fatal incidents in medical science(Therac25)/property theft1985 to 1989: Tools, discipline, formal methods, process, and professionalism were touted as silver bullets; No (single) Silver Bullet. SSAD/OOAD/Documentation/Standards1990 to 1999: Prominence of the Internet (spread of networks/web/virus/SEOs/natural lanuage translators) – growth of the user base2000 to Present: Lightweight MethodologiesTools, discipline, formal methods, process, and professionalism were touted as silver bullets
In the olden days, our focus was to write detailed specs with the hope that this was the “perfect” requirement and then put a whole bunch of process rigor to make sure that we build it right! Then, this model faltered... So, we then started focussed on a process of continuous validation with the end user to see if we are building the right product? This automatically meant that some of the best practices of software engineering to make the product right is already built in! You cannot build a huge technical debt and hope that this will come be refactored later.
Think of it as a pipeline... Anything, that slows things flowing out of the pipeline is a waste.
Map the Value Stream. A Kanban approach looks at the whole stream of work, from where it enters the scope of the team, to where it leaves. Thus typically, a Kanban system will explicitly include the transformation of work from the problem or idea, through to its release. i.e. Concept to Cash (or Consumption), or Incubate to Liquidate.Visualise the Work. A Kanban approach will make all the work as visible as possible, across the whole Value Stream. In particular, this includes the visualisation of expanding/contracting, or zooming in and out, of work items to make their value/solution, or other hierarchical relationships visible.SUDI>>> The points mentioned are particular to an electronic board. However, the visualization aspect remains important even for the manual board (as per Slide 10)Limit Work in Progress. A Kanban approach will explicitly limit work in progress. This is distinct from managing work in progress through the use if time-boxes as described by David Anderson. This absolute limiting of work in progress is what makes Kanban a pull system, rather than a very small batch push system.SUDI>>> Not clear I get it… why should limiting WIP make it a pull system?Establish a Cadence. A Kanban approach will create a natural rhythm by setting up a cadence which will help the team deliver. This will typically de-couple the input (planning and prioritization) from the output (release), allowing more freedom than the time-box, but still providing a framework to release regularly, measure performance and continuously improve. Simply put, establishing a Cadence means, establishing a regular frequency for doing things that need to be done repetitively. These could be Customer Reviews, Production Releases, Daily Team Meetings, etc.SUDI>>> I think this aspect has been significantly simplified. The whole premise that you can release regularly just because you a cadence/rhythm is not right. One needs to grouping line items in a logical way that will make a release (SCRUM like planning). a significant assumption that not just testing but test automation is happening at the same pace. Not just TDD but actual functional test case automation to make a final release.
Value Stream analysis and mapping provides a visual of where waste may be occurring. Waste is any step where no value is being added to the production or the service delivery process.
SUDI>>> Also, work on items that risk being obsolete by the time we actually take it for development…