|IBM home | Products & services | Support & downloads | My account|
|Demystifying Extreme Programming: "XP distilled" revisited, Part 3|
Roy Miller completes his review of XP practices by exploring the customer practices and management practices. The customer practices address the issues of determining which features should be in each release. The management practices help management give business direction to the entire team and keep them focused on the problem at hand. With the programmer practices and joint practices discussed in previous articles, you'll now have the complete picture of XP practices.
Over the last couple months, we've talked about joint practices and programmer practices. Joint practices pull all of the members of our "one team" together; everybody needs to do these all the time. The programmer practices detail the practices that programmers need to follow; while others may care about those practices, programmers need to live them daily.
This month we'll explore the customer practices and management practices. As with the programmer practices and joint practices, some of these practices weren't in the original XP list of 12. In the following sections, after each name, I'll parenthetically note whether the practice is new, unchanged, or maps to an original name. Note that these names are in flux, but the principles probably aren't.
Static documents that feel like contracts don't fit into the XP scene very well. XP teams learn as they go. This doesn't mean you shouldn't think before you start to code. It does mean you should be realistic about how far into the future you can think -- not very far at all. So, should we give up planning? No, but we need to plan differently. The release planning practice covers this, but with XP there's a prerequisite that involves a new way to communicate: story telling.
Think back to some of the requirements gathering exercises you've participated in. You might have conducted interviews, held rather lengthy meetings, and so on. You probably asked some clarifying questions and probed for more detail. At the end, you created a document and sent it around to everybody that mattered (and some people who didn't, but had to get the document anyway for political reasons). They were supposed to review it and sign off that you captured all the requirements. Did that go well? The only time it ever did for me was when the system was trivial, if then. Most of the people who had to sign off on the requirements felt nervous about doing it. They often said things like, "I'll sign off for now so we can proceed, but I'm not sure you captured everything." That made me nervous as I imagined the eleventh-hour revelations about critical requirements we missed. It simply wasn't a recipe for success.
The XP approach is radically different. It proposes that a team sit together in a room and talk about what the proposed system needs to do and how it needs to do it. Programmers or customers write these things down on note cards. Each note card says something like:
As a <some user role>, I need the system to <functional requirement> so that I can <business reason for the requirement>.
The stack of note cards becomes the set of requirements for the system, as they are known right then. The cards don't have exhaustive detail on them. Rather, each card is a promise for a future conversation to flesh out the details. In the meantime, the card simply needs enough meat on it to give the programmers an idea of how much work it will take to build it, and to give the customers enough detail to write an acceptance test (see Acceptance testing).
This form of requirements gathering requires a different skill from the business people who are the source of the requirements. In my experience, people in requirements meetings tend to throw any old thing out there just to go on record as having said it. That way, if something gets missed, it isn't their fault. This is bad for the team and is a significant cause of project failure. What we really need is requirements contributors who are good at telling stories. They tell them at the right level of detail, and they take responsibility for being the one to flesh them out when a pair of developers actually tries to code them.
Some people criticize this XP practice as too informal. I assume they mean that the requirements documents most projects have contain more formal language, each requirement has a reference number, and the requirements gathering process is more focused on arranged meetings with various stakeholders. In my experience, none of those things leads to better -- or more complete -- requirements. In fact, my experience tells me they lead to junk that's outdated as soon as it hits the page.
I have worked on successful projects with such formal requirements documents and requirements gathering methods, but my gut tells me the formal requirements document and process had nothing to do with our success. My teams still had to follow up on each requirement when it came time to code something. We still had to ask the source of the requirements to tell us the story XP says they should tell us to begin with. Why not shorten the process and start with the story? That's what this practice is about. Story telling is a skill, and some people are better at it than others, but everybody who contributes requirements to an XP project has to do it. Fortunately, everyone doing it can improve with practice.
Release planning (Maps to the planning
Some people like to criticize XP as glorified hacking -- just a bunch of cowboys cobbling together a system without any discipline. Wrong. XP is one of the few methodologies out there that recognizes that you can't know everything when you start. Both the customers and the developers will learn things as the project progresses. Only methodologies that encourage and embrace such adaptability will be effective. Status quo methodologies ignore change. XP listens. The way it listens is through release planning.
The main idea behind this practice is to make a rough plan quickly and refine it as things become clearer. The artifacts of release planning are:
The critical factor that lets this style of planning work is to let the customer make business decisions and allow the programmer team to make technical ones. Without that, the whole process falls apart.
Planning happens often, which provides frequent opportunity for either customers or programmers to adjust the plan as they learn new things.
Ideally, customers will have the customer tests for the stories in an iteration written before that iteration is over. Customer tests should be automated and run frequently to ensure developers are not breaking any existing features as they implement new ones. Typically, customers will need some help from the programmer team to write these tests. On one project, we developed a reusable automated customer test framework in Ruby, which in my opinion is the best possible language for the job (unless I can figure out a way to do it in Smalltalk). This framework lets the customer specify "actions" that the system should perform. The syntax is quite English-like. The interesting part is that the test scripts customers write are executable Ruby code. The Ruby framework reads each script, executes each action, and spits out "PASSED" or "FAILED" for each. The framework handles Web applications and desktop applications written with the IBM Standard Widget Toolkit (SWT). Customers have seen the value quickly. My company, RoleModel Software, is planning on making the framework open source.
Not all of the customer tests have to pass all the time. The customer decides which ones are critical and which ones aren't -- that's a business decision. The point is that these tests help customers gauge how "done" the project is. They also allow customers to make informed decisions about whether something is ready for release.
Frequent releases (Maps to small
Release the system as soon as it makes sense to do so. This provides value to the customer as early as possible (remember that money today is worth more than money tomorrow). Frequent releases also provide concrete feedback to developers on what meets customer needs and what doesn't. The team can then include these lessons in its planning for the next release.
Why is this a customer practice? Because the customer team needs to drive what the programmer team releases. The customer team is the one that knows whether certain system functions are useful for users at any point in time. Also, making the customer team responsible for frequent releases keeps them focused on the reason you developed the software in the first place: to deliver a useful product that people will in fact use. The best way to do this is to let your users tell you what they want. Most often, they can't do that very well if they don't have something to see and touch. Give that to them and they'll give you the feedback you need.
Defunct customer practice -- On-site
In my own experience, I have found it vital to be close to the customer. Ideally, I'd like the customer to sit in my cubical area, close enough that he can overhear what the team is saying. That would allow us to ask a question immediately whenever it comes up. Unfortunately, this kind of intimacy can't always happen. The next best thing is to have the customer close by, which means the programmer team has to be located with the customer. It is almost impossible to use XP effectively when you aren't close enough to your customer to ask questions immediately, or at least very soon. We've tried to have a remote customer who is available by phone "anytime," but it just doesn't work as well.
This [practice] is a big shift for management, as it implies giving up control yet still being responsible for the team working effectively.
Having been a project manager, I know this approach sounds a little scary. But driving people like slaves -- or treating them like children -- sounds worse to me and is an approach that is likely to fail. It is very difficult to force somebody to do things your way. Instead, I would rather raise issues, make people confront them, and then let them figure out how to solve the problems. That way, you let developers and customers accept responsibility without abusing them.
Air cover (New)
There are also a lot of administrative and organizational things that get in the way of a team making software, such as signoffs for access to certain environments and getting broken workstations fixed. Management needs to remove those obstacles.
Finally, the team fits into an organization somewhere, and those other groups need to know what the team is doing and why. Management needs to be responsible for this communication.
Sustainable pace (Maps to 40-hour
Management also needs to make sure the team has the time it needs to do what it needs to do. For example, many people consider refactoring a waste of time. In fact, keeping your code clean will allow you to keep your speed up; letting it get dirty will slow you down sooner or later. Management needs to make sure the team gets the time it needs for refactoring and other necessary tasks.