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.
Note
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:
Our pledge to users, management, and other stakeholders.
We promise to:
Make steady progress
Finish the features that you consider most valuable first
Show you working software that reflects our progess every week, on (day of week) at (time) in (location)
Be honest and open with you about our successes, challenges, and what we can reasonably provide
In return, we ask you to be patient with changes in our productivity and understanding of our mistakes as we learn this new way of working over the next two quarters.
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.
Important
Plan and build infrastructure incrementally throughout the entire project.
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.
Important
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
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.
Important
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.
Important
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.
Note
In this discussion, I assume you have a project burdened with a lot of technical debt and a high bug rate. If your situation isn’t that bad, this process is still appropriate, if much easier.
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.
Note
You can also rewrite the project from scratch or stop for several weeks to do nothing but pay down technical debt. Although these approaches take less effort than incremental debt paydown, they’re risky. These efforts often take much longer than expected, and you lose feedback from stakeholders as well as the opportunity to take advantage of new business opportunities in the meantime.
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.
Note
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.
Close or defer all the bugs that you decide not to fix in this release. You can revisit them when you plan the next release. At this point, all that remains in the database is bugs that you will fix. Turn these bugs into stories, have the programmers estimate any that remain unestimated, and put them in the release plan.
Note
If you have a lot of bugs, consider spreading bug fixes throughout your plan. Although normally it’s better to fix bugs immediately, spreading out the bugs will allow you to deliver feature enhancements in each iteration, which may be better for stakeholder relations.
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.
Important
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).
This process will allow you to reduce technical debt, increase code quality, and remove defects. As you do, productivity will increase. At first, your progress will be imperceptible. Depending on the amount of technical debt you face, it could take many months to get to the ideal of nearly zero new bugs each month. It will take months more to finish your regression test suite, eliminate the need for a separate pre-release testing phase, and integrate your testers.
As long as each iteration has less debt than the previous, however, you will get there. It will take time and hard work, but it will be well worth it. After the first few months, you should start seeing progress in the form of more reliable estimates and more enjoyable programming.
Note
If you don’t see progress within two months, there may be something wrong. Talk to your mentor (see Find a Mentor” in Chapter 2) for advice.
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.
Important
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.”
If instead you need to create your own requirements document, XP doesn’t have much to add. Use traditional requirements-gathering techniques in this situation, perhaps using iterations and requirements-gathering stories for structure.
Important
Requirements documents can’t replace on-site customers.
Requirements documents aren’t a replacement for a good product manager or on-site customers. Without those people, you will have difficulty filling in missing details in the requirements documents. You will also have more trouble making good schedule/scope trade-offs.
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.
If you can, conduct actual XP iterations during the design phase and work on the first stories in your release plan. Use the time to create an initial design and architecture incrementally. Document the results in your design document.
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.
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:
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.
Get The Art of Agile Development now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
