240 likes | 465 Views
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.
E N D
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 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 (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.