Transformation of the Website Team at Constant Contact through Kanban

1. Upstream Kanban
Process Evolution in the
Constant Contact Website Team
Rick Simmons – Mike Fitterman
This work is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.

2. Mike Rick
Engineering Mgr, Web Team Director, Agile Practices
 20 years in dev leadership  22 years in dev/ops leadership
 Tried many processes: “All can  Tried many processes: “Some
work” work better than others”
 Interested in process beyond  Interested in change and
utilization and deadlines maturity at organizationlevel
mfitterman@constantcontact.com rsimmons3k@rallydev.com
Twitter @cutshot Twitter @simmons3k
Now Director Now
of Engineering Agile Coach

4. R
Kanban: Kanban flow
quantitative Your roles,
competencies,
workflow processes,
management etc.

5. R
How do you Kanban?
Map the “value stream”
Put it on the wall 5 2 2 4
Pick some WIP limits
Pull work through
Cycle Time
Measure
Watch, tackle, improve

6. R
Constant Contact Website:
 Login portal • Convert visitors to
trialers

7. R
Organization Before
190 ppl
Product Strategy Engineering
PRODUCT DELIVERY
Product Mgt Dev Ops
Web
Design team: 15

8. R
Upstream?
Stakeholders
Marketing
Web Team:
Service
Organization

9. R
Milestones
6/09 11/09 4/10
Launch
Policies
Team reorganization
Metrics
Upstream board
Upstream WIP limits

10. M
Team Makeup and Process, 2009
Shared
POs, QA
Engineering Design
4 Java/J2EE Developers 4 Design/Web Developers
+ Manager + Manager
Scrum
• Monthly Releases • Weekly Releases
• Delivered “hard” changes – Java • HTML/JSP/CSS only changes
code, integrations, etc. • 1 ½ days testing to ship
• Week-long Regression to ship
6/09 11/09 4/10
Launch

11. M
Challenges
Upstream Silo Disjoint Split QA
dependencies development cycles lower quality
Plan/retro time Small Reputation
Redundancy 12-24 hr/mo per change for slow
member from retros delivery

12. M
Initial Goals
• Have teams work together
 Smooth out delivery • Release more things more
flow often
 Function as one
team • Eliminate Developer and QA
problems from 2 teams working
 Gain back some on code base
• Coordinated planning meetings
time
 Iterate fast and
make change • Eliminate PO/Scrum Master/QA
as we go time split
• Shorter planning meetings, but
more often

13. R
First Board
Swim lanes WIP limits Verify col.

14. R
Week 2: overloaded, hidden work
Verify column over limit
Blocked Items
Work not on board

15. R
Week 4: Board mods and policies
Wait states Less columns Team adding policies
6/09 11/09 4/10
Policies

16. M
Policies on wiki page…
…but no one
ever went there
:(
Eventually we put them on the board

17. M
Week 5: Broke down code queue
Items Tasks

18. M
A few days later….
Deploy states
No work not
on board

19. R
Large-scale
Reorganization
Marketing “Kaikaku”
Product Strategy
Engineering

20. R
Before re-org
Marketing
PM Rest of org
Product Strategy PO PO Engineering
Web Design Web Eng

21. R
After re-org
Product Strategy
Web Team
GM
Rest of
org
K
POs
Marketing a
n
b
Engineering Delivery team a
Engineering Design n

22. R
Reorganization
 Strategy aligned with Execution
 Eliminated redundant functions
 Made team made self sufficient
– Approve own work, remove wait
states
6/09 11/09 4/10
Team reorganization

23. M
2 teams, 1 board: single flow

24. M
Month 5: Metrics & Mike’s lesson
■ Ability to watch and tune
■ From intuition to quantitative management
6/09 11/09 4/10
Metrics

25. M
What the metrics showed
■ QA is many times overloaded
■ Needed to get them below their limits
■ Worked on “constant” delivery
■ Delivering late causes overload and quality problems

26. M
How We Smoothed Out Flow
Work on separate dev branches
 Test in parallel on other QA Environments
 Earlier testing, less work at end
More policies
 Automation/unit testing; Metrics
add known bugs to tests
 Increase functional testing;
are the KEY
added Cubic Test
to constant
 Unit Testing
improvement

27. M
6 Months
New Class of Service:
Bugs & “Footprints”
Explicit policies,
but no WIP limit

28. M
Upstream board to marketing
 Visibility up 200%, extends up to GM
 Eliminated redundant Excel data
 Collaborative prioritization PO’s
idea!
6/09 11/09 4/10
Upstream Board

29. M
9 Months: Too much stuff
4X capacity Downstream
upstream… capacity:
Need to limit 5 to 7 items
upstream WIP per week

30. M
10 Months: WIP Limits on PO Board
Current Board
Old Board
6/09 11/09 4/10
Upstream WIPLs

31. M
Month 10: Single queue
Produc
e
Tod
o
Item and task
type by color
Bugs & Footprints on board
WIPL = 6 full items
Visible policies

32. M
Kanban… “It’s really about
management” –Mike
 Improvement just from the visualizing flow
 Manager is responsible to make improvement
happen
– Not the Team, although they are empowered to
 Change should be based on metrics
 Value in measuring change
– Know that it was a “good change”
– Show effectiveness to team
– Show improvement to organization

33. R
Kanban…
“It’s really
about
improvement”
–Rick

34. M
Business Value Metrics (Sticky Color)
Managers care
about bugs
PO/PMs care about where time is going overall

35. M
Throughput metrics
Possible inverse
correlation between
items and bugs?

36. M
Cycle Times
Class of SLA to Production
Service
Footprint 7 Calendar Days
Bug 12 Calendar Days
Small 15 Calendar Days
Medium 56 Calendar Days
Large Class of Service: unpredictable… eliminated
Cycle Time is an SLA is for the Product Mgt Team
Will extend to “Lead Time”, a Stakeholder SLA

37. M
Interim Adjustment Example - CFD
Bugs increased after
an increase in WIP
8 Items
11 Items

38. M
Control Chart - Smalls
This is perfect!
Just what we would expect… very predictable

39. M
Control Chart - Mediums
Just enough to start being significant
Erratic scatter – more likely to miss SLA
Experimenting with breaking Mediums into Smalls

40. M
Challenges -> benefits
Meeting waste Kaizen has
Upstream
reduced by 51Silo Disjoint Split QA
dependencies development cycles taken root
lower quality
person-hrs in the
Replaced with whole team
design & code
reviews, JIT
tasking
Plan/retro time Small Reputation for
Redundancy 12-24 hr/mo per change from slow delivery
member retros

41. M
Challenges -> benefits
Collaboration
is way up
Upstream Silo Disjoint Split QA
dependencies development cycles lower quality
Increased pace
of delivery for
Plan/retro time both Small
teams
Design: less wait states Reputation for
Engineering: 4X pace of
Redundancy change from slow delivery
delivery 12-24 hr/mo per
member retros

42. M
Challenges -> benefits
WIPLs transformed
upstream prioritizing
& approval cycles
Upstream Silo Disjoint Split QA
dependencies development cycles lower quality
Collapsed redundant
marketing functions
Small Reputation for
Plan/retro time
Redundancy 12-24 hr/mo per change from slow delivery
member retros

43. M
Challenges -> benefits
• Goal team with real
metrics
• See issues as they Managing
by metrics Split QA
Upstream happen rather than long Disjoint
Silo
dependencies after
development cycles lower quality
• Understand why they
happened rather than
intuit it
Reputation
transformed
Plan/retro time Small Reputation for
Redundancy 12-24 hr/mo per change from slow delivery
member retros

44. R
Organizational Change and
Rick’s lesson…
Value from
small change
influences
big change

45. R
Organization After Rest of org
Product Strategy Engineering
PRODUCT DELIVERY
Product Mgt Dev Ops
5 teams
LIVE
3 teams 5 teams
trying thinking

46. The best thing about success…
influencing change
Upstream Silo Disjoint Split QA
dependencies development cycles lower quality
Small Reputation for
Redundancy Thanks for coming!
Plan/retro time
12-24 hr/mo per change from slow delivery
member retros
Upstream Kanban by Rick Simmons and Mike Fitterman is licensed under the Creative Commons Attribution-
NonCommercial-ShareAlike 3.0 Unported License.