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 cross- team 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?