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

mfitterman@constantcontact.com 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

rsimmons3k@rallydev.comTwitter @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.