Upstream Process Evolution Kanban in the Constant Contact Website Team

Transcription

1 Upstream Process Evolution Kanban in the Constant Contact Website Team Mike Fitterman Rick Simmons Lean Systems and Software Conference April, 2010

2 Who are we? Mike Engineering Mgr, Web Team 20 years in dev leadership Not a process guy or consultant Tried lots of processes All can work Interested in process beyond keeping people loaded/working and meeting deadlines mfitterman@constantcontact.com Rick Director, Agile Practices 22 years in dev/ops leadership Reluctant process guy Tried everything Some work better than others Interested in org-level change & maturity simmons3k@yahoo.com

3 Website is about two things: Login portal Convert visitors to trialers

4 Upstream? Stakeholders Service Organization

5 Timeline & Milestones 6/09 11/09 4/10 Launch Policies Team reorganization Metrics Upstream board Upstream WIP limits

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

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

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

9 Visualizing work flow

10 Week 2 Clogged QA and Work not on Board Verify column over WIP limit Limits! Blocked items Stars Work not on board

11 Policies on wiki page but no one went there :( Eventually learned to put them on the board

12 Week 4: Policies Removed People responsible for coming up with policy Wait States 6/09 11/09 4/10 Policies

13 Items Tasks Week 5 Broke down Code Queue

14 A few days later. Deploy No work States not on board

15 Reorganization Components of Engineering, Product Strategy and Marketing reorganized under a General Manager 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

16 Context Before Marketing PM Rest of org Product Strategy PO PO Engineering Web Design Web Eng

17 Context After Product Strategy Rest of org Marketing Engineering Web Team POs Delivery team GM K a n b a n Engineering Design

18 Month 4 - One Board!

19 Month 5: Metrics Metrics and Mike s big lesson Ability to watch and tune From intuition to quantitative management 6/09 11/09 4/10 Metrics

20 Month 5: metrics lessons QA is many times overloaded Needed to get them below their limits Worked on constant delivery Delivering late causes overload and quality problems

21 Month 5: Smoothing 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; add known bugs to tests Increase functional testing; added Cubic Test Unit Testing

22 6 Months New Class of Service: Bugs & Footprints not WIP limited; explicit policies

23 Upstream Board Extended to marketing/po idea generation/development Visibility up 200%, extends up to GM Eliminated redundant Excel data Collaborative prioritization 6/09 11/09 4/10 Upstream Board

24 9 Months: Too much stuff Downstream capacity: 5-7 items/week Need to limit Upstream WIP

25 10 Months`: WIP Limits on PO Board Current Board Old Board 6/09 11/09 4/10 Upstream WIPLs

26 Rick s big lesson Influence change by demonstrating value

27 Month 10 Design and Engineering queues gone Produ ce Tod o Task type colors Item color is Business Type Explicit Agreements on the wall Bugs/Footprints WIP limit now 6 full now items on board (bugs/footprints (plan to limit not soon) limited)

28 Kanban It s really about Management! 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 upper mgmt.

29 Business Value Metrics (Sticky Color) Managers Care about Bugs PO/PMs care about where time is being spent overall

30 Throughput metrics Possible Inverse Correlation between Items and Bugs

31 Cycle Times Class of Service Footprint SLA to Production 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

32 Interim Adjustment Example - CFD Bugs increased after an increase in WIP 11 Items 8 Items

33 Control Chart - Smalls This is perfect! Just what we would expect very predictable

34 Control Chart - Mediums Just enough to start being significant Erratic scatter more likely to miss SLA Experimenting with breaking Mediums into Smalls 3 Sm = Md? 5 Sm = Md?

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

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

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

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

39 Best thing about success influencing change Upstream dependencies Silo development Disjoint cycles Split QA lower quality Redundancy Plan/retro time hr/mo per member Small change from retros Reputation for slow delivery