Getting Started with eXtreme Programming: Toe Dipping, Racing Dives, and Cannonballs
- Getting Started with XP:Toe Dipping, Racing Dives, and Cannonballs
- Finding Your Style
- Appendix: Primary Practices
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
I've read about Extreme Programming and it sounds interesting. It seems so far from where we are today, though. Where do I start? How do I start?
The recently published second edition of Extreme Programming Explained: Embrace Change explains how and why to use XP. But where to start? XP Explained uses the analogy of entering a swimming pool to describe how organizations get started with XP. There are toe dippers, racing divers, cannonballers, and all manner of variations in between. In this paper I'll characterize these styles. I hope you will find a style of applying XP that works for you and your organization.
Here are some of the promised benefits of XP: fewer defects, more predictability, greater flexibility, closer conformance between delivered features and actual needs, and shorter lead time for new features. A typical XP project has weekly milestone releases, each of which is technically ready to deploy. In order to be constantly ready to deploy, the system is being continuously exercised by automated tests, some written by programmers to avoid debugging time and some written by testers and business experts on the team. The whole team; programmers, testers, project and product managers, real customers, and analysts; sits together in an open workspace festooned with up-to-date project information (my favorite being a lava lamp that glows green if the most recent build passed all its tests). Projects requiring more people than fit comfortably in one room are broken into sub-projects which are coordinated conventionally or using a process like Scrum that calls for monthly milestones. This style is similar to how some existing teams work, but it is very different from how others work.
A problem that people have had since the articulation of XP is how to how to start moving from how they work today toward an XP style of development. You want to start in the right place, convince the right people, and "do it right" so you can reap all the benefits. There is no "right". There is just the doing or the freezing in fear. XP is about courage, about embracing the experience of change. It starts when you start and where you start. Eight years of observing and coaching the application of XP has convinced me that there are as many ways of starting and sustaining change as there are ways to get into a swimming pool.
In spite of diversity in applying XP, there are some common factors to successfully instigating change.
- Read XP Explained, 2nd edition. This will give you a shared vocabulary for the techniques you are about to try.
- Share what you have learned with others. Change happens best with the support of a like-minded community.
- Make a public commitment to change. Calling your shot in public is a great motivator to stick with change when it gets hard.
- Make a plan for your changes. XP-style planning is a good way to prioritize when you have too many changes to make all at once. Start with the area you can best leverage.
The XP principles that guide our choice of practices for software development come into play when starting with XP. In addition, there are some other principles to consider regarding how we work and institute change in the workplace:
- Human speed—people can only change so fast. When that speed is exceeded, they revert.
- Self-interest—people need to see why the changes are in their best interest.
- Grow or die—change spreads through an organization. If not, those who have changed will be forced to recant or leave.
- Safety—people need to feel safe to change. The organization needs to support change, through both the inevitable hiccups and the successes. Safety is relative, though, so the risks of the change process may seem safer than a disaster they know is coming.
Applying these principles in different organizations and in different circumstances will result in very different styles of change. Here are three stereotypical ways teams and organizations get started with XP, though the "right" way to start XP for your company is the one you think will work for you.
Toe Dipping
Some people and teams value continuity. They don't want to let go with one hand before they have a firm hold with the other. When they get started with XP they start one practice at a time, firmly instilling one before adding the next, and leaving the rest of their development process intact in the meantime. A few years ago I thought that teams would start with either testing or planning. Experience has shown that the gradual path into XP has many entrances. That's why the second edition of XP Explained describes 13 "primary" practices (listed in the appendix), all of which are safe places to start and any of which will provide some immediate improvement.
Examples of toe dipping include making a point of programming together in a conference room several hours a day, having developers write some automated tests as they code, or even just dividing a big risky release into two smaller releases. Some toe dippers work on XP on their own. Individuals can start improving their own process even if the whole team is not yet ready. Others hire coaches to help facilitate the process.
If you are a toe dipper, think about the area you would most like to improve, find the practice that addresses that issue, and implement it on a trial basis. After a month or two, evaluate the effects of this change, barriers you met, successes you had, and share your experiences with your support community. Then refine or repeat the process to add the next most valuable practices.
Cannonball
Some teams want to feel in control of the changes to their software process. They want quick results and they are willing to deal with the chaos of radical change as long as they are in control. These are the teams that start doing every practice they can at full throttle. The result is, predictably for the short term, chaos; but it can be constructive chaos. Everyone is learning new techniques every day and those techniques interact in unpredictable ways. Some days work smoothly. Others days are like driving in bumper-to-bumper traffic. After a sharp learning curve, things settle out into a much more highly interactive and refined team able to leap small buildings in a single bound. They produce more, make fewer mistakes, and have confidence in themselves and their ability to handle challenges.
The cannonball is attractive when you want a fresh start and there aren't any catastrophic effects from the ensuing chaos. If you are beginning a release planned to take nine months, for instance, a cannonball might be a good choice. It is not a good choice if you have two weeks left before deployment. Amplified positive interactions between practices, quick turnaround, and the confidence boost the team gets from gaining control on their own are all good reasons to try a cannonball.
Some of chaos of the cannonball is mitigated by the synergies between the practices. If you are going from an eight-week testing phase to a one-week testing phase, you would be sunk without the tests written by the programmers.
One of the challenges of managing the cannonball is that groups outside the team are quickly affected by the team's changes. The team will ask for communication sooner and more directly than they used to. They will likely break existing power chains, skipping across the organizational chart to find the information they need to succeed. Whether a cannonball results in lasting improvement depends not only on how the team does its work but also on how the rest of the organization responds to their change. Outside support can encourage a team to stick with their changes long enough to see improvement and form new habits. Executive support for the change is essential for breaking organizational log jams. Otherwise you'll have a frustrated team unable to grow because they can't get the help they need.
Teams that cannonball successfully have a sense of pride and confidence in their accomplishments and flexibility. They know they can adapt to whatever circumstances they encounter.
Racing Dive
Teams that want quick results and are willing to trust outsiders often turn to XP coaches for an "assisted cannonball". A good coach can smooth out the rough edges of your entry and save you some of the pain of learning. The name of the services provided by some coaches, such as "immersion", suggest the experience—dive in and do it. These teams make a lot of changes quickly but they have the support of someone who has been there before and has the experience to eliminate some of the pain and accelerate the learning.
The racing dive is a good choice for a team that wants quick results but can't afford as much floundering and chaos as the cannonballers. It is also a good choice for teams that want the effects of XP but don't have the courage or persistence to make and sustain change on their own.
One of the limitations of learning XP on your own is that teams sometimes can't even imagine working in the XP style. I have pair programmed with self-taught XPers for whom test-first programming and refactoring were a revelation. They didn't realize just how tiny the steps could be, how many tests could profitably be written, and how often they could be run.