Teams Take Learning for Granted

Because continuous learning isn't an articulated value or practice, customers and developers often take learning for granted. It's something that is just supposed to happen.

You might imagine that if a team truly appreciates the XP values of feedback and communication, continuous learning will result. But in practice, this doesn't necessarily happen. Either teams don't associate feedback and communication with continuous learning, or they don't reflect enough to realize that they need to learn. This is understandable. Imagine if XP's 40-hour workweek principle were not articulated but only implied. Do you think teams would strive to work just 40 hours?

I've noticed that XP teams often miss the chance to learn in ways that could significantly improve their performance. XP teams are very code-centric and focused on making functional software. When reflection and learning happen, it's often in a watered-down, haphazard way.

Learning on an XP project today can be a bit like the practice of refactoring was before Kent Beck described it as an XP practice and turned up the knob on this practice to 10. Before XP, programmers would refactor their code when they felt like it, or maybe after code was shipped or released, but not all the time. By articulating refactoring as a practice and defining the importance of doing it continuously ("mercilessly"), XP challenged programmers and teams to improve their process.