Many people's perspectives must come into play for effective software development to occur. The XP practice Whole Team suggests that a variety of people work together in interlinking ways to make a project more effective. They have to work together as a group for each to be successful. Everyone on an XP team has linked his future in the realm of work. XP started out prescribing effective ways for programmers to behave on a project. Here are the beginnings of prescriptions for each member of an XP team.
The principle of flow suggests that more value is created in a smooth, steady stream of software than in occasional large deployments. Flow is particularly important in structuring the different kinds of work that go into software development, but it can be difficult to apply. I remember sitting in an all-day meeting planning how an organization wanted to develop software. The programmers and executives were there at the beginning of the day. Representatives of different specialities were scheduled to join the meeting throughout the day to give their perspectives on what style of development was needed.
The programmers started by talking about XP: risk management, immediate return, feedback, and why we favored activities over phases. Heads were nodding. It all made sense.
Then in came the architects. They explained that, while XP was okay for programming, if they designed the architecture in a phase at the beginning of projects everything would run much more smoothly. They were showered with the arguments for flow and how that meant that they would have to continuously refine the architecture as they went along, starting with just enough architecture to get going. They reluctantly agreed that they could do so, but it wouldn't be as good as an architecture phase.
Next came the interaction designers. They explained that, while XP was okay for programming, if they designed the interaction in a phase at the beginning of projects everything would run much more smoothly. The programmers, executives, and architects came back with all the arguments for flow. The interaction designers supposed they could continuously refine the interaction, starting with just enough interaction to get going; but it wouldn't be as good as if they could do their work at the beginning of the project.
By the time the infrastructure planners proposed that we let them make all the infrastructure decisions at the beginning of the project, the meeting was getting comical. It didn't take long to get their reluctant agreement to work incrementally.
There was no happy ending to this story. You can't be convinced against your will. None of the groups saw themselves as part of a larger whole. Under stress, they reverted to trying to do all of their work up front.
It was as if the different perspectives were roped together walking up a glacier and all they wanted to do was argue about who got to be first in line. It didn't really matter who was first. What the whole team was missing was a sense that they were roped together. Walking abreast, they could make more progress than if any one group tried to force the others to follow.
Testers on an XP team help customers choose and write automated system-level tests in advance of implementation and coach programmers on testing techniques. On XP teams much of the responsibility for catching trivial mistakes is accepted by the programmers. Test-first programming results in a suite of tests that help keep the project stable. The role of testers shifts to early in development, helping define and specify what will constitute acceptable functioning of the system before the functionality has been implemented.
In Weekly Cycle, the first thing that happens to the chosen stories is that they are turned into automated system-level tests. This is one leveraged place for strong testing skills. Customers may have a good idea of the general behavior they want to see, but testers are good at looking at “happy paths” and asking what should happen if something goes wrong. “Okay, but what if login fails three times? What should happen then?” In this role testers amplify communication. They ensure that the system-level tests succeed only when the stories are fully implemented and ready for deployment.
Once the tests for the week are written and failing, testers continue to write new tests as implementation uncovers new details that need to be specified. Testers can also work to further automate and tune tests. Finally, when a programmer gets stuck on a knotty testing problem, a tester can pair with the programmer to help solve the problem.
Interaction designers on an XP team choose overall metaphors for the system, write stories, and evaluate usage of the deployed system to find opportunities for new stories. Addressing the concerns of eventual users is a priority for the team. The tools of interaction design, such as personas and goals, help the team analyze and make sense of the world of the user, although they are no substitute for conversation with real people.
Much advice for interaction designers is based on a phasist model of development: first interaction designers figure out what the system is supposed to do, and then programmers go make it do that. Phases reduce feedback and restrict the flow of value. Mutual benefit is possible between interaction design and the rest of an XP team without separating development into phases.
On an XP team, interaction designers work with customers, helping to write and clarify stories. Interaction designers can use all their usual tools during this process. They also analyze actual usage of the system to decide what the system needs to do next. Interaction designers specify a little bit up front and continue to refine the user interface throughout the life of the project.
Architects on an XP team look for and execute large-scale refactorings, write system-level tests that stress the architecture, and implement stories. Architects apply their expertise a little bit at a time throughout the project. They direct the architecture of the project throughout its evolution. The architecture for a little system should not be the same as for a big system. While the system is little the architect makes sure the system has just the right little architecture. As the system grows, the architect makes sure the architecture keeps pace.
Making big architectural changes in small, safe steps is one of the challenges for an XP team. The principle of the alignment of authority and responsibility suggests that it is a bad idea to give one person the power to make decisions that others have to follow without having to personally live with the consequences. Architects sign up for programming tasks just like any programmer. However, they are also on the lookout for big changes that have big payoffs.
Tests can communicate architectural intent. I talked with the architect of a major credit card processor who said that in such a high-capacity environment you don't want any architecture that might get in the way. To achieve this his team had a sophisticated stress testing environment. When they wanted to improve the architecture they would first improve the stress tests until the system broke. Then they would improve the architecture just enough to run the tests.
I suggested this strategy to an architect at another company. He complained of spending all of his time writing specifications and then explaining them to developers. He was frustrated that he didn't have time to code any more. I suggested he write a testing infrastructure and then use tests instead of specifications and explanations. If he saw a hole in a design he should write a failing test to point it out. I wasn't able to convince him to try the idea, but I still think it's valuable.
Another task for architects on an XP team is partitioning systems. Partitioning isn't an up-front, once-and-for-all task, though. Rather than divide and conquer, an XP team conquers and divides. First a small team writes a small system. Then they find the natural fracture lines and divide the system into relatively independent parts for expansion. The architects help choose the most appropriate fracture lines and then follow the system as a whole, keeping the big picture in mind as the groups focus on their smaller section.
Project managers on an XP team facilitate communication inside the team and coordinate communication with customers, suppliers, and the rest of the organization. Project managers act as team historians, reminding the team how much progress it has made. Project managers need to be creative in packaging the project's information for presentation to executives and peers. To remain accurate, the information changes frequently; which gives project managers the challenge of communicating changes helpfully.
Planning in XP is an activity, not a phase. Project managers are responsible for keeping plans synchronized with reality. They are often in the best position to drive improvement in the planning process itself. Teams may start spending a day on planning every week; but with continual improvement, they can get better results in less time. The best teams accurately plan a week's worth of work in an hour, but achieving this efficiency requires practice.
Information flows both ways, into and out of the team. Project managers facilitate communication coming into the team from customers, sponsors, suppliers, and users. To facilitate communication, they introduce the right person on the team to the right person outside the team as needed, rather than act as a communication bottleneck. Project managers also facilitate communication within the team, increasing cohesiveness and confidence. The power gained from being an effective facilitator exceeds that of being a controller of even important information.
In XP, product managers write stories, pick themes and stories in the quarterly cycle, pick stories in the weekly cycle, and answer questions as implementation uncovers under-specified areas of stories. A product manager doesn't just pick a bunch of stories at the beginning of the project and then sit back. A plan in XP is an example of what could happen, not a prediction of what will happen.
When the team has overcommitted, the product manager helps the team decide priorities by analyzing the differences between actual and assumed requirements. The product manager adapts the story and theme to what is really happening now.
Stories should be sequenced for business, not technical, reasons. The goal is a working system from the first week. Product managers don't necessarily start at the beginning and work through to the end. I talked to the product manager for a planning tool. He wanted to try the editing features first. The programmers didn't think it made sense to modify information before the user could enter it in the first place. Since editing was the most valuable part of the product, the product manager defined a dummy data set that could be entered manually by the programmers. Then everyone could see what editing was like. This gave the whole team an early look at the heart of the product and gave them plenty of time to refine it.
The system should be “whole” at the end of the first weekly cycle. If you plan to process images, you should be able to process an image at the end of the first week. The product manager picks stories to make this happen.
Product managers encourage communication between customers and programmers, making sure the most important customer concerns are heard and acted on by the team. If the team is practicing Real Customer Involvement, product managers are responsible for encouraging the system to grow in a way that meets the particular needs of the customers who are picking stories as well as the market as a whole.
Executives provide an XP team with courage, confidence, and accountability. The strength of an XP team, shared progress toward shared goals, can also be a weakness. What if the team's goal doesn't align with corporate goals? What if the goal drifts because of the pressures and excitements of success? Articulating and maintaining large-scale goals is one job for executives sponsoring or overseeing XP teams.
Another job for executives sponsoring or overseeing XP teams is monitoring, encouraging, and facilitating improvement. Since the goal of XP is making outstanding software development the norm, executives have a right to see not just good software coming from the team, but continuing improvement as well.
Executives are free to ask for explanations about any aspect of an XP project. The explanations should make sense. If they don't, the executive should expect the team to reflect and provide a clear explanation.
Executives should expect honesty and clear explanations of options from the team in any decision-making process. The executive needs to keep perspective in the face of problems, focusing on the actual needs of the organization and requirements of the project even when faced with the need to cut scope. Because of frequent, open communication, when such a decision is required, the executive already has the information necessary to make an informed decision.
I trust two metrics to measure the health of XP teams. The first is the number of defects found after development. An XP team should have dramatically fewer defects in its first deployment and make rapid progress from there. Some XP teams that have been on the path of improvement for several years see only a handful of defects per year. No defect is acceptable; each is an opportunity for the team to learn and improve.
The second metric I use is the time lag between the beginning of investment in an idea and when the idea first generates revenue. Even small organizations typically find they take more than a year from investment to return. Gradually reducing the time from investment to return increases the amount and timeliness of feedback available to the whole team.
Both post-development defects and investment-to-return are indicators of team effectiveness much as a speedometer is an indicator of speed. You don't make a car go faster by grabbing the speedometer needle and moving it over. If you want to go faster, you push on the gas pedal and then look at the speedometer to see if that was effective. Similarly, while you can set goals based on metrics, your team needs to address underlying problems. Trying to “game” the numbers directly will not result in improvement of anything but the numbers and defeats the value of transparency on the project.
XP teams may not match the organization's expectations. Part of the executive's job is presenting the team positively to the rest of the organization. The team is willing to stand or fall on its own merits. The executive needs to have the courage to proceed in the face of criticism. Once the team begins deploying new functionality frequently, the bottleneck in the flow of value will shift elsewhere in the organization. The executive needs to prepare the company to see this shift in a positive light. After the constraint shifts, executives must be prepared to stand firm in the face of demands that software development change back to keep other departments from looking bad.
People evaluating XP teams should understand what an effective team looks like. This may differ from other teams they have seen. For example, talking and working go together on an XP team. The hum of conversation is a sign of health. Silence is the sound of risk piling up. Executives may need to learn new rules of thumb to understand and effectively apply their experience and perspective to XP teams.
The role of technical publications on an XP team is to provide early feedback about features and to create closer relationships with users. The first part of the role comes because the technical writers on the team are the first to see features, often while they are just sketches. If the writer is sitting in the room with the rest of the team he can say, “How am I going to explain that?” Maybe there is a good way to explain it and maybe there isn't. Either way, the team as a whole learns. Explaining the system in prose and pictures is an important link in the chain that creates feedback for the team.
The second part of the role is creating closer relationships with users: helping them learn about the product, listening to their feedback, and addressing confusion with further publications or new stories. The publications can take any form: tutorials, reference manuals, technical overviews, video, and audio. Writers should listen to customers, listening for the types of misunderstandings that arise when users really use the product. Weaknesses in communication are corrected with further publications. Weaknesses in the product turn into input for the planning process. You might, for example, pick stories that address a certain kind of “user error” based on users' criticisms.
The challenge of doing technical publications with XP comes from the pace of change of an XP-developed system. Back in the old days, you would freeze the specification early in development. The writers would turn it into manuals while the programmers turned it into code. In the XP world, the whole precise specification isn't frozen until very late in the game. The better the team, the later it is willing to make big changes. This leaves technical publications always playing catch-up.
You can get close, though. This week's stories can become next week's documentation tasks, putting the completion of the documentation one week behind the completion of the stories. Once you master that, you can try to have the documentation done the same week as the stories.
What would be the perfect documentation? It would be done exactly when the features it documents are done. It would be trivial to update when it was found in need of improvement. It would be cheap. It wouldn't add any time to the basic development cycle. It would be valuable to the users. The writing of it would be valuable to the team.
The XP philosophy is to start where you are now and move towards the ideal. From where you are now, could you improve a little bit? If you are using paper manuals that add six weeks to the deployment cycle, could you go fully electronic? Could you send out paper manuals six weeks after deployment? If you already have fully electronic documentation but it's not done until two months after the features, can you figure out a way to shift the time you spend so it's done two weeks after? The same week?
XP teams should get feedback from actual usage. If the manuals are online at your site, then you can monitor usage. If users never look at a certain kind of documentation, stop writing it. You can find better ways to invest that time. If the documentation is deployed with the product and the product has usage tracking built in, ask to have documentation usage added to the tracking. This will help you provide more of what your customers value.
Users on an XP team help write and pick stories and make domain decisions during development. Users are most valuable if they have broad knowledge and experience with systems similar to the one being built and if they have strong relationships with the larger user community that will use the system once it is fully deployed. Users need to keep in mind that they are speaking for an entire community. They should defer decisions with broad consequences until they can talk with others in that community, giving the team other stories to work on in the meantime.
Programmers on an XP team estimate stories and tasks, break stories into tasks, write tests, write code to implement features, automate tedious development process, and gradually improve the design of the system. Programmers work in close technical collaboration with each other, pairing on production code, so they need to develop good social and relationship skills.
Two challenges have been reported for human resources when teams begin applying XP: reviews and hiring. The problem with reviews is that most reviews and raises are based on individual goals and achievements, but XP focuses on team performance. If a programmer spends half of his time pairing with others, how can you evaluate his individual performance? How much incentive does he have to help others if he will be evaluated on individual performance?
Evaluating XP team members individually need not be much different from evaluating them before applying XP. In XP, valuable employees:
Act respectful.
Play well with others.
Take initiative.
Deliver on their commitments.
Teams have solved the evaluation problem in two ways: either by continuing individual goals, reviews, and raises or by moving to team-based incentives and raises. The transparency of XP gives managers plentiful information on which to base individual evaluations. Every week each team member publicly signs up for, estimates, and accomplishes tasks directly related to work requested by the customers. The need for altruistic behavior, however, moves some teams to give raises to the team as a whole instead of to individuals. Another idea is to mix the two, with individual evaluations and raises and bonuses for excellent teamwork.
Hiring for XP teams can differ from existing hiring practices. XP teams put much more emphasis on teamwork and social skills. Given the choice between an extremely skilled loner and a competent-but-social programmer, XP teams consistently choose the more social candidate. The best interviewing technique is to have the candidate work with the team for a day. Pair programming provides an excellent test of technical and social skills.
Roles on a mature XP team aren't fixed and rigid. The goal is to have everyone contribute the best he has to offer to the team's success. At first, fixed roles can help in learning new habits, like having technical people make technical decisions and business people make business decisions. After new, mutually respectful relationships are established among the team members, fixed roles interfere with the goal of having everyone do his best. Programmers can write a story if they are in the best position to write the story. Project managers can suggest architectural improvements if they are in the best position to suggest architectural improvements.
In saying that the above roles can contribute to an XP team, I don't mean to imply that there is a simple mapping from one person to one role. A programmer may be a bit of an architect. A user may grow into a product manager. A technical writer can also test. The goal is not for people to fill abstract roles, but for each team member to contribute all he can to the team.
As the team matures, keep in mind the alignment of authority and responsibility. Everyone on the team can recommend changes, but they should be prepared to back up their concerns with action.