Transcript Kanban in Action City Grid Media Case Study Jason Lenny What is Kanban? (To us..) • • • • • • Visualizing the Workflow. Iterationless development. Limiting work-in-progress. Monitoring cycle time. Using service.

Kanban in Action
City Grid Media Case Study
Jason Lenny
What is Kanban? (To us..)
•
•
•
•
•
•
Visualizing the Workflow.
Iterationless development.
Limiting work-in-progress.
Monitoring cycle time.
Using service classes.
Experimenting with the process.
Kanban Adoption Timeline
Kanban Timeline
• Where were we before we started?
– Used Scrum for 6-8 months with success (mostly).
– Fear of failing the sprint was causing sacrifices to be made
in order to complete the work on time.
– We had in many ways reached peak efficiency and
maturity with Scrum.
Kanban Timeline
• January: Kanban for Releases
– Introduced Kanban for release management. Work queue
came in through JIRA as deployment requests, and I was
keeping the board up to date myself.
– This did not come from an executive mandate – the plan
was to start with a single process and trust that it would
catch on.
Initial Workflow (Releases)
•
•
•
•
•
•
Waiting for Code Freeze
Ready to Test
Testing
QA Approved
Releasing
Released
Kanban Timeline
• February: Stabilizing the Release Process
– 40+ cards on a physical board was too much to handle so
we moved to a digital tool – AgileZen.
– Cross-functional Kanban boards work great – teams were
adding items, Ops was picking them up for deployment,
and then QA was moving them to verified.
Kanban Timeline
• March: Planning for Development Kanban
– New CTO started with background in Kanban.
– My role changed: moved from release manager to
engineering manager so I began doing analysis and
planning on how to implement Kanban.
– Initial idea was to model the existing process using the
board, and then start iterating on process improvements.
Kanban Timeline
• April: Implementing Development Kanban
– Engaged teams by prototyping the process with one team
and then having them present their findings to the rest of
the teams.
– Scrum Masters became Agile Facilitators.
– Read “Kanban” by David Anderson.
Kanban Timeline
• May: Growth and Learning
– Moved to iterationless Kanban for development.
– Started Kaizen transformation (sharing ideas,
experimenting with the process.)
– Implemented “Classes of Service.”
– Began tracking metrics.
– Brought David Anderson in for training.
– Most change and experimentation was led by me.
Initial Service Classes (Software)
• Standard: Items that come from our product team.
• Service Desk: Production support escalations.
• Infrastructure: Items that come from our engineering team.
Initial Workflow (Software)
•
•
•
•
•
•
To-Do (8)
Analysis (2)
Waiting for UX (2)
Working (3)
UAT (2)
Releasing (No limit)
Kanban Timeline
• June: Continued refinement
– Began using Kaizen logs.
– Established SLAs for the service classes.
– Added “Expedited” and “Due Date” service classes.
– Team is starting to understand Kanban from a user
perspective, but is not yet participating in process
engineering.
Kanban Timeline
• July: Continued Refinement
– Continued experimenting and iterating on the process.
Around this time people were generally understanding the
process and more open to experimentation.
– Established explicit success criteria to move between
columns.
Kanban Timeline
• August: Success
– Moved team boards from walls to AgileZen. Primary driver
was newly distributed teams.
– Reorganized teams around technology portfolios vs.
Product Owners.
– Realized that all major remaining constraints were teams
not using Kanban/not part of the delivery team, so we’ve
started bringing them in.
Kanban Timeline
• September: Post-Adoption
– Moved release process to the team board rather than
being a separate black box.
– Team is now engaged in process design at a fundamental
level.
Kanban Timeline
• What changed over time?
– Workflow is much more explicit now, includes success
criteria, and includes the entire delivery flow.
– Service classes are not based on stakeholder, but are based
on delivery risk/value.
– Stakeholders share a board (and prioritization) so that they
communicate amongst each other to establish
prioritization. We took ourselves out of saying “No.”
Current Service Classes (Software)
• Standard: Normal items with no rush and no explicit due date.
• Expedite: Items that need to be done ASAP and all other work
should be sacrificed (if necessary) to make it happen.
• Due Date: Items with an explicit due date that needs to be
minded.
Current Workflow (Software)
•
•
•
•
•
•
•
•
Unsorted Backlog (No limit)
Estimated & Prioritized (6)
Analyzing & Writing Tests (4)
Re-estimated & Started (6)
Merged & Added to Plan (No limit)
Deployed to QA (No limit)
Ready for Production (No limit)
Verified and Updated in JIRA (no limit)
Lessons Learned
Lessons Learned (Releases)
• What went well?
– The board improved communication and status tracking to
a significant level. What was once a black box became well
understood and optimized.
• What went poorly?
– Release management should be within the context of the
delivery team – separating the release process from
development is an anti-pattern.
Lessons Learned (Software)
• What went well?
– Having Lean experienced managers and a team already
familiar with Agile was a huge boon.
– Kanban works great for larger teams, allowing you to
combine smaller Agile teams into larger pools.
• What went poorly?
– Product consistently reports a feeling that we are slower,
even though metrics show otherwise.
Lessons Learned (Overall)
• What went well?
– Kanban works great to get everyone to understand crossteam process and their roles; improving communication,
visibility, and encouraging ongoing process improvement.
• What went poorly?
– A successful implementation requires a thorough
understanding of the tool; otherwise you end up using the
board as a fancy status report.
Questions?