Stuart Kent and Lauren Malatesta
When I facilitated a session of the game getKanban for the first times last year at [A Major Michigan University], it was with the purpose of teaching Lean principles to a team of software developers who were… well… historically resistant to change. But I was surprised by the positive results, and the general acceptance of the principals that the game teaches. I had lots of people come up to me afterwards and let me know how much they’d learned and that they were going to suggest that everyone on their team participate in an upcoming session. So as I was thinking about what I could bring to Labs as a Delivery Lead, and how I could help our project teams deliver more effectively, I hypothesized that running a few sessions of getKanban would be a great way to solidify some of our own project best practices while stimulating a bit of friendly competition.
GetKanban is a board game that teaches the basic principles of Kanban through simulated project work. You can find more information on the game here. Each 5-7 person team represents a software development company. The winning team is the one who makes the most profit for their company, mostly done by releasing new features that attract new subscribers. As the game progresses, the teams are presented with typical (and maybe some atypical) project challenges – your developer is blocked on a task that can only be completed by someone outside of the team, a new manager comes in and changes policies for the good of his group without thinking of the impact to everyone else, someone needs a new feature completed and released ASAP, etc. The great thing about this game is that every team responds differently, though they all face the same challenges. Ultimately the correct combination of planning and reaction leads to success.
As a Delivery Lead, I was hoping to bring more awareness to some Big-A Agile and kanban practices and help our project teams work within project teams more effectively. Was it successful? I sat with a recent participant to find out.
Our current first place team, NOT4CATS, strategizes on how to improve delivery.
Our current first place team, NOT4CATS, strategizes on how to improve delivery.
Lauren: Hi Stuart. I hope you had fun playing getKanban, and that I tricked you into learning something in the process.
Stuart: Hi Lauren! Your subterfuge was successful, I definitely picked up a few tips I’ll try to take back to my project team. Having said that, I’m also really glad we mixed up the getKanban teams – it was great fun tackling this challenge with colleagues I’ve not had the pleasure of working closely with before. Coming from different projects also meant we brought a range of perspectives on workflow to the table.
Lauren: In playing the game, I was really hoping to broaden everyone’s viewpoints, to show that an understanding of the entire project system as a whole is more useful to the team than a myopic understanding of one individual’s role. For example, how does a piece of work flow from Ready to Deployed? How long does it take to get there? How can we make predictions to our customers based on the data that we have? Where are the bottlenecks, and how can I help alleviate them? As a game participant, did you pick up on that at all?
Stuart: Absolutely. In responding to in-game events, it was pretty clear that a ‘localized’ issue (for example, a delay that affects the testing phase only) can impact all workflow phases. We handled these issues much better if we were not afraid to distribute our resources (QA engineers, developers, and testers) wherever needed, even if it meant significant role-swapping day-to-day. While excellent at promoting flexible resource allocation, I think getKanban was not quite as good at demonstrating the power of flow rate metrics – partly because disruptive events occurred very frequently, and partly because the highest-priority parcels of work were special cases. The relative strengths and weaknesses of the various metrics we tracked are not totally obvious to me.
Lauren: I notice that people tend to play the game similarly to how they work in real life. For example, those who try to do many things at once also have problems with WIP limits in the game. I hoped that teams would call each other on these things, and help each other understand why doing lots of things at once is more hurtful to the project than helpful. Did you notice any of your own bad habits coming out during gameplay? How did your team deal with them?
Stuart: I might surprise you here by saying no – I don’t think any of our bad habits interfered (feel free to disagree). There are a couple of reasons for this: (1) the game rules explicitly prevent breaking WIP limits (not quite so rigidly enforced in real life, for better or worse), and (2) in trying to ‘win’ the game, we focused more on the flow of work through the entire system, which prevented us from falling victim to the myopia you alluded to earlier. getKanban was working as advertised, in other words! Despite being a team of all-developers, I think we did a good job of avoiding strategies that prioritized developer concerns over those of other system components. We instead spent most of our time calling each other out for (a) forgetting to factor in one of the many pieces of information we were juggling every turn, and (b) failing to fully understand the full range of consequences – immediate, imminent and eventual – of every event we encountered.
Lauren: Ha! Yes! It appears that you understand the glory and sorrow of being a Project Manager – constantly juggling multiple pieces of information in order to help guide your team to the best decisions, both short term and long term. The more the team understands these metrics and risks as well, the more helpful they can be in making these decisions.
On another note, I’ve had people learn about kanban and say, “This sounds great! Let’s do kanban instead of scrum! That way we don’t have to commit to getting anything specific done for our Product Owner by the end of the iteration [because there are no iterations].” But it makes me laugh, because someone like a Product Owner is still front and center. Someone is prioritizing your backlog. Someone is making commitments to end users. You still use past data to make predictions on future behavior. It’s just there is an increased focus on the reduction of wasted work and wasted time with kanban, while scrum allows for increased product stability, and in my experiences, more immediate credibility with clients (due to some of the things Scrum calls for, like constant Show and Tells and sprint planning).
Stuart: Yeah, I have noticed that proponents of various agile approaches tend to defend their preferred systems rather vigorously. At Detroit Labs, it seems like there are two main considerations that dominate our process selection: customer requirements (how should progress be estimated/measured/reported; which of scope/date/manpower is easiest to vary; etc.) and internal team preference. Most of our current customers seem to prefer Scrum-style sprints, and I suspect that this is because the increased structure of sprints results in more tangible targets. On the other hand, our devs seem to naturally lean more towards the continuous delivery of kanban because it better accounts for (inevitably) imperfect estimates and any increases in scope. I totally think it’s possible to find a middle ground that mixes elements of Scrum and kanban and keeps everyone happy – as long as communication is really open and a certain level of trust is established and maintained. Thank you, delivery leads, for working hard to keep that happening!
Lauren: Was there a lightbulb moment for you as you were playing the game? Something that made you sit up and say, “Oh man, that makes sense. I/We should start doing this on my projects.”
Stuart: In my current team, app releases are scheduled every 1-2 months. This removes pressure to push cards all the way through to ‘done’ as soon as possible – features just need to be implemented and QA’d by the release date. While the team is pretty good about respecting WIP limits for development phases, us developers only tend to assist with piled-up QA tasks right before release deadlines. Playing getKanban and seeing all the available flow-tracking metrics (even though their usefulness in the context of the game was limited, as I described earlier) really helped me internalize that swapping roles more often early on in the development period would help make the progress estimates we provide our client much more meaningful. That was the single biggest takeaway for me.
Lauren: That’s awesome. That’s definitely one thing that I wanted everyone at Labs to understand and experiment with. And one reason why it’s so important to create a team of people with diverse skillsets.
Your team is currently in first place. Nice work. Any final thoughts about what you’ll take away after playing getKanban? Would you encourage others to play?
Stuart: In addition to the highlights I described above, I credit getKanban with raising my awareness of some of the subtleties of project management and inspiring me to learn more about the philosophies behind various workflow systems. My planned next step is reading Ohno’s “Toyota Production System”. The game was challenging without being overwhelming, and I have already recommended it to a bunch of other Labbers – even though that may create more opportunities for my team to be de-throned!
Lauren: Excellent! I’m excited to see how this plays out long-term for Detroit Labs.