Kanban in Action

1. Kanban in Action City Grid Media Case Study Jason Lenny

2. What is Kanban? (To us..) • Visualizing the Workflow. • Iterationless development. • Limiting work-in-progress. • Monitoring cycle time. • Using service classes. • Experimenting with the process.

3. Kanban Adoption Timeline

4. 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.

5. 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.

6. Initial Workflow (Releases) • Waiting for Code Freeze • Ready to Test • Testing • QA Approved • Releasing • Released

7. 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.

8. 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.

9. 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.

10. 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.

11. 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.

12. Initial Workflow (Software) • To-Do (8) • Analysis (2) • Waiting for UX (2) • Working (3) • UAT (2) • Releasing (No limit)

13. 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.

14. 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.

15. 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.

16. 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.

17. 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.”

18. 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.

19. 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)

20. Lessons Learned

21. 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.

22. 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.

23. 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.

24. Questions?