Group Learning

Once teams produce enough learning content, they will need to reflect on and discuss it. There are two good places to do this: For technical matters, the best place is a programmers' study group; and for team, people, or process matters, the best place is in an iteration retrospective. As you will see later, study groups and retrospectives are powerful learning tools, both of which take time away from programming. Some may worry about this lost time. This is fear talking, saying, "We have to act, we don't have time to learn or reflect."

Such fear is quite common on XP projects, particularly when it comes to refactoring. Under pressure, many developers skip refactorings to go faster. They don't yet know that this will eventually slow down the entire team as the code becomes bulkier and more brittle.

It's not easy to understand that you have to slow down to go fast. Taking time to refactor seems as if it may slow you down, but it will actually make you go faster. Taking time to reflect and learn may also seem as if it's slowing you down, but it, too, will make you go significantly faster.

Nevertheless, a coach or team may still be uncomfortable taking the time to conduct group learning sessions because, unlike refactoring, this work doesn't have a directly visible effect on the code. But although the effect of group learnings on the code is indirect, it is nevertheless highly beneficial.

For example, I once worked with an XP team that had experienced a few bumpy iterations. They had not been refactoring enough, and after these bumpy iterations, it became harder to implement new code, given the heavy accumulation of code smells. One day I discovered a particularly potent design smell and pointed it out to my pair. He said that he had known about that problem for a few months. This alarmed me. I wondered, was he the only one who knew about this? Did other programmers or the coach know about it? What other potent smells were out there but unknown to the entire team?

It was clear to me that every programmer on the team needed to at least be aware of the system's potent smells. This would enable them all to pay attention to these smells and consider how to refactor them out of existence. So we began a process of documenting these potent smells on index cards, which we stacked on the group table. Doing this work enabled the group to learn, and those learnings eventually led to direct action.