AGILE OR PLAN-DRIVEN SOFTWARE DEVELOPMENT METHODOLOGY SELECTION USING PERSONALITY TRAITS OF DEVELOPERS

2011 INTERNATIONAL RESEARCH CONFERENCE AND COLLOQUIUM
Contemporary Research Issues and Challenges in Emerging Economies
AGILE OR PLAN-DRIVEN: SOFTWARE DEVELOPMENT
METHODOLOGY SELECTION USING PERSONALITY TRAITS
OF DEVELOPERS
Anuj Sharma
Indian Institute of Management, Indore, India
f09anujs@iimidr.ac.in
Shubhamoy Dey
Indian Institute of Management, Indore, India
shubhamoy@iimidr.ac.in
ABSTRACT
In the software development, the most challenging task is to select the development methodology that is
appropriate as per user requirements, problem domain complexity and development team. Since there
are many software development methodologies, project managers face problems to decide which
methodology to apply in a software project and then how to select the development team appropriate for
the methodology. While the main issues related to development team are team experience, maturity,
team size, and organizational culture, it is equally important to understand the different working
personalities of software developers. This paper investigates applicability of Big-Five personality
dimensions of the developers to predict the suitability and appropriateness of plan-driven or agile
software development methodology. The empirical evidence presented in this paper suggests that
personality traits like extraversion and agreeableness can indicate the interest and inclination towards
plan-driven or agile methodology. The knowledge of appropriate software development methodology as
per developers’ specific personality traits may help in better staffing of development teams and more
importantly in improving the success rate of software projects.
KEYWORDS: Agile, Plan-Driven, Software Development Methodology, Personality Traits.
INTRODUCTION
A software development methodology (SDM) can be defined as a recommended mean to achieve the
development of program systems, based on a set of rationales and an underlying philosophy. It usually
includes a definition of phases, procedures, tasks, rules, techniques, guidelines, documentation and tools
(Avison & Fitzgerald, 2003). SDM adoption can be defined as the actual level and consistency of use of
officially recommended SDM in the observed organisation. Although most organisations, involved in
software development, follow certain rules and procedures during development, there is a distinction
between organisations with rules and procedures written in a form of a formal SDM and organisations that
rely only on informal agreements between developers on how to develop software. Different studies
indicate that adoption of formal SDMs facilitate increases in productivity and quality (Fitzgerald, 1998;
Riemenschneider, Hardgrave, & Davis, 2002).
Different approaches to improve the level of SDMs adoption in organisations are proposed (Agarwal,
Tanniru, & Wilemon, 1997; Niazi, Wilson, & Zowghi, 2005). The results of the formal SDMs adoption
research nevertheless suggest that these efforts have been met with limited success.

The appropriateness of a SDM depends upon its technical suitability for the current project and its fitness
with social characteristics of a development team and an organization. Example, it is difficult to introduce
a rigorous SDM into an organization that has a liberal culture; a non-innovative development team will
probably reject an innovative SDM, etc. (Rawstorne, Jayasuriya, & Caputi, 2000; Gallivan, 2003; Green,
Collins, & Hevner, 2004). The consequence of using a SDM that is either technically unsuitable for a
project at hand, or socially inappropriate for a given development team is that even though an
organisation might have invested a considerable amount of resources into the SDM, developers consider
it useless and therefore reject it.
In software industry, the proper methodologies such as plan-driven, iterative and agile development
promise the high quality software, increased customer satisfaction, and stability. However, to acclimatize
any development methodology, the software company needs to carefully investigate the internal and
external conditions. It’s always a highly debated topic of determining whether one software development
methodology is better than another for a development team in terms of its feasibility, efficiency, quality of
outcome and acceptability. As software development process is an extremely complex work, this requires
strong technical and effective interpersonal skills to succeed. Along the way, there are two famous
methodologies, which are used in most of software development projects: Plan-driven, also known as
Waterfall model and Agile development model.
The Waterfall model is a traditional development methodology used in almost all software development
projects at the early stage of software industry. It defines a set of standard work procedures that are
grouped in sequential development phases for the purpose of managing software development projects
effectively. It was prevalent and favoured since it was understandable for practitioners at all levels and
easy to implement. In 2001, a new concept came out – the agile model for software development. The
proponents of the agile model believe that they found a better ways of developing software by using the
lightweight methods.
The appropriateness and proper adoption of any software development methodology (planned or agile)
depends on whether it is socially inappropriate for a given development team. Not only knowing the
technical skills and past experience of team members is required but also understanding the different
working personalities of software developers will be needed to select proper methodology. The secret of
development team productivity is to match the requirements of a particular project with the personalities
of team members. Effective team formation in software development projects is difficult to achieve and
requires careful amalgamation of personality traits. This is proposed in physiology literature that effective
assessment of the personalities of software developers can predict their conformity to the task and
responsibilities of software development as per the selected development methodology (Howard, 2001).
Personality is a consistent and long-lasting tendency in behaviour. The Big Five personality trait factors
have been generally used to assess personality of people. The research literature that relates personality
styles to software engineering processes has been scattered and difficult to interpret uniformly. This
scarcity of confirmed theories could indicate that the relationship between software engineering and
personality styles is too complex to investigate. For instance, certain personality traits such as
introversion/extroversion might have a significant impact on requirement collection and system analysis,
but they might not affect the other software life cycle phases like coding and testing. Thus, studies to
determine which personality types are more appropriate for specific software development activity as
individual and software development methodology as a whole, are of vital importance. A major rationale
behind this paper is to discern connections between developer’s personality traits and the adoption of
software development methodology. This interdisciplinary human-centered study incorporates theories
about psychological types, human or interpersonal factors, and software engineering. The contribution of
this study is to link software engineering and human psychology, with an attempt to shed light on several
outstanding problems regarding proper development methodology selection that plague the software
industry.
This paper investigates the applicability of the personality traits of the software developers to predict the
suitability and appropriateness of plan-driven or agile software development methodology for them. The

empirical results suggest that after a careful investigation of the personality of different developers, we
can predict the best suitable and adoptable software development methodology for them.
The structure of this paper is as follows. The section 2 gives a short description of the plan-driven
software development methodology. Section 3 describes Agile methodology and section 4 describes Big
Five personality traits for predicting the appropriate methodology for developers. We present future work
and conclusion in the fifth section.
PLAN-DRIVEN SOFTWARE DEVELOPMENT METHODOLOGY
Plan-driven software development is a formal and well planned methodology for developing software
applications. Plan-driven methodologies incorporate repeatability and predictability, well defined
incremental process, extensive documentation, up-front system architecture, detailed planning, process
monitoring, resource controlling, risk management, verification and validation and user training. The Plan-
driven methodologies are also known as "Heavy-weight" methodologies or "Traditional" methodologies.
Planned methodologies were invented to control and solve the problems of "code and fix" development
style, where the software was written without any underlying plan, and the design of the system was
cobbled together from many short term decisions. As these system evolved, it became increasingly
difficult to add new features or to fix any bug (Pressman, 2005). Planned methodologies tried to solve
these problems by imposing a disciplined process upon software development, with the aim of making
software development more predictable, manageable and efficient. To be more predictable, planned
methodologies focus on creating a comprehensive up-front design, from which detailed design, coding
and test plans are formulated. Waterfall and incremental models are the most two well known models of
planned approach.
Waterfall model suggests a systematic approach to software development that begins with customer
specification of requirements and study of current system and then progress through analysis, planning,
system design and modelling, construction and deployment, culminating in on-going support and
maintenance of the complete software (Pressman, 2005).
The incremental model combines elements of the Waterfall model but applied in an iterative fashion in
such a way that software evolves, starting with a basic working version and then as per time schedule,
more functionalities are added to it. The incremental model applies linear sequences of Waterfall model in
a staggered fashion as calendar time progress. Each linear sequence produces deliverable increment of
the software (Pressman, 2005).
Using incremental model, development team can start working on the known increments, and clarify the
rest later. Other problems may arise later if project is not well defined or if the definition changes much
later. Development team should make a project priority chart, and plan the increments accordingly (Petri,
& Maarit, 2004). The description of the software development models under plan-driven methodology is
out of scope of this paper and can be found in (Wikiversity, 2011; Pressman, 2005).
The trend of planned methodologies does not serve projects that have a compelling need to get software
to market quickly such as web applications. Such applications exhibit a time to market that can be a
matter of a few days or weeks with giving high consideration to maximizing product values and customer
satisfaction. For that reason more flexibility and more customer involvement in the development process
are needed.
AGILE SOFTWARE DEVELOPMENT METHODOLOGY
Agile software development is a group of software development methodologies based on iterative and
incremental development, where requirements and solutions evolve through collaboration between self-
organizing, cross-functional teams. These methodologies promote a disciplined project management

process for software development that encourages frequent inspection and adaptation, teamwork, self-
organization and accountability, a set of engineering best practices for rapid delivery of high-quality
software.
Agile software engineering combines a philosophy and a set of development guidelines. The philosophy
promotes customer satisfaction by engaging the customer in development process. The philosophy
suggests early incremental delivery of software by small but highly motivated project teams using informal
methods and minimal software engineering work products, and thus it helps to attain overall development
simplicity. The development guidelines suggest considering on time product delivery instead of lengthy
analysis and design, and promote active and continuous communication between developers and
customers (Williams, & Cockburn 2003). Proponents of agile methods believe that they promote a
disciplined project management process for software development that encourages frequent inspection
and adaptation, teamwork, self-organization and accountability, a set of engineering best practices for
rapid delivery of high-quality software, and a business approach that aligns development with customer
needs and company goals (Agile Manifesto, 2011).
The lightweight software development methods emerged as a reaction against traditional heavyweight
development methods in mid-1990s. The heavyweight development methods were characterized by their
critics as a command and control regulated, regimented, micromanaged, waterfall like sequential
model of development. Early implementation of lightweight methods includes Scrum (1995), Crystal
Clear, Extreme Programming (1996), Adaptive Software Development, Feature Driven Development,
and Dynamic Systems Development Method (DSDM) (1995). These are now typically referred to as agile
development methodologies.
Extreme Programming
The attributes of agile software development methodologies include short development time, dynamic
user requirements, frequent releases, and customer focus. These properties make agile methods
appropriate to embrace today’s volatile business and software ecosystem. Among many agile software
process paradigms, the most popular one is extreme programming, or XP (Beck, 2000). XP is well-suited
for risky projects with dynamic requirements and mainly geared for small to mid-size application
development. Software process stages that are considered unnecessary are eliminated, freeing
programmers from documentation and other overhead chores.
By most software engineering standards, the techniques used in XP are viewed as unconventional. For
example, in traditional paradigms, the software development process focuses on formal software
requirements documentation. But in XP practice, the software development process focuses on feedback
from an on-site customer, a customer representative who remains on-site throughout the development
project. Despite these unorthodox principles, XP yields promising results (Nosek, 1998; Williams, Kessler,
Cunningham, & Jeffries, 2000). XP’s no documentation, no formal requirement engineering, no up-front
design, and other anecdotal features are under debate (Glass, 2001), but often lead to high productivity in
the form of frequent releases, high quality and fewer code errors (Cockburn & Williams, 2001).
XP is dependent upon the combined use of best practices and one of these best practices is paired
programming in which all production code is written by two developers sitting at one machine. Pair
programming, is defined as a programming activity where two individuals sit next to each other sharing
one keyboard and one display. This can also be done virtually with two programmers in geographically
different locations sharing one common view of code development and taking turns programming. While
one person, who is called the “driver”, is coding, the other person, who is called the “navigator”, does real-
time code review. Each programmer takes a turn being the “driver” and the “navigator”. The active
collaboration in designing, coding, and reviewing thus eliminates the overhead cost of a more formal code
review (Williams & Kessler 2002).
Scrum
Scrum developed in the late 1980's and early 1990's primarily with object oriented development circles as
a highly iterative development methodology. Scrum was developed by Ken Schwaber, Jeff Sutherland,
and Mike Beedle (Beedle & Schwaber, 2001).

Scrum is an iterative, incremental framework for project management and agile software development.
Although Scrum was intended for management of software development projects, it can be used to run
software maintenance teams, or as a general project/program management approach. Scrum
concentrates on the management aspects of software development, dividing development into thirty day
iterations (called 'sprints') and applying closer monitoring and control with daily scrum meetings. It places
much less emphasis on engineering practices and many people combine its project management
approach with extreme programming's engineering practices.
Scrum is a process skeleton which contains sets of practices and predefined roles. The main roles in
Scrum are:
1. The “Scrum Master”, who maintains the processes (typically in lieu of a project manager)
2. The “Product Owner”, who represents the stakeholders and the business
3. The “Team”, a cross-functional group of about 7 people who do the actual analysis, design,
implementation, testing, etc.
During each “sprint”, typically a two to four week period (with the length being decided by the team), the
team creates a potentially shippable product increment (for example, working and tested software). The
set of features that go into a sprint come from the product “backlog”, which is a prioritized set of high level
requirements of work to be done. Which backlog items go into the sprint is determined during the sprint
planning meeting. During this meeting, the Product Owner informs the team of the items in the product
backlog that he or she wants completed. The team then determines how much of this they can commit to
complete during the next sprint. During a sprint, no one is allowed to change the sprint backlog, which
means that the requirements are frozen for that sprint. Development is time-boxed such that the sprint
must end on time; if requirements are not completed for any reason they are left out and returned to the
product backlog. After a sprint is completed, the team demonstrates how to use the software (Beedle &
Schwaber, 2001).
PERSONALITY TRAITS AND SOFTWARE DEVELOPMENT METHODOLOGY
One method of categorizing personality influences is in the context of the Five-Factor Model. The Five-
Factor Model (FFM) divides personality into a series of five dimensional traits (Costa & McCrae, 1992).
The first trait, Neuroticism, reflects a person’s tendency to experience psychological distress and high
levels of the trait are associated with a sensitivity to threat. Extraversion, the second trait, reflects a
person’s tendency to be sociable and able to experience positive emotions. The third factor, Openness to
Experience, represents an individual’s willingness to consider alternative approaches, be intellectually
curious and enjoy artistic pursuits. Agreeableness, as the fourth factor, is another aspect of interpersonal
behaviour, reflecting a tendency to be trusting, sympathetic and cooperative. The fifth dimension,
Conscientiousness, reflects the degree to which an individual is organized, diligent and scrupulous.
Personality and Software Development
The effects of personality traits are being examined across all areas of science and engineering. This is
because personality is concerned with human beings, who are key actors or resources in all spheres of
lives. Some of the areas where personality traits would certainly have significant influence on human
performance are the application areas of information system, software engineering or computer science.
Wang and King (2006) studied several characteristics of human factors and their influences in
engineering. The author presented a similar work that applies Real-Time Process Algebra (RPTA) to
describe the motivations and attitudes in software engineering.
Wynekoop and Walz (1998) explored the differences in personality profiles of key IT personnel and found
out that personality plays significant role in differentiating profiles of programmers, systems analysts, and
project managers. Similar to this, is the work of Chilton and Hardgrave (2004) that assessed the
behavioural skills (technical and managerial) and determined the relationship between these skills and
personality traits.

Houghton (2004) introduced a theoretical framework for understanding the role of personal traits in
collaboration in virtual contexts. The work stated that individual traits and dyadic complementarities are
mediating factors in interpersonal trust and willingness to use new technologies and significantly affect
the initiation, duration, and productivity of computer-mediated collaboration.
Another work is conducted by Dick and Zarnett (2002) on paired programming and personality traits. The
work was carried out to determine whether the members have personality traits that are needed for
maximum performance. The results suggested that the team members in paired or extreme programming
should be selected based on personality traits that are beneficiary to paired programming approach.
Howard (2001) emphasized in his paper the need to check whether software engineers have got the right
personality for the job.
A lot of previous work stresses the need to assess the personality trait of IT personnel, but none have
actually provided a technique for doing this and for relating personality and software development
methodology. Also, Software Engineers have their typical domain like designing, programming, testing,
etc., it is important to determine whether they have the right personalities for the chosen field.
The Personality Traits
A personality trait is a consistent and long-lasting tendency in behaviour. There are different personality
traits that people normally exhibit. The Big five personality factors as proposed by Goldberg (1990) are
used widely to classify personality traits and are used as the basis for the assessment of personality. The
Big five personality factors consist of Neuroticism, Extraversion, Agreeableness, Conscientiousness and
Openness to experience.
Neuroticism: - This personality trait is related with tendency to experience unpleasant emotions relatively
easily. Neuroticism can be defined by factors like anxiety, hostility, depression, self-consciousness, and
impulsiveness. People with low in neuroticism are emotional stable or high in self-control.
People who are high in this factor are faced with effect of decreasing cognitive and performance
capacities, have increasing probability of errors, are more distracted from the task at hand, have tendency
to experience greater stress symptoms, tend to be pre-occupied with their anxieties and worries
(Goldberg, 1990).
Individuals with a neurotic personality being emotionally unstable are not likely to be able to get along
with others (John & Srivastava, 1999). Especially in software development, which requires working with
others, developers with a neurotic personality trait may not be able to tap in to the expertise of others to
overcome a challenge like uncertainty in requirement specifications. Further, neuroticism is characterized
by feelings of fear, sadness, and difficulty in managing stress (McElroy, Hendrickson, Townsend, &
DeMarie, 2007). So, they may give in to the stress that comes with uncertainty in requirements. Further,
as they are not sociable and are hostile they are not likely to acquire the knowledge and information that
is required to handle the new challenges in the project. It is more like a hidden profile task for developers
with a neurotic personality, as they neither share nor receive information that can help to leverage their
abilities to deliver a high performance. Also, research in psychology has shown that people with
neuroticism are less satisfied with the physical aspects of their work environments than stable individuals
are and that there is a relation between neuroticism and negative traits like absenteeism, complaining and
lower career satisfaction (Seibert & Maria 2001). Hence, we expect developers with an overarching
neurotic personality to be unable to perform well in the presence of requirements uncertainty.
From the review of literature we can infer that developer with a neurotic personality will like to follow plan-
driven software development methodology since in this we follow traditional waterfall model. In plan-
driven software development, all the requirements are stable, risk is well defined and the whole process is
mature, systematic and well documented. Developer, who are low in neuroticism and are emotional
stable, will have no problem in communication with team members, collaboration for knowledge sharing
and dealing with the changing requirements. We can predict that people with emotional stability will like
to follow agile software development methodology.

HYPOTHESIS 1a: There is a positive correlation between neurotic personality and an individual’s
predilection for following plan-driven software development methodology.
HYPOTHESIS 1b: There is a positive correlation between emotionally stable personality and an
individual’s predilection for following agile software development methodology.
Extraversion: - This trait explains the tendency to seek environmental simulation and to enjoy the
togetherness of other people. Extraversion is defined by constituents like warmth, sociable, assertive,
energetic, adventurous, and enthusiastic. People who are high in extraversion factor are sensitive to
monotony of life, high sensation seekers, and more risks takers and demonstrate significantly poor
performance on vigilance tasks (McElroy, Hendrickson, Townsend, & DeMarie, 2007).
Extraversion personality type people are sociable, cheerful, optimistic and status striving (Barrick &
Mount, 1993). Further, as they want to be the centre of attention and as they are likely to be motivated by
a desire to get ahead of others they will strive to perform well in situations involving uncertainty to
establish themselves well among peers (Barrick & Mount, 1993). Further, as requirements elicitation
requires good interpersonal skills and the ability to relate to the customers, developers with an
extraversion personality can be expected to be able to elicit requirements better than people of other
personality types. They are well suited for social and interpersonal demands of the contextual activities. It
was found that extraversion was consistently related to career success which possibly was due to greater
visibility, influence and social/political skills. As working in teams requires the ability to be able to tap in to
each other’s expertise and knowledge, extraverted developers may be more successful at it due to their
social/political skills. Hence, it can be proposed that extraverted software developers will perform better
under conditions of dynamic and uncertain requirement and when things are less planned.
HYPOTHESIS 2a: There is a positive correlation between introvert personality and an individual’s
HYPOTHESIS 2b: There is a positive correlation between extrovert personality and an individual’s
predilection for following agile software development methodology.
Conscientiousness: - This is defined as the tendency to show self-discipline, to be dutiful, and to strive for
achievement and competence. Conscientiousness is explained by self-discipline, consultative,
competence, order, dutifulness and thorough performance. People who are high in this factor are always
thorough in decision-making style, follow rules and regulations, interested in goal targeting and
systematic approach, always interested in providing adequate cost-benefit analysis and contingency
planning and are less vulnerable to cognitive failures (Clarke & Robertson, 2005).
Individuals with a conscientious personality trait are goal oriented and are persistent and organize and
actively plan, organize and carry out tasks. Conscientious people are able to align themselves as per the
situation requirements, so as to achieve the goal. So we can expect that those with a conscientious
personality trait will exert themselves to do well on the software development project. Even in cases of
dynamic project requirements, it can be expected that, being highly organized and dutiful they can more
systematically approach the challenge and emerge successful.
Further, as they are of a dependable nature, they will strive to go that extra mile to ensure the project is a
success. They will also likely equip themselves well with knowledge required to overcome the challenge,
to be able to be a point of reference/help to the team members. Research has also found that
conscientiousness is a consistent predictor of job performance in various occupations (Wallace & Chen,
2006). Thus we expect that conscientious individuals will perform well even in the presence of
requirements uncertainty since they are more planned and organized.
HYPOTHESIS 3a: There is a positive correlation between conscientious personality and an individual’s
HYPOTHESIS 3b: There is a positive correlation between non- conscientious personality and an
individual’s predilection for following agile software development methodology.

Agreeableness: - This is a tendency to be compassionate towards others and not antagonistic. Its
components include pleasant, tolerant, tactful, helpful, trust, respectful, sympathetic and modest. People
who are high in this factor are generally easy to get along with. They are salient in situations that involve
interaction or cooperation with others, less aggressive and trustworthy (Clarke & Robertson, 2005).
Individuals with an overarching agreeableness personality trait are characterized by sympathy, good-
nature and cooperation. It is a fundamental trait associated with the intention to strive for communion with
others. Being such, they are more likely to be ready to share their knowledge with others to overcome the
challenges in the project. They facilitate smooth knowledge sharing among team members. But in critical
situations, like requirement uncertainty, where one is required to take a position of authority to proceed
forward, people with an agreeableness personality trait are likely to avoid taking the appropriate actions to
avoid being un-agreeable. Consequently they may have to follow the decision of the groups or “significant
others” in tackling the new changes in the project as they comply with outside pressures (McCrae & John,
1992). So it is very likely that they will be led by team or peer decisions than by their own, even if it is
significantly better. Also prior research have shown a negative relation between agreeableness and
external career success in people oriented jobs and that it could be a liability hampering one’s own
success at the cost of obliging others. Thus, it is expected the performance of developers with
agreeableness personality trait to be lower (than what they are capable of) in the presence of
requirements uncertainty in agile software development.
HYPOTHESIS 4a: There is a positive correlation between agreeable personality and an individual’s
HYPOTHESIS 4b: There is a positive correlation between non-agreeable personality and an individual’s
predilection for following agile software development methodology.
Openness to experience: - This is the tendency to enjoy new intellectual experiences and ideas. Its
components include imaginative, curious, unconventional, broadminded and cultured. Individuals with an
“openness to experience” personality are characterized by curiosity and playfulness, intellect and
unconventionality (John & Srivastava, 1999). People who are high in this factor have positive disposition
towards learning and they tend to be liable to rule violations, experimentation and improvisation (Clarke &
Robertson, 2005).
Due to the inherent curiosity it is very likely that such individuals will be more adventurous and explore
various possible approaches of software development. Further, they can be expected to be more agile
and be able to quickly adapt to changes (in requirement). Hence they are more likely to revel in situations
such as dynamic changes in the project requirement and like the challenges that come with it. It can be
expected that the challenge will motivate them to perform well under such conditions of uncertainty. Also,
such persons are imaginative and original. So, it can be expected that they will use innovative
approaches to solve the problem. Thus we expect developers with an “openness to experience”
personality trait to perform well with the agile software development methodology.
HYPOTHESIS 5a: There is a positive correlation between being less open to new experience personality
and an individual’s predilection for following plan-driven software development methodology.
HYPOTHESIS 5b: There is a positive correlation between being more open to new experience
personality and an individual’s predilection for following agile software development methodology.
RESEARCH METHODOLOGY
Sample
A selection of three hundred and fifty Information Technology (IT) professionals from India was selected
for sending the survey questionnaire over the Internet for the present study. Out of them, 60 participants
responded for the present study confirming 17.1% response rate which falls within an acceptable
response rate for panel Web-based surveys. The sample comprised of 41 men (68.3%) and 19 women

(31.7%) participants, having an average age of 27 years (SD=2.5) and average experience of 35 month
(SD=19.2) in software development from different IT and software organizations across the country. The
gender skew may introduce bias, but the gender ratio of participants in present study was better than the
actual gender ratio in Indian IT organization. The sample is justified based on age because the social
acceptance of software development methodology is more important in the early years of developer’s
working experience. The sample includes different ethnic backgrounds, work profiles, and different
cultural backgrounds.
FIGURE 1: The Proposed Model for Predicting Software Development Methodology
Measures and Procedure
The 44-Item Big Five Personality Inventory (BFI) by John & Srivastava (1999) is utilized for measuring
personality traits of the developers (John & Srivastava, 1999). This inventory scale was devised as an
instrument for measuring the Big-Five dimensions of personality, the most widely used model in
psychology to classify and scale personality traits. The BFI shows high convergent validity with other self-
report scales and with peer ratings of the Big Five. The BFI items were rated on a 5-point scale ranging
from 1 (disagree strongly) to 5 (agree strongly).
The inclination towards agile or planned development methodology was measured using scales of 10
items each for planned and agile development. Each item was rated on a 5-point scale ranging from 1
(disagree strongly) to 5 (agree strongly). The agile and planned scales were developed after selection of
22 attributes set for each methodology that defines it well. After a focus group discussion with the expert
related to this area, we narrowed down the item to 10 in each scale to measure agile and planned
development inclination of developers. The agile and planned scales items were also rated on a 5-point
scale ranging from 1 (disagree strongly) to 5 (agree strongly). The agile and planned questionnaire was
improved by pretesting on a sample of 10 respondents. The face validity was used to validate the scales
for agile and planned. The reliability of the scales was verified as the Cronbach's Alpha values for 44-
Item Big Five Personality Inventory (BFI) was 0.662. The Cronbach's Alpha value for 10-Item planned
development scale was 0.928 and for 10-Item agile development scale was 0.923.
RESULTS
Before progressing to multivariate analysis, zero-order correlations tested the correlation among the
dependent and independent variables. Table 1 shows descriptive statistics for personality dimensions and
planned and agile methodologies. Table 2 shows correlation matrix for all variables. The correlations are
significant at the 0.01 level.
The independent variables of interest, i.e. personality traits, were correlated to each other as expected.
The highest correlation was openness with extraversion, r = .868, p < .001. In general, people with high
Neuroticism
Extraversion
Conscientiousness
Agreeableness
Openness to experience
Agile Development
Plan-Driven Development

levels of extraversion tend to be more emotionally stable and open to new experiences. People with high
in neuroticism were found to be introvert and less agreeable. To test whether there was a relationship
between personality traits and agile or planned development methodology inclination, multiple
regressions were conducted.
Due to the high correlation between openness to new experience with extraversion, we have discovered
collinearity between these variable (variance inflation factor was 6.955 for extraversion and 6.321 for
openness to new experience, when all five variables were included in the model). Since the correlation
between openness to new experience with extraversion was very high and even centering (transforming
the offending independents by subtracting the mean from each case) did not produced enough
improvement in variance inflation factor, we removed the variable openness to new experience from the
model.
Table 1
Descriptive Statistics
Descriptive Statistics
Mean Std. Deviation N
Extraversion 3.26667 .940065 60
Agreeableness 3.64072 .499951 60
Conscientiousness 3.53332 .747990 60
Neuroticism 2.81042 .718067 60
Openness 3.54000 .821986 60
Planned 3.18167 .954293 60
Agile 3.44333 .787910 60
Table 2
Correlation Matrix for all Variables
Inter-Item Correlation Matrix
Extraversion Agreeableness Conscientiousness Neuroticism Openness Planned Agile
Extraversion 1 .565
**
-.609
**
-.738
**
.868
**
-.820
**
.832
**
Agreeableness .565
**
1 -.216 -.691
**
.645
**
-.677
**
.686
**
Conscientiousness -.609
**
-.216 1 .254
***
-.652
**
.538
**
-.48
**
Neuroticism -.738
**
-.691
**
.254
***
1 -.600
**
.724
**
-.75
**
Openness .868
**
.645
**
-.652
**
-.60
**
1 -.747
**
.783
**
Planned -.820
**
-.677
**
.538
**
.724
**
-.747
**
1 -.81
**
Agile .832
**
.686
**
-.484
**
-.747
**
.783
**
-.807
**
1
N=60,
**
p < 0.01 (Correlation is significant at the 0.01 level; 2-tailed).
***
p < 0.05 (Correlation is significant at the 0.05 level; 2-tailed).
Table 3 shows the model summary for agile and planned methodology while taking personality traits as
independent variables. The significant F value from both the models indicates that a significant

relationship exists between the weighted linear composite of the independent variables as specified by
the model and the dependent variable.
The first hypothesis, developers with a neurotic personality will like to follow plan-driven software
development methodology (1a) and developers with low in neuroticism and high in emotional stability will
like to use agile software development methodology (1b) was rejected since neuroticism was not
statistically significant. The standardized coefficient (β) = .166 and probability (p) = .168 for planned and
β= -.162, p= .169 for agile methodology were obtained when regressed with personality traits as shown in
Table 4. These results are consistent with other findings from previous research linking neuroticism to
agile methodology as in (Salleh, Mendes, Grundy, & Burch, 2010).
The second hypothesis, about correlation between introvert personality and individual’s predilection for
following plan-driven software development methodology (2a) and, correlation between extrovert
personality and individual’s predilection for following agile software development methodology (2b) was
supported. For the plan driven methodology and extraversion personality, we found β= -.437, p= 0.001
and for agile methodology and extraversion personality, we found β= .522, p< 0.000 (Table 4).
Table 3
Model Summary
Table 4
Regression on Plan-driven and Agile Methodology
Plan-driven Development Methodology Agile Development Methodology
Standardized
Coefficients (β)
Std.
Error
Significance
Standardized
Coefficients (β)
Std.
Error
Significance
Extraversion -.437 .131 .001 .522 .106 .000
Agreeableness -.279 .176 .004 .264 .142 .005
Conscientiousness .170 .115 .063 -.068 .092 .444
Neuroticism .166 .158 .168 -.162 .128 .169
The third hypothesis, about correlation between conscientious personality and individual’s predilection for
following plan-driven software development methodology (3b) and about correlation between non-
conscientious personality and individual’s predilection for following agile software development
methodology (3b) was not supported. For the plan driven methodology and conscientious personality, we
found β= .170, p= .063 which was not significant and for agile methodology and conscientious
personality, we found β= -.068, p= .444 which was not significant (see Table 4).
The fourth hypothesis, about correlation between agreeable personality and individual’s predilection for
following plan-driven software development methodology (4a) and correlation between non- agreeable
personality and individual’s predilection for following agile methodology (4b) gave some unexpected
results. Agreeableness was found to be negatively but significantly correlated with plan driven
methodology (β= -.279, p= 0.004) and thus it can be concluded that people who are low in agreeableness
Model Summary
Model R R Square
Adjusted R
Square
Std. Error of
the Estimate
Change Statistics
Durbin-
Watson
R Square
Change F Change df1 df2
Sig. F
Change
1 .871
a
.758 .741 .485880 .758 43.148 4 55 .000 1.492
2 .877
a
.769 .753 .391849 .769 45.886 4 55 .000 1.613
a
. Predictors: (Constant), Neuroticism, Conscientiousness, Agreeableness, Extraversion
Model 1:- Dependent Variable: Planned
Model 2:- Dependent Variable: Agile

tend to follow plan-driven software development methodology. Agreeableness was also found to be
significant predictor for agile development methodology use by developers (β= 0.264, p= 0.005).
The fifth hypothesis regarding openness to new experience as an indicator for developer’s interest to
follow plan driven or agile software development methodology was discarded due to high correlation of
this personality trait with extraversion. As the sample was from a population of software engineers, so we
can assume that due to their technical background, this trait can be excluded from the model.
CONCLUSIONS AND DISCUSSION
This paper attempts to understand the different working personalities of software developers so that we
can predict their inclination towards a particular software development methodology that is socially
acceptable. This work investigates applicability of personality traits of developers as a predictor of the
predilection of software developers for using plan-driven or agile software development methodology. The
results suggest that a careful assessment of the personality of different developers can help in predicting
the best suitable and adoptable software development methodology for them. Based on review of
literature we have proposed and tested five hypotheses. Empirical evidence suggests that extraversion
and agreeableness are significant predictors for agile, and introversion and low agreeableness are
significant predictors for plan-driven methodology inclination of software developers.
As agile development methodology needs continuous discussion, customer reviews and meetings, this
may be more liked by extrovert developers. Developers with agreeableness personality are found to be
helpful, trusting and kind. These may be important behavioural properties for inclination towards agile
development since agile development requires code sharing and pair programming for which trusting and
helpful nature should be needed. Plan-driven methodology like Waterfall Model follows a systematic and
predictable process which may not need developers to be social, talkative and with an assertive
personality. We can conclude that developers with high in introversion may like to follow plan-driven
development methodology. The same may be explained for developers with low agreeableness having
interest in plan-driven development since this methodology is more suitable for developers who do not
like interaction or cooperation with others, are more aggressive and are less trusting.
IMPLICATIONS FOR THE EMERGING ECONOMIES
Since, software development is often shrouded in uncertainties about adoption of the specific software
development methodology, especially with more software development being off-shored to developing
countries due to their cost effectiveness. It is vital for both practicing managers and research scholars to
understand the role personality elements can play in defining the inclination of a developer towards a
particular methodology. Knowledge of this dynamics can help researchers to extend the frontiers in the
domain of software developer performance and satisfaction in relation to the adoption of a specific
methodology, using personality traits as a lens.
Better quality software results from the combined effects of a variety of mental processes, outlooks, and
values. It might be advantageous for software organizations to consider employee personality types when
assigning project tasks. More than ever, software engineering needs different personality types for
different development methodologies. Putting it in a single context, a proper analysis of personality traits
can solve a number of problems associated with software development and maintenance.
For practicing managers this can help in determining appropriate staffing, so that people with the
personality traits that are most suited for different methodologies available can be appropriately assigned
to those specific development activities so as to ensure proper tasks execution and to maximize software
developers’ work satisfaction. This can further help in improving the chances of success of software
development projects and can help in reducing overall development time and cost.

ACKNOWLEDGEMENTS
The authors would like to thank Prof. P. K. Singh of OB & HR area, Indian Institute of Management,
Indore for his valuable comments, and all the respondents for completing the survey questionnaire for this
research.
REFERENCES
Agarwal, R., Tanniru, M., & Wilemon, D. (1997). Assimilating information technology innovations:
strategies and moderating influences. IEEE Transactions on Engineering Management, 44, 347–
358.
Agile Allia ce’s Ma ifesto for Agile Soft are De elop e t Methodology a d Tech iques
(http://www.agilemanifesto.org).
Avison, D. E., Fitzgerald, G. (2003). Information systems development: methodologies, techniques and
tools. London: McGraw-Hill.
Barrick, M. R., & Mount, M. K. (1993). Autonomy as a moderator of the relationships between the big five
personality dimensions and job performance. Journal of Applied Psychology, 78, 111-118.
Beck, K. (2000). Extreme programming explained: Embrace change. Addison Wesley Reading, MA.
Beedle, M. & Schwaber, K. (2001). Agile software development with SCRUM. Upper Saddle River, New
Jersey: Prentice Hall, Inc.
Chilton, M. A., & Hardgrave, B. C. (2004). Assessing information technology personnel: Toward a
behavioural rating scale. The DATABASE for Advances in Information Systems, 35(3).
Clarke, S. & Robertson, I. T. (2005). A meta-analytic review of the big five personality factors and
accident involvement in occupational and non-occupational settings. Journal of Occupational and
Organisational Psychology, 78, 355-376.
Cockburn, L. A., & Williams. (2001). The costs and benefits of Pair Programming in Extreme
Programming examined. Addison-Wesley, Reading, MA.
Costa, P. T., & McCrae, R. R. (1992). Revised NEO personality inventory (NEO-PI-R) and the NEO Five-
Factor inventory (NEO-FFI): Professional manual. Odessa, FL: Psychological Assessment
Resources Inc.
Dick, A. J., & Zarnett, B. (2002). Paired programming & personality traits. Paper presented at the Third
International Conference on XP and Agile Processes in Software Engineering, May 26-29, Alghero,
Sardinia, Italy.
Fitzgerald, B. (1998). An empirical investigation into the adoption of systems development methodologies.
Information & Management, 34, 317–328.
Gallivan, M. J. (2003). The influence of software developers’ creative style on their attitudes to and
assimilation of a software process innovation. Information & Management, 40, 443–465.
Glass, R. L. (2001). Extreme programming: the good, the bad, and the bottom line. IEEE Software, 18 (6)
111–112.
Green, G. C., Collins, R. W., & Hevner, V. (2004). Perceived control and the diffusion of software process
innovations, Journal of High Technology Management Research, 15, 123–144.
Goldberg, L. R. (1990). An alternative “description of personality”: The big-five factor structure. Journal of
Personality and Social Psychology, (59), 1216-1229.
Howard, A. (2001). Software engineering project management. Communications of the ACM, 44(5).
Houghton, G. B. (2004). Interpersonal traits, complementarily, and trust in virtual collaboration. Journal of
Management Information System, 20(4).
John, O. P. & Srivastava, S. (1999). The Big Five Trait Taxonomy: History, Measurement and Theoretical
Perspectives. Handbook of Personality: Theory and Research, 2nd edition.
McCrae, R. R., & John, O. P. (1992). An introduction to the Five-Factor Model and its applications.
Journal of Personality, 60, 175-215.

McElroy, J. C., Hendrickson, A. R., Townsend, A. M., & DeMarie, S. M. (2007). Dispositional Factors in
Interent Use: Personality versus cognitive style. MIS Quarterly, 31(4), 809-820.
Niazi, M., Wilson, D., & Zowghi, D. (2005). A maturity model for the implementation of software process
improvement: An empirical study. Journal of Systems and Software, 74, 155–172.
Nosek, J. T. (1998). The case for collaborative programming. Communications of the ACM, 41 (3), 105–
108.
Petri, K., & Maarit, L. (2004). How to steer an embedded software project: Tactics for selecting the
software process model. The Journal of Information and Software Technology, 47, 587–608.
Pressman, R. S. (2005). Software Engineering: A Practitioner's Approach, McGraw-Hill International
Edition.
Rawstorne, P., Jayasuriya, P., & Caputi, P. (2000). Issues in predicting and exploring usage behaviours
with the technology acceptance model and the theory of planned behaviour when usage is
mandatory. Paper presented in the Proceedings of the Twenty first International Conference on
Information Systems, Brisbane, Australia.
Riemenschneider, C. K., Hardgrave, B. C., & Davis, F. D. (2002). Explaining software developer
acceptance of methodologies: A comparison of five theoretical models. IEEE Transactions on
Software Engineering, 78, 1135–1145.
Salleh, N., Mendes, E., Grundy, J., & Burch, G. S. (2010). The effects of neuroticism on pair
programming: An empirical study in the higher education context. Paper presented at the
Proceedings of the 4th ACM-IEEE International Symposium on Empirical Software Engineering and
Measurement.
Seibert, S. E., & Maria L. K. (2001). The five factor model of personality and career success. Journal of
Vocational Behavior, 58, 1-21.
Wallace, C., & Chen, G. (2006). A multilevel integration of personality, climate, self- regulation and
performance. Personnel Psychology, 59, 529-557.
Wang, Y., & King, G. (2006). Software engineering processes: Principles and applications. USA: CRC
Press Series.
Wikiversity. (2011). Plan-driven software development methodology and techniques documentation,
http://en.wikiversity.org/wiki/Plan-driven_software_development accessed on, June 12, 2011.
Williams, L., Kessler, R. R., Cunningham, W., & Jeffries, R. (2000). Strengthening the case for pair
programming, IEEE Software, 17 (4), 19–25.
Williams, L., & Cockburn, A. (2003). Agile software development: It's all about feedback and change.
IEEE Computer.
Williams, L., & Kessler, R. R. (2002) Pair programming illuminated, Addison- Wesley, Reading, MA.
Wynekoop, J. L., & Walz, D. B. (1998). Revisiting the perennial question: Are IS people different? The
DATABASE for Advances in Information Systems, 29(2).

AGILE OR PLAN-DRIVEN SOFTWARE DEVELOPMENT METHODOLOGY SELECTION USING PERSONALITY TRAITS OF DEVELOPERS

Recommended

Recommended

More Related Content

Similar to AGILE OR PLAN-DRIVEN SOFTWARE DEVELOPMENT METHODOLOGY SELECTION USING PERSONALITY TRAITS OF DEVELOPERS

Similar to AGILE OR PLAN-DRIVEN SOFTWARE DEVELOPMENT METHODOLOGY SELECTION USING PERSONALITY TRAITS OF DEVELOPERS (20)

More from Kaela Johnson

More from Kaela Johnson (20)

Recently uploaded

Recently uploaded (20)

AGILE OR PLAN-DRIVEN SOFTWARE DEVELOPMENT METHODOLOGY SELECTION USING PERSONALITY TRAITS OF DEVELOPERS