Introduction
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.
Scoring
Give yourself a 0 (worst), 1, or 2 (best) for each entry, then add up your score for each category.
Plot that score on the corresponding axis, then connect the dots.
Programming
__ Test-first programming
__ Automated unit tests
__ Simple design – embodying “You Aren’t Gonna Need It” (YAGNI)
__ Merciless refactoring – part of the development cycle, code appears “once and only once”
__ TOTAL “PROGRAMMING” SCORE
Planning
__ Planning game – explicit customer and programmer roles, story and task breakdown
__ Frequent/small releases – delivered to users every 1-3 months
__ Short iterations – days to weeks (then delivered to Customer)
__ 40-hour week – team not relying on sustained overtime to maintain its pace
__ TOTAL “PLANNING” SCORE
Customer
__ Dedicated customer – primary responsibility is to be customer of the XP team
__ On-site customer – sits with the team
__ Automated acceptance tests
__ Customer steers – the plan is flexible so the customer can change it at any time
__ TOTAL “CUSTOMER” SCORE
Pair
__ Pair programming – all production code developed by pairs
__ Open workspace – everybody in one room
__ Collective ownership – any pair can change any code
__ Integration machine – machine (or at least token) used to reserve main line of code
__ TOTAL “PAIR” SCORE
Team
__ Continuous integration – at least daily by each pair
__ Unit tests maintained at 100%
__ Metaphor – core names & relations that everybody understands
__ Coding standard – that whole team accepts and uses
__ TOTAL “TEAM” SCORE
Radar Chart
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.
“Distributed XP”
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.
“Developer-Only XP”
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 will suffer.
“XP Subversive”
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.
“Becoming XP”
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.
A Gallery
Parting Thoughts
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.
Resources
- Extreme Programming Explained: Embrace Change, Kent Beck, 1999.
- A Gallery of Team Rooms and Charts – contribute yours!
- Big Visible Charts (xprogramming.com) – Ron Jeffries.
[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.]