#Agile Perfection musings

One of the many toys my kids got over Christmas was the game Perfection. I can remember playing this game many times when I was young and I was happy to see my kids take a liking to it. For the uninitiated, the game of Perfection involves matching plastic shapes with their appropriate match on the board before the timer runs out and the spring releases the board and shoots all the pieces in the air. Good old-fashioned fun. Funny thing is that the game has not changed over the years other than introducing subtle mirror image shapes to confound adults who think they have the game figured out. 😦

While I was playing the game with both my children, I couldn’t help to try to instil some Agile principles in their thinking. But to my surprise the kids already were playing the game with the smallest iterations possible. Instead of trying to create batches of shapes to place, they both instinctively took a piece at a time and tried to place them before looking for the next piece. I instead watched them with fascination as they tried to become more efficient by implementing some more traditional processes.

A couple of these were:

  • One interesting observation came with my son. He soon discovered that he could be more efficient if he batched 2-3 pieces in his hand at a time. Fewer pieces than that and he found that there was too much motion to get the pieces and forgetting of where the matches were on the board. More pieces than that and he spent too much time searching through the pieces in his hand to find the one he was looking for. This was quite fascinating as the process he used was sometime looking on the board first to find a matching piece if he remembered it was one of the batch he had just picked up. So to save on motion he sometimes went from hand to board and board to hand if he recognized he had another match in his backlog.
  • Another interesting observation then came with my daughter. My daughter is much more results focused and really disliked the game popping on her. Her first solution was just to add more time to the game so it didn’t pop. 🙂 Once I mentioned that this wasn’t really in the spirit of the game, she then focused on another angle. She focused on the pieces that gave her the most problems and was sure to do those first. Interesting. My 5 year old daughter just performed Risk Mitigation on her Perfection project. Awesome.

So what does this have to do with Agile?

Good question. The game of perfection is at its heart a game about problem solving just like Software Development. And I think the observations about how to be efficient at Perfection can provide some insight in Software Development and Agile Software Development in particular.

If we wanted to complete the comparison to Agile Software Development one could look at the following analogies:

1)      The Perfection Board can be thought of the entire solution for the project

2)      All the shape pieces are the entire backlog of User Stories for the project

3)      The small number of shapes in hand is the iteration backlog

4)      The placing of the shapes in the board is the iteration itself


This leads to the following observations on the process:

1)      Creation of small batches can provide additional efficiency

When the process was matching a shape one by one, there was a lot of movement from the board to the backlog of all the shapes. There was more physical movement and it was harder to remember the location of the pieces on the board AND in the backlog to find the required shape. Once small batches were created, it became apparent that the small batches helped to minimize the amount of motion AND help in the memory of the location of the pieces. Although the board was still the same size, the ability to locate the piece in your hand was much easier. It is much easier for a human brain to focus and remember 5-6 items versus 30 items.

In addition, the small batches provided feedback on our progress throughout the game. You got a much better sense on how you were doing by the duration of the iteration as compared to prior ones.

Iterations assist in minimizing movement, providing focus, and maximizing feedback.

2)      Creation of small batches can group like items together further saving on motion and possibly waste.

One thing that certainly increased the probability of success was when you had successive pieces that ended up being located beside each other on the board. I think this is very analogous to planning User Stories on a project. If you can group the User Stories together in the same iteration, it should save on rework that might be required if you did them separately. In addition, it will also save on subsequent context switching to understand that aspect of the solution again in the future.

I am taking artistic license here by comparing the physical movement of the piece to proper spot on the board to the act of understanding the context of that area of the solution and proposing that adjacent solution areas may impact one another.  So revisiting areas can cause additional work to gain context and also possibly cause some rework.

In addition, other groupings like risky or hard items can also provide additional value.

Not all User Stories are independent and interchangeable, planning is required

3)      Measurement, feedback and learning are critical to any process

 Measurement, feedback and learning are critical to being better. Although the popping of the board is a negative event, it was a key driver to getting better. I’m not sure my kids would have been focused to improve if there was no reason to improve. (although I would have preferred positive reinforcement versus negative reinforcement.) To become better and more efficient, measurement is required. Without providing goals and measuring performance against those goals, we may never have achieved the innovation in our process.

 Goals and Measurement are required for Innovation, but they cannot lead the process. The goals and measures must be managed by people, people should not be managed by goals and measures.  


At the end of the day, the one belief I had that was clarified was that I firmly believe the Iterative approach is better suited for Agile Software Development Projects than Continuous Flow.  This was confirmed by the following three observations:

1)      Iterations assist in minimizing movement, providing focus, and maximizing feedback.

2)      Not all User Stories are independent and interchangeable, planning is required

3)      Goals and Measurement are required for Innovation

Although Continuous Flow has great benefits for processes that are independent, repeatable, and predictable, I firmly believe the problem solving nature of Software Development benefits from the planning, execution, and feedback structures of Iterations.

All from a little game of Perfection. 🙂