This is a presentation that I did for a team to introduce them to Agile, Lean and Kanban, It covers these these 3 areas, how they overlap and then gets into greater details about the Kanban Method.
2. Let’s bust some myths first...
2
Agile methods are NOT:
You can get temporary speed... but not sustainable
Speed needs much more discipline that otherwise!
Sloppy
Whatever-you-want-to-do
No-questions-asked, no-managers or no-dates
Compressing schedule
Throwing out documentation
Coding till the last minute
Think Formula One racing!
Agile teams need testers... with strong testing skills
12/10/2013
8. Emergence of Agile
8
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
12/10/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
Think of it as a pipeline... Anything, that slows things flowing out of
the pipeline is a waste
12/10/2013
12. A different balancing act...
12
Cost
(resources)
Time
Scope
Agile software
development
Traditional
software
development
Time
Cost
(resources)
Scope
(Target business
goals & outcomes)
12/10/2013
14. What is Kanban?
14
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
12/10/2013
15. 15
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
12/10/2013
17. Value Stream
17
Through metrics you can evaluate your efficiency.
How much time spent on value add vs non value
add
12/10/2013
18. Why Pull? Why Kanban
18
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
12/10/2013
19. Limiting Work-In-Progress (WIP)
19
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
12/10/2013
20. Making policies explicit
20
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?
12/10/2013
28. How work happens today?
28
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
Team members try to juggle between
what is planned (and kept on
schedule) + new arrivals!
In most cases, people avoid reprioritization (you can’t do it for every
incremental piece)
As a result:
Planned tasks start slipping
Multiple reasons: some in control of
project team and some not...
Quality drops because people multitasking and context switching
Unscheduled tasks start coming in
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!
12/10/2013
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
29. How a “Project Board” changes
this?
29
Shows all work items, their current
state of progress and the people
who are on it
Help collaborate between the
project team:
If someone needs help, they can
“block” without escalation/followup
If someone is overloaded, others
in the team can respond
Work items move forward as they
progress!
Everyone knows what others are
working on
Provide for additional social tools
to collaborate within project team
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?
Chat/Threaded Discussions
“What-if” simulation models
Project Board is touch screen
enabled and available on mobile
12/10/2013
platforms
30. 30
How a “Project Board” changes
this?
Putting a limit on the work in
process determines what
really needs to be done
Creates a scorecard with just
having a simple Kanban board
The board keeps us
accountable
You know how many get done!
The person who owns the card has to
move it forward
Encourage teamwork as the
tasks that are not being
completed will focussed and
12/10/2013
worked on, together
31. 31
Kanban – an evolutionary
approach
Kanban is an
adaptive capability
for evolutionary
change
Not
a process
definition or a
framework to be
tailored
12/10/2013
34. 34
The Challenges of Status
Calls…
People report to leader…
Leader
summarizes the status update
… and sometimes “massage” the status update
Often, there is chaos, no agenda, too many
people
Louder
personalities (few) dominate
Many sit quiet in tacit acceptance
12/10/2013
35. 35
Rationale behind the Standup
call
Regularly communicating, working together and
helping each other is the best team practice
Gaining a shared understanding of what work is
done and what remains to be done
12/10/2013
36. 36
Standup Call is the Team
Huddle!
We have all seen the “HUDDLE”… in action
Why not in your teams?
12/10/2013
37. This is what happens…
37
Team Meeting to provide a Daily Status Update in 15 min
Gather issues during the Standup
Process issues after the Standup: take discussions offline
Each person tells their peers (not their manager)
What they did yesterday and what they plan on doing today
Where are they stuck or need help?
Think ahead your elevator pitch
Use the Board; have a facilitator
Same place; same time
Do not wait; do not repeat
Ideally, start the day with a Standup
12/10/2013
38. GIFTS (goals) of a Standup Call
38
G – Good Start to the day
Give energy; instil a sense of
purpose/urgency
Clear understanding what needs to
be done to achieve it
BUT… if you cannot START the
day, schedule it at the end of the
day so that it is not linked to
starting work in the day
Expose problems to allow us to
improve
Share better techniques and ideas
Focus on moving work through the
system to achieve our objectives
T – Reinforce the sense of Team
Strongly tied with team members
helping each other with shared
obstacles
Effective teams are built by regularly
communicating, working, and helping
each other
I – Support Improvement
F – Reinforce Focus on the Right
Things
No "false urgency“: where people
are geared up for activity but are
without shared direction
Effective teams are autonomous (selforganizing)
S – Communicate Status
How is the work progressing?
Is there anything else interesting that
12/10/2013
39. Some more guidelines
39
Who Attends?
“All Hands”
People are giving update on
behalf of the stories
Reject any meeting that risks
that timeline
Including your manager’s or
your customers
They will appreciate your
commitment to the “Huddle”
Set your reminder 5 min
ahead of start time
Speaking order:
Round-robin… OR…
Replace some
meetings/reports with Standup
“Stories” are the participants
The last person who arrives
speaks first
Speak loudly; don’t whisper…
You have to energize!
End the meeting with a high
note
Break eye contact with the
manager
For larger teams
May not be possible in 15 min
Focus on Blocked Cards,
Expedite Cards
12/10/2013
Leave time for something that
40. Standup Call - Mistakes
40
Be cautious of few issues dominating the call
Take them offline
Not Standing: Take out the chairs!
Some people get into “story telling”
Team members not showing up on time
Get support from line managers
Pick a time that everyone is OK with
Provide buffer between meetings
Allowing distractions
Location, No mobiles/laptops
Meeting etiquette
Not having a dedicated team room
Not using Standup for distributed teams
12/10/2013
42. The Retrospective Template:
For mid-size projects
42
Appreciations
Let everyone write their own
points on a post-it and stick it on
the white board
What do they mean:
Puzzles
Risks
Wishes
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.
12/10/2013
43. Scope
43
What did we plan to do?
What actually happened? Why?
What would we do next time?
What do we want to do more of, what do we
want to change or stop? (5 mins max)
12/10/2013
44. The method
44
Nominate a facilitator
Consider an outside facilitator
to eliminate inter-personal
issues
Consider removing chairs =>
No more endless debates
Avoid the product owner
(unless you have a great
one!)
Tend to hijack the discussion
with “all problem with dev”
Collect data for 15 min
Define ground rules.
Consider:
Be respectful
interrupt
Put away laptops and phones
Park long discussions in the
designated lot
What is said here stays here
Look at Cumulative Flow,
Cycle Time and Lead Time –
what issues do we see, what
actions can we take? (5 mins
max)
12/10/2013
Collate your blockers
Recap what you hear to
ensure understanding
Go round the group – what
have we done for the
improvement actions we
committed to last week? (23min per person)
; Do not
46. getKanban Game
46
Each team has a playing board representing a Kanban task board,
and a collection of story cards representing work to be done.
Each card has a value associated to it and an estimated effort for
each stage
Team earns as cards complete the Value Stream
Teams compete to maximise net profit by optimizing the flow of work
All resources can do everything except when the system specifically
mentions a constraint
System generates events and you have to keep re-planning based
on the same
Lookout for Expedite or FixedDay cards; there is price for missing
deadlines
When you pull cards, from the Backlog, new cards will appear; notice
for the value of the cards
12/10/2013
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.
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 obselete by the time we actually take it for development…
Pause for a moment and explain how having a “Done” lane enables Pull.Also, that typically one should have a “Done” lane when work flows from one person to another (not within stages of the same person’s execution)!
Understand the significance of “Get Coffee”! You are telling them not to keep developing things because I am not ready to absorb them!
In SWIFT-Kanban Dev team:Stand up is of 20-30min Followed by an issue based discussion involving concerned peopleThis approach works well for us because one team is in US; so, need for other callsin the middle of the day is reduced