Even more than other methodologies ("frameworks", whatever), Kanban requires deep understanding in order to bring about real change and measurable results. Too many teams struggle, even after they understand the "rules" of Kanban—failing to recognize visible problems on their own boards, or not knowing how to replace old bad habits with better ones.

I see the same struggle, in microcosm, when I train teams using the **open-source getKanban Version 2.0**. Even though the game urges teams to limit work in progress (WIP)—the linchpin of Lean and Kanban—I found that my players inevitably wanted to raise it. Over numerous classes and diverse groups of players, I tried hints, then rants, about how limiting WIP reduces cycle time. But there was a problem: play teams who took my advice and lowered their WIP weren't seeing better outcomes.

In this session, I'll show you the adjustments I've made to getKanban Version 2.0 to guide players to their "a-ha" moment—a deep, personal experience they feel and remember. Now, instead of just the basics of how a Kanban board works, my students understand how to detect and solve problems that impede their flow. I see the difference when they leave the game and go back to work. For players and coaches who are already familiar with the basics of Kanban, my new open-source hacks to Version 2.0 will help you go deeper and illuminate Lean principles for your clients and teams—and yourselves!—so you can achieve real results faster.

Additional Resources

About the Speaker(s)

Cheryl Hammond, a.k.a. @bsktcase, has a couple decades' experience as a software leader in the private and public sectors. She ran her team's successful adoption of Scrum-ban for a mission-critical regulatory compliance project under multi-agency state and federal government oversight, mentored former COBOL devs into true-believing unit-testing XP evangelists, and turned a threatened software product at risk of litigation into a lean, revenue-generating flagship offering in nine months, all of which leads her to believe that anything is possible. She is not sorry for her many biases, including strong preferences for servant-style leadership and team-based, holistic problem-solving and a strong aversion to agile zealotry. Whether consulting or in-house, Cheryl endeavors to make life suck less for software delivery organizations and the humans who inhabit them.