introduction to whole-part-whole teaching

In the post I will give a short introduction to a teaching/learning method called whole-part-whole and how this is paralleled in agile software development.

I was first introduced to the whole-part-whole method in a basketball coach certification course (yes, there are certifications outside of IT…). The guiding question was how complex content like game plays could be best taught to players. In a nutshell it works like this:

At first a new concept is introduced by lining out general principles and pointing out what it is good for. In basketball that could for example be a new play against a certain zone defense. This would be the whole.

Afterwards the coach would break it down into small chunks that would be easier to grasp and to execute. These would be your parts. Each of this chunk would be way more detailed and deal with more subtleties than the whole described before. Furthermore these chunks could build up on one another. Chunk A could be basic moving patterns, chunk B decision making based on defender behavior, chunk C shooting from certain spots. The big question always was if to work on chunks in a sequential or parallel way. In my experience it was a mixture of both. In the given example I would have my team work on chunk A until a basic understanding was there. Then I would go on and work further on chunk A, while introducing B. This way a basic version of the whole concept would come into being quickly, which is the second whole. This whole would be refined again and again by working on the different chunks.

This method has two big advantages in my opinion:

• A basic understanding of what is to come is given in advance
• A basic version of the whole can be put into action quickly

I have put this kind of teaching/learning into action for almost 20 years and feel really good about it.

Maybe that is also the reason why agile software development feels quite natural to me as there are some parallels.

First of all there is a product vision developed in advance (whole). This is realized by different backlog items (stories, chunk, whatever you name them, these are your parts). Putting basic functionality together in terms of a minimum viable product is the first evolution of your second whole. The advantages stay the same in this case. You are able to get a product with basic functionality quickly and it helps you not to get lost in single backlog items by providing a guiding vision in advance.