agile conference2010 upstream-kanban_at_ctct
DESCRIPTION
Transformation of the Website Team at Constant Contact through KanbanTRANSCRIPT
Upstream KanbanProcess 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.
MikeEngineering Mgr, Web Team
20 years in dev leadership Tried many processes: “All can
work” Interested in process beyond
utilization and deadlines
[email protected] Twitter @cutshot
RickDirector, Agile Practices
22 years in dev/ops leadership Tried many processes: “Some
work better than others” Interested in change and
maturity at organization level
[email protected] @simmons3k
Now Directorof Engineering
Now Agile Coach
Kanban:quantitative
workflow management
Kanban flow
Your roles, competencies,
processes,etc.
R
Map the “value stream”
Put it on the wall
Pick some WIP limits
Pull work through
Measure
Watch, tackle, improve
How do you Kanban?
Cycle Time
5 2 2 4
X
R
• Convert visitors to trialers
Constant Contact Website:
Login portal
R
EngineeringProduct Strategy
Organization Before
PRODUCT DELIVERYProduct Mgt Dev Ops
Design
190 ppl
Web team: 15
R
Upstream?
Web Team: Service
Organization
StakeholdersMarketing
R
Milestones
6/09 4/1011/09
Launch
Policies
Team reorganization
Metrics
Upstream board
Upstream WIP limits
R
Team Makeup and Process, 2009
Engineering4 Java/J2EE Developers+ Manager
Design4 Design/Web Developers+ Manager
SharedPOs, QA
Scrum• Weekly Releases• HTML/JSP/CSS only changes• 1 ½ days testing to ship
• Monthly Releases• Delivered “hard” changes – Java code, integrations, etc.• Week-long Regression to ship
6/09 4/1011/09
Launch
M
Silo development
Disjoint cycles
Split QAlower quality
Upstream dependencies
?Plan/retro time12-24 hr/mo per
member
Small change
from retros
Reputation for slow delivery
Redundancy
ChallengesM
Initial Goals
Smooth out delivery flow
Function as one team
Gain back some time
Iterate fast and make change as we go
• Have teams work together• Release more things more often
• Eliminate Developer and QA problems from 2 teams working on code base
• Coordinated planning meetings
• Eliminate PO/Scrum Master/QA time split
• Shorter planning meetings, but more often
M
First Board
Swim lanes WIP limits Verify col.
R
Week 2: overloaded, hidden work
Verify column over limit
Blocked Items
Work not on board
R
Week 4: Board mods and policies
6/09 4/1011/09
Policies
Wait states Less columns Team adding policies
R
Policies on wiki page…
…but no one ever went there
:(
Eventually we put them on the board
M
Week 5: Broke down code queue
Items Tasks
M
A few days later….
Deploy states
No work not on board
M
Engineering
Product Strategy
Marketing
Large-scale Reorganization
“Kaikaku”
R
EngineeringProduct Strategy
Before re-org
Rest of org
Marketing
Web Design Web Eng
PO PO
PM
R
Product Strategy
Web Team
After re-org
Rest of org
Marketing
Delivery team
Engineering
Engineering
Design
Kanban
GM
POs
R
Strategy aligned with Execution Eliminated redundant functions Made team made self sufficient
– Approve own work, remove wait states
Reorganization
6/09 4/1011/09
Team reorganization
R
2 teams, 1 board: single flowM
Month 5: Metrics & Mike’s lesson■ Ability to watch and tune
■ From intuition to quantitative management
6/09 4/1011/09
Metrics
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
Before After
M
How We Smoothed Out FlowWork on separate dev branches Test in parallel on other QA Environments Earlier testing, less work at endMore policies Automation/unit testing;
add known bugs to tests Increase functional testing;
added Cubic Test Unit Testing to constant
improvement
Metrics are the KEY
M
6 Months
Explicit policies, but no WIP limit
New Class of Service: Bugs & “Footprints”
M
Visibility up 200%, extends up to GM Eliminated redundant Excel data Collaborative prioritization
Upstream board to marketing
6/09 4/1011/09
Upstream Board
PO’s idea!
M
9 Months: Too much stuff
Downstream capacity:5 to 7 items per week
4X capacity upstream…Need to limit upstream WIP
M
10 Months: WIP Limits on PO BoardCurrent Board
6/09 4/1011/09
Upstream WIPLs
Old Board
M
Month 10: Single queue
Produce
Todo Item and task
type by color
WIPL = 6 full items
Bugs & Footprints on board
Visible policies
M
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
Kanban… “It’s really about management” –Mike
M
“It’s really about
improvement”
–Rick
Kanban…R
Business Value Metrics (Sticky Color)
Managers care about bugs
PO/PMs care about where time is going overall
M
Throughput metrics
Possible inverse correlation between items and bugs?
M
Cycle TimesClass of Service
SLA to Production
Footprint 7 Calendar Days
Bug 12 Calendar Days
Small 15 Calendar Days
Medium 56 Calendar Days
Large Class of Service: unpredictable… eliminatedCycle Time is an SLA is for the Product Mgt TeamWill extend to “Lead Time”, a Stakeholder SLA
M
11 Items
Interim Adjustment Example - CFD
8 Items
Bugs increased after an increase in WIP
M
Control Chart - Smalls
This is perfect! Just what we would expect… very predictable
M
Control Chart - Mediums
Just enough to start being significantErratic scatter – more likely to miss SLAExperimenting with breaking Mediums into Smalls
M
Silo development
Disjoint cycles
Split QAlower quality
Upstream dependencies
?Plan/retro time12-24 hr/mo per
member
Small change from
retros
Reputation for slow deliveryRedundancy
Challenges -> benefits
Replaced with design & code
reviews, JIT tasking
Meeting waste reduced by 51
person-hrs
Kaizen has taken root
in the whole team
M
Silo development
Disjoint cycles
Split QAlower quality
Upstream dependencies
?Plan/retro time12-24 hr/mo per
member
Small change from
retros
Reputation for slow deliveryRedundancy
Challenges -> benefits
Design: less wait statesEngineering: 4X pace of delivery
Increased pace of delivery for
both teams
Collaboration is way up
M
Silo development
Disjoint cycles
Split QAlower quality
Upstream dependencies
?Plan/retro time12-24 hr/mo per
member
Small change from
retros
Reputation for slow deliveryRedundancy
Challenges -> benefits
WIPLs transformed upstream prioritizing
& approval cycles
Collapsed redundant marketing functions
M
Silo development
Disjoint cycles
Split QAlower quality
Upstream dependencies
?Plan/retro time12-24 hr/mo per
member
Small change from
retros
Reputation for slow deliveryRedundancy
Challenges -> benefits
• Goal team with real metrics
• See issues as they happen rather than long after
• Understand why they happened rather than intuit it
Reputation transformed
Managing by metrics
M
Organizational Change and Rick’s lesson…
Value from small change influences big change
R
EngineeringProduct Strategy
PRODUCT DELIVERYProduct Mgt Dev Ops
Organization After
?
?
Rest of org ??
?
3 teams trying
5 teams thinking
5 teams LIVE
1
23
4* *
*
5
R
Silo development
Disjoint cycles
Split QAlower quality
Upstream dependencies
?Plan/retro time12-24 hr/mo per
member
Small change from
retros
Reputation for slow deliveryRedundancy
The best thing about success… influencing change
Thanks for coming!
Upstream Kanban by Rick Simmons and Mike Fitterman is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.