This chapter is from the book
This chapter is from the book
This chapter is from the book
Summary
The examples in this chapter are simplified and can only be read as representative of the use of the methods. However, even in this context one can make observations about their use. While they point out the differences between the methods, they also illustrate some strong similarities. These similarities point to some fundamental principles that can form the foundation for hybrid methods.
Differences
The two approaches have significantly different ideas of the depth and scope of metrics needed to manage the project. TSP has detailed process-control metrics as well as quality and performance measures. The XP measures tend to be product oriented and are used primarily to estimate progress and schedule future iterations.
There is a marked difference between XP and TSP in the specificity of the process followed. XP has a few guidelines and some fairly strict practices, while TSP provides a larger number of detailed scripts, forms, and roles, as well as process exit criteria that serve as baselines for tailoring the project's processes.
The level and scope of project reporting is another activity where the two approaches vary. XP reporting is generally informal and temporal, while TSP has established reports for many of the tasks and phases of the project that are maintained as a history of the project. XP does have a historian, but the XP notion of history is more one of capturing what did and didn't work rather than documenting activity.
Finally, there is a distinct difference in the way the two approaches handle their customer interface. TSP has a much more formal relationship with the customer than XP's collocated, customer participation paradigm. While both seek support from the customer and are committed to satisfy their needs, there is a contractual feel to the TSP customer relationship, as opposed to the collegial feel in XP.
Similarities
Surprisingly, there are strong similarities in the two methods. Both rely heavily on a collaborative team environment with specific responsibilities, roles, and accountability. There are well-defined roles in each method, although the level of specificity of a particular role differs significantly. Following the spiral philosophy, they are both risk- and increment-driven with iterative planning and execution cycles. Both methods do rely on differing levels of performance measurement to support effort estimation. There is a similar emphasis on technical matters. Test-first is espoused by both of the methods, although XP has a stronger requirement for automated test facilities.
Observations
By observing the nature of the interactions and the type of activities performed in implementing both an agile and disciplined method, it is much easier to see the connection points where the methods may be complementary. In Chapters 4 and 5 we will examine how to take advantage of the similarities to develop successful development strategies.
The bottom line, however, is that getting the people factors right is much more important in the end than technology or method considerations. Each method enabled the team to jell around its mode of operation and to find roles for team members that fit their skills and stimulate their growth. It is likely that some or most of the TSP people would be less than satisfied working on the XP team and vice versa. But diversity is what makes life interesting.
Perhaps the most important people factor in both PSP/TSP and XP is what Watts Humphrey might call “preparedness” and what Kent Beck calls “courage.” When PSP/TSP and XP teams are faced with an unanticipated user need, they are quick to respond. They are also quick to prepare and courageously defend a counterproposal for deferring either the previously planned schedule or functionality. Any technique that promotes this kind of preparedness, courage, and solidarity in managing the expectations of overdemanding users has in one stroke removed a major source of software overruns and failures.