Weitere ähnliche Inhalte Ähnlich wie Agile The Kanban Way - Central MA PMI 2011 (20) Mehr von Gil Irizarry (10) Kürzlich hochgeladen (20) Agile The Kanban Way - Central MA PMI 20111. Agile The Kanban Way
PMI: Central MA Chapter
Gil Irizarry
Constant Contact
Copyright © 2011 Constant Contact Inc.
2. Learning Objectives
• Learn what Kanban is
• Learn value stream mapping and how to apply it
to your team
• Learn how to read a cumulative flow diagram
Copyright © 2011 Constant Contact, Inc. 2
3. Agenda
• A bit about me and Constant Contact
• Theory –
• Motivations
• Background
• What is Kanban and how does it work
• Practice –
• Setting up a Kanban board
• Establishing policies and limits
Copyright © 2011 Constant Contact, Inc. 3
4. My background
• Program Manager at Constant Contact
• Over 20 years software development and
management experience, over 5 years in an agile
software development environment
• CSM and PMP certifications, Kanban coaching
training with David Anderson
• BS from Cornell, ALM from Harvard, certificate in
Management from MIT Sloan
• girizarry@constantcontact.com, gil@conoa.com
• http://www.slideshare.net/conoagil
Copyright © 2011 Constant Contact, Inc. 4
5. Background on Constant Contact
• SaaS company offering on-line e-mail
marketing, event marketing and surveys. Recent
enhancements extend the services to the social
media space
• >$200MM gross revenue per year
• >850 employees
• >475K paying customers
• Engineering and Operations total about 150
people
• First Scrum team formed in 2006
Copyright © 2011 Constant Contact, Inc. 5
6. Motivations
• We want to move to Agile management methods.
Why?
• React quicker to changing market conditions
• Get new features to users more quickly
• Frequent releases are smaller releases
• Better Quality
Copyright © 2011 Constant Contact, Inc. 6
7. Quick Review of Scrum
• Fixed iterations
• Daily stand-ups
• What did you do yesterday, what did you do
today, any impediments
• Retrospectives
• Burn-down chart
• Board with To Do, In Progress and Done
states
Copyright © 2011 Constant Contact, Inc. 7
8. Lean Principles
• Eliminate Waste
• Build Quality In
• Create Knowledge
• Defer Commitment
• Deliver Fast
• Respect People
• Optimize the Whole
Leading Lean Software Development: Results Are not the Point by Mary
and Tom Poppendieck
Copyright © 2011 Constant Contact, Inc. 8
9. What is Kanban?
• A scheduling system that tells you what to
produce, when to produce it, and how much to
produce.
• An effective tool to support the running of the
production system as a whole.
• An excellent way for promoting improvements
because reducing the number of work cards in
circulation highlighted problem areas
Wikipedia: http://en.wikipedia.org/wiki/Kanban
Copyright © 2011 Constant Contact, Inc. 9
10. Foundational Principles of Kanban
• Start with what you do now
• Agree to pursue incremental, evolutionary change
• Respect the current process, roles, responsibilities
& titles
From:
http://agilemanagement.net/index.php/Blog/the_pr
inciples_of_the_kanban_method (David Anderson)
Copyright © 2011 Constant Contact, Inc. 10
11. 5 Core Properties of Kanban
• Visualize the workflow
• Team board states are a reflection of the
value stream
• Limit WIP
• Manage Flow
• Implied that flow should be continuous
• Make Process Policies Explicit
• Improve Collaboratively (using models & the
scientific method)
Copyright © 2011 Constant Contact, Inc. 11
12. Kanban and Roles
• Prioritization
• Definition
• Ready-Ready
Org
• Work mgmt.
• Delivery
• Metrics
• Flow
• Improvement
Lead Team
Copyright © 2011 Constant Contact, Inc. 12
13. You are one team!
Copyright © 2011 Constant Contact, Inc. 13
15. Sample Value Stream
Shop Unpack Cook
Value: for food groceries Food Eat!
30 min 5 min 15 min
Drive to Drive Wash Serve
No
market home Pots Dinner
Value:
30 min 30 min 15 min 5 min
50 min / 130 min = 38% efficiency
Copyright © 2011 Constant Contact, Inc. 15
16. Map the value stream in your group/dept./firm
• Work with your teams or teams on which you are
dependent in order to drive more efficiency
Copyright © 2011 Constant Contact, Inc. 16
17. Sample Kanban Board
States
WIP Limits
Classes of Service
Copyright © 2011 Constant Contact, Inc. 17
18. Pull, not Push
• Work items should be pulled into available lanes
• Work should not be pushed when
completed, even if its lane is full
Pull: Push:
Copyright © 2011 Constant Contact, Inc. 18
19. Limit WIP
• Why?
• Less multitasking
• Less time lost to context switching
• Better quality
• Smoother flow
Copyright © 2011 Constant Contact, Inc. 19
20. Classes of Service
• Different types of work need to be handled and
prioritized differently
• We manage this through the concept of classes of
service. Similar projects are grouped into classes
and each class is assigned an allocation.
• For example, we may decide that 20% of ops
time should be spent on infrastructure
improvements, and 80% spent on servicing
development
Copyright © 2011 Constant Contact, Inc. 20
21. Sample CFD
60
What happened here?
50
40
User Story
Mockups
Lead Time Cycle Time Ready-Done
30
In Development
WIP Dev Done
In Testing
20 Complete
10
Potential Bottlenecks
0
11/9/2010 12/9/2010 1/9/2011 2/9/2011 3/9/2011 4/9/2011
Copyright © 2011 Constant Contact, Inc. 21
22. Team Kanban
• Teams plan continuously. Backlogs should be
constantly groomed.
• Teams test continuously
• It’s OK if a team finds a defect on the last day of
the release. Pull the feature or delay the
release, but keep the flow continuous
• It’s OK if a team starts work for the next release
in the current release
• Aim for development and testing to flow more
smoothly through your system
Copyright © 2011 Constant Contact, Inc. 22
23. Metrics
• Considering gathering the following:
• Cycle time on items after grouping them by
size:
• Completion time for small, medium and large
• Spread of cycle times
• Work items completed
• Open defects in production, to give a high-
level approximation of technical debt
Copyright © 2011 Constant Contact, Inc. 23
24. Metrics guide planning and estimation
• Over time, we would expect that the spread of
cycle times for a given item size goes down.
• So, over time, an estimate of completion time for
items of a given size should become more
accurate.
• Work items can be sized by t-shirt sizes
(smalls, mediums or larges) and the average cycle
times for those sizes from the last release become
the estimate for the upcoming release.
• Large items should in most cases be broken down
into smaller items
Copyright © 2011 Constant Contact, Inc. 24
25. Average Cycle Times for work items
35
30
25
20 Average of Cycle Time
(small - 1 Story Point)
15 Average of Cycle Time
(medium - 3 Story
Points)
10 Average of Cycle Time
(large - 5 Story Points)
5
0
2010 R7 2010 R8 2011 R1 2011 R2 2011 R3 2011 R4
Copyright © 2011 Constant Contact, Inc. 25
27. Why Kanban?
• Shorter sprint lengths were forcing us to
artificially break up items in order to fit within
sprint boundaries.
• Sprint planning consumed the team for an entire
day.
• Most of the work for a sprint was getting
completed all at once, close to the end of the
sprint.
• QA had nothing to do at the beginning of a
sprint, but were overworked at the end.
Copyright © 2011 Constant Contact, Inc. 27
28. Mapping the Value Stream
• At the time, the Website team was really 2
teams, Engineering and Design.
• We asked the teams to map out their current
development process.
• It was really complicated…
Copyright © 2011 Constant Contact, Inc. 28
30. One Team – Single Flow
Produc
e
Tod
o
Item and task
type by color
Bugs & Footprints on board
WIPL = 6 full items
Visible policies
Copyright © 2011 Constant Contact, Inc. 30
31. Cumulative Flow Diagram
• QA overloaded
• Worked on more constant delivery
• Identified a bottleneck with source control
• Changed our branching strategy to improve
Copyright © 2011 Constant Contact, Inc. 31
32. Cumulative Flow Diagram
• By September, we’re now releasing twice a week to Production
• Much smoother CFD, continuous deliver improves cycle time
Copyright © 2011 Constant Contact, Inc. 32
33. One Year Later…
New classes of
Copyright © 2011 Constant Contact, Inc.
service 33
34. Resources
• Kanban by David J Anderson
• Implementing Lean Software Development: From
Concept to Cash - by Mary Poppendieck and Tom
Poppendieck
• Scrumban - Essays on Kanban Systems for Lean
Software Development - by Corey Ladas
• http://www.netobjectives.com/
Copyright © 2011 Constant Contact, Inc. 34
35. Conclusion
Thank you!
Copyright © 2011 Constant Contact, Inc. 35
Hinweis der Redaktion We had 3 “swim lanes” “P1” or “expedite”, Engineering and Design. The lanes converged in the verify column.We had WIP limits for each column or “state”Engineering Lanes: Queue, Requirements & Test Plans, Design, Review& Revision, Code, Review & Revision, Verify, DoneDesign Lanes: Queue, User Experience, UX Review & Revision, Design, Review& Revision, Test Plan, Code, Review & Revision, Verify, Done We had trouble managing dependencies between the two boards/teamsWe decided to pull together as one team, one board, one goal This example is from September of last year. Pretty smooth. Throughput was down because we had 4 large projects going on simultaneously, so smaller items blocked.Infrastructure work (e.g. code cleanup, upgrades, etc.) were not getting done.Team defined classes of service – pebbles, rocks, sand, plus infrastructure and design only.