The goal of the challenge was for each team to pick a work style that aided them in getting the greatest number of puzzles completed in a very short time (10 minutes per sprint). The set of puzzles to solved was a mix of crosswords, mazes, word-search, sudoku, word jumbles, and number blocks. The teams were told that there was no partial credit at the end of the ten minute sprint. The teams were given a menu of practices to choose from:
Teams made an initial selection, then were allowed some adaptation.
In initial selection of work style, teams tended toward twos or threes. As the challenge progressed and they realized how hard the "work" was and how short the time was, they tended to migrate toward 33333 in their style.
Is it surprising that when the chips are down, they opted for less command-and-control to help them increase speed?
.Teams with the highest scores did a few surprising things. One is that they "cheated" by rejecting all work they could not accomplish easily within the 10-minute span. Although they were initially told that they should do the work in the priority order (as it was given to them), they quickly realized that the system was flawed and that taking on tasks larger than 10-minutes was a waste of their time and talent. Rejecting over-sized work gave them a distinctive edge. This is a lesson most agile teams should learn.
Another advantage went to teams where people chose the work based on their skills and interests instead of having work handed to them by a strong leader or by following strict priority. Doing work that interested them, in areas where they had already developed skills, moved them forward. Even so, they found a huge disadvantage in working alone. Most puzzles had at least two people working on them by the end of the second sprint, and this trend continued through the end of the challenge. Even when skills differed, there was no other advantage as great as having a partner.
Teams were further accelerated if they found the "Work-In-Progress sweet spot." If they had too much in progress, very little got finished. If they had too little in progress, stuff got done but scores were lower.
Some teams stopped taking on new work at the 2 minute (remaining) mark. There was little chance in starting jobs that could not be finished by the end of the sprint. Instead they spent the time talking about how they could perform better on the next sprint. Again, a lesson worth learning.
One challenge attendee said that he learned that chaos is hard to manage or predict, but it really helped get things done. I applaud his insight.
I was a little disappointed that some rebel didn't totally crush it by using a style I would never have chosen. That would have been cool, if puzzling. I suppose I'll have to settle for having my agile mindset validated once again.
thank you for sharing this game!
I'd like to play ist with our teams and I'm not sure about two details:
a) every teams chooses as "style" before the challenge starts. When are they allowed to adapt? After every sprint or at any time?
b) What does the "Adjustment" row on your scorecard mean?
a) If they choose 2, they may adapt one attribute between sprints. 1 does not adapt, 3 does always.ReplyDelete
b) I sometimes awarded a bonus point for doing a larger puzzle (word search, large sudoku, crossword)
I didn't talk much about score, but more about improvement from sprint to sprint.
thumbs-up. wish i could have made it.ReplyDelete
New comments today on take-aways from the game, thought I'd share:ReplyDelete
* Learned that work in progress is work at risk.
* Learned that you can only fit so many people into some problems
* Learned that some jobs can't be accepted into a tight timeframe.
* "having different sets of eyes looking at the same problem brings a different perspective and allows to find a solution in different ways"
Would this make a good conference or openspace talk?ReplyDelete