The First Puzzle Challenge

Today we held the first ever Puzzle Challenge at my client's site.

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:

Team members could one mode of adaptation, leadership, teamwork, noise level, and task switching. A style of 11111 would mean a 1 in each of these categories, a style strongly resembling an "ideal" organization in the buttoned-down 80s. A style of 33333 is basically a productive chaos, which might have been more widely recommended in the free-spirited 60s.

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.