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?