This scoring sheet and chart combination is designed to help you assess where you are as a team, in doing the "vanilla" practices of XP.
Who is this for? It's for a team that's moving toward XP, and wants some reminder of what it could be doing to get there. Once a team has adopted the XP practices in a sustainable way, they can and should move beyond them to the practices that work best for that team.
Give yourself a 0 (worst), 1, or 2 (best) for each entry, then add up your
score for each category.
Team, Programming, Planning, Customer, Pair
Variations of "Not XP"
There are many ways a team can be "not XP." I put them all in quotes because
most give up something.
This refers to a team that's trying to do XP, but where the team members are
in different locations. The "pair" dimension suffers, and the team will need to
do something to make up for the missing communications.
In some places, the developers want to adopt XP but don't have support of a
customer. The "customer" dimension will tend to be low, and the "planning"
dimension will not be up to its potential.
"XP for One"
If there's only one programmer on the team, pairing is not possible. If this
is a subcase of "developer-only XP," the "customer" and "planning" dimensions
If a person is part of a bigger team, but they're the only one trying to be XP, all they can do is work on the "programming" dimension. The "pair," "team," "customer," and "planning" dimensions may be completely empty.
I like a lot of ice in my drink. Before I got an ice-maker, I'd always empty
and refill the ice-cube trays whenever they were ready. When I lived alone, this
strategy worked. When I had roommates who didn't value my having lots of ice, it
didn't work. An "XP subversive" faces the same problem: it's no use being the
only person following a coding "standard" or the only person integrating often.
Some teams will cover more of the area as they move towards XP.
"Beyond (Vanilla) XP"
Some teams may have started with the "standard" practices, but then adapted
them to their situation. These charts aren't really addressed to them - they'll
have their own needs.
All the dimensions point to improved communication as a key. The "programming" dimension puts the test-code loop in place, for feedback at the code level. The "team" and "pair" dimensions push for communication within the team, and the "customer" and "planning" dimensions push for better communication with the customer.
This approach to thinking about processes is not there to give you some sort of certification of authenticity, but rather to help you say "Have we tried this? Why wouldn't we do that?" Some teams need a little kick in their thinking, to force them to face the fact that they're weak on customer interaction or testing.
XP asks a team to be reflective, to consider what's working for them. By suggesting a set of practices as a starting point, XP can give a group a reference point and ideas for improvement.
[The idea of an XP radarchart is from Don Roberts and Ron Jeffries; the dimensions and questions were my doing; thanks to Ron and Don for feedback. 12-13-00. Added related articles, Feb., '04.]
Copyright 1994-2010, William C. Wake - William.Wake@acm.org