Commitment and Consistency in the Collaborative Software

Development Process of Extreme Programming

D. Woit

and K. Bell

Department of Computer Science, Ryerson University, Toronto, Canada

School of English and Liberal Studies, Seneca College, Toronto, Canada

Keywords: Communication, Collaboration, Software Development Process, Extreme Programming, Qualitative Case

Study.

Abstract: In this work we (i) expose and analyse the social-psychological principle of commitment and consistency

embedded in the Extreme Programming software development process, (ii) illustrate how this principle can

be leveraged to impact upon project success, and (iii) provide practical evidence of the manifestation of this

principle and its effects in the Extreme Programming domain, through nascent results from our qualitative

case study. This work is in its initial stages; our intent is to persuade the reader that commitment and

consistency are indeed relevant factors in Extreme Programming process, are potentially impactful on

organizational success, and are worthy of further study.

1 INTRODUCTION

The work presented here forms part of a larger

project, the goal of which is to produce an overall

positive impact on organizational success, (i) by

exposing and analysing the influences of extant

social-psychological, interpersonal communications

phenomena on collaborative software development

practices, and (ii), by devising guidelines to aid

organizations in leveraging associated positive

influences, while mitigating their potentially

detrimental effects. In this report, we relate initial

work on one element of the project: the social-

psychological commitment and consistency

principle’s role in the collaborative software

development methodology of Extreme Programming

(XP), and the principle’s implications for project

success.

The XP software development methodology

embraces collaboratively-based processes and

practices which are aimed at improving project

success, and are motivated by two crucial elements:

effective communication among the people involved

in a project, and an even division of responsibility

between business people and technical people (Beck,

1999). These processes and practices have their

basis in a set of principles stressing collaboration,

receptivity to feedback, respect, and honesty among

individuals. XP practices and processes are designed

to support information sharing at both the social and

technological levels.

In developing XP processes and practices, Beck

drew upon work exploring a people-oriented

approach to software engineering, such as

Weinberg’s seminal text The Psychology of

Computer Programming (1998), which provides

insights into issues such as ego, personality traits,

motivation, interpersonal communication, and

teamwork (Beck, 1999). However, no accounts

exist, to our knowledge, suggesting that Beck

explicitly incorporated the social-psychological

commitment and consistency principle into XP

processes and practices. We hypothesize that this

principle indeed pervades XP practices, and

furthermore, that it impacts on the success of the XP

process. The purpose of this paper is to present an

argument that our hypothesis is reasonable, and

technically consistent with XP process. This work is

an important precursor to any practical test of the

hypothesis, such as our complete future study

involving in-depth assay of our qualitative data. Our

argument is based upon technical analysis of the

nature of XP process, and upon inceptive analysis of

our qualitative data. In the sequel, we support our

argument as follows: first, we provide a brief outline

of XP processes and practices, and of the

commitment and consistency principle; next, we

375

Woit D. and Bell K..

Commitment and Consistency in the Collaborative Software Development Process of Extreme Programming.

DOI: 10.5220/0005155003750381

In Proceedings of the International Conference on Knowledge Management and Information Sharing (KMIS-2014), pages 375-381

ISBN: 978-989-758-050-5

 2014 SCITEPRESS (Science and Technology Publications, Lda.)

analyze XP processes and practices to clearly reveal

the presence of the commitment and consistency

principle therein; next, we determine how this

principle manifests in XP operational practices

involving people interaction; and finally, we present

nascent supportive evidence from our ongoing, and

incomplete, industrial case study.

2 XP PROCESS

XP belongs to the agile family of software

development methodologies, and thus, embodies a

process which is iterative and incremental. The

project is comprised of some number of releases,

and each release is implemented by some number of

iterations. Releases occur frequently, normally

every one to three months. Each release provides an

increment in system functionality, and constitutes a

complete, working system. A release is comprised of

some set of iterations, each of which is typically one

to three weeks in duration. New functionality is

incorporated frequently, typically multiple times

daily, and the current, working system is available to

all stakeholders at all times.

The project’s business people are represented by

one individual, known as the customer. This

individual is always available on-site, and her

responsibilities include generating user stories

(system requirements), participating in release and

iteration planning, and responding to questions about

user stories posed by developers (the technical

people).

Each release is governed by a release plan, which

is established by developers, the customer, and

possibly managers, at a release planning meeting. In

this meeting, the customer presents some set of user

stories, and developers estimate timelines for each

story. The customer, with the aid of developers, then

selects some group of stories to include in the next

release. The customer selects the set based either on

scope (desired functionality) or time (stories that are

accomplishable by a given date). During release

planning, the customer may alter user stories based

on developer input. For example, a story may be

partitioned into a set of smaller stories so that the

customer can retain important functionality in this

release, and leave less important functionality for a

future release. Developers, the customer, and

possibly managers, negotiate until all agree to the

release plan (Beck & Fowler, 2000).

A release is implemented over several iterations.

User stories for an iteration are selected by the

customer from among those in the current release,

typically in order of importance to the customer. The

number of stories included is determined by the

developer timelines provided during release

planning. Next, developers collaborate to decompose

the selected user stories into distinct programming

tasks, each of which can be completed in one to

three days. A list of these tasks is maintained in a

highly visible, public area, such as a whiteboard in

the development area. Developers sign up for tasks

of their choice. The developer who signs up for a

task must write her name alongside the task, as well

as her own estimation of the time it will take to

complete the task. If the iteration’s total task

estimation time differs from the customer’s

expectation, the customer may alter the iteration by

adding or removing (parts of) stories (Beck &

Fowler, 2000). The tasks are subsequently

implemented by developers. During task

implementation, a developer may consult the

customer, at any time, for clarifications to user

stories that impact the task.

Mandatory to XP process is the daily meeting,

which is attended by all developers and business

people. As part of the meeting, developers provide

updates on the progress of their chosen tasks, and

record these updates on the public task display.

We have presented a very brief account of XP

process above. It is important to note that, for the

sake of brevity, we have omitted details that are not

principally relevant to our work of relating XP

process to the social-psychological principle of

commitment and consistency.

3 COMMITMENT AND

CONSISTENCY PRINCIPLE

In this section, we provide a brief description of the

commitment and consistency principle for the

purpose of relating it to XP process. A

comprehensive account of this principle and its

various implications is beyond the scope of this

initial report. The interested reader is referred to a

pertinent summary in (Cialdini, 2008).

3.1 Outcome Consistency

The social-psychological principle of commitment

and consistency is summarized as follows: “Once we

make a choice or take a stand, we will encounter

personal and interpersonal pressures to behave

consistently with that commitment. Those pressures

will cause us to respond in ways that justify our

KMIS2014-InternationalConferenceonKnowledgeManagementandInformationSharing

376

earlier decision” (Cialdini, 2008, p. 53). The

pressures are so powerful that a person’s fulfilment

of the commitment feels “automatic” (Cialdini,

2008, p. 55). The principle can thus shape future

reality by causing individuals to behave consistently

with expectations, which in turn can enhance

performance (Kruglanshi & Higgins, 2007). Note

that such commitment fulfilment is referred to in

social psychology literature as outcome consistency,

compliance, or behavioural confirmation.

Not all commitments, however, are equally

effective in eliciting consistent future action.

Commitments are most effective when they are

active, public, and require some effort; moreover,

the most important precondition for effectiveness is

that the individual assumes responsibility for the

commitment freely (Guéguen & Pascual, 2000).

Evidence from numerous domains demonstrates that

effective commitments elicit outcome consistency

(Cialdini, 2008). The various underlying social-

psychological factors driving outcome consistency

are beyond the scope of this report, but are well-

described in the realm of social psychology

(Aronson, 2011).

3.2 Compliance Escalation

The effects of the commitment and consistency

principle are not limited to a single commitment. It

has been shown that outcome compliance for a

commitment is strengthened if that commitment is

the end result of a progressively escalating sequence

of commitments (Aronson, 2011). Compliance

escalation can produce positive results; however, it

is often used unscrupulously in a compliance

technique commonly referred to as foot-in-the-door

(Burger, 1999). Evidence abounds from various

domains, such as sales and marketing, detailing the

deliberate exploitation of this aspect of the

commitment and consistency principle to influence

behaviour (Cialdini, 2008).

4 COMMITMENT AND

CONSISTENCY IN XP

PROCESS

The commitment and consistency principle

manifests in XP process during planning activities

and task implementation. Below, we outline both

positive and negative outcomes of the this principle

in XP process.

4.1 Positive Outcomes

The commitment and consistency principle

manifests in XP iteration planning. The

commitment is undertaken when the developer takes

responsibility for a task. The commitment is active,

since the developer selects her own task, and derives

her own time estimate. The commitment is public,

since the developer records her name and estimate

on the task list, which is in a prominent public

location, and recounts task progress in daily

meetings. Most importantly, the commitment is

made freely, since the developer, herself, chooses to

assume responsibility for the task. Thus, XP process

clearly sets the stage for effective commitments; if

the commitment and consistency principle applies in

this domain, then outcome consistency implies that

developers will complete their tasks on time. This is

an important consequence, since timely task

completion is known to be critical to the success of

software development projects (Verner, et al., 2008).

Compliance escalation can occur during task

implementation, when a developer’s task changes as

a result of customer clarifications. If the

commitment and consistency principle holds in this

domain, it implies outcome consistency would be

strengthened; the developer’s urge to complete the

task on time would be strengthened, along with

associated positive implications for project success.

It is important to note that these positive results

can be expected only if the commitment and

consistency principle holds in the domain of XP

software development. This is a reasonable

assumption, since transference to various domains is

well-established (Cialdini, 2008). Nonetheless,

transference to this domain must be corroborated

with evidence from the domain itself. Providing

such evidence is part of our larger project; initial

results are presented in Section 5.

4.2 Counter-Productive Outcomes

As noted above in Section 4.1, the commitment and

consistency principle can manifest in the form of

compliance escalation during task implementation.

However, a positive outcome is not guaranteed in all

such situations. The outcome is counter-productive

when outcome consistency, i.e., completion of the

altered task, requires more time than afforded by the

recorded estimation. The developer can fall behind,

which is known to negatively impact project success

(Verner, et al., 2008). It is important to note that

such a situation is not considered part of normal XP

process. Customer clarifications are expected to be

CommitmentandConsistencyintheCollaborativeSoftwareDevelopmentProcessofExtremeProgramming

377

of a minor enough nature that the recorded time

estimate remains appropriate for the escalated task.

If the recorded estimate is no longer appropriate, XP

process requires iteration renegotiation. However,

we note that due to the effects of compliance

escalation, it is possible the developer may fail to

recognize the need for renegotiation. Thus, she may

find herself in an impossible position: Outcome

consistency causes her to feel a strong urge to

complete her task within an unrealistic time-frame.

Social psychology provides ample evidence from

various domains detailing such counter-productive

outcomes stemming from the principle of

commitment and consistency (Cialdini, 2008).

Although it is reasonable to assume transference to

the domain of software development, this

assumption must be corroborated with evidence

from the domain itself. Providing such evidence is

part of our larger project; initial results are presented

in Section 5.

It is worth noting that the aforementioned

manifestations of the commitment principle, both

positive and counter-productive, are specific to XP

process. These issues cannot arise in traditional

software development methodologies, because

developers’ tasks and deadlines are largely

determined by business agents, and the commitment

and consistency principle therefore does not apply.

5 CASE STUDY

In this section, we describe the current standing of

our ongoing, incomplete, study relating XP process

to the social-psychological commitment and

consistency principle. The study’s setting, approach,

and data acquisition methods are briefly outlined

below, and a more comprehensive treatment is

available in (Woit & Bell, 2014). Data analysis

relating to the commitment and consistency

principle is ongoing; however, some relevant

preliminary results are presented in the sequel.

5.1 Study Setting and Approach

The study is set in a private organization that follows

the XP development methodology to develop web-

based communication software. The development

team comprises twelve individuals; the customer

works on-site, attends all meetings, and is always

available to respond to developer questions.

The research approach is qualitative in order to

explore how the participants attach meaning to their

own experiences (Merriam, 2009). It is

phenomenological in that it seeks to explore the

issues from a shared perspective, and in context

(Reid, et al., 2005). The phenomenological approach

is apt in this context because the participants are not

a random sampling of a larger population, and are

relatively few in number (Onwuegbuzie & Leech,

2007).

5.2 Data Acquisition

Data is collected via participant observation and

unstructured interviews in order to explore locally

relevant issues without imposing pre-determined

categories or themes (Guest, et al., 2013). Data

integrity is reinforced via an aide memoire (Zhang &

Wildemuth, 2009), containing broad topic categories

which include interactions with developers,

interactions with customer, and examples.

5.3 Results and Data Analysis

Data analysis is ongoing; below, we group

preliminary results into categories, and within each

category, present a provisional interpretation of the

results with respect to the commitment and

consistency principle in this XP domain. A limited

amount of non-qualitative data is incorporated into

the analysis for the purpose of corroborating some

observational and interview data. This additional

data is obtained from project documentation, such as

records of planning and iteration meetings, and XP

tracking documents.

5.3.1 Requirement Concession Escalation

during Release Planning

Data from customer interviews and observation

indicate that during release planning, the customer

frequently agreed to a requirement concession that

came about as an extension of a smaller, previously

agreed-to, concession. The customer reported that he

would not have agreed to many such concessions

had they not been presented as extensions of

previous concessions. Nonetheless, he reported

feeling mostly more satisfied with his final

requirements. This demonstrates accordance with

the commitment and consistency principle: The

customer is more likely to agree to an escalated

concession given that he has already agreed to a

smaller version of the concession. There is outcome

consistency, in that the customer has no desire to

subsequently alter his final agreement. This is a

positive outcome of the commitment and

consistency principle, since customer satisfaction,

KMIS2014-InternationalConferenceonKnowledgeManagementandInformationSharing

378

which is the measure of success in an XP project, is

increased (Beck & Andres, 2004).

5.3.2 Unplanned Task Escalation during

Implementation

Observational data, and developer responses indicate

that frequent task escalation occurred during the

implementation phases. Some escalations resulted

from customer clarifications which were solicited by

the developer. Other escalations, however, resulted

from customer-initiated interventions. These latter

situations occurred when the customer accessed the

current working product, and found a task

implementation inconsistent with his understanding

of the requirements.

Developers reported sometimes being unable to

complete their tasks within the recorded time

estimations, known as over-commitment in XP,

because they accepted task scope escalations even

though they were untenable within the recorded time

estimations. Developers reported over-commitment

negatively affected their motivation. When probed,

they were perplexed as to why they had accepted

such escalations, and as to why they had not realized

the modified tasks were un-implementable within

their recorded time estimations. They were

especially confused by the fact that the more effort

they had put into the definition of a task, the more

willing they were to accept its escalation. This

behaviour seemed counter-intuitive and

unexplainable. However, some explanation is

provided by considering the commitment and

consistency principle: The individual is more likely

to agree to the escalated task since she has already

agreed to a smaller version of the task. Her

commitment to the task is strong because she has put

effort into defining the task, and her willingness to

escalate the task grows from this strength.

Furthermore, the effects of commitment escalation

may render her unlikely to subject the recorded time

estimate to subsequent scrutiny.

The interplay of XP process and the commitment

and consistency principle result in developer over-

commitment. This is counter-productive in two

ways. First, it negatively impacts project success

directly (Beck & Fowler, 2000). Second, it

demotivates developers, which is also known to

negatively impact project success (França, et al.,

2011).

5.3.3 Deliberate Task Escalation during

Implementation

Data from customer interviews indicates that

occasionally, under the guise of a simple

requirement clarification, the customer deliberately

escalated a task’s scope in order to recover some

concession he had made during release or iteration

planning. The developer’s willingness to accept the

escalation, the interplay of XP process and the

commitment and consistency principle, and the

associated counter-productive outcomes, are all

similar to those outlined above in Section 5.3.2.

However, on two occasions, data from developer

and customer reports, and from observation, indicate

that the customer made no attempt to disguise his

deliberate scope extension as a simple clarification,

and in fact asked the developer to collude with him,

in violation of normal XP process. The developer

agreed for the reasons outlined in Section 5.3.2

above. Data from developer interviews indicates the

emergence of additional counter-productive

outcomes in these two situations. Other developers

reported feeling betrayed by the collusive behaviour,

and experienced an associated decrease in

motivation. As noted in Section 5.3.2, decreased

motivation negatively impacts project success

(França, et al., 2011). Developers also reported

feeling that XP’s spirit of collaboration and trust had

been undermined. Although more analysis is

required in our particular situation, it has been

reported that such feelings can also impact

negatively upon the success of an XP project (Beck

& Andres, 2004).

This situation also differs from the unplanned

task escalation outlined in Section 5.3.2 in that the

commitment and consistency principle does not

appear to influence the customer. Normally, the

customer reported satisfaction with the requirements

concessions he agreed to during planning, in

accordance with the commitment and consistency

principle, as reported above in Section 5.3.1. Why,

on some occasions, did he find himself dissatisfied

with a concession? The customer reported that these

were concessions he had felt pressured into making.

Thus, the commitment and consistency principle did

not apply in this situation, since its important

precondition—free agreement—had been violated.

Therefore, it is unsurprising that the customer felt no

obligation to follow through with these concessions.

Note that we expect the customer’s feelings of

coercion were a result of the psychological

phenomenon known as social proof (also called

informational social influence). Further research is

required regarding the interplay of the commitment

and consistency principle and social proof;

however, this is beyond the scope of our preliminary

analysis.

CommitmentandConsistencyintheCollaborativeSoftwareDevelopmentProcessofExtremeProgramming

379

5.3.4 Timely Task Completion

Our data confirms that the conditions necessary for

effective commitments do hold in our domain, as

follows. Observational data confirms commitments

were active and public. Data from developer

interviews indicate developers did not feel coerced

into their commitments, and that they felt satisfied

with the agreements they forged during release and

iteration planning. Thus, if the commitment and

consistency principle holds in our domain, we

should expect consistency of outcome, in the form of

timely task completion, and our data does indeed

corroborate this. Our initial analysis of

observational data, and of project documentation,

indicates timely task completion occurred; that is,

actual task completion time was acceptably close to

the recorded estimated time. Our explanation of

timely task completion is vague, and perhaps

unsatisfying, because a comprehensive account of

our actual measurements is beyond the scope of this

preliminary report.

Data from observation and project

documentation does show exceptions to timely task

completion, however. Preliminary data analysis

shows these exceptions coincided with periods of

developer over-commitment, as outlined above, in

Sections 5.3.2 and 5.3.3. They also coincided with

uncontrollable external factors, such as illness, and

infrastructure modifications.

5.4 Threats to Validity

It is possible developers were unwilling to disclose

issues they considered disparaging to the customer,

because he was a primary stakeholder in the

organization. Data collector bias is also possible

(unconscious distortion of collected data). These

threats are common to empirical studies based on

qualitative data. We endeavour to address these by

the generally accepted methods of (i) following an

aide memoire (ii) using unstructured interviews to

put participants at ease, (iii) assuring participants of

anonymity, (iv) including an organizationally-

external researcher, and (v) data-triangulation

(Shadish, et al., 2002).

6 CONCLUSIONS

This work relates our preliminary investigations into

the role of the social-psychological commitment and

consistency principle in the collaborative software

development methodology of Extreme Programming

(XP). We hypothesize that the commitment and

consistency principle is intrinsic to XP process, and

impacts on its success. We argue that this hypothesis

is reasonable, and technically consistent with XP

process, supporting the argument through technical

analysis of XP process, and nascent analysis of

preliminary data from our qualitative case study.

Our data indicates that the commitment and

consistency principle manifests in our domain to

promote timely task completion and to increase

customer satisfaction, both of which are critical to

project success. Our data is also reveals that the

commitment and consistency principle can

contribute to developer over-commitment and

demotivation, both of which are known to negatively

impact project success. Finally, our data

demonstrates that when its preconditions are not

met, the commitment and consistency principle does

not hold in our domain, and that, moreover, its

absence contributes to demotivation, with negative

implications for project success.

Our results imply that individuals must play an

active role in properly managing the manifestation

of the commitment and consistency principle in XP

processes and practices. Ignorance of the principle,

or its improper management, can contribute to

preventable, negative outcomes. However, when

properly leveraged, the principle can impact

positively on project success.

This work is in its preliminary stages, and does

not yet constitute comprehensive support of the

notion that issues related to commitment and

consistency are intrinsic to XP project success.

However, we hope our preliminary analysis and

nascent supportive evidence have provided an

arguable case for the importance of continued data

analysis, and continued investigation into this area.

ACKNOWLEDGEMENTS

This work is supported in part by a Natural Sciences

and Engineering Research Council of Canada

(NSERC) Discovery Grant.

REFERENCES

Aronson, E., 2011. The Social Animal. 11 ed. New

York(NY): Worth Publishers.

Beck, K., 1999. Extreme Programming Explained:

Embrace Change. Boston(MA): Addison-Wesley

Professional.

KMIS2014-InternationalConferenceonKnowledgeManagementandInformationSharing

380

Beck, K. & Andres, C., 2004. Extreme programming

explained: Embrace chanage. 2 ed. Reading(MA):

Addison-Wesley Professional.

Beck, K. & Fowler, M., 2000. Planning Extreme

Programming. Boston(MA): Addison-Wesley

Longman Publishing Co., Inc..

Burger, J., 1999. The foot-in-the-door compliance

procedure: A multiple-process analysis and review.

Personality and Social Psychology Review, Volume 3,

pp. 303-325.

Cialdini, R., 2008. Influence: Science and Practice. 5 ed.

Boston: Pearson.

França, A. C. C. et al., 2011. Motivation in software

engineering: a systematic review update. Proceedings

of the 15th Annual International Conference on

Evaluation & Assessment in Software Engineering,

(Durham, England, April 11-12), pp. 154-163.

Guéguen, N. & Pascual, A., 2000. Evocation of freedom

and compliance: The "But you are free of… "

technique. Current Research in Social Psychology,

Volume 5, pp. 264-270.

Guest, G., Namey, E. & Mitchell, M., 2013. Collecting

Qualitative Data: A Field Manual for Applied

Research. Thousand Oaks(CA): Sage Publications

Inc..

Kruglanshi, A. & Higgins, E. eds., 2007. Social

Psychology: Handbook of Basic Principles. 2 ed. New

York(NY): The Guilford Press.

Merriam, S., 2009. Qualitative research: A guide to

Design and Implementation. San Francisco(CA):

Jossey-Bass.

Onwuegbuzie, A. & Leech, N., 2007. Sampling designs in

qualitative research: making the sampling process

more public.. The Qualitative Report, June, 12(1), pp.

238-254.

Reid, K., Flowers, P. & Larking, M., 2005. Exploring

lived experience: and introduction to interpretive

phenomenological analysis. The Psychologist,

January, 18(1), pp. 20-23.

Shadish, W., Cook, T. & Campbell, D., 2002.

Experimental and Quasi-Experimental Designs for

Generalized Causal Inference. Boston(MA):

Houghton Mifflin Company.

Verner, J., Sampson, J. & Cerpa, N., 2008. What factors

lead to software project failure?. Second International

Conference on Research Challenges in Information

Science (RCIS 2008). Marrakech, Morocco, June 3-6,

2008, IEEE, pp. 71-80.

Weinberg, G., 1998. The Psychology of Computer

Programming: Silver Anniversary Edition. New

York(NY): Dorset House Publishing Co., Inc..

Woit, D. & Bell, K., 2014. Do XP customer-developer

interactions impact motivation? Findings from an

industrial case study. 7th International Workshop on

Cooperative and Human Aspects of Software

Engineering (CHASE 2014), at the 36th International

Conference on Software Engineering (ICSE 2014),

Hyderabad, India, June 2-3, 2014, IEEE, pp. 79-86.

Zhang, Y. & Wildemuth, B., 2009. Unstructured

interviews. In: B. Wildemuth, ed. Applications of

Social Research Methods to Questions in Information

and Library Science. Westport(CT): Libraries

Unlimited, pp. 222-231.

CommitmentandConsistencyintheCollaborativeSoftwareDevelopmentProcessofExtremeProgramming

381