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.
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.
The Satir Change Model is one way of understanding teams’ reactions to change. [Smith] has a good article on the Satir model at http://www.stevenmsmith.com/my-articles/article/the-satir-change-model.html that includes tips for helping team members through each stage.
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.
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?”
Be bold. You have the right people, the right workplace, and the will to succeed. Do it!
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.
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.
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.
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.
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:
All the “Collaborating” practices (Chapter 6)
All the “Planning” practices (Chapter 8)
Version control, collective code ownership, and “done done” (described in Chapter 7), and customer reviews (see Incremental Requirements” in Chapter 9)
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.
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.
If users expect to ask questions through your bug database, consider leaving the questions in the database. You risk alienating your users by requiring them to use a different forum.[11]
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.
Either way, as your bug database becomes a reliable bug repository, make a fix or don’t fix decision for each bug. You should probably involve the product manager at some level and you may need the programmers to estimate the cost of fixing some of the bugs.
Over the remainder of the release, fix the bugs and work on preventing their causes as described in No Bugs” in Chapter 7. Continue to pay down technical debt and start applying a bit of root-cause analysis as well.
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.
If your organization conducts an upfront analysis phase, you may receive a requirements document as a fait accompli. In this case, decompose the requirements document into stories. One starting point is to create a story out of each sentence including the words “must,” “shall,” or “should.”
XP assumes the use of incremental design and architecture that is intimately tied to programming with test-driven development. An upfront design phase has little to add to this approach.
XP focuses on improving and adapting the design throughout the project. Simple design is central to doing so. Dedicated design phases often lead to complex designs, so minimize the amount of time you spend on upfront design if you can.
XP fits well into the coding phase. Break your coding phase into one-week iterations and conduct XP as normal.
XP performs a lot of testing every iteration. A phase-based organization that considers XP to be the coding phase and expects a long testing phase might schedule too little time for coding and too much time for testing. However, testing is an important part of XP and should remain integrated.
With a good build, you should be ready to deploy at the end of any iteration. You can schedule XP’s wrap-up activities for the deployment phase.
What if your team doesn’t meet this book’s conditions for using XP? What then?
If you struggle with frequent interruptions, try adopting day-long iterations (see Iteration Planning” in Chapter 8). Use the planning game (see The Planning Game” in Chapter 8) and the team’s measured velocity (discussed in Estimating” in Chapter 8) to conduct a joint planning session at the beginning of each day, then defer all interruptions until the next planning meeting, which will be less than a day away. Be sure to have programmers estimate their own tasks.
If you aren’t interrupted frequently, but still feel a sense of chaos in your planning, try using weekly iterations (see Iterations” in Chapter 3). In this case, you may also benefit from daily stand-up meetings (see Stand-Up Meetings” in Chapter 6) and weekly iteration demos (see Iteration Demo” in Chapter 6). As time goes on, consider using index cards for planning and a big chart to show upcoming work, as described in Release Planning” in Chapter 8.
Frequent retrospectives (see Retrospectives” in Chapter 5) are an excellent way for your team to adapt and improve its process. If your team has the authority to make any improvements to its process, try scheduling weekly or biweekly retrospectives.
A fast, automated build will make a big difference to your quality of life, and it will open up opportunities for other improvements as well. See Ten-Minute Build” in Chapter 7 for more.
Continuous integration not only decreases integration problems, it also drives improvements to your build and tests. See Continuous Integration” in Chapter 7 for more.
Although test-driven development (see Test-Driven Development” in Chapter 9) isn’t as easy to adopt as the other practices, it’s very powerful. Test-driven development is the basis for reducing bugs, increasing development speed, improving your ability to refactor, and decreasing technical debt. It can take some time to master, so be patient.