Go!

Are you ready to adopt XP? Great! Your first step is to arrange for your open workspace (see Sit Together” in Chapter 6). Start solving this problem now. It will probably take longer than you expect.

Next, find an appropriate project for the team to work on. Look for a project that’s valuable, but be wary of projects that will be under intense scrutiny. You need room to make mistakes as you learn.

Note

Avoid taking a project with low value as a “learning opportunity.” You’ll have trouble involving customers and achieving an organizational success. Your organization could view the project as a failure even if it’s a technical success.

At the same time, figure out who will be on your team. The XP Team” in Chapter 3 provides some suggestions for team structure. Talk with your project’s executive sponsor and other stakeholders about who to include as your on-site customers. (See Real Customer Involvement” in Chapter 6 for ideas.) Be sure your team members want to try XP.

As you’re forming your team, consider hiring an experienced XP coach to work with the team full-time. Although a coach isn’t necessary—I learned XP by reading about it and trying it—a good coach will make things go more smoothly.

It’s a fact of life: change makes people uncomfortable. XP is probably a big change for your team. If you previously used a rigid, document-centric process, XP will seem loose and informal. If you previously had no process, XP will seem strict and disciplined. Either way, expect team members and stakeholders to be uncomfortable. This discomfort can extend into the larger organization.

Discomfort and a feeling of chaos is normal for any team undergoing change, but that doesn’t make it less challenging. Expect the chaotic feeling to continue for at least two months. Give yourselves four to nine months to feel truly comfortable with your new process. If you’re adopting XP incrementally, it will take longer.

To survive the transformation, you need to know why you are making this change. What benefits does it provide to the organization? To the team? Most importantly, what benefits does it provide to each individual? As you struggle with the chaos of change, remember these benefits.

A supportive work environment is also important. Team members are likely to experience defense reactions to the lack of familiar structure. Expect mood swings and erratic behavior. Some team members may lash out or refuse to cooperate. Acknowledge the discomfort people are experiencing, and help team members find constructive outlets for their frustration.

Your stakeholders may be uncomfortable with your team’s new approach to planning and reporting progress. Managers and executives may see the team’s initial chaos as a sign that XP won’t work. To help everyone feel more comfortable, consider giving them this pledge:

Before starting XP, it’s a good idea to discuss working agreements—that is, which practices your team will follow and how your practice of XP will differ from what I describe in this book. (I recommend following the book as closely as you can until you’ve had several months of experience.) Discuss your roles and what you expect from each other. It’s best to hold these conversations as collaborative team discussions. Try to avoid assigning roles or giving people orders.

In the final weeks before starting your new XP project, review the practices in Part II. Try some of the practices in your current work and consider taking courses on the practices that seem challenging.

When you’ve finished these preparations, if you have a greenfield project—meaning your team is creating a new codebase from scratch—you’re ready to go. Review the practices in Part II one more time, take a deep breath, and start your first iteration.

“Wait!” you may say. “Isn’t there a way we can ease into this?”

Well... yes. You can follow the incremental approach that legacy projects use, but if you have a greenfield project, it’s actually easier and faster to adopt all the practices at once. It’s the chaos and uncertainty of change that makes adopting XP difficult, not the practices themselves. If you adopt XP incrementally, every new practice will disrupt the equilibrium you’ll be fighting to achieve. You’ll actually extend the period of chaos and uncertainty, making the transition all the more difficult. In my experience, teams that adopt XP incrementally make substantial improvements, but it’s the teams that adopt it all at once that really excel.

Be bold. You have the right people, the right workplace, and the will to succeed. Do it!

When starting a brand-new XP project, expect the first three or four weeks to be pretty chaotic as everyone gets up to speed. During the first month, on-site customers will be working out the release plan, programmers will be establishing their technical infrastructure, and everyone will be learning how to work together.

Some people think the best way to overcome this chaos is to take a week or two at the beginning of the project to work on planning and technical infrastructure before starting the first iteration. Although there’s some merit to this idea, an XP team should plan and build technical infrastructure incrementally and continuously throughout the project as needed. Starting with a real iteration on the first day helps establish this good habit.

Your very first activity is to plan your first iteration. Normally, this involves selecting stories from the release plan, but you won’t have a release plan yet. Instead, think of one feature that will definitely be part of your first release. Brainstorm a few must-have stories for that feature. These first few stories should sketch out a “vertical stripe” (see Figure 8-3) of your application. If the application involves user interaction, create a story to display the initial screen or web page. If it includes reporting, create a story for a bare-bones report. If it requires installation, create a story for a bare-bones installer.

Don’t expect much from these initial stories. The programmers’ estimates for them will be fairly high because they need to establish some technical infrastructure. As a result, the stories should do very little. The report might display headers and footers, but no line items. The installer might just be a .zip file. The initial screen might have nothing more than your logo on it.

Important

Estimating

These basic stories will give you ideas for more stories that will add missing details. Brainstorm 10 to 20 in the first planning session and have the programmers estimate them. These should keep the programmers busy for several iterations. Try to choose stories that the programmers already understand well; this will reduce the amount of time customers need to spend answering programmer questions so they can focus on creating the release plan.

Iteration planning is a little more difficult during the first iteration because you haven’t established a velocity yet. Just make your best guess about what your velocity might be. (Some teams add up the available programmer-hours and divide by π.) During the iteration, work on just one or two stories at a time and check your progress every day. This will help you deliver completed stories even if your initial plan is wildly inaccurate.

After you’ve finished planning, programmers should start establishing their technical infrastructure. Set up an integration machine, create your version control repository, and so forth. (I recommend creating engineering tasks for these items during iteration planning. See Iteration Planning” in Chapter 8 for more about the role of engineering tasks in iteration planning.) Once that’s set up, start working on your stories.

During the first iteration, it’s a good idea to have all the programmers work on the first few stories as a group. Set up a projector so the whole team navigates while one person drives. (See Pair Programming” in Chapter 5 for an explanation of driving and navigating.) Sometimes individual programmers (or pairs) peel off to take care of some necessary issue, such as installing a version control system or setting up the programmers’ workstations, but for the most part you should work as a team. This reduces the chaos that occurs when multiple people work on a tiny project and allows you to jointly establish initial conventions, such as project structure, filenames and namespaces, and basic design choices.

After the first few days, the fundamentals should be well-established and the project should be large enough for people to work on separate parts without unduly interfering with each other. At this point, you can break into pairs and work normally. It’s also a good time to schedule your first coding standards discussion. For that first meeting, you can usually just document what you agreed on while working as a group.

While the programmers are working on stories, customers and testers should work on the vision and release plan. First, work with stakeholders to create the product vision. You probably already have an idea what the vision for the project is; now formalize it. Finalizing the vision can take a few weeks, so while that’s in progress, brainstorm the stories for your first feature. Start thinking about other features you want to include, and pick a date for your first release. Decide on your planning horizons as well. (See Release Planning” in Chapter 8 for more about planning horizons.)

Each subsequent iteration will be a little easier to plan. The programmers’ estimates will stabilize and your velocity will become predictable. You’ll be able to estimate the scope of your next release and fill out your planning horizons. The feeling of chaos will subside as the team works in a steady, predictable rhythm.

Greenfield projects can adopt all the XP practices at once. You’ll experience some bumps along the way, but you’ll typically have things figured out in four to nine months.

If you’re working with an existing codebase that has no tests, particularly one that’s been around for a year or more—in other words, if you have a legacy project—you can achieve the same results, but it will take more time. In this case, adopt XP incrementally.

Other than change itself, the biggest challenge in applying XP to an existing project is not writing tests, refactoring, or cleaning up your bug database. The biggest challenge is setting aside enough time to pay down technical debt.

If you have a typical legacy project, your current velocity is a polite fiction based on shortcuts. In other words, you incur new technical debt in order to meet your deadlines. To improve productivity and reduce bug production, not only do you need to stop incurring new technical debt, you need to set aside extra slack (see Slack” in Chapter 8) for paying down the existing debt. This double hit will cause your velocity to go down. It might go down a lot.

Fortunately, as your technical debt decreases, your velocity will rise again. Eventually it will surpass your current velocity. This can take a while. Depending on the amount of technical debt you have and how much slack you set aside for paying it down, expect your velocity to remain low for at least a quarter, probably more.

Note

The more slack you provide for paying down technical debt, the lower your velocity will be, but the less time it will take for your velocity to rise again. Think of velocity as cash flow: the more principal you pay on your debt, the less cash you have each week, but the more quickly you can stop paying interest.

Setting aside slack is a painful decision. However, if you don’t stop accumulating technical debt, your velocity will continue to decrease and your defect production rate will increase. Eventually, the cost of development will exceed the value of even simple changes. Your organization will either shelve the product or rewrite it at great expense.

Product managers, avoid this fate by acting decisively now. This is your best option for turning a debt-ridden legacy project into a long-term asset.

The first thing you need to do is bring structure to your project. Many legacy projects have a chaotic approach to planning, even if they started out well.

Start by introducing XP’s structural practices. Move the team, including customers and testers, into a shared workspace, start pair-programming, conduct iteration planning and retrospectives, and so forth. Apply:

Two-, three-, or even four-week iterations may be best for you. Start with two-week iterations. In particularly challenging environments, you may have trouble making your stories both small and customer-valued (see Stories” in Chapter 8). Consider increasing your iteration length, but talk to your mentor (see Find a Mentor” in Chapter 2) before doing so.

Note

At this point, your method is very similar to the Scrum method. You may find Scrum courses and reading material useful.

Other than working more closely together, the biggest changes will be to planning. Take your existing project plan and convert each line item into a story card. If the stories aren’t customer-centric, that’s OK for now; once the team is used to working in iterations, the customers and the project manager should start revising the stories to make them more customer-centric.

When you are comfortable with the structural practices, begin introducing technical practices.

The biggest problem facing legacy projects is usually excessive technical debt. You need to stop the bleeding by preventing more technical debt from occurring. First, create a ten-minute build. Follow up with continuous integration. Introduce test-driven development.

Meanwhile, reduce existing technical debt by introducing extra slack into your iterations (see Slack” in Chapter 8). Use it to pay down technical debt as described in How to Introduce Slack,” also in Chapter 8. At first, your clean-up efforts will seem fruitless, but over time, you’ll see greater and greater benefits to quality and productivity. As your code quality improves, introduce the remaining practices in Chapters 7 and 9.

These first steps will allow you to steadily pay down technical debt while continuing to make progress on new stories. As the bug rate for new code drops, you can start organizing your bug backlog.

If your team is like most teams, your bug database is full of to-dos, questions, feature requests, and genuine defects. Customers and testers, go through the database and eliminate duplicates and unimportant issues. Close feature requests by turning them into stories or rejecting them. Find another way to address to-dos and questions. When you’re done, the only items remaining should be genuine defects.

Depending on the size of your bug database, you may not be able to do this work in a single session. Chip away at it every iteration, just as the programmers do with technical debt.

If your bug database is in use by stakeholders, support personnel, or other people outside the team, find a way to keep new entries clean. You may be able to institute new policies for using the database, but your best approach is probably to review, clean up, and categorize new entries every day.

When you start this process, your testers will probably spend their time testing each release prior to delivery. A large part of their workload is likely to be manual regression testing. The programmers’ focus on test-driven development will slowly create an automated regression suite and reduce the pressure on the testers.

As time passes, productivity improves, and as programmers have less need to pay down technical debt, use your iteration slack to automate the remaining manual regression tests. You may need to create end-to-end tests at first. Over time, refactor the end-to-end tests into more focused unit and integration tests.

With the regression testing burden eliminated and the team producing few new bugs, the testers will have time available for other work. Take advantage of this opportunity to finish integrating the testers into the team. Move them forward in the process so that, rather than testing after a development phase, they help the team produce higher quality code from the beginning. Have them work with customers to find holes in requirements (see Customer Tests” in Chapter 9) and begin conducting exploratory testing (see Exploratory Testing” in Chapter 9).

XP assumes that you use iterations, not phases, which makes using XP in a phase-based environment difficult. If your organization uses a phase-based approach to development, you may be able to use the XP development practices (see Chapter 7 and Chapter 9) even if you can’t use the other practices.

Your organization may want to try XP within your existing phase-based structure. Your best course of action is to convince your organization to let you try XP’s simultaneous phases. If that doesn’t work, you may be able to shoehorn XP into a phase-based structure. It’s difficult and the exact approach depends on your organization. The following suggestions are a starting point; talk to your mentor for more specific advice.

Your organization may have a planning phase or planning gate that expects you to deliver a detailed plan. If you can, allocate a month for the planning phase and use it to run four actual iterations. (You may be able to combine the planning phase and analysis phase to get more time.) Use the approach described in Release Planning” in Chapter 8 to create your release plan during those first iterations. You’ll end up with a good plan and you will have finished some actual software, too.

If you can’t use this approach, whatever approach your organization currently uses for planning will be fine, although it probably won’t be as accurate as conducting actual iterations.

What if your team doesn’t meet this book’s conditions for using XP? What then?

Although you won’t be able to use all the XP practices in this book, you may be able to add some practices to your existing method. Several practices are easy to adopt and are likely to make an immediate difference:



[10] Avoid permanent markers; they bleed through the paper and damage your whiteboard if you use the wrong pen by mistake.

[11] Thanks to Erik Petersen for this insight.