“The Kanban Racing Challenge is an immersive workshop where you learn the basic practices of a Kanban team by building an obstacle course for radio-controlled cars.” Really? Build an obstacle course, race a remote-controlled car and practice Kanban in a half-day workshop? Sign me up!
This was the first time Nate Oster ran the Kanban Racing Challenge outside of a client site. It was a good test for the workshop since each team had a mix of backgrounds and levels of experience with Kanban. Two-thirds of my team had never even met before that afternoon. After a basic overview of the key attributes of Kanban – limit work in process, pull work, manage visually with a Kanban wall, and continuously improve, we put immediately put it in action.
Our volunteer Product Owner prioritized the first three user stories and we started to build our obstacle course. Once we got the hang of it with the first two user stories, we then started to branch off and tackle more and more user stories in parallel. Just like in real life, as soon as we were running fairly smoothly we got our first expedite request. An expedite request is a special request for a feature that takes priority over all other work in process. About halfway through, we held a stand-up meeting and realized a lot of work wasn’t integrated because we didn’t know the overall plan for our track. We quickly fixed that and a bunch of features suddenly got to done. When it was time for the final time trial, we had built a fun course and were tied with the other team with respect to how many points we earned for feature implementation. Unfortunately, we lost when the other team ran their car through their course faster.
A few things I learned in this workshop:
- Both teams implemented the exact same features. The other team was able to navigate their course a little faster due to the design of those features. As a result, their course was a little shorter and two of their obstacles were easier for their car to navigate. While this observation is not about Kanban, it reinforced the importance of paying attention to design choices and how they meet the end goal. One of our design choices worked out better, but it was the two that were more complicated that most affected our overall design. No matter how you do your work: keep your designs as simple as possible.
- Even when the team is flowing with getting features done, don’t lose sight of the big picture. We had three features built but not integrated because we didn’t know where to put them. No one was responsible for the overall map of the track and we weren’t able to do take care of it naturally as a team. Once we were clear on who we should consult when we were ready to integrate a feature, we were quickly able to put the features on the track, test them and move them to done.
- Always remember to get your features to done before starting new ones. It is really easy to put something aside when we ran into a roadblock and work accumulated really quickly. This is why Kanban limits work in process.
- Any leader who does not understand why Agile strongly recommends that teams be kept stable and focused should take an interactive workshop like this. Because most of the team had never met before, so we had all the challenges that a forming team goes through while we were trying to figure out how to build the obstacle course and learn how to do Kanban. This is the same thing that happens whenever companies move people around and constantly form and reform teams. Learning how to work with each other is not trivial and it affects the pace of product development and the pace of process understanding and adoption.
I’m always a fan of interactive workshops, since active learning is always more memorable than passively listening to a lecture. The Kanban Racing Challenge is well designed and a good introduction to the fundamentals of Kanban. I would recommend combining it with a more in-depth discussion on the principles, either before or after the racing challenge, to reinforce the concepts. The workshop was a lot of fun and a good learning experience. If I were to see it on a conference schedule in the future, I would sign up again.
Related articles
More Articles From Agile Development Conference East
Sockets and Lightbulbs 
November 12, 2014
Agile