Conclusion

In concluding, we focus on two points. First, how has Extreme Maintenance helped our engineering group, and second, what things will we be doing in the future to improve on the practices to refine the model that is presented by XP?

Our metrics (although not particularly extensive) seem to show some quantitative improvements in productivity during the period in which pair programming was being used to address specific deliverables or bug fixes for a major customer. This productivity increase has continued beyond the initial experiment. This is perhaps attributable to the fact that more people seem to be using the pair programming and open collaborative spaces we created during that period. As the graph in Figure 20.3 shows, during the period of this effort (the week of November 2, 2000 through the end of November) we saw a measurable peak in productivity over and above the previous several months. This was an improvement of 67% based on the next most productive five-week period, and by looking at the trend line, we see continued improvement.

The graph in Figure 20.3 shows several things. First, the new bugs represent issues that the team must address. An eight-week running average trend line would show that this averages to four issues a week. Second, the number of closed issues represents the number of issues that are resolved in a patch to the customer. This patching cycle represents our XP iteration and is on the order of two to three weeks (note the closure peaks).

One of the greatest success stories concerns improvements in visibility. This is, in our opinion, the greatest single benefit to the entire team. By having a big storyboard set up where we prioritize tasks and discuss progress daily, we are encouraging best practices, giving people an opportunity to see what others are working on, and giving management the chance to gauge actual progress. It's all about improving communications!

Figure 20.6 shows the dramatic improvements in our workflow queues as a result of using the storyboard. In February 2001, when we installed the board, it focused people's attention on the fact that they were allowing issues to go unverified for significant amounts of time. We also saw a dramatic increase in the number of issues that people started to actively work on. It is felt that visibility alone was a strong motivational factor in this turnaround. In the future, we are looking to see how to scale this practice across multiple development sites.

Figure 20.6. Workflow queues

How can XP help us improve even more? First, improving the pair programming initiative is something that we feel can improve our lack of cross-training among the many modules of the code base. Granted, it is not a practice for which this is intended, but it is felt that it is a useful side benefit to a real problem as the team grows smaller. Engineers have accepted the benefits, but we are still in the process of structuring a more general approach to ensuring that the practice of pairing becomes part of the IONA culture. The current plan is to have each new bug, enhancement request, or refactoring effort signed up for by an individual, and to have that individual then be responsible for grabbing a partner to work through the issue. Our technical leads feel comfortable with this approach, and we intend to propose it to the whole team early in 2001.

Second, metrics are critical to the replanning game, but it is difficult to get engineers to contribute. To plan how long it will take to complete a story, you need to know how long it took to complete a similar piece of work, based on the estimates of the engineer to whom the work is assigned. "As the basis for your planning, assume you'll do as much this week as you did last week" [Beck+2000]. Kent Beck and Martin Fowler call this rule "Yesterday's Weather," and we think it is an appropriate analogy.

We are currently running an internal project to improve our ability to enter metrics into our defect tracking system and report on them automatically. The volume of issues makes it difficult to track using a simple spreadsheet, but we do it anyway. Our operations lead speaks to each developer and notes how they have progressed on the work they are doing. The limited metrics we have indicate that it takes an engineer, on average, two ideal weeks to fix a bug [Beck+2000]. This matches exactly the suggested length of time to implement a story in the XP model. By measuring the calendar time with the defect tracking system, we can measure the calendar time it took to resolve an issue, and ultimately measure the velocity of the team [Beck+2000]. This information is invaluable in planning what we will do in the next patch or release iteration.

It is felt that XP represents an extremely viable and successful model for teams involved in maintaining and enhancing any code base. It provides mechanisms for dealing with the dynamic environment that exists in a software development project (customer support issues, feature requests and enhancements, and so on) and yet provides a very structured approach to identifying the features of deliverables as part of planning or replanning efforts. It encourages improvements in engineering practices through mentoring and pair programming, and creates an environment that encourages people to think outside the box, to look for solutions to problems rather than Band-Aids for issues.

We encourage others to look at XP if they are having problems with team productivity and quality in a maintenance environment, or if they see significant communications and prioritization problems or difficulty delivering to schedules in their teams. It appears to have provided our engineering teams with a boost in productivity, quality, and improvements in engineering practice, and an overall feeling of empowerment. Our customer services and sales teams as well as the CEO have all commented on the dramatic improvements.