Discipline in Extreme Programming

Discipline in Extreme Programming Relating XP and CMM in a Discipline Perspective Joakim Recht Department of Computer Science Aalborg University Denmark god@cs.auc.dk Michael L. M. Nielsen Department of Computer Science Aalborg University Denmark lerskov@cs.auc.dk ABSTRACT This article examines discipline in two different paradigms for software development, XP and CMM. Although XP is seen by many as a methodology based on hacking, it is actually highly disciplined, just as processes based on CMM are. However, the type of discipline is very different, and the way discipline is cultivated and maintained is also very different. One goal of this article is uncovering these differences. We argue that the differences are due to opposing world views, basic values, and management styles, and that an understanding of these differences is needed in order to improve processes successfully. Furthermore, we breach the subject of combining these apparently incompatible approaches into a combined framework by dividing a process into different domains of responsibility based on the organizational level. Keywords Discipline, Extreme Programming, CMM, management, leadership, process improvement. 1. INTRODUCTION All software developers want to do a good job delivering the system needed to fulfill customer needs, in the shortest possible time and with the expected quality - Nobody likes working sloppy. Everybody likes doing a good job [4, p. 38]. To do this developers have to be and act like professionals, i.e. having the knowledge of what to do and the discipline to do it [11]. Knowledge can be gained by professionals through education and practicing their profession, but discipline is somewhat harder to achieve. Often, long-term goals conflict with the professionals personal short-term interests. Even though the professional has the knowledge of what to do and how to do it, his own interests might lead him to cut corners. This is a known phenomenon within Software Process Improvement (SPI). Most professionals have good ideas of how their jobs could be improved. However, when asked why they do not actually make the improvements they always have some good excuses, e.g. they are too busy [11]. The question, then, is how to develop this needed discipline. In this article we will examine how the software engineering methodology Extreme Programming (XP) and the SPI model Capability Maturity Model (CMM) cultivate discipline. These two approaches are both highly disciplined as they both fall apart when people does not act professionally and work disciplined. Although XP is seen by many supporters of CMM as pure hacking, advocates of traditional software development have begun recognizing XP as truly disciplined [16] and as a way of driving hackers towards being responsible [5]. As expressed by Alistair Cockburn, XP requires discipline in the sense that people will actually fall away from the practices if they don t have some particular mechanism in place to keep them practicing [6]. CMM, on the other hand, is designed to provide a disciplined environment wherein discipline controls the environment and methods according to specific standards [10]. Although both XP and CMM are disciplined, the discipline is achieved in different ways. Later in this article we will go into detail about the concrete differences between the two approaches. However, for now we are concerned with the most basic difference between XP and CMM - the underlying difference in their understanding of the world. 1.1 Opposing World Views Dahlbom and Mathiassen [7] divide the way we think about the world into two main schools; the mechanistic and the romantic. Advocates of the mechanistic view believe the world is deterministic, and predicting the future is only a matter of a detailed plan specifying what is going to happen. Their focus in software development is on prescribing the development process and continuously improving this process in terms of thorough analysis. Believers of the romantic view, on the other hand, see the world as constantly changing without any possibility of predicting what is going to happen. Instead of trying to control the development process trough descriptions, the romantics see process control as the ability to cope with changes. Mechanists and romantics are the extremes of a framework to understand the way we conceive the world. As with any other framework, you hardly find anyone at the extremes. People tend to be placed somewhere in between, some are more drawn towards a mechanistic view while others tend to view the world as romantics. Looking at CMM and XP through the glasses of this framework, these approaches are quite different in their world view. CMM originates from the predominantly mechanistic view with advocates such as Osterweil [15] who sees developers as replaceable parts that can be controlled just as a program on a computer. Because of this fundamental world view CMM has its focus on processes, 1

planning, and documentation. XP, on the other hand, was developed by some of the romantics behind the wave of agile methodologies. The ideas of this wave are articulated in the manifesto for agile software development 1 [8] where, among other things, the differences between traditional and agile software development are drawn up (see table 1). This outline illustrates well the impact of a romantic line of thought over a mechanistic mentality. The Agile Manifesto Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan Table 1: Agile over traditional software development. In this article we will, as previously stated, go into detail about the differences in how XP and CMM achieve discipline. We will make it clear that maintaining the discipline requires the ability to perform according to XP or at least make deliberate choices when not. However, before we begin analyzing XP and CMM mechanisms for discipline, we want to give a definition of discipline as we see it, as the term is subject to many different interpretations. Following the discussion of the term discipline we analyze the various discipline mechanisms in XP and CMM in sections 3 and 5 which will help understand what to look at when considering alternatives for discipline mechanisms. This leads us to a discussion of discipline in section 7, ending with some considerations on how management style can affect discipline and on how XP and CMM might be combined to form a useful framework. 2. DISCIPLINE If we look in the Merriam-Webster dictionary, one of the definitions of discipline is a rule or system of rules governing conduct or activity. This fits well with the definition of a disciplined process which Zahran gives in [20], a disciplined process will manifest itself in ordered and consistent patterns of behaviour. However, the words rule and system imply that the right way of doing things is explicitly formulated and controlled, which is in line with the mechanistic world view where everything is ordered and can be described through rules. The romantic world view, on the other hand, takes another stance, namely that everything is chaotic and can only be described through examples [7]. Taking those two interpretations into consideration, we prefer a broader definition of discipline, namely mechanisms governing conduct or activity. In this definition mechanisms are understood to be the union of rules, regulations, values, tools, and other ways of controlling behavior. This definition does not state anything about the source of the mechanisms or by whom they are controlled. It does, however, say that there will always be a common understanding of how to do something, so if, for example, a group is working disciplined, all the members are acting according to corresponding mechanisms, with a common goal and each 1 Further information about agile development can be found at www.agilemanifesto.org. contributing to the final solution. In figure 1 such a situation is illustrated together with a situation with very low discipline [20]. Another way of describing discipline is that working disciplined means doing what should be done even though it might be very hard, and at the same time not doing what is not necessary although it might be very enjoyable. Humphrey [10] also mentions discipline as control over the working environment and methods according specific standards. Again, our view is that this description is a little too strict, as the control can also be according to implicit standards, for example common values. Figure 1: Low vs high discipline. Discipline can be divided into two categories depending on the source of the mechanisms governing conduct. The source can either be external or internal. When the source is external, some entity other than the object itself seeks to control discipline, for example through rules and regulations. In software development, this is used for example when the development is controlled through process descriptions or award programs. Although the developers might not sympathize with the approach, the reasons behind the processes might be valid, and the developers follow them because they are told to, not because they necessarily want to. The opposite to the external source is the internal where discipline is controlled by mechanisms coming from those doing the work. When this is the case, they themselves have found the right way of doing things. In software development, this corresponds to a situation where a team introduces new practices to improve development because they feel it is the best to do, without anybody telling them to do so. Often, discipline is built in two stages, the first where discipline is maintained using external sources which should affect the values of the object so the external sources can be replaced by internal sources, internalizing the behavior. This is the assumption behind many models for process internalization, but the reality is that it is very hard to change the way people think and behave by means of rules and regulations, which are the mechanisms most often used by external sources [14]. The problem is not so much in changing the knowledge of the people. Everybody knows that testing is important, but developing a consistent testing process is difficult. As Sherwin says, change is great when you are its agent; it is only bad when you are its object [19]. The definition of discipline does not say anything about who does the acting. This is not a coincidence, as the acting can take place on different levels. We have given an example where a group is acting, but it might as well be an individual, an organization or an entire community. Figure 2 illustrates the different levels on which we can talk about discipline. At the center is the individual. If there is nobody else interested in ensuring disciplined behavior of the individual, the individual will act only according 2

to internal discipline, as there are no external sources of control. The arrows in the figure indicate that the levels influence each other. The individual might be member of a group, in which case the group s internal discipline will affect the individual s as external discipline, while at the same time the individual s discipline will affect the group s. Likewise, the group can be a part of a larger organization, in which case the group will affect the organization, and the organization will affect the group. In other words, it is important to keep a holistic way of thinking when considering discipline. It is not enough only to take one part into account. The system must be considered as a whole. Individual Group Organization Environment Figure 2: Discipline in different contexts. Having established a common understanding of discipline and how discipline can operate on different levels, we continue with a description of XP and which mechanisms XP contains for maintaining discipline. Then follows a section on discipline in CMM, which represents a different view than XP, and we will see that the mechanisms used in CMM are radically different from those used in XP. Furthermore, we will compare the underlying values of the two paradigms to get a better understanding of these differences. 3. XP ESSENTIALS When speaking of XP most people will emphasize the 12 practices as the essential in this methodology. XP is something about programming in pairs, not documenting anything, and writing tests all the time. However, the practices are only suggestions on how to achieve an XP development process, just like CMM s descriptions of each key process area are only guidelines on how the CMM goals can be met. But what is then the essentials of XP, if it is not the practices? Practices Principles Values it all together. The shell is not necessarily the 12 practices suggested by Kent Beck, it could be any other practices. However, these other practices should be well thought out since they must embrace the basic principles and values, support the whole development process, and the strengths of one practice should cover the weaknesses of another. As stated by Beck: Adopting XP does not mean that I get to decide how you are going to develop. I can tell you what I found to work well. I can point out the consequences that I see from deviating [4, p. 42]. How to devise another set of practices meeting these criteria is not an issue of this article. The point is that it is possible to do XP without following the 12 practices. The values and principles are more important. In this article, however, Beck s practices will be the main focus, since we are convinced that these actually support each other s weaknesses and embrace the core of XP. Let us move into the essentials of XP. 3.1 Values - The Heart of XP Kent Beck [4] has built the methodology around four basic values, which must be shared by the participants of an XP project: Communication is the basis of XP. Any problem occurring can invariably be traced back to lack of communication either between the developers or between the developers and the customer. As such, it is important never to let communication become a secondary priority. Simplicity is to make the simplest solution solving the problem instead of blowing it out of proportions. Developers tend to make solutions complex and generic even though the solutions might only be used in a small number of special cases. Feedback about the current state of the system is valuable information, as it keeps both the developers and the customer up to date with the current state of the system. Without feedback the customer does not know if the system is on schedule and the developers do not know if they implemented what was intended. Courage in the team is needed if it wants success in developing high-quality software. This include both courage to follow ideas, even the wild ones, but also to abandon them if they turn out to be bad. Courage in the team also implies knowing and acknowledging the team s limitations so the team does not embark on projects it cannot fulfill, and so the developers ask for help when needed. Figure 3: The parts of XP. Figure 3 shows that the essential parts are shared values and basic principles, and the practices is the shell holding Even though these four values are regarded as fundamental to XP there lies an even more fundamental value behind these - respect. If the individuals in an XP project do not respect each other then the XP project is doomed to fail. When adopting XP, these four values are aimed at ensuring the discipline of the individuals, i.e. to avoid conflicts 3

between short-term goals of the individuals and long-term goals of the project or organization. If the introduction of XP is to be successful, all participants should subscribe to these values. However, when introducing a new methodology it is very likely that there will be both believers and skeptics. For instance, implementing CMM is highly vulnerable to turf guarding, cynicism, or an attitude towards SPI that it gets in the way of real work [9]. Therefore, if the values are not backed up by something more it is hard to get people to adopt them. In XP this is done by the principles. 3.2 From Heart to Principles From the values Kent Beck derives a number of basic principles that should be adopted by the organization to support XP. Where a value can be vague, principles are more concrete and tangible; either you have rapid feedback or you do not. In XP the basic principles are: Rapid feedback is the best way to learn. Get feedback, interpret it, and put the new knowledge into the system as quickly as possible. Assume simplicity by solving today s problems as simple as possible. If needed, complexity can be added later on. Incremental change by changing a little at a time instead of making revolutions. Embracing change in the work by solving the most pressing problems and at the same time preserving the most options. Quality work is important for both the customer and the developers. If the developers work does not have high quality they do not enjoy their work and therefore will not do it well. Even though the principles are more concrete than the values, each principle embodies all four values. The idea is that the principles are used to guide the invention of the practices needed in the development process. When devising a practice, it can be compared with the principles to see how it measures against them. In this way it is ensured that the practices used actually encompass the core of XP. It should be noted that these five principles are not the only ones. They are, however, the most central. Beck suggests a number of other principles, which could be embraced by the practices used by the XP team [4]. 3.3 Practices - Embracing The Core of XP As stated earlier, the practices used by an XP team must embrace the values and principles. Beck s suggestion on how to devise such practices is to go back to basics where the focus is on coding, testing, listening, and designing. According to Beck, these are the central parts of a stable and predictable software development process. Without coding nothing is developed. If we do not test we have no way of telling whether we have coded what was intended or not. The only way to know what to code and test is by listening. Finally, designing is used to continuously keep coding, testing, and listening. Going back to basics, Beck derives the 12 practices which make up the XP development process: The Planning Game - Determine the scope of the next release using customer priorities and technical estimates. Small releases - Release as often as possible. Metaphor - Use a simple shared story to guide the development. Simple design - Keep it simple by removing any unnecessary complexity. Testing - Drive the development through continuous testing. Refactoring - Restructure the system continuously to enhance its quality. Pair programming - All programming is done in pairs. Collective ownership - Anyone is entitled to change any code in the system at any time. Continuous integration - Integrate and build the system many times a day. 40-hour week - Work no more than 40 hours a week and never work overtime two weeks in a row. On-site customer - Include a real customer in the development team. Coding standards - Code is central to communication which is the reason why its structure should be governed by rules. These 12 practices are aimed at getting the XP team to work in a common direction. In the next section, we will take a closer look at the practices used to ensure discipline. 4. DISCIPLINE IN XP The essentials of XP should now be clear, and it is time to take a closer look at the mechanisms for discipline in XP and discuss the relation between XP and discipline. 4.1 Mechanisms for Discipline in XP The mechanisms for discipline in XP can, roughly speaking, be divided into practices and roles. We have already looked at the practices in XP but there also exists a number of roles in the team. These are the programmer, the customer, the tester, the tracker, the coach, the consultant, and the big boss. We will not go into detail about all of these roles, we will only mention those acting as mechanisms for discipline in the team: 4

The Coach The coach, in non-xp projects often called the project manager, is responsible for the team s process as a whole. When people in the team deviate from the team s process the coach notices this and brings it to the team s attention. In addition, the coach possesses a deeper understanding of the application of XP, which makes her capable of suggesting alternative practices and deciding whether deviation from the team s process is important enough to intervene at all. As the team matures, the role of the coach minimizes - in the end the process should be everybody s responsibility not just that of the coach. However, coaching is a kind of management aimed at ensuring the discipline in the team. The Tracker The tracker is likely to be the same person as the coach, but this is not always the case. His job is to keep track of the team s progress. How good are the estimates, how many tests are devised, and how many actually run. The task of the tracker is to maintain such measures, and, even more important, to make them visible to the team so they can continuously follow the progress. By making progress visible to everybody, discipline is cultivated in both the team and the individual. If progress is slowing down, the team is made aware of the need to identify if the slow-down is due to decreasing discipline. On the individual level, tracking increases the awareness of how much the individual contributes to the product, which cultivates discipline at the individual level since, as previously stated, no one likes doing a bad job. The Big Boss Occasionally any team will not do as they say they do. If the coach does not handle this the big boss, who is not a part of the development team, should insist on it. On the other hand, she should also support the team when needed, e.g. by securing the necessary resources. This role is actual management. If the team does not act as expected the manager cuts through and dictates what the team should do. Just as coaching, the big boss role is management aimed at ensuring team discipline. By looking at the purpose of each of the practices suggested by Beck and considering if they can affect discipline, we have found 5 of the 12 practices to be mechanisms for ensuring discipline, and in the following we will go through them. Testing The concept of test-driven development ensures that the developers test all components of the system as needed on the unit level. The idea is that the developers write the tests before coding. The tests thus encompass the requirements which should be fulfilled. When the tests run, development is done. This approach to development ensures that what should be done is actually done, and the developers can always see when they are done. This makes it easier to avoid feature creeps and over-designing. In addition, developers are not allowed to commit any code that does not pass the tests, which places an external constraint on the developers behavior. Small Releases The software should be released to the customer in small and frequent releases. Small releases have a number of impacts on discipline. First of all, it is easier to make a detailed plan one month ahead in time instead of six months. This decreases the likelihood of people deviating from an unrealistic plan. Secondly, small releases keep people focused and in control. Combined with the customer s priorities, small releases help the developers being focused on developing what the customer really needs and wants. Pair Programming All programming in XP is done in pairs. One developer in charge of the keyboard and one having a grasp of the overall strategy used. The result is that the developers are more productive and focused. If, for example, one developer runs out of ideas on how to implement a specific algorithm the other might have an idea on how to do it. The developers are more focused through cooperation and guidance, and they are able to develop code of high quality by continuously reviewing each other s work. Collective Ownership In XP the developers work as a team and not as individuals. Therefore all developers are responsible for all work products produced by the team. This means that if a developer finds a way of adding value to the project he is entitled to do so. The collective ownership results in enforcing group discipline. Having collective ownership, undisciplined behavior is not only a matter of the individual but the entire team. If a developer deviates from the discipline norms in the team the other members are likely to react to get the developer on the right track again. Coding Standards Small releases and collective ownership make it necessary to follow a common standard for writing code. As any other standard a coding standard regulates the way the developers work. However, XP does not state anything about the form of such a standard - it could either be common agreements, precisely defined rules, or something in between. Both pair programming, collective ownership, and coaching ensures compliance with the standard. If the standard is built using formal rules it might even possible to devise a tool that is able to check for compliance, depending on the semantics of the rules. 4.2 XP and Discipline Returning to the figure of discipline and its context (figure 2) it is hard to tell precisely which levels XP targets. From a naive point of view, XP is aimed at establishing a disciplined development process in the XP team, i.e. the group level. However, practicing XP also depends on the individuals to support the central values. If not, XP is bound to fail. In addition, the organization should adopt the principles into its general policies. Otherwise, the XP team will have a hard time living within the organization s settings. The adoption of XP in the organization is not the hardest, the most difficult part is the adoption in the organi- 5

zation s environment. Within the past couple of years the software industry has begun using the ideas of XP in practice. However, XP teams and organizations have to make an effort convincing the surrounding environment that it will also benefit from supporting the ideas. It is highly unlikely that customers will immediately accept using a methodology where one or more employees have to be placed in the software organization and without knowing in advance what the actual outcome of the development process will be. The latter might be regarded as a common problem for all software development, but in traditional development the software company and the customer sign a contract specifying in detail what the customer gets. In XP the system delivered evolves during the development process as a result of co-operation between the developers and the customer. 4.3 Summary By now it should be clear that XP is not hacking but in fact a highly disciplined methodology for software engineering centering on the basic value of respect. Having respect and adopting the values and principles of XP, a team is already on the way to being disciplined, since its members have a shared understanding of how the development process should be. If the practices and roles suggested by Kent Beck are used, the team also has some mechanisms in place, which effectively influence the discipline of the team as a whole, as well as of the individuals. However, doing XP is like balancing on the edge of a ravine - if you do not stay balanced, undisciplined behavior is not far away. Discipline Mechanisms in XP Roles: the coach, tracker, and big boss Testing Small releases Pair programming Collective ownership Coding standards Table 2: The mechanisms used in XP to cultivate discipline. We have now presented the essential parts of XP and the mechanisms used to govern a disciplined development process. These mechanisms are summed up in table 2 and it is now time to move on to the essentials of the other paradigm investigated in this article - CMM. 5. CMM ESSENTIALS Before we go into detail about the mechanisms used in CMM for ensuring discipline, we will discuss the CMM essentials, that is, the values which lie behind these mechanisms. CMM clearly has a mechanistic view on how the world functions. One of the basic assumptions is that everything can be documented, and that by having documented processes, experience can be handed over, avoiding that mistakes are repeated. In other words, a large part of CMM is about externalizing knowledge in documents which can then be used by other projects or by the organization as a whole to create standard processes. This fits well with the mechanistic view. CMM basically assumes that it is possible to take knowledge from a group of developers and write it down in documents. By handing the documents over to another group of developers, the new group can learn what the old one did and why, and by following the same process, the new group will accomplish the same. The mechanistic view says that everything is predictable, it is only a question of discovering the governing rules. This is what CMM tries to do. It tries to describe the processes used by the developers in order to understand them better and to be able to repeat them successfully. This line of thought has been known quite some time, at least since Leon Osterweil s paper on why software processes are like software [15]. However, CMM s line of thought has a number of drawbacks which are pointed out by Aaen. In [1] Aaen especially points out use of externalization as the root of many SPI related problems. 6. DISCIPLINE MECHANISMS IN CMM In this section, we will describe the mechanisms in CMM for developing and maintaining discipline. Most of these mechanisms are based on external sources of control in some way, which makes CMM radically different from XP. CMM consists of 18 key process areas, each setting a number of goals [17, 18]. Both the purpose of the key process areas and the description of how they should be implemented give indication as to the discipline mechanisms. Plans Every key process area must be planned and the relevant parties must commit to the plans. By committing each other to a common plan, there is some amount of pressure among the people to follow the plan. Written Policies All key process areas require written policies describing how to meet the goals of each area. Projects are therefore limited in their behavior by these policies. However, CMM does not say anything about the level of detail of these policies, only that the policies should exist, and that when they do, they must be followed. Reviews and Audits All processes are reviewed and audited on a regular basis by several parties ranging from project managers to senior managers. This serves several purposes. First of all, the quality of the processes is controlled and it is possible to avoid large deviations from the standard processes. Secondly, it gives attention to process work in the organization, pointing to its importance and urgency. This can help avoiding some of the common pitfalls of process improvement [2], for example neglectation of the effort and loss of process focus. Reporting, Tracking, and Measuring A large part of CMM is about different sorts of monitoring. Monitoring can be used to control discipline in the same way as reviews and audits. It keeps attention focused on the processes and underlines the importance of 6

good processes by measuring performance and improvements. Training The key process areas all require training of those involved in the activities described in the areas. Training developers for certain tasks gives them greater insight in the advantages of performing the activities consistently. Depending on the type of training, higher-level learning can actually take place if the involved parties begin reflecting on their current working processes, which increase the chance of internalizing the new processes. Roles and Responsibilities An important mechanism for maintaining discipline in CMM is the use of roles and responsibilities. All important processes must have a person who is responsible for the process and how it is carried out. The purpose is to ensure responsibility for the processes through officially appointing persons to be it. This makes sure there is attention on all processes all the time. Otherwise, the organization has to trust the employees to have the processes in focus through tacit agreements. Tools Many key process areas depend on tools for supporting the processes. Tools can be important as they help ensuring certain processes are always performed in the same way. For example, by introducing a version control system and requiring all projects use it, a part of the software configuration management process area can be fulfilled. 6.1 Summary If we look a little closer at these mechanisms, we find that most of them depend on one thing, commitment. XP has respect as the underlying value but in CMM, this underlying value is commitment. This underlines the differences between XP and CMM. XP depends on people subscribing to the basic values and principles, with the fundamental value of respect for each other as a driving force. CMM, on the other hand, prescribes how the values can be put into practice and hopes to convince people to commit to the CMM values. CMM assumes that by posing reasonable processes and presenting them to people, the people s individual values can be affected, leading to internal discipline. However, the original source of discipline is still external because the new processes are, to some degree, induced upon the organization, the groups, and the individuals, leaving the main focus on the control aspect. Discipline Mechanisms in CMM Plans Written policies Reviews and audits Monitoring Training Roles and responsibilities Tools Table 3: Discipline mechanisms in CMM. Table 3 summarizes the mechanisms used in CMM for maintaining discipline. If we compare table 3 and table 2, we find that many mechanisms actually depend on the same things, only there is no formality in XP. For example, XP has pair programming where CMM has training. The purpose is the same, to get people to work in a homogeneous way. In XP it is done by informal training by working together with a more experienced colleague. In CMM it is done through a formal training program. CMM has roles that are normally fixed whereas in XP, the roles are more dynamic and can rotate between the members of the groups. However, the XP mechanisms are there to support the group and for them to work, the group has to respect them. The CMM mechanisms are more formal and mechanistic and needs commitment, something we will discuss more in the next section where we will also discuss how respect and commitment affect process improvement. In the next section, we will also continue with a closer comparison with XP and discuss in which contexts CMM and XP operate with regard to figure 2. 7. MANAGEMENT AND LEADERSHIP The underlying values of XP and CMM and the way they affect discipline also have an important influence on process improvement due to the impact they have on how projects are managed. Sherwin [19] argues that there are two opposite styles of management. There is the well-known style where management is based primarily on power and where leadership is a part of the management tool-box. The other style is where leadership without formal power is the central part. Instead of using power to achieve results, leadership is a relation between the leader and the followers, trying to enable the individuals to satisfy their own psychological needs by their own actions. Management then becomes a tool of leadership to achieve the organization s purposes. This view on management requires all managers to think of themselves primarily as leaders, and then as practitioners of management. Having leadership instead of management as the primary method of achieving the organization s goals implies the need for a strong leader, also in the project groups. This emphasizes the need for a good coach in XP, because the coach is the one responsible for guiding the group. The need for strong leaders is one of the dangers of XP, because processes can easily become uncontrolled if leadership is too weak. A natural solution would be to use power to regain control over the processes, but using power is in conflict with the underlying value of XP, respect. On the other hand, CMM is based on the opposite view where leadership is just a part of management. Commitment, the basic value behind CMM, is based primarily on power. Although CMM suggests the use of action teams and pilot projects as the basis for improved processes, this is still selecting only a relatively small part of the organization and trying to generalize on behalf of that. Furthermore, the responsibility for the improvements is often placed in a software engineering process group. Of course, CMM tries to create followers in order to get stable processes, but it does so using power, or external sources of discipline as discussed earlier. 7

However, the use of power has a somewhat positive impact when we look at the organizational level. One thing is creating followers within a group, another is to do it across an entire organization. In this case, power might be a reasonable way of achieving the organization s overall goals. If we look again at figure 2, CMM operates mainly on the organizational level, whereas XP operates on the group level. That CMM is concentrated on the organizational level becomes obvious when studying the CMM practices, as they are all about organizational policies and standards. XP does not really say anything about intergroup coordination or knowledge sharing. If an entire organization is to be built on respect and strong leadership, this demands that all the leaders from top to bottom lead in the same direction and according to the same values and principles. How this is achieved is far from clear, but if it is not achieved, it is likely to result in balkanization among leaders, making the groups more or less autonomous. This is probably one of the reasons why XP is said not to scale very well [3], at least if we by scale mean both the group size and the number of groups working together. XP only says something about how the organization should function indirectly by having some overall values and principles which should always be followed. One suggestion on how to solve the problem of intergroup coordination and knowledge sharing is given by Aaen [1]. In Aaen s approach, SPI is made an everyday concern to the people. This means the organization must seek to establish infrastructures that support learning and reflection. Such infrastructures should support knowledge flow between people, seeking new opportunities, and aligning the organization s software process. Even though CMM itself focuses on the organization, the SEI has developed complementary models for the group and individual levels. These models are the Team Software Process (TSP) [13] and the Personal Software Process (PSP) [12]. PSP aims at improving the individual developers working process by measuring their performances and acting based on the measurements. TSP does more or less the same, only on the group level. PSP and TSP were both developed by Watts Humphrey, and are based on the same principles as CMM. The line of thought behind them is mechanistic as it is with CMM, and they use mainly external sources of control for discipline. However, by introducing developers to PSP first, then to TSP and finally to CMM, the hope is that the developers and groups will have gained some amount of internal discipline, making it easier to make the change from PSP to TSP to CMM, as the purpose PSP and TSP basically is to develop the developers values. Before going on to the conclusion we will sum up on the terms we have used to differentiate XP and CMM in this article. Table 4 is a summary of these terms according to which approach they match best. Of course, the world is not black and white, and the table should not be interpreted literally. Both XP and CMM are placed somewhere between these key words, but the table still shows where the basic ideas come from. XP vs CMM Romantic vs mechanistic Internal discipline vs external discipline Respect vs commitment Leadership vs power Group focus vs organizational focus Table 4: XP and CMM compared. 8. IMPLICATIONS In this article we have argued both XP and CMM strive towards high discipline, and their ultimate goals are the same, namely to create high quality software consistently. However, the mechanisms used are quite different as they are built on different principles and values. Ultimately, these differences come from two different views on the world, the romantic and the mechanistic. The differences do not mean the two are completely incompatible, though. Even XP projects need some ground rules and conditions to work under, and these can be seen as external sources of discipline. This implies that XP projects must not be left completely to themselves because there has to be something, such as organizational policies, providing the start conditions for the projects. Furthermore, we are convinced that in order to improve and keep processes stable in their improved forms, a change in the value sets of the involved parties is needed. This change should occur based on respect and leadership, not commitment and management. If the change is based on power, the processes are in danger of becoming unstable. The result is that people will most likely fall back to their old practice. Looking at table 4 again, we see that comparing XP and CMM is not as simple as one might think. We have been concentrated on how discipline is cultivated and maintained in the two approaches, but even when just looking at discipline we cannot avoid mentioning other areas. The question is if XP and CMM are completely irreconcilable or if they can be combined in some way? We have found indications that a combination might be possible, as CMM operates mainly on the organizational level whereas XP operates on the group level. Furthermore, Sherwin s statement about management being a part of leadership also hints a possible combination of the two approaches, for example using XP for leadership and CMM for management. However, the precise relationship needs further examination. We think there are some interesting perspectives in such a relationship. For example the SPI efforts could be targeted better, and the disadvantages of both CMM and XP can be reduced. Finally, the question of internal versus external sources of discipline is not clear. We believe that process improvement should be based on internal sources, but how is this type of discipline cultivated, and can it be done without passing a stage of external discipline first? If we assume that XP and CMM can be joined in a combined framework, it is hard to say if XP should be a part of CMM or CMM should be a part of XP. If it is impossible to start with internal discipline, it is probably hard to achieve a 8

situation where an organization is based primarily on XP. Cultivating and maintaining discipline in the work of software professionals are issues that have bugged the industry and SPI research for many years. We truly believe XP should be taken into consideration since this approach cultivates discipline on a group level. However, CMM is also needed for its organizational focus in order to be in control. This means that advocates of both camps should not view XP and CMM as competitors but instead work hard to make them coexist. 9. REFERENCES [1] I. Aaen. Software Process Improvement: Blueprints versus Recipes. IEEE Software, July/August 2003. [2] I. Aaen, J. Arent, L. Mathiassen, and O. Ngwenyama. A Conceptual MAP of Software Process Improvement. Scandinavian Journal of Information Systems, 13:81 101, 2001. [3] K. Auer and R. Miller. Extreme Programming Applied: Playing to Win. Addison-Wesley, 2002. [4] K. Beck. Extreme Programming Explained: Embracing Change. Addison-Wesley, 6th edition, June 2001. [5] B. Boehm. Get Ready for Agile Methods, with Care. IEEE Computer, pages 64 69, January 2002. [14] K. Jonas, A. H. Eagly, and W. Stroebe. Attitides and persuation. In M. Argyle and A. M. Colman, editors, Social Psychology. 1999. [15] L. J. Osterweil. Software processes are software too. IEEE Computer Society Press, pages 2 13, 1987. [16] M. C. Paulk. Extreme Programming from a CMM Perspective. IEEE Software, pages 19 26, November/December 2001. [17] M. C. Paulk, B. Curtis, M. B. Chrissis, and C. V. Weber. Capability maturity model for software, version 1.1. Technical Report CMU/SEI-93-TR-024, Software Engineering Institute (SEI), 1993. [18] M. C. Paulk, C. V. Weber, S. M. Garcia, M. B. Chrissis, and M. Bush. Key practices of the capability maturity model, version 1.1. Technical Report CMU/SEI-93-TR-025, Software Engineering Institute (SEI), 1993. [19] D. S. Sherwin. Strategy for winning employee commitment. In Harvard Business Review - On Management, pages 669 685. 1977. [20] S. Zahran. Software Process Improvement - Practial Guidelines for business success. Addision Wesley Longman, Harlow, 1. edition, 1998. [6] A. Cockburn, R. Jefferies, K. Beck, et al. High Discipline Methodology. URL: http://c2.com/cgi/wiki?highdisciplinemethodology, April 2003. [7] B. Dahlbom and L. Mathiassen. Computers in Context - The Philosophy and Practice of Systems Design. NCC Blackwell, 1993. [8] M. Fowler and J. Highsmith. The agile manifesto. software development, August 2001. [9] J. Herbsleb, D. Zubrow, D. Goldenson, W. Hayes, and M. Paulk. Software Quality and the Capability Maturity Model. IEEE Software, pages 30 40, June 1997. [10] W. S. Humphrey. A Discipline for Software Engineering. Addison-Wesley Pub Co, 1st edition, 1994. [11] W. S. Humphrey. Managing Technical People - Innovation, Teamwork, and The Software Process. Addison-Wesley, 1st edition, 1997. [12] W. S. Humphrey. Personal software process. Technical Report CMU/SEI-2000-TR-022, Software Engineering Institute/Carnegie Mellon University, November 2000. [13] W. S. Humphrey. Team software process. Technical Report CMU/SEI-2000-TR-023, Software Engineering Institute/Carnegie Mellon University, November 2000. 9