Maintenance is really the normal state of an XP project. You have to simultaneously produce new functionality, keep the existing system running, incorporate new people into the team, and bid farewell to members who move on.
Every release begins with an exploration phase. You may try big refactorings that you were afraid of late in the previous release. You may try new technology that you intend to add in the next release, or migrate to newer versions of the technology you are already using. You may
experiment with new architectural ideas. The customer may try writing wacky new stories in search of a big winner for the business.
Developing a system that is in production is not at all the same as developing a system that isn't yet in production. You are more careful of the changes you make. You have to be prepared to interrupt development to react to production problems. You have live data that you have to be careful to migrate as you change the design. If preproduction weren't so dangerous, you'd keep from going into production forever.
Being in production is likely to change your development velocity. Be conservative with your new estimates. While you are exploring, measure the effect production support has on your
development activities. I have seen an increase in the ratio of ideal engineering time to calendar time of 50% after having gone into production (from two calendar days per engineering day to three). Don't guess, though; measure.
Be prepared to change the team structure to deal with production. You may want to take turns manning the "help desk," so most of the programmers don't have to deal with production
interruptions most of the time. Be careful to rotate all the programmers through the position—there are things you learn from supporting production that you just can't learn any other way. On the other hand, it isn't as much fun as developing.
Put newly developed software into production as you go along. You may know that parts of the software won't be executed. Put it into the production system anyway. I have been on projects where this cycle was daily or weekly, but in any case you shouldn't leave code lying around for longer than an iteration. The timing depends on how much verification and migration cost. The last thing you need when you are at the end of a release is to integrate a big gob of code, which
"couldn't possibly" break anything. If you keep the production code base and the development code base nearly in sync, you will have much earlier warning of integration problems.
When new members come on the team give them two or three iterations where their job is to ask lots of questions, act as a pair programming partner, and read lots of tests and code. When they feel ready, they can take responsibility for a few programming tasks, but at a reduced load factor. When they have demonstrated that they can deliver, they can raise their load factor.
If the team changes gradually, in less than a year you can replace the original development team with all new people without disrupting either production support or ongoing development. This is a far less risky handoff than the typical "here it is and this stack of paper contains all the information you need." In fact, it is just as important to communicate the culture around the project as the details of the design and implementation, and that can only be done with personal contact.
Death
Dying well is as important as living well. This is as true for XP as for people.
If the customer can't come up with any new stories, then it is time to put the system into mothballs. Now is the time to write a five- to ten-page tour of the system, the kind of document you wish you would find when it comes time to change something in five years.
That's the good reason to die—the customer is happy with the system and can't think of anything they would like to add for the foreseeable future. (I've never experienced this, but I've heard about it, so I included it here.)
There is also a not-so-good reason to die—the system just isn't delivering. The customer needs features and you just can't add them economically. The defect rate creeps up to where it is intolerable.
This is the entropic death you have fought against for so long. XP is not magic. Entropy eventually catches XP projects, too. You just hope that it happens much later rather than sooner.
In any case, we have already posited the impossible—the system needs to die. It should happen with everybody's eyes open. The team should be aware of the economics of the situation. They, the customers, and the managers should be able to agree that the team, and the system, just can't deliver what is needed.
Then it is time for a fond farewell. Throw a party. Invite everyone who has worked on the system to come back and reminisce. Take the opportunity to try to plot the seeds of the system's downfall, so you'll know better what to look for in the future. Imagine with the team how they would run things differently next time.
Chapter 22. Roles for People
Certain roles have to be filled for an extreme team to work—programmer, customer, coach, tracker.
A sports team works best when there are certain roles that someone takes responsibility for. In soccer you have the goalie, the striker, the sweeper, and so on. In basketball you have a point guard, a center, a shooting guard, and so on.
A player taking one of these positions accepts a certain set of responsibilities—setting up teammates for scoring, preventing the other team from scoring, perhaps managing a certain portion of the field. Some of the roles are nearly solitary. Others require that the player correct the mistakes of teammates, or manage their interactions.
These roles become customary, and sometimes even embedded in the rules of the game, precisely because they work. At some time, probably every other combination of responsibilities has been tried. The ones you see today are there because they worked and the other ones didn't. Good coaches are effective at getting a player to work well at their position. They spot deviations from the usual practice of the position and either help the player correct the deviation, or
understand why it is acceptable for that player to do things a little differently.
However, the great coach knows that the positions are merely customary, not laws of nature. From time to time, the game changes or the players change enough so that a new position becomes possible or an old one becomes obsolete. Great coaches are always looking for what advantages could be had by creating new positions and eliminating existing ones.
Another facility of great sports coaches is their ability to mold the system to their players, instead of the other way around. If you have a system that works fabulously if you have quick players, and the team that shows up at the first workout is big and strong instead, then you will do better
creating a new system that lets the team's talents shine. Lots of coaches can't do this. Instead, they get so focused on the beauty of "the system" that they can't see that it isn't working.
All of this is leading up to a big warning about what follows. Here are some roles that are found to have worked well on previous projects. If you have people who don't fit the roles, change the roles. Don't try to change the people (well, not too much). Don't act like there isn't a problem. If a role says, "This person must be willing to take large chances," and you have a watchmaker instead, you have to find a different division of the responsibilities that will meet your goals without the role in question being filled by a risk taker.
For example, I was talking to a manager about a team of his. A programmer was also the
customer. I said that couldn't possibly work, since the programmer has to execute the process and make technical decisions and be sure to defer business decisions to the customer (see the
The manager argued with me. "This guy is a real bond trader," he said, "he just happens to know how to program, too. The other bond traders all like and respect him, and they are willing to trust him and confide in him. He has a solid vision for where the system is headed. The other