eXtreme Programming eXperienced (Part 2)

The Planning Game

Stories were used in an informal version of the planning game. As the client had never written stories before, Cognitech had to lead the client through writing the first few stories. Once the client understood the purpose of the stories, it started to create them by itself. The client prioritized the stories, and the development team worked through stories in priority order. The full planning game was not played out by defining set stories per iteration. In fact, the iterations were really defined in each steering group meeting on a weekly basis. In these meetings, the last week's worth of stories implemented were reviewed and the stories to carry out in the following week were defined.

Bug killing is always a task less than relished by developers, but by identifying bugs when they are young, it somehow moves into the realm of getting the code working in the first place, which is of course nothing like bug fixing! In order to identify bugs as early as possible the team carried out early and continuous testing, they defined test plans on the first day of the project and built testing tools before and during development phases. This allowed the team to constantly confirm any assumptions made. The test plans and tools were also reviewed by the client to ensure that they were testing the right criteria. Bad tests are often worse than no tests, as they can provide a false sense of security.

As previously mentioned, a daily build and smoke tests also helped to provide overall system status feedback. This involved creating a script that could be run to build the entire system, including the installer and then run it through a set of test harness code. This obviously helps to minimize the risk of integration issues later on in the project life-cycle, it also reduces the risk of producing a low-quality solution. As discussed, it also supports easier defect diagnosis and better progress monitoring. Other side-effects of doing the build and smoke tests include improved morale in the development team and improved customer relations. By providing everybody involved with daily feedback of the state of the system, there are fewer unknowns, and it is often these unknowns that worry developers and clients.

Embrace Change

Adapting to change is one of the main tenets of the XP model, and Cognitech used several approaches to reduce the cost of change throughout the project.

The first approach used was a strong emphasis on iterative design. The project was broken down into a set of stories. These stories were then used by the customer to define the weekly releases. When prioritizing the stories, we insisted that no two stories could have the same priority. The steering group then constantly reviewed the stories and updated the project plan accordingly. The development was then always focused on the highest priority business requirement. This iterative approach created small (micro) milestones that could be tested early and enabled the delivery of the most valuable features as early as possible. Within the first month, the core system was ready to ship. This also made it easier to steer the development and keep the number of bugs down close to zero throughout the process.

Pair programming (also called the buddy system) was used throughout this project. This is usually what most people think of when XP is discussed and is possibly one of the more contentious methods employed within XP. It takes time to perfect pair programming techniques, but it seems to be a worthwhile exercise. There is no doubt that the pair programming carried out by Cognitech on this project helped to reduce the bug rate significantly. Two brains working on a single problem are far more effective than two developers working alone. The developers spot flaws in each other's designs and together produce far more robust and solid code solutions. It also enables the entire team's knowledge of the system to grow faster; and most importantly, it makes the work more fun. Developers who are having fun writing code produce a much higher quality solution. The buddy system also ensures that there is never a reliance on just one person for the project's success, another case of risk reduction. Involving more than one person in each stage of the implementation, makes the code easier to maintain and removes any issues of code ownership.

After the Alpha release of the software, two technical staff from the client spent some time each week working on the code, paired up with Cognitech developers. This had another benefit in that the client could start to take ownership of the code with a low handover cost. There were, however, problems with this approach. The technical staff from the client had no previous experience of pair programming, and there was a culture conflict that needed to be addressed. This was not unexpected, but did need close management from the team coach to make sure the situation was kept under control.

Taking the "always ready to ship" approach to the development had a number of benefits. It meant that there was always a successful outcome, even if the project was cut short. What Jim McCarthy calls "zero defect milestones" was already being practiced at Cognitech before they even heard of XP, so they were used to making sure that all bugs were fixed at each milestone. The main benefit is that shipping the product is just the last milestone in the project, and each milestone is really an opportunity to practice shipping. This is yet another strategy to lower the risk in software development projects, as Jim McCarthy says, "If you slip, don't fall." Kent Beck might put it another way; he would say the world changes and so be prepared for that change and do whatever you can to minimize the impact of change. The mini-milestone approach is supported by always being in a known state and adding features a small step at a time. This is, in turn, supported by carrying out the build and smoke tests.

Conclusion

The more of the XP ideas and methods that were used, the more the development team realized how they all interact with each other. Independently, each method provides a certain amount of value to the development process, but using several together adds up to far more than the sum of the parts.

Another important lesson that Cognitech has learnt from adopting XP is that the development process has to become a relationship with the client and it is not possible to simply "sell" a solution. This is something that is stated in other references, but XP seems to strengthen the ability to actually work this way. XP provides systems that empower the client by the relationship; much of this appears to come from the planning game. It has become clear that this very close relationship that can be formed with a client is likely to be the most important aspect of ensuring the success of the project. XP provides a set of tools that facilitate this.

The direct benefits that Cognitech could see from taking the XP path were:

• The system was produced in small incremental stages.
• A multi-release approach helped keep the focus.
• After each stage, the system was ready to ship.
• If the client's business needs changed, the side-effects to the project would never be catastrophic.
• The development was always tackling the problem most important to the client!

What the client said:

"Cognitech have worked in partnership with ISMA Limited on a mission-critical project. ISMA Limited found Cognitech to be a small but professional company dedicated to delivering quality software. They adhere to the three project rules Time, Cost, Quality, and ISMA Limited found their development technique innovative and effective. We were pleased with Cognitech's up front and open approach and trusted them to complete the project as planned. The final product was delivered on time and was everything we expected."

What is eXtreme Programming?

Extreme Programming (XP) is a formalization of a set of methods that have been shown to work well together. It is based around the idea that the cost of change for a software development project does not need to rise throughout the life-cycle of the project. If the cost of change can be leveled off then the attitude toward the development process can be radically rethought.

XP works with four basic values in order to ensure that high-quality software gets produced to meet the most pressing business needs. These values are: communication, simplicity, feedback, and courage. Each one interacts with each other one, and together they work to create a strong foundation for developing high-quality software solutions.

XP is nothing new, much of what XP preaches is old-school software development techniques, the only difference is that XP pulls them all together and "turns the volume up." The idea is to find the things that work well and make them work even better!

At first glance, XP appears to be driven from the programmer's perspective, but it never loses focus on the business aspects. The importance of the customer's input is highly valued throughout the development process. The XP approach actually empowers the customer to have closer control of the project.

References

1. Dynamics of Software Development by Jim McCarthy; Microsoft Press; ISBN: 1556158238.
2. Rapid Development: Taming Wild Software Schedules by Steve McConnell; Microsoft Press International; ISBN: 1556159005.
3. Extreme Programming Explained by Kent Beck; Longman Higher Education; ISBN: 0201616416.

About the Author

Dr. Neil Roodyn has been involved with software development for far too long. He did his Ph.D. at University College London in software architectures for distributed real-time systems. Neil currently mentors several London-based software houses and teaches around the world.