A Bias for Action

XP teams, especially new or inexperienced ones, are often too action-centric. Customers want to keep producing stories and writing acceptance tests, while developers want to keep testing, coding, and refactoring. But when does the process improve? Don't the customers want to get better at what they do: writing stories, planning, interacting with their customers, communicating with development, trimming fat from stories and tasks? And don't developers want to improve at refactoring, pair programming, design, automated testing, patterns, integration, or the simple art of knowing when to ask for help?

Certainly they do. But do they make time to improve? You might think that they don't need to, that learning will just happen over time. But I've been frustrated by the slowness of this process, which is largely due to the lack of time devoted to group learning.

For example, I can learn three hugely valuable things in one day, but my team isn't going to know about these learnings because the process doesn't include time for sharing them.

You might argue that XP does include time for sharing, because XP advises that teams conduct daily stand-up meetings, in which participants physically stand up and give summaries of what they're working on and how they're doing. Isn't that a good time for sharing learnings? Absolutely not.

Stand-up meetings are meant to be quick events they aren't appropriate for conducting learning sessions, in which reflection and dialogue are requisite. So when would be an appropriate time? More to the point: What is the simplest, most cost-effective way to share learnings?