One of the most fun things about training is the way that the trainees surprise me. At my last training session, a team floored me with their creative solution to the penny game that I previously wrote about.

During the second round of the game, one group stopped pulling from the backlog about midway through the ten “days.” Instead, the first person in line, who would normally pull from the backlog, focused on getting work through the remaining portion of the system. The group then proceeded to clear out the early workstations, constantly focusing on later and later workstations each “day.”

The results were astounding. The group increased the number of items released to production by almost 40% and had almost no WIP at the end.

I ran the game again with a few of the participants from that round, as well as a few new “guinea pigs.” We played a few rounds in different ways. I wasn’t sure what conclusions I would get out of this, or even if there would be any, but I wanted to see it play out.

At first, we ran the game using the innovation that I previously mentioned. The difference this time was that we started the game knowing that this would be our approach. We pulled new work into the system for a few rolls. About midway through the “sprint,” the team started focusing on getting work out of the system. Surprisingly, this failed spectacularly. We played a few more rounds this way, tweaked our process a little, and ended up pushing a large number of pennies through.

We played one round where we represented the development team. We had no work on the table at the start of the “sprint.” We committed to a certain number of pennies, pulled those into our system as fast as we could, and then focused on getting them through. This, too, failed spectacularly. We abandoned that approach after that round.

In another round, I played the role of a Product Owner who needed to accept work as done, as outlined in SAFe’s Product Owner job description. This meant that I, as the PO, would no longer help with “development work” and that the “development team” could no longer help me with my work. This incentivized the team to get work to me early, and then focus on keeping me fed with work throughout the “sprint.” An interesting outcome was that we completed as much work as we did when we worked in the kanban fashion, we just started and ended with no WIP. (Well, almost no WIP at the end. There were a couple pennies that didn’t make it through.)

The only clear-cut takeaway that I think I could use as a training exercise is that teams should focus on getting work to the PO early and keeping that work moving through the PO in a steady flow. If you get too much to the PO to early, the team sits idle waiting on the PO to finish it all. If you get it all to the PO too late, the PO can’t get through it all. However, my gut tells me that this is too convoluted of an exercise to really get that point across.

As a personal lesson, I was reminded of the expression, “all models are wrong, some are useful. With this particular model, the team’s innovation demonstrated that when a team figures out how to game the system, the usefulness of the model in reference to kanban breaks down. And trying to apply this model to Scrum increases the wrongness. Still, I like having the experience in my back pocket in case I see a situation where it might be more useful and less wrong.