Discipline in Extreme Programming
Relating XP and CMM in a Discipline Perspective
Joakim Recht
Department of Computer Science Aalborg University
Denmark
Michael L. M. Nielsen
Department of Computer Science Aalborg University
Denmark
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 op-posing 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 incom-patible 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 short-est possible time and with the expected quality - “No-body likes working sloppy. Every“No-body likes doing a good job”[4, p. 38]. To do this developers have to be and act likeprofessionals, 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’ per-sonal 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 withinSoftware Process Improvement (SPI). Most professionals have good ideas of how their jobs could be improved. However, when asked why they do not actu-ally 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 engineer-ing methodologyExtreme Programming (XP)and the SPI modelCapability Maturity Model (CMM)cultivate disci-pline. These two approaches are both highly disciplined as they both fall apart when people does not act
profes-sionally 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 hack-ers towards being responsible [5]. As expressed by Alistair Cockburn, XP requires discipline in the sense that “peo-ple 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 con-trols the environment and methods according to specific standards [10]. Although both XP and CMM are disci-plined, the discipline is achieved in different ways. Later in this article we will go into detail about the concrete dif-ferences between the two approaches. However, for now we are concerned with the most basic difference between XP and CMM - the underlying difference in their under-standing 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 themechanistic view be-lieve the world is deterministic, and predicting the future is only a matter of a detailed plan specifying what is go-ing to happen. Their focus in software development is on prescribing the development process and continuously improving this process in terms of thorough analysis. Be-lievers of theromantic 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 be-tween, 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 con-trolled just as a program on a computer. Because of this fundamental world view CMM has its focus on processes,
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 articu-lated in the manifesto for agile software development1 [8]
where, among other things, the differences between tradi-tional and agile software development are drawn up (see table 1). This outline illustrates well the impact of a ro-mantic line of thought over a mechanistic mentality.
The Agile Manifesto
·Individuals and interactionsover processes and tools ·Working softwareover comprehensive documentation ·Customer collaborationover contract negotiation ·Responding to changeover following a plan
Table 1: Agile over traditional software develop-ment.
In this article we will, as previously stated, go into detail about the differences in how XP and CMM achieve dis-cipline. We will make it clear that maintaining the disci-pline 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 disci-pline, 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 sec-tions 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, end-ing 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 gov-erning conduct or activity”. This fits well with the defi-nition 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 roman-tic world view, on the other hand, takes another stance, namely that everything is chaotic and can only be de-scribed through examples [7]. Taking those two interpre-tations 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 cor-responding mechanisms, with a common goal and each
1Further information about agile development can be
found atwww.agilemanifesto.org.
contributing to the final solution. In figure 1 such a sit-uation is illustrated together with a sitsit-uation 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 con-trol 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 reg-ulations. In software development, this is used for exam-ple when the development is controlled through process descriptions or award programs. Although the develop-ers 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 mecha-nisms 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 dis-cipline 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 behav-ior. This is the assumption behind many models for pro-cess 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 of-ten used by external sources [14]. The problem is not so much in changing the knowledge of the people. Every-body 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 act-ing 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. Fig-ure 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
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 or-ganization, in which case the group will affect the organi-zation, 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.
Organization
Environment
Group Individual
Figure 2: Discipline in different contexts.
Having established a common understanding of discipline and how discipline can operate on different levels, we con-tinue with a description of XP and which mechanisms XP contains for maintaining discipline. Then follows a sec-tion 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 some-thing about programming in pairs, not documenting any-thing, and writing tests all the time. However, the prac-tices are only suggestions on how to achieve an XP devel-opment 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?
Values Principles Practices
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
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 cri-teria 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 occur-ring can invariably be traced back to lack of commu-nication either between the developers or between the developers and the customer. As such, it is im-portant never to let communication become a sec-ondary 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 ge-neric even though the solutions might only be used in a small number of special cases.
Feedback about the current state of the system is valu-able 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 de-velopers do not know if they implemented what was intended.
Courage in the team is needed if it wants success in de-veloping 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.
Even though these four values are regarded as fundamen-tal to XP there lies an even more fundamenfundamen-tal value be-hind 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 ensur-ing the discipline of the individuals, i.e. to avoid conflicts
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 method-ology it is very likely that there will be both believers and skeptics. For instance, implementing CMM is highly vul-nerable 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 prin-ciples that should be adopted by the organization to sup-port 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 sim-ple as possible. If needed, comsim-plexity can be added later on.
Incremental change by changing a little at a time in-stead of making revolutions.
Embracing change in the work by solving the most pres-sing 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 oncoding,testing,listening, and design-ing. 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 con-tinuously keep coding, testing, and listening. Going backto 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 esti-mates.
Small releases - Release as often as possible.
Metaphor - Use a simple shared story to guide the de-velopment.
Simple design - Keep it simple by removing any unnec-essary complexity.
Testing - Drive the development through continuous test-ing.
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 sys-tem 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 de-velopment team.
Coding standards - Code is central to communication which is the reason why its structure should be gov-erned 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 speak-ing, be divided intopractices and roles. We have al-ready looked at the practices in XP but there also exists a number of roles in the team. These arethe program-mer, 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:
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 pro-cess the coach notices this and brings it to the team’s attention. In addition, the coach possesses a deeper un-derstanding 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 en-suring 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 mak-ing progress visible to everybody, discipline is cultivated in both the team and the individual. If progress is slow-ing 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 previ-ously 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 sug-gested by Beck and considering if they can affect disci-pline, we have found 5 of the 12 practices to be mecha-nisms 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 cus-tomer’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 indi-viduals. 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 individ-ual 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 com-mon 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 pos-sible 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 (fig-ure 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 hard-est, the most difficult part is the adoption in the
organi-zation’s environment. Within the past couple of years the software industry has begun using the ideas of XP in prac-tice. 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 engi-neering 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 de-velopment 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 disci-pline 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 pro-cess. 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 mech-anisms. 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 docu-mented processes, experience can be handed over, avoid-ing that mistakes are repeated.
In other words, a large part of CMM is about external-izing 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 mech-anistic 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 num-ber 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 num-ber of goals [17, 18]. Both the purpose of the key process areas and the description of how they should be imple-mented 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 there-fore 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 se-nior managers. This serves several purposes. First of all, the quality of the processes is controlled and it is possi-ble to avoid large deviations from the standard processes. Secondly, it gives attention to process work in the organi-zation, pointing to its importance and urgency. This can help avoiding some of the common pitfalls of process im-provement [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 monitor-ing. Monitoring can be used to control discipline in the same way as reviews and audits. It keeps attention fo-cused on the processes and underlines the importance of
good processes by measuring performance and improve-ments.
Training
The key process areas all require training of those involved in the activities described in the areas. Training devel-opers for certain tasks gives them greater insight in the advantages of performing the activities consistently. De-pending on the type of training, higher-level learning can actually take place if the involved parties begin reflect-ing on their current workreflect-ing 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 impor-tant 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 at-tention on all processes all the time. Otherwise, the orga-nization 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 en-suring certain processes are always performed in the same way. For example, by introducing a version control sys-tem 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 dif-ferences 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 pos-ing reasonable processes and presentpos-ing them to people, the people’s individual values can be affected, leading to internal discipline. However, the original source of disci-pline 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 exam-ple, XP has pair programming where CMM has training. The purpose is the same, to get people to work in a ho-mogeneous 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 for-mal 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 pro-cess 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 for-mal 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 sat-isfy 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. Commit-ment, 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 orga-nization and trying to generalize on behalf of that. Fur-thermore, 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 pro-cesses, but it does so using power, or external sources of discipline as discussed earlier.
However, the use of power has a somewhat positive im-pact 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 over-all 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 poli-cies 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 leader-ship, this demands that all the leaders from top to bottom lead in the same direction and according to the same val-ues and principles. How this is achieved is far from clear, but if it is not achieved, it is likely to result in balkaniza-tion among leaders, making the groups more or less au-tonomous. 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 organi-zation 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 reflec-tion. 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 Soft-ware Process (TSP) [13] and the Personal SoftSoft-ware Pro-cess (PSP) [12]. PSP aims at improving the individual developers’ working process by measuring their perfor-mances 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. How-ever, 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 disci-pline, 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 inter-preted literally. Both XP and CMM are placed somewhere between these key words, but the table still shows where the basic ideas come from.
XPvsCMM
Romanticvs mechanistic Internal disciplinevs external discipline
Respectvscommitment Leadershipvs power
Group focusvs 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 some-thing, 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 main-tained 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 state-ment about managestate-ment being a part of leadership also hints a possible combination of the two approaches, for ex-ample using XP for leadership and CMM for management. However, the precise relationship needs further examina-tion. 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 improve-ment 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 frame-work, 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
situation where an organization is based primarily on XP. Cultivating and maintaining discipline in the work of soft-ware professionals are issues that have bugged the indus-try and SPI research for many years. We truly believe XP should be taken into consideration since this approach cul-tivates discipline on a group level. However, CMM is also needed for its organizational focus in order to be in con-trol. 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. [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.
[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. InHarvard 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.
