The following text is excerpted from The Art of Agile Development by James Shore and Shane Warden, published by O'Reilly. Copyright © 2008 the authors. All rights reserved.
What's wrong with this sentence?
What we really need is more keyboards cranking out code.
That's a quote from a manager I once worked with. In a way, he was right: you will never give your customer what she wants without typing on a keyboard.
That wasn't our problem, though. I later realized that our progress had a single bottleneck: the availability of our staging environment. More keyboards wouldn't have helped, even if we had more programmers sitting at them. If we had realized this sooner, we would have been much more productive.
Sometimes the biggest gains in productivity come from stopping to think about what you're doing, why you're doing it, and whether it's a good idea. The best developers don't just find something that works and use it; they also question why it works, try to understand it, and then improve it.
XP doesn't require experts. It does require a habit of mindfulness. This chapter contains five practices to help mindful developers excel.
Pair Programming doubles the brainpower available during coding, giving one person in each pair the opportunity to think about strategic, long-term issues.
Energized Work acknowledges that developers do their best, most productive work when they're energized and motivated.
An Informative Workspace gives the whole team more opportunities to notice what's working well and what isn't.
Root-Cause Analysis is a useful tool for identifying the underlying causes of your problems.
Retrospectives provide a way to analyze and improve the entire development process.
The purpose of this étude is to practice mindfulness. If you're new to agile development, you may use it to help you understand the XP practices, even if you're not currently using XP. If you're an experienced agile practitioner, review Chapter 11 and use this étude to consider how you can go beyond the practices in this book.
Conduct this étude for a time-boxed half-hour every day for as long as it is useful. Expect to feel rushed by the deadline at first. If the étude becomes stale, discuss how you can change it to make it interesting again.
You will need multiple copies of this book (if you don't have enough copies on hand, you can make photocopies of specific practices for the purpose of this exercise), paper, and writing implements.
Step 1. Start by forming pairs. Try for heterogeneous pairs—have a programmer work with a customer, a customer work with a tester, and so forth, rather than pairing by job description. Work with a new partner every day.
Step 2. (Timebox this step to 15 minutes.) Within your pair, pick one practice from Part II of this book and discuss one of the following sets of questions. Pick a practice that neither of you have discussed before, even if you didn't get to lead a discussion yesterday. Timebox your discussion to fifteen minutes. It's okay not to finish the section, particularly if you haven't read it before. You'll have the chance to read it again.
If you aren't using the practice:
What about the practice would be easy to do? What would be hard? What sounds ridiculous or silly?
How does it differ from your previous experiences?
What would have to be true in order for you to use the practice exactly as written?
If you are using the practice:
What aspects of the practice do you differently than the book says? (Observations only—no reasons.)
If you followed the practice exactly as written, what would happen?
What one experimental change could you try that would give you new insight about the practice? (Experiments to prove that the practice is inappropriate are okay.)
Step 3. (Timebox this step to 15 minutes.) Choose three pairs to lead discussions of their answers. Try to pick pairs so that, over time, everyone gets to lead equally. Timebox each presentation to five minutes.