Working solo on your own project—“scratching your own itch”—can be a lot of fun. There are no questions about which features to work on, how things ought to work, if the software works correctly, or whether stakeholders are happy. All the answers are right there in one brain.
Team software development is different. The same information is spread out among many members of the team. Different people know:
All of this knowledge is necessary for success. XP acknowledges this reality by creating cross-functional teams composed of diverse people who can fulfill all the team’s roles.
XP teams sit together in an open workspace. At the beginning of each iteration, the team meets for a series of activities: an iteration demo, a retrospective, and iteration planning. These typically take two to four hours in total. The team also meets for daily stand-up meetings, which usually take five to ten minutes each.
Other than these scheduled activities, everyone on the team plans his own work. That doesn’t mean everybody works independently; they just aren’t on an explicit schedule. Team members work out the details of each meeting when they need to. Sometimes it’s as informal as somebody standing up and announcing across the shared workspace that he would like to discuss an issue. This self-organization is a hallmark of agile teams.
On-site customers—often just called customers—are responsible for defining the software the team builds. The rest of the team can and should contribute suggestions and ideas, but the customers are ultimately responsible for determining what stakeholders find valuable.
Customers’ most important activity is release planning. This is a multifaceted activity. Customers need to evangelize the project’s vision; identify features and stories; determine how to group features into small, frequent releases; manage risks; and create an achievable plan by coordinating with programmers and playing the planning game.
On-site customers may or may not be real customers, depending on the type of project. Regardless, customers are responsible for refining their plans by soliciting feedback from real customers and other stakeholders. One of the venues for this feedback is the weekly iteration demo, which customers lead.
In addition to planning, customers are responsible for providing programmers with requirements details upon request. XP uses requirements documents only as memory aids for customers. Customers themselves act as living requirements documents, researching information in time for programmer use and providing it as needed. Customers also help communicate requirements by creating mock-ups, reviewing work in progress, and creating detailed customer tests that clarify complex business rules. The entire team must sit together for this communication to take place effectively.
Typically, product managers, domain experts, interaction designers, and business analysts play the role of the on-site customer. One of the most difficult aspects of creating a cross-functional team is finding people qualified and willing to be on-site customers. Don’t neglect this role; it’s essential to increasing the value of the product you deliver. A great team will produce technically excellent software without on-site customers, but to truly succeed, your software must also bring value to its investors. This requires the perspective of on-site customers.
Include exactly one product manager and enough other on-site customers for them to stay one step ahead of the programmers. As a rule of thumb, start with two on-site customers (including the product manager) for every three programmers.
[Coffin] describes an experience with two nearly identical teams, one that did not have on-site customers and one that did. The team with no on-site customers took fifteen months to produce a product with mediocre value:
The total cost of the project exceeded initial expectations and the application under delivered on the user’s functional expectations for the system... real business value was not delivered until the second and third [releases] and even then the new system was not perceived as valuable by its users because it required them to change while providing no significant benefit.
A team composed of many of the same developers, at the same company, using the same process, later produced a product with compelling value in less than three months:
The first production release was ready after 9 weeks of development... it surpassed scheduling and functional expectations, while still coming in on-budget.... In the first two months of live production usage over 25,000 citations were entered using the new system. The application development team continued to deliver new releases to production approximately every six weeks thereafter. Every release was an exciting opportunity for the team of developers and users to provide value to the company and to improve the user’s ability to accomplish their jobs.
One of the primary reasons for this success was customer involvement:
Many of the shortcomings of the [first] system stemmed from a breakdown in the collaborative atmosphere that was initially established. Had users been more involved throughout the project, the end result would have been a system that much more closely aligned with their actual needs. They would have had a greater sense of ownership and communication between the various groups would have been less tense.
...
The success of the [second] system caused many people in the organization to take note and embrace the lessons learned in this project... other projects teams restructured their physical arrangements into a shared project room as the [second] team had done.
If the customers won’t move to the team, move the team to the customers.
Customer involvement makes a huge difference in product success. Make an extra effort to include customers. One way to do so is to move to their offices rather than asking them to move to your office. Make sure the customers agree and that there’s adequate space available.
The product manager has only one job on an XP project, but it’s a doozy. That job is to maintain and promote the product vision. In practice, this means documenting the vision, sharing it with stakeholders, incorporating feedback, generating features and stories, setting priorities for release planning, providing direction for the team’s on-site customers, reviewing work in progress, leading iteration demos, involving real customers, and dealing with organizational politics.
In addition to maintaining and promoting the product vision, product managers are also often responsible for ensuring a successful deployment of the product to market. That may mean advertising and promotion, setting up training, and so forth. These ordinary product management responsibilities are out of the scope of this book.
The best product managers have deep understandings of their markets, whether the market is one organization (as with custom software) or many (as with commercial software). Good product managers have an intuitive understanding of what the software will provide and why it’s the most important thing their project teams can do with their time.
A great product manager also has a rare combination of skills. In addition to vision, she must have the authority to make difficult trade-off decisions about what goes into the product and what stays out. She must have the political savvy to align diverse stakeholder interests, consolidate them into the product vision, and effectively say “no” to wishes that can’t be accommodated.
Product managers of this caliber often have a lot of demands on their time. You may have trouble getting enough attention. Persevere. Theirs is one of the most crucial roles on the team. Enlist the help of your project manager and remind people that software development is very expensive. If the software isn’t valuable enough to warrant the time of a good product manager—a product manager who could mean the difference between success and failure—perhaps it isn’t worth developing in the first place.
Make sure your product manager is committed to the project full-time. Once a team is running smoothly, the product manager might start cutting back on his participation. Although domain experts and other on-site customers can fill in for the product manager for a time, the project is likely to start drifting off-course unless the product manager participates in every iteration. [Rooney] experienced that problem, with regrettable results:
We weren’t sure what our priorities were. We weren’t exactly sure what to work on next. We pulled stories from the overall list, but there was precious little from the Customer [product manager] in terms of what we should be working on. This went on for a few months.
Then, we found out that the Gold Owner [executive sponsor] was pissed—really pissed. We hadn’t been working on what this person thought we should.
In a predictable environment, and by delegating to a solid set of on-site customers, a product manager might be able to spend most of his time on other things, but he should still participate in every retrospective, every iteration demo, and most release planning sessions.
Some companies have a committee play the role of product manager, but I advise against this approach. The team needs a consistent vision to follow, and I’ve found that committees have trouble creating consistent, compelling visions. When I’ve seen committees succeed, it’s been because one committee member acted as de facto product manager. I recommend that you explicitly find a product manager. Her role may be nothing more than consolidating the ideas of the committee into a single vision, and that’s likely to keep her hands full. Be sure to choose a product manager with plenty of political acumen in this case.
Most software operates in a particular industry, such as finance, that has its own specialized rules for doing business. To succeed in that industry, the software must implement those rules faithfully and exactly. These rules are domain rules, and knowledge of these rules is domain knowledge.
Most programmers have gaps in their domain knowledge, even if they’ve worked in an industry for years. In many cases, the industry itself doesn’t clearly define all its rules. The basics may be clear, but there are nitpicky details where domain rules are implicit or even contradictory.
The team’s domain experts are responsible for figuring out these details and having the answers at their fingertips. Domain experts, also known as subject matter experts, are experts in their field. Examples include financial analysts and PhD chemists.
Domain experts spend most of their time with the team, figuring out the details of upcoming stories and standing ready to answer questions when programmers ask. For complex rules, they create customer tests (often with the help of testers) to help convey nuances.
On small teams, product managers often double as domain experts.
The user interface is the public face of the product. For many users, the UI is the product. They judge the product’s quality solely on their perception of the UI.
Interaction designers help define the product UI. Their job focuses on understanding users, their needs, and how they will interact with the product. They perform such tasks as interviewing users, creating user personas, reviewing paper prototypes with users, and observing usage of actual software.
Don’t confuse graphic design with interaction design. Graphic designers convey ideas and moods via images and layout. Interaction designers focus on the types of people using the product, their needs, and how the product can most seamlessly meet those needs.
You may not have a professional interaction designer on staff. Some companies fill this role with a graphic designer, the product manager, or a programmer.
Interaction designers divide their time between working with the team and working with users. They contribute to release planning by advising the team on user needs and priorities. During each iteration, they help the team create mock-ups of UI elements for that iteration’s stories. As each story approaches completion, they review the look and feel of the UI and confirm that it works as expected.
The fast, iterative, feedback-oriented nature of XP development leads to a different environment than interaction designers may be used to. Rather than spending time researching users and defining behaviors before development begins, interaction designers must iteratively refine their models concurrently with iterative refinement of the program itself.
Although interaction design is different in XP than in other methods, it is not necessarily diminished. XP produces working software every week, which provides a rich grist for the interaction designer’s mill. Designers have the opportunity to take real software to users, observe their usage patterns, and use that feedback to effect changes as soon as one week later.
On nonagile teams, business analysts typically act as liaisons between the customers and developers, by clarifying and refining customer needs into a functional requirements specification.
On an XP team, business analysts augment a team that already contains a product manager and domain experts. The analyst continues to clarify and refine customer needs, but the analyst does so in support of the other on-site customers, not as a replacement for them. Analysts help customers think of details they might otherwise forget and help programmers express technical trade-offs in business terms.
A great product vision requires solid execution. The bulk of the XP team consists of software developers in a variety of specialties. Each of these developers contributes directly to creating working code. To emphasize this, XP calls all developers programmers.
Include between 4 and 10 programmers. In addition to the usual range of expertise, be sure to include at least one senior programmer, designer, or architect who has significant design experience and is comfortable working in a hands-on coding environment. This will help the team succeed at XP’s incremental design and architecture.
If the customers’ job is to maximize the value of the product, then the programmers’ job is to minimize its cost. Programmers are responsible for finding the most effective way of delivering the stories in the plan. To this end, programmers provide effort estimates, suggest alternatives, and help customers create an achievable plan by playing the planning game.
Programmers spend most of their time pair programming. Using test-driven development, they write tests, implement code, refactor, and incrementally design and architect the application. They pay careful attention to design quality, and they’re keenly aware of technical debt (for an explanation of technical debt, see XP Concepts” later in this chapter) and its impact on development time and future maintenance costs.
Programmers also ensure that the customers may choose to release the software at the end of any iteration. With the help of the whole team, the programmers strive to produce no bugs in completed software. They maintain a ten-minute build that can build a complete release package at any time. They use version control and practice continuous integration, keeping all but the last few hours’ work integrated and passing its tests.
This work is a joint effort of all the programmers. At the beginning of the project, the programmers establish coding standards that allow them to collectively share responsibility for the code. Programmers have the right and the responsibility to fix any problem they see, no matter which part of the application it touches.
Programmers rely on customers for information about the software to be built. Rather than guessing when they have a question, they ask one of the on-site customers. To enable these conversations, programmers build their software to use a ubiquitous language. They assist in customer testing by automating the customers’ examples.
Finally, programmers help ensure the long-term maintainability of the product by providing documentation at appropriate times.
Everybody codes on an XP team, and everybody designs. Test-driven development combines design, tests, and coding into a single, ongoing activity.
Expert designers and architects are still necessary. They contribute by guiding the team’s incremental design and architecture efforts and by helping team members see ways of simplifying complex designs. They act as peers—that is, as programmers—rather than teachers, guiding rather than dictating.
In addition to the obvious titles (programmer, developer, software engineer), the XP “programmer” role includes other software development roles. The programmers could include a database designer, a security expert, or a network architect. XP programmers are generalizing specialists. Although each person has his own area of expertise, everybody is expected to work on any part of the system that needs attention. (See Collective Code Ownership” in Chapter 7 for more.)
Testers help XP teams produce quality results from the beginning. Testers apply their critical thinking skills to help customers consider all possibilities when envisioning the product. They help customers identify holes in the requirements and assist in customer testing.[6]
Include enough testers for them to stay one step ahead of the programmers. As a rule of thumb, start with one tester for every four programmers.
Testers also act as technical investigators for the team. They use exploratory testing to help the team identify whether it is successfully preventing bugs from reaching finished code. Testers also provide information about the software’s nonfunctional characteristics, such as performance, scalability, and stability, by using both exploratory testing and long-running automated tests.
However, testers don’t exhaustively test the software for bugs. Rather than relying on testers to find bugs for programmers to fix, the team should produce nearly bug-free code on their own. When testers find bugs, they help the rest of the team figure out what went wrong so that the team as a whole can prevent those kinds of bugs from occurring in the future.
These responsibilities require creative thinking, flexibility, and experience defining test plans. Because XP automates repetitive testing rather than performing manual regression testing, testers who are used to self-directed work are the best fit.
Some XP teams don’t include dedicated testers. If you don’t have testers on your team, programmers and customers should share this role.
XP teams self-organize, which means each member of the team figures out how he can best help the team move forward at any given moment. XP teams eschew traditional management roles.
Instead, XP leaders lead by example, helping the team reach its potential rather than creating jobs and assigning tasks. To emphasize this difference, XP leaders are called coaches. Over time, as the team gains experience and self-organizes, explicit leadership becomes less necessary and leadership roles dynamically switch from person to person as situations dictate.
A coach’s work is subtle; it enables the team to succeed. Coaches help the team start their process by arranging for a shared workspace and making sure that the team includes the right people. They help set up conditions for energized work, and they assist the team in creating an informative workspace.
One of the most important things the coaches can do is to help the team interact with the rest of the organization. They help the team generate organizational trust and goodwill, and they often take responsibility for any reporting needed.
Coaches also help the team members maintain their self-discipline, helping them remain in control of challenging practices such as risk management, test-driven development, slack, and incremental design and architecture.
The coach differs from your mentor (see Find a Mentor” in Chapter 2). Your mentor is someone outside the team who you can turn to for advice.
Every team needs a programmer-coach to help the other programmers with XP’s technical practices. Programmer-coaches are often senior developers and may have titles such as “technical lead” or “architect.” They can even be functional managers. While some programmer-coaches make good all-around coaches, others require the assistance of a project manager.
Programmer-coaches also act as normal programmers and participate fully in software development.
Project managers help the team work with the rest of the organization. They are usually good at coaching nonprogramming practices. Some functional managers fit into this role as well. However, most project managers lack the technical expertise to coach XP’s programming practices, which necessitates the assistance of a programmer-coach.
Project managers may also double as customers.
Include a programmer-coach and consider including a project manager.
The preceding roles are a few of the most common team roles, but this list is by no means comprehensive. The absence of a role does not mean the expertise is inappropriate for an XP team; an XP team should include exactly the expertise necessary to complete the project successfully and cost-effectively. For example, one team I worked with included a technical writer and an ISO 9001 analyst.
Projects don’t live in a vaccuum; every team has an ecosystem surrounding it. This ecosystem extends beyond the team to the project community, which includes everyone who affects or is affected by the project.[7] Keep this community in mind as you begin your XP project, as everybody within it can have an impact on your success.
Two members of your project community that you may forget to consider are your organization’s Human Resources and Facilities departments. Human Resources often handles performance reviews and compensation. Their mechanisms may not be compatible with XP’s team-based effort (see Trust” in Chapter 6). Similarly, in order to use XP, you’ll need the help of Facilities to create an open workspace (see Sit Together” in Chapter 6).
Stakeholders form a large subset of your project community. Not only are they affected by your project, they have an active interest in its success. Stakeholders may include end users, purchasers, managers, and executives. Although they don’t participate in day-to-day development, do invite them to attend each iteration demo. The on-site customers—particularly the product manager—are responsible for understanding the needs of your stakeholders, deciding which needs are most important, and knowing how to best meet those needs.
The executive sponsor is particularly important: he holds the purse strings for your project. Take extra care to identify your executive sponsor and understand what he wants from your project. He’s your ultimate customer. Be sure to provide him with regular demos and confirm that the project is proceeding according to his expectations.
The exact structure of your team isn’t that important as long as it has all the knowledge it needs. The makeup of your team will probably depend more on your organization’s traditions than on anything else.
In other words, if project managers and testers are typical for your organization, include them. If they’re not, you don’t necessarily need to hire them. You don’t have to have one person for each role—some people can fill multiple roles. Just keep in mind that someone has to perform those duties even if no one has a specific job title saying so.
At a minimum, however, I prefer to see one person clearly designated as “product manager” (who may do other customer-y things) and one person clearly defined as “programmer-coach” (who also does programmer-y things).
The other roles may blend together. Product managers are usually domain experts and can often fill the project manager’s shoes, too. One of the customers may be able to play the role of interaction designer, possibly with the help of a UI programmer. On the programming side, many programmers are generalists and understand a variety of technologies. In the absence of testers, both programmers and customers should pick up the slack.
The guidelines in this book assume teams with 4 to 10 programmers (5 to 20 total team members). For new teams, four to six programmers is a good starting point.
Applying the staffing guidelines to a team of 6 programmers produces a team that also includes 4 customers, 1 tester, and a project manager, for a total team size of 12 people. Twelve people turns out to be a natural limit for team collaboration.
XP teams can be as small as one experienced programmer and one product manager, but full XP might be overkill for such a small team. The smallest team I would use with full XP consists of five people: four programmers (one acting as coach)and one product manager (who also acts as project manager, domain expert, and tester). A team of this size might find that the product manager is overburdened; if so, the programmers will have to pitch in. Adding a domain expert or tester will help.
On the other end of the spectrum, starting with 10 programmers produces a 20-person team that includes 6 customers, 3 testers, and a project manager. You can create even larger XP teams, but they require special practices that are out of the scope of this book.
Prefer better to bigger.
Before you scale your team to more than 12 people, however, remember that large teams incur extra communication and process overhead, and thus reduce individual productivity. The combined overhead might even reduce overall productivity. If possible, hire more experienced, more productive team members rather than scaling to a large team.
A 20-person team is advanced XP. Avoid creating a team of this size until your organization has had extended success with a smaller team. If you’re working with a team of this size, continuous review, adjustment, and an experienced coach are critical.
All the team members should sit with the team full-time and give the project their complete attention. This particularly applies to customers, who are often surprised by the level of involvement XP requires of them.
Some organizations like to assign people to multiple projects simultaneously. This fractional assignment is particularly common in matrix-managed organizations. (If team members have two managers, one for their project and one for their function, you are probably in a matrixed organization.)
Fractional assignment is dreadfully counterproductive.
If your company practices fractional assignment, I have some good news. You can instantly improve productivity by reassigning people to only one project at a time. Fractional assignment is dreadfully counterproductive: fractional workers don’t bond with their teams, they often aren’t around to hear conversations and answer questions, and they must task switch, which incurs a significant hidden penalty. “[T]he minimum penalty is 15 percent... Fragmented knowledge workers may look busy, but a lot of their busyness is just thrashing” [DeMarco 2002] (p. 19–20).
If your team deals with a lot of ad hoc requests, you may benefit from using a batman, discussed in Iteration Planning” in Chapter 8.
That’s not to say everyone needs to work with the team for the entire duration of the project. You can bring someone in to consult on a problem temporarily. However, while she works with the team, she should be fully engaged and available.
[6] This discussion of tester responsibilities is part of my variant of XP (see the sidebar A Little Lie,” earlier in this chapter). Classic XP doesn’t include testers as a distinct role.
[7] Thanks to David Schmaltz and Amy Schwartz of True North pgs, Inc., for this term.