Research Issues in Systems Analysis and Design, Databases and Software Development phần 3 docx

 Erckson, Lyytnen, & Sau

wonderfully executed along with other cores practices, and the result might
be exemplary, but due to changes in the requirements from the outset, the
system developed might not be the “correct” system. Of course that problem
is endemic to systems development in general, but since XP proponents claim
that the approach is superior, then fewer instances of building the wrong
system should be evidenced. As to research in this area, while planning is
critical and essential for success, it remains to be seen as to whether the specific XP approach is more beneficial than other more standard approaches
to developing user requirements.
Companies or organizations using the heavier methodologies typically had
trouble adopting incremental releases because of the implications that core
practice has for several other core practices: simple design, testing, refactoring, and continuous integration. These core practices appear to be closely
related since, for example, a daily build means that the testing suite must also
be ready daily, which in turn has implications for continuous integration and
refactoring. Research into these core practices will nevertheless be necessary
if the overall approach is to be accepted by the mainstream.
If pair dynamic programming is used, the coding-standards core practice
means that developers must agree up front on the conventions used for naming
classes as well as, for example, on a host of other coding practices. A coding
standard in the end means that someone looking at a code segment cannot
tell which team member wrote it. This should be something that programmers do for all projects, but sadly it is not. Research should be implemented
that compares practice with recommendation in both the traditional and XP
areas. However, this instance also highlights once again the difficulties of
examining XP’s core practices individually: the likelihood that interaction
or correlation between and among other core practices will be possible and
even probable. In this case, the coding-standards practice is related to and
could be affected by pair programming and development of the test suite,
just to name two, and there are likely to be other interactions as well.
The efforts of Kuppuswami et al. (2003) represent a pioneering effort in XP
research. They used a process model simulation to vary the level (in labor)

of XP’s core practices one at a time to judge the effect upon total effort for
the project. They found that increasing effort (independent variable) into
XP core practices reduced the total effort (dependent variable) needed to
create the system, although interactions and other moderating effects were
not discussed at great length. While the research provides some support for

Copyright © 2007, IGI Global. Copying or distributing in print or electronic forms without written permission
of IGI Global is prohibited.


Understandng Agle Software, Extreme Programmng, and Agle Modelng 

XP practices, field verification of the simulation is definitely indicated and
would be very beneficial.
Other empirical efforts to study XP, in total or just its core practices, are
quite limited as well. Williams’ numerous and varied studies along with a
few others (Alshayeb & Li, 2004; Müller & Padberg, 2003) are the primary
exceptions in this area of research. Agile modeling is almost totally unstudied, and any research into the methodology would be an improvement over
the current state of affairs. The models themselves could be used as the
measures of the efficacy of the methodology, although assessing models as
to their relative “goodness” or “badness” is at least somewhat subjective and
a possible threat to the validity of research conducted in that manner. The
study of agile methodologies appears to be unorganized and, for want of a
better word, random.

Conclusion
From a research-based perspective, it appears the research community,
practitioners, and educators might benefit from a more structured approach
to the study of XP. The bulk of the existing research appears focused on
validating the overall XP approach, which is probably, or perhaps arguably,

satisfactory if one is only concerned with the macro perspective of XP as a
whole. However, since the proponents, as noted previously, seem to universally accept the 12 core practices as integral and necessary parts of XP, then
it would seem logical to empirically examine the efficacy of each of the 12
core XP practices separately if we want to examine what it is that makes XP
successful (or not). In other words, do we want XP to remain a “black box”
and simply accept that it works? Other than pair programming, incremental
releases, and at most a few of the other core practices, many of the others
remain relatively unstudied, at least in an XP environment.
As to XP specifically or agility in general as approaches to systems development, there is anything but unanimous agreement that there is really anything
new. Merisalo-Rantanen et al. (2004) conducted a case study and concluded
that XP is really nothing new, but simply a repackaging of old (though arguably useful) techniques for developing systems. Turk et al. (2004) also
indicate that the benefits to be gained from adopting agile methods are not
realized if the underlying assumptions are not met.
Copyright © 2007, IGI Global. Copying or distributing in print or electronic forms without written permission
of IGI Global is prohibited.


 Erckson, Lyytnen, & Sau

Confounding factors could also cause problems with research in this direction.
For example, what are the differences between the prescribed approaches
(heavy or light) and practice, and what effect do these differences or gaps
have on the success of the various development efforts? Also, if we begin
looking at the efficacy of the 12 core XP practices separately, that opens up
the possibility of interaction effects. In other words, it appears that a number
of the core practices are obviously related to one another—pair programming
and collective ownership, for example. If that is the case for obvious and
even for nonobvious relationships, then what effect upon the overall success
of the project, and ultimately the methodology, does strict adherence to the
rules of a prescribed approach for one core practice have if other practices

are glossed over or even not used for whatever reason? Perhaps the 12 core
practices of XP could even be grouped together into related areas, such as
actors (participants in the development effort), technology, structure, and
process, and studied from that perspective.
Another potentially critical issue facing software developers and researchers
alike is that of software standards. In light of ISO and other standards imposed
by governments, implementing organizations, or other regulatory bodies, the
quest to render development methodologies more agile by cutting away or
eliminating some of the overhead could become difficult or even virtually
impossible since the artifacts of development often become a large part of
the documentation requirements.
Theunissen, Kourie, and Watson (2003) looked at the potential adaptability
of agile software methodologies with regard to ISO/ISE 12207:1995, among
other standards. They found that XP in particular could be used to satisfy
many of the standard’s requirements and developed a set of guidelines for
potential users. However, research should be executed regarding whether the
guidelines have been successfully adopted and used in practice.
There is no—and likely will never be—an easy fix for these problems. There
are no magic solutions (Germain & Robillard, 2005). In addition, from the
extremely high failure rates commonly associated with system development
efforts (estimates range from 50 to 75%), it appears that there should be
ample room for improvement in development efforts, whatever shape or form
they take. Agile modeling and extreme programming represent a possible
step in the right direction if developers have the courage to commit people
and resources to the effort and pain involved in managing the changes that
will inevitably occur as a result. However, organizations must also practice
caveat emptor and clearly state that they cannot embrace a particular develCopyright © 2007, IGI Global. Copying or distributing in print or electronic forms without written permission
of IGI Global is prohibited.

Understandng Agle Software, Extreme Programmng, and Agle Modelng 

opment methodology simply because a person or group of people says that
it is good.
The proponents of AM and XP have expressed themselves quite clearly and
forcefully on the subject of agile modeling and programming, and, judging
from the current bleak and stony landscape of systems development, it appears that they are correct. Those that know (industry insiders and researchers)
simply point to statistics that back up their claim that many of the processes
we have used and are using to develop information systems are broken and
likely unrepairable. When 60% of a typical system’s O&M budget goes toward
Band-aiding the results of inadequate analysis and development, when two
thirds to three quarters (depending upon whose statistics you wish to use)
of information systems developed can be considered failures in that they do
not provide the functionality required, when we have all been taught to build
throwaway systems that can often be obsolete before projects are completed,
and when we systematically exclude from development those whom we are
building the system for, then it is indeed time to take a step back, look at the
mirror, and say, “Just what is wrong with this picture?”

References
Abrahamsson, P., Warsta, J., Siponen, M., & Ronkainen, J. (2003). New directions on agile methods: A comparative analysis. In Proceedings of the
25th International Conference on Software Engineering (pp. 244-254).
Aiken, J. (2004). Technical and human perspectives on pair programming.
ACM SISOFT Software Engineering Notes, 29(5).
Alshayeb, M., & Li, W. (2005). An empirical study of system design instability metric and design evolution in an agile software process. Journal of
Systems and Software, 74, 269-274.
Ambler, S. (2001a). Agile modeling and extreme programming (XP). Retrieved March 31, 2005, from />agileModelingXP.htm
Ambler, S. (2001b). Debunking extreme programming myths. Computing
Canada, 27(25).
Ambler, S. (2001c). Values, principles and practices equal success. Computing Canada, 27(10).

Copyright © 2007, IGI Global. Copying or distributing in print or electronic forms without written permission
of IGI Global is prohibited.


0 Erckson, Lyytnen, & Sau

Ambler, S. (2001-2002). The principles of agile modeling (AM). Retrieved
March 31, 2005, from />Ambler, S. (2002a). Agile development best dealt with in small groups.
Computing Canada, 28(9).
Ambler, S. (2002b). Know the user before implementing a system. Computing Canada, 28(3).
Aoyama, M. (2000). Web-based agile software development. IEEE Software.
Armano, G., & Marchesi, M. (2000). A rapid development process with
UML. Applied Computing Review, 18(1).
Beck, K. (1999). Extreme programming explained: Embrace change. Boston:
Addison-Wesley.
Booch, G., Rumbaugh, J., & Jacobson, I. (1999). The unified modeling language user guide. Boston: Addison-Wesley.
Cockburn, A., & Williams, L. (2000). The costs and benefits of pair programming. In Proceedings of XP 2000 Conference, Sardinia, Italy.
C3 Team. (1998). Chrysler goes to “extremes.” Distributed Computing.
Erdogmus, H., & Williams, L. (2003). The economics of software development
by pair programmers. The Engineering Economist, 48(4), 283-319.
Erickson, J., & Siau, K. (2003, April). UML complexity. In Proceedings of
the Systems Analysis and Design Symposium, Miami, FL.
Erickson, J., & Siau, K. (2004, December). Theoretical and practical complexity
of unified modeling language: A Delphi study and metrical analyses. In
Proceedings of the International Conference on Information Systems.
Extreme modeling Web site. (2005). Retrieved January 25 from http://www.
extrememodeling.org/
Fowler, M. (2001). The new methodology. Retrieved March 31, 2005, from
/>Fowler, M., & Highsmith, J. (2001). The agile manifesto. Retrieved March
31, 2005, from />Fruhling, A., & De Vreede, G. (2006). Field experiences with extreme

programming: Developing an emergency response system. Journal of
Management Information Systems, 22(4), 39-68.

Copyright © 2007, IGI Global. Copying or distributing in print or electronic forms without written permission
of IGI Global is prohibited.


Understandng Agle Software, Extreme Programmng, and Agle Modelng 

Germain, E., & Robillard, P. (2005). Engineering-based processes and agile
methodologies for software development: A comparative case study.
Journal of Systems and Software, 75, 17-27.
Grenning, J. (2001). Launching extreme programming at a process intensive
company. IEEE Software.
Hedin, G., Bendix, L., & Magnusson, B. (2005). Teaching extreme programming to large groups of students. Journal of Systems and Software, 75,
133-146.
Henderson-Sellers, B., & Serour, M. (2004). Creating a dual agility method:
The value of method engineering. Manuscript submitted from publication.
Herbsleb, J., & Goldenson, D. (1996). A systematic survey of CMM experience and results. In Proceedings of ICSE-18 (pp. 323-330).
Hirsch, M. (2002). Making RUP agile. SIG Programming Languages.
Holmström, H., Fitzgerald, F., Ågerfalk, P., & Conchúir, E. (2006). Agile
practices reduce distance in global software development. Information
Systems Management, 23(3), 7-18.
Jeffries, R. (2001). What is extreme programming? XP Magazine. Retrieved
March 31, 2005, from />htm
Karlsson, E., Andersson, L., & Leion, P. (2000). Daily build and feature
development in large distributed projects. Limerick, Ireland: ISCE.
Kuppuswami, S., Vivekanandan, K., Ramaswamy, P., & Rodrigues, P. (2003).
The effects of individual XP practices on software development effort.
ACM SIG Software Engineering Notes, 28(6).

Lindstrom, L., & Jeffries, R. (2004). Extreme programming and agile software development methodologies. Information Systems Management,
24(3).
Manhart, P., & Schneider, K. (2004). Breaking the ice for agile development
of embedded software: An industry experience report. In Proceedings
of the 26th International Conference on Software Engineering.
Merisalo-Rantanen, H., Tuunanen, T., & Rossi, M. (2004). Is extreme programming just old wine in new bottles: A comparison of two cases.
Manuscript submitted for publication.

Copyright © 2007, IGI Global. Copying or distributing in print or electronic forms without written permission
of IGI Global is prohibited.


 Erckson, Lyytnen, & Sau

Müller, M., & Padberg, F. (2003). On the economic valuation of XP projects.
In ACM SIGSOFT Software Engineering Notes: Proceedings of the
9th European Software Engineering Conference held jointly with 11th
ACM SIGSOFT International Symposium on Foundations of Software
Engineering, 28(5).
Newkirk, J., & Martin, R. (2000). Extreme programming in practice. Minneapolis, MN: OOPSLA.
Palmer, S. (2000). Feature driven development and extreme programming.
Togethersoft Corporation.
Paulk, M. (2001). Extreme programming from a CMM perspective. IEEE
Software, 18(6), 19-26.
Pfleeger, S., & McGowan, C. (1990). Software metrics in a process maturity
framework. Journal of Systems and Software, 12(3), 255-261.
Poole, C., & Huisman, J. (2001). Using extreme programming in a maintenance environment. IEEE Software.
Schuh, P. (2001). Recovery, redemption, and extreme programming. IEEE
Software.
Siau, K., & Cao, Q. (2001). Unified modeling language (UML): A complexity analysis. Journal of Database Management.

Siau, K., Erickson, J., & Lee, L. (2002, December). Complexity of UML:
Theoretical versus practical complexity. In Proceedings of the Workshop
on Information Technology and Systems (WITS), Barcelona, Spain.
Strigel, W. (2001). Reports from the field: Using extreme programming and
other experiences. IEEE Software.
Theunissen, W., Kourie, D., & Watson, B. (2003). Standards and agile software development. In Proceedings of SAICSIT (pp. 178-188).
Turk, D., France, R., & Rumpe, B. (2004). Assumptions underlying agile
software development process. Manuscript submitted for publication.
Wake, W. (1999). Introduction to extreme programming (XP). Retrieved
March 31, 2005, from />What is refactoring? (2005). Retrieved March 13 from />wiki?WhatIsRefactoring
Williams, L., & Kessler, R. (2000a). All I really need to know about pair
programming I learned in kindergarten. Communications of the ACM,
43(5).
Copyright © 2007, IGI Global. Copying or distributing in print or electronic forms without written permission
of IGI Global is prohibited.


Understandng Agle Software, Extreme Programmng, and Agle Modelng 

Williams, L., & Kessler, R. (2000b). The effects of “pair-pressure” and
“pair-learning” on software engineering education. Presented at the
Conference of Software Engineering Education and Training.
Williams, L., & Kessler, R. (2001). Experimenting with industry’s “pairprogramming” model in the computer science classroom. Computer
Science Education.
Williams, L., Kessler, R., Cunningham, W., & Jeffries, R. (2000). Strengthening the case for pair programming. IEEE Software.
Williams, L., & Upchurch, R. (2001, October). Extreme programming for
software engineering education. In Proceedings of the ASEE/IEEE
Frontiers in Education Conference, Reno, NV.
Wills, A. (2001). UML meets XP. Retrieved March 31, 2005, from http://www.
trireme.com/whitepapers/process/xp-uml/paper.htm

Copyright © 2007, IGI Global. Copying or distributing in print or electronic forms without written permission
of IGI Global is prohibited.


 Aydn, Harmsen, Hllegersberg, & Stegwee

Chapter III

Adaptation of an
Agile Information System
Development Method
Mehmet N. Aydn, Unversty of Twente, The Netherlands
Frank Harmsen, Capgemn, The Netherlands
Jos van Hllegersberg, Unversty of Twente, The Netherlands
Robert A. Stegwee, Unversty of Twente, The Netherlands

Abstract
Little specific research has been conducted to date on the adaptation of agile
information systems development (ISD) methods. This chapter presents the
work practice in dealing with the adaptation of such a method in the ISD
department of one of the leading financial institutes in Europe. The chapter
introduces the idea of method adaptation as an underlying phenomenon
concerning how an agile method has been adapted to a project situation
or vice versa in the case organization. In this respect, method adaptation is
conceptualized as a process or capability in which agents holding intentions
Copyright © 2007, IGI Global. Copying or distributing in print or electronic forms without written permission
of IGI Global is prohibited.

Adaptaton of an Agle Informaton System Development Method 

through responsive changes in, and dynamic interplays between, contexts and
method fragments determine an appropriate method for a specific project
situation. Two forms of method adaptation, static adaptation and dynamic
adaptation, are introduced and discussed in detail. We provide some insights
plus an instrument that the ISD department studied uses to deal with the
dynamic method adaptation. To enhance our understanding of the observed
practice, we take into account two complementary perspectives: the engineering perspective and the socio-organizational perspective. Practical and
theoretical implications of this study are discussed.

Introduction
Despite the best endeavors in the area of information systems research and
practice, the effective use of information systems development methods (ISDMs) remains an issue on both academics’ and practitioners’ agendas (Iivari,
Hirschheim, & Klein, 2001). In the 1980s and 1990s, the rationales behind
structured, brand-named ISDMs, the so-called conventional methods, were
being questioned as being IT oriented, complex, rigid, and inappropriate for
postmodern forms of organizations whose distinctive character was to be
adaptable to continual change (Sauer & Lau, 1997). Recently, agile—denoting “having a quick resourceful and adaptable character” (Merriam-Webster
Online, 2003)—ISDMs, agile methods in short, have appeared as a solution
to the long-standing problems related to conventional methods.
This chapter is mainly concerned with the adaptability of agile methods
(i.e., the extent to which a method is to be adapted to the project situation
at hand or vice versa) yet points out the need for further research in order
to understand other distinctive aspects of agile systems’ development and
to make sense out of the dispersed field of agile methods (Abrahamsson,
Warsta, Siponen, & Ronkainen, 2003). As we shall see later on, many studies concerning the effective use of ISDMs adopt the notion of adaptation but
use different terms or concepts in their theoretical constructs, for example,
“method fragment adaptation” in Baskerville and Stage (2001), “scenario
use” in Offenbeek and Koopman (1996), “method tailoring” in Fitzgerald,

Russo, and O’Kane (2000), “situational” or “situated method engineering” in
Harmsen, Brinkkemper, and Oei (1994) and Slooten and Brinkkemper (1993),

Copyright © 2007, IGI Global. Copying or distributing in print or electronic forms without written permission
of IGI Global is prohibited.


 Aydn, Harmsen, Hllegersberg, & Stegwee

“context-specific method engineering” in Rolland and Prakash (1996), and
“method engineering” in Siau (1999).
Two limitations with these studies have motivated us to carry out this research.
First, the existing studies use different perspectives and provide countervailing
arguments for the notion of adaptation. Second, the proposed models appear
to be limited to theoretical arguments and need empirical findings to support
their arguments. More precisely, as Fitzgerald, Russo, and O’Kane (2003,
p. 66) state, “little research has been conducted to date on method tailoring
specifically.” This observation is particularly true for agile methods.
Our research addresses these two limitations and illustrates the working practices in a large-scale IT department dealing with the adaptation of an agile
method, dynamic systems development method (DSDM), as elaborated later
on, in different project situations. Besides the description of the observed
practice, this chapter argues the need for a multitheoretic lens combining the
engineering and the socio-organizational perspectives, and uses it to elaborate
the notion of adaptation in agile systems development. Similar to the research
approach adopted by Fitzgerald et al. (2003), this chapter inductively draws
lessons from agile method adaptation in practice rather than tests hypotheses defined in advance. In doing so, the chapter provides valuable insights
for both practitioners and academics concerning the effective use of agile
methods in large-scale IT departments.
The structure of the chapter is as follows. First, the motivation behind the
research has been outlined in this section. The remainder of the chapter consists of three key sections: (a) a review of related research, (b) the conduct

of this research, and (c) discussions and conclusions of the research.

Background
Given that the existing explanations concerning method adaptation are fragmented and countervailing, we need a framework in which to organize the
previous research relevant to method adaptation. Such a framework will also
help us indicate the focus of this chapter. Before introducing the framework,
we will clarify our interpretation of key terms such as method and method
adaptation, and their usages in this chapter.

Copyright © 2007, IGI Global. Copying or distributing in print or electronic forms without written permission
of IGI Global is prohibited.


Adaptaton of an Agle Informaton System Development Method 

The first term is method. As various definitions of method exist, we use its
simplest yet broadest meaning; as such, it refers to “an explicit way of structuring one’s thinking and actions” (Jayaratna, 1994). While new methods
are promoted as a panacea for well-publicized ISD failures, old ones have
been criticized for being rigid, comprehensive, and built upon the idea that
a method can be used for all projects, which brings on a “one-size-fits-all”
issue. In fact, a fundamental problem still remains that methods, irrespective
of their preferred features (agility, state-of-the-art knowledge foundations),
by nature involve certain thinking and often prescribe certain actions for ISD.
The subject matter at hand addresses this one-size-fits-all issue and aims to
deal with how an ISD method is adapted and can be supported so that the
resulting method, the so-called situated method, fits a project situation. The
idea behind a situated method is that any prospective method to be used for
a development project is subject to certain adjustments because of the fact
that the method is limited to its preferred thinking and prescribed actions for
ISD that cannot fully accommodate the uniqueness of a project situation. In

this regard, such adjustments are needed for the method along with a premise
that the resulting method can provide a well-suited means for ISD and in turn
reduce the risk of its failures.
The fundamental assumption about method existence in IS development
states that as long as IS development takes place, a method must be present
in the development of an IS, and human actions and thinking involved in IS
development are purposely structured to achieve certain goals. This assumption follows from the definition of method (an explicit way of structuring
one’s thinking and actions). Accordingly, method has two essential functions
in ISD: (a) the function that purports certain effects on human thinking (such
as augmenting, facilitating, and structuring), for which we use the term intellectual, punctuating the strategic orientation of a method fragment, and (b)
the function that purports certain effects on human behaviour (i.e., supporting, automating), for which we use the term procedural, emphasizing the
operational orientation of a fragment.
These two functions are intimately intertwined because it is granted in the
field of the philosophy of mind that certain kinds of human behaviour (e.g.,
purposive human behaviour) cannot be truly isolated from associative cognitive models (schemata) in the human mind. A number of researchers in
the domain of method engineering, including Siau (1999), have studied a
psychological perspective on method adaptation. Similar argument can be

Copyright © 2007, IGI Global. Copying or distributing in print or electronic forms without written permission
of IGI Global is prohibited.


 Aydn, Harmsen, Hllegersberg, & Stegwee

made for techniques and tools that can treat methods, tools, and techniques as
methodical means and/or intellects—that is, possessing certain viewpoints on
thinking about IS and ISD, which supposedly aim to support practitioners for
effective and efficient development of an IS. As methodical means the focus
of methods is on their practical use; as such they can support practitioners’
actions during ISD. Besides practical use, one can look at implications in the

context of human thinking related to development activities. In this sense,
methods interact with their users and such interactions can be seen as hermeneutic—that is, interpretative—processes (Introna & Whitley, 1997). This
has to do with mutual understanding, and augmenting and structuring their
way of thinking about IS and ISD. Methods are just instruments, but along
with this interaction they have another role and posses certain intellects and
even aim to convey certain thinking about IS and ISD. As such, methods have
their own reasoning mechanism or understanding of whatever methods are
supposed to do. It is this understanding that gives methods power to influence
the way of thinking held by the practitioners in the course of action during
ISD.1 It is this fact that gives methods a special role in the development of
human intellects.2 Having presented the meaning of method, we can turn our
attention to adaptation.
The second term is adaptation. The term adaptation simply implies “a modification according to changing circumstances” (Merriam-Webster Online,
2003). Since its significance might vary, for the purpose of this chapter, we
further define method adaptation as a process or capability in which agents
through responsive changes in, and dynamic interplays between, contexts,
intentions, and method fragments determine an appropriate method for a specific project situation. With this definition we aim to stay at an abstract level
that will allow us to organize related previous research. Before explaining
the terms in the definition above, two key perspectives concerning method
adaptation are introduced.
As noted in Baskerville and Stage (2001), existing studies related to method
adaptation follow one of two key perspectives: the engineering perspective
representing the positivist views of natural science, and the socio-organizational
perspective representing interpretative views of social science (see Table 1).
The former is of interest to the school of method engineering, emphasizes
the structural aspects of the method, and usually employs contingency-based
models for method adaptation. The latter appears to be concerned with better understanding of how a method and its components are invented on the

Copyright © 2007, IGI Global. Copying or distributing in print or electronic forms without written permission
of IGI Global is prohibited.

Adaptaton of an Agle Informaton System Development Method 

Table 1. Framework for organizing previous research relevant to method
adaptation
The Engineering Perspective

The Socio-Organizational
Perspective

Method engineers as dominant actors

An interplay between people, including
project managers, method engineers,
developers, and end users, involved in a
project

Factor-based characterization of context

Emerging context in ISD setting

Method Fragment

Coherent and structured parts of a
method

Innovated, unstructured fragments
separated from a prescribed method

Process/Intention

Static and dynamic use of factors
mediated by an intention, often in terms
of risk and success factors

An ill-structured, complex organizational
phenomenon

Agent

Contexts

fly and are actually used in an emerging work setting, and this is reflected
in the body of knowledge contained in the socio-organizational literature
(Baskerville & Stage).
These two perspectives adopt different levels of abstraction for method adaptation (Iivari, 1989). The engineering perspective stays at a conceptual level
where the main focus is on models of the real or empirical world rather than
the real world itself (Harmsen, 1997). In comparison, the socio-organizational
perspective looks into the empirical world and tries to understand method
adaptation in practice, examining real, concrete development processes. The
empirical study of Fitzgerald et al. (2003) presented how method adaptation had been carried out in the Motorola organization at various levels. The
authors distinguished three adaptation levels: the industry, the organization,
and the project. Our focus in this chapter is on method adaptation at the
project level.

Prescribed vs. Emerging Context
The term context refers to a collection of relevant conditions and surrounding
influences that make a project situation unique and comprehensible (Hasher
& Zacks, 1984). The complexity of context as a subject has been acknowledged by many scholars, including Akman and Bazzanella (2003). Andler

(2003) argues that relevant discussions on this subject in philosophy evolve
Copyright © 2007, IGI Global. Copying or distributing in print or electronic forms without written permission
of IGI Global is prohibited.


0 Aydn, Harmsen, Hllegersberg, & Stegwee

from its narrowest meaning about the consideration of texts in linguistics to
its broadest meaning, something to do with “situated cognition,”3 which is
invariably situated, as elaborated in the field of pragmatism. In particular, a
traditional view of the notion of context suggests that contexts are preexisting and stable environments that perhaps include unobservable factors that
cause agencies to behave in partly unpredictable ways (Rogoff & Lave, 1984).
This view appears to be akin to what Andler calls the optimistic claims stating that for all classes of cognitive tasks and processes, there is a uniform
context matrix, whatever the features or factors are granted, such that for all
situations in the class, the outcome of any process in the class is determined
by the values taken by the matrix in the situation.
This is often contrasted with the contemporary view that asserts that all
contextual regularities, conditions, and any other relevant features are assumed to be dynamically activated and accomplished in the situation (Linell
& Thunqvust, 2003). Context has also been studied as a central notion in
human decision making. Pomerol and Brézillon (2001) illuminate the dynamics of context and the employment of reasoning for practical decision
making. Practical decision making, as discussed by Pomerol and Brézillon
(2004), is reminiscent of naturalistic decision making, an adopted orientation in this work.
Different kinds of context are introduced with a duality character (Schegloff, 1992) such as immediate or proximate contexts. These include features
pertaining to actual surroundings in situ vs. distal or mediate contexts that
cover background knowledge, cognitive frames, or assumptions about ongoing, upcoming, or even a priori activities relevant in situ. Another distinction is made between so-called primary and secondary context, the extent to
which influencing characteristics are stable (Pomerol & Brézillon, 2001). In
relation to this duality character, Andler (2003) defends a “mixed model of
inquiry,” which combines rationalist reliance either on fact or principles with
a consideration for appropriateness to the situation at hand. This is indeed
where the pragmatics view of context stands and of which several accounts

are proposed. Mey (2003), for instance, advocates this view and argues
that ambiguity is inherent in contextualization, decontextualization, and
recontextualization through which one may effectively marginalize certain
agencies and their legitimate interpretations by virtue of an institutionally
embedded context.
But what does context then include? Or to say it differently, what is included
and excluded in this contextualizing? Brézillon and Pomerol (2002) suggest
Copyright © 2007, IGI Global. Copying or distributing in print or electronic forms without written permission
of IGI Global is prohibited.


Adaptaton of an Agle Informaton System Development Method 

focusing on the dynamic of context rather than things included and excluded
in contextualizing and propose three types of knowledge for contextualizing:
external, a part of knowledge not used in a specific situation at the moment
contextualizing occurs; contextual, a part of knowledge relevant for contextualizing; and proceduralized, a part of knowledge invoked, structured, and
effectively situated in contextualizing. Perhaps a more provocative question
would be who excludes what, and on whose premises? These questions have
to do with the roles of agencies in this contextualization. Andler (2003) states
that:
... the ultimate goal of a general theory of context would be an account for
regularities, if any, which can be observed in the effects of context on cognitive
process. If there are indeed such regularities, the context problem, relative
to the class of situations and processes at hand, has an in-principle solution,
consisting in refining and otherwise modifying the state space. (p. 354)
Human agency is central to contextualization. In connection with this work,
of course, method fragments are also considered during this contextualization. However, exclusion of the agency and method fragments is in effect
when the context is framed and reframed along with the cognitive structure
and processes (Piaget, 1983). After successive approximation, this eventually

leads to an appropriate context under consideration in which the decision
is made. Accordingly, cognitive structures change through the process of
adaptation by assimilation and accommodation. This is boldly marked in
the radical constructivism along with the principle stating that the function
of cognition is adaptive and serves the agency’s framing or organizing of
the experiential world, not the discovery of an objective ontological reality
(Glasersfelds, 1997). We employ the ideas of contextualizing, framing, and
appropriation in relation to the very notion of context.
Interested readers can see the elaborations of existing models or views characterizing the context in which an IS development takes place (Lyytinen,
1987). Both the perspectives discussed above use various kinds of factors to
understand the context. Even though the proposed list of factors in the domain
of method engineering is supposed to be lengthy, it is apparent that social and
organizational issues are not the focus of attention. The socio-organizational
perspective, however, does put more emphasis on social and organizational
elements of the context. In addition, this perspective considers context as an
emerging ISD setting rather than as a prescribed project situation.
Copyright © 2007, IGI Global. Copying or distributing in print or electronic forms without written permission
of IGI Global is prohibited.


 Aydn, Harmsen, Hllegersberg, & Stegwee

Structured vs. Innovated Method Fragments
Both perspectives use the concept of fragments. From the engineering perspective, a method fragment is a description of an ISDM or any coherent
part thereof. It is usually prescribed and structured in terms of fragment
properties (Harmsen, 1997). Conversely, the socio-organizational perspective
gives more attention to those fragments that are distinct from a prescribed
method. This perspective sees fragments as follows: “Under [this] concept,
each systems development project is a moving pastiche of miscellaneous
parts; bits of external methodologies, internal methods, innovative, unique

techniques invented on-the-fly, etc.” (Baskerville & Stage, 2001, p. 18). To
differentiate between the two meanings of this concept, we consider there
to be two types of fragments. We use the terms structured and unstructured
fragments to refer to the meanings in the engineering and socio-organizational
perspectives respectively.
Fragments can be principles, fundamental concepts, products to be delivered,
activities needing to be performed, job aids—techniques, tools, hints, tips—to
be used, and so forth. Some of them are essential to the ISD approach. The
term ISD approach, and we adopt the definition of Iivari et al. (2001), refers
to a high-level description of the method including the goals and the guiding principles, and the beliefs, fundamental concepts, and principles of an
ISD process.
Fragments can be related to aspects of the method, such as the way of thinking, modeling, working, controlling, and supporting (Wijers, 1991). We are
interested in those fragments related to the way of thinking, and to some
extent to the way of modeling and working. The terms principles and assumptions used in published methods often refer to this kind of fragments (Turk,
France, & Rumpe, 2005). These are called strategic fragments in that they
have strategic orientations or effects on the way of thinking on ISD and IS
and reflect intellectual function of the method. They are concerned with, for
instance, modeling aspects and scope, development strategy, and deployment
strategy. As such, they are often referred to as building blocks of scenarios
or a planned approach in literature (e.g., Slooten & Hodes, 1996).
So, we identify the following fragments and corresponding decision variables
related to several aspects such as the modeling aspect, design-development
aspect, and user-engagement aspect. Consequently, we have the following.

Copyright © 2007, IGI Global. Copying or distributing in print or electronic forms without written permission
of IGI Global is prohibited.


Adaptaton of an Agle Informaton System Development Method 

Strategic fragments that are related to modeling aspects:
•

•

•

•

Modeling scope (the boundary of the target system and dimensions):
The extent to which the approach considers the tracing of several perspectives such as functional, information, process, organizational, and
operation (e.g, Curtis, Kellner, & Over, 1992)
Approach orientation (the orientation of the problem-solving system):
Problem or solution orientation and social aspect (technical-administrative or social-organizational; see Offenbeek & Koopman, 1996)
The analysis starting point (knowledge acquisition strategy): Current
situation or future situation (direct acceptance of user requirements; the
actual system as a starting point, possibly from the point of view of the
old system; determining information requirements from scratch, starting
from perspective of the object system)
Reuse (design) strategy: Using a reference (architecture) model, a new
architecture, or a combination of both

Strategic fragments that are related to design-development aspects:
•
•

•
•

Dividing strategy: Increment strategy (how to partition the problem

and/or solution space)
Realization strategy: The way to realize a number of increments—at
once (no subsystem), concurrently (parallel), overlapping, or consecutively (subsystems are developed one after another, incrementally)
Development strategy: Linear, overlapping, throwaway, keep-it prototyping, evolutionary, or reverse engineering
Delivery strategy: The way to deploy a solution in an organizational
setting—big bang (at once), incremental, evolutionary

Strategic fragments that are related to stakeholder-engagement aspects:
•

Validation strategy: Immediate acceptance, definition of norms, and test
cases by means of which assessment takes place or whether the chosen
solutions meet the requirements; prototyping; validation by usage

Copyright © 2007, IGI Global. Copying or distributing in print or electronic forms without written permission
of IGI Global is prohibited.


 Aydn, Harmsen, Hllegersberg, & Stegwee

•

Engagement strategy: Based on the interaction model of Offenbeek
and Koopman (1996) and in particular on the user engagement (degree
of user involvement and responsibility)

Agents Leading Method Adaptation with an Intention
An agent is an actor with one role or more in a method adaptation process.
The socio-organizational perspective does not specify any specific roles in
that process, yet the emphasis is on the practical interplay between people at

work. The socio-organizational perspective considers the method adaptation
process as “an ill-structured, complex socio-organizational phenomenon”
(Baskerville & Stage, 2001, p. 14). Anthropology is referred to as a potential reference discipline to study such a process, and Agar’s (1986) practical
ethnography and its four major units of analysis are used to explain how the
process develops in practice.
The engineering perspective regards method engineers as the dominant actors in method adaptation. Their role is to carry out the process leading to
a tailored method, that is, a method that is adapted to the project context at
hand. Such a process usually employs contingency-based models. Offenbeek
and Koopman (1996) discuss the limitations of 17 contingency-based models
that have been proposed for determining an appropriate approach for an IS
development project. As they note, the factors taken into account in these
models can be numerous, or limited to certain IS views and used in a static
manner. That is, these models ignore possible bilateral interactions between
the context, characterized by the factors, and the approach, and further lack
dynamic interactions among the factors. Offenbeek and Koopman propose
the concept of a dynamic fit between context and approach as a solution
to the static use of contextual factors, the approach, and the corresponding
method fragments. They state, “To a certain extent the dominant actors cannot only choose their approach but also their context, whether by definition
or by intervention, that is by deliberately changing the context” (p. 257). It
is important to note that both the context and the approach are subjects for
adaptation, and a form of mediating construct is needed to facilitate this
adaptation process. Such a construct is here called an intention and has been
referred to using different terms in the various models proposed for method
adaptation; see, for instance, risk in conventional contingency-based models
as listed in Van Offenbeek and Koopman (1996), success in Harmsen et al.

Copyright © 2007, IGI Global. Copying or distributing in print or electronic forms without written permission
of IGI Global is prohibited.

Adaptaton of an Agle Informaton System Development Method 

(1994), goal in Baskerville and Stage (2001), and mediating factors in Slooten
and Brinkkemper (1993). We consider the intention as an indication of what
drives the agents while carrying out method adaptation.
In the dictionary (Merriam-Webster Online, 2005) and everyday language,
the term intention is synonymous with volition, purpose, and significance,
and indicates “a determination to act in a certain way.” Other derivations
and uses of the term appear as intent, intentionality, doing with an intention, or doing something intentionally. To ground explanations concerning
their differences would require a long philosophical treatise that belongs to
the philosophy of mind, but the treatment of intention and intentionality in
Bratman (1987) and Morison (1970) is relevant to our subject. The treatment
of the terms intention and intentionality should be separated as the former
has been articulated in relation to action, planning, and practical rationality
(Bratman), and the latter is proposed in phenomenology, a particular school
of thought in the philosophy.
Intention is considered a state of mind (what it is to intend to do something)
and a characteristic of action (having an intention to do something or doing
something intentionally). Intentionality derives from the Latin verb intendere,
which means to point to or to aim at, and Brentano (1838-1917) accordingly
characterized the intentionality of mental states and experiences as their feature of each being directed toward something. Intentionality in this technical
sense then subsumes the everyday notion of doing something intentionally:
An action is intentional when done with a certain intention, that is, a mental
state of aiming toward a certain state of affairs. One of the most comprehensive expositions of the term intention is in the work of Michael Bratman.
His treatment reveals complexity and the essence of its characteristics and
functions along with two forms (future and present directed4). Bratman (1987)
extensively discusses his account in relation to planning theory and agent
rationality, for which we cannot condense the body of literature he employs
in a few pages. The forms and kinds of intention he proposed, however, are
especially useful for characterizing the agency action in method adaptation.

Upon deeper examination of the idea of intending to act, which channels
a future-directed form of intention, or having an intention to act, which is
present-directed action, he contends that intentions are neither desires nor
beliefs but plans, and that plans have an independent place in practical thinking. One of the central facts about intentions essential for this work is that
they are conduct-controlling pro-attitudes and serve as inputs for further
practical reasoning.
Copyright © 2007, IGI Global. Copying or distributing in print or electronic forms without written permission
of IGI Global is prohibited.


 Aydn, Harmsen, Hllegersberg, & Stegwee

The Conduct of the Study
Research Objective
During our case-study investigation in an organization, we explored, described,
and analyzed the work practices dealing with method adaptation without
limiting ourselves to a specific perspective. To frame our research scope, we
formulated our goal as to investigate how an agile method is adapted to different project contexts in a large-scale IT department. By using the constructs
elaborated in the previous section, this goal statement could be formulated
as follows: to investigate the ways through which a method engineer and a
project manager together adapt dynamically both structured and unstructured
fragments of an agile method to different contexts at the project level. We
especially looked into the early stages of the systems development process
where the adaptation process appeared to be more essential and more transparent in the organization investigated.

Research Method
The research approach adopted in this study is that of an interpretive field
study. Many researchers, including Fitzgerald et al. (2000) and Sauer and
Lau (1997), have also used this research approach for the study of method
use in practice. It has been suggested as an appropriate research method for

explorative and descriptive types of research and, according to Klein and
Myers (1999, p. 69), “interpretive research does not predefine dependent and
independent variables, but focuses on the complexity of human sense making
as the situation emerges; it attempts to understand phenomena through the
meanings that people assign to them.”
The field research was conducted in the form of a research project in the
organization and carried out by a research team consisting of people from
both the university and the case organization. The Appendix summarizes the
characteristics of the research method applied, such as the use of multiple study
stages, various sources of knowledge, an iterative process of data analysis
(Walsham, 1995), a collaborative style of the research team’s involvement,
“engaged” data gathering (Jones & Nandhakumar, 1993), and the use of different feedback mechanisms for the validity of the data analysis. One can
see that the mentioned characteristics are indeed related to the principles of
Copyright © 2007, IGI Global. Copying or distributing in print or electronic forms without written permission
of IGI Global is prohibited.


Adaptaton of an Agle Informaton System Development Method 

interpretive field research (Klein & Myers, 1999). (Due to a space limitation,
we could not further articulate the relations between the characteristics and
the principles, but as an example, notice that the use of various sources of
knowledge is related to the principles of multiple interpretations, suspicion,
and contextualization.)

Introducing the Case Organization
The organization we investigated is one of the leading financial institutions
in Europe and operates in a dynamic business environment. One of the global
strategic business units, Consumer and Commercial Clients (C&CC), focuses
exclusively on services to individual clients and small- to medium-sized businesses. The Netherlands Business Unit (BU) is one of the five BUs under

C&CC. IT Development is one of the departments within the Netherlands
BU and employs 2,000 people involved in systems development projects.
Such a large IT department was chosen because it enabled us to investigate
method adaptation in various project contexts.
It is worth noting that the organization has considerable experience of ISDmethod use. The organization’s identity goes back 10 years to the merger of
two organizations, both of which were used to using conventional methods.
One of them had been using a method developed in house, and the other a
brand-named method. Until the introduction of an agile method, just 2 years
ago, there had been a lot of effort put into achieving a standard method
influenced heavily by previous development procedures, processes, and
templates.

About the Agile Method: DSDM in a Nutshell
Dynamic systems development can be considered an agile method because it
has the ability to be adaptable to a variety of development situations (Abrahamsson et al., 2003). In the United Kingdom and in Benelux countries,
DSDM, which is supported by a consortium of over 600 organizations, has
become the de facto market standard. The method strongly emphasizes the
concepts of suitability and adaptability; DSDM will be, to a certain extent,
suitable for a project or an organization, and is adaptable if not completely
suitable.

Copyright © 2007, IGI Global. Copying or distributing in print or electronic forms without written permission
of IGI Global is prohibited.


 Aydn, Harmsen, Hllegersberg, & Stegwee

For the purpose of this research, we have considered three components of
DSDM: its underlying philosophy (captured in nine principles), its framework
(stages, activities, products), and its essential techniques (Aydin & Harmsen,

2002). In practice, each of these components can be applied separately, and
subsets of the components can also be applied on their own. The principles of
the method are active user involvement, frequent delivery of products, iterative and incremental development, an empowered team, fitness for business
purposes, reversible changes, requirements at a high level, testing throughout
the life cycle, and a cooperative approach. The DSDM framework suggests
a complete project approach that includes key phases, products, and roles
that should be customized according to the project situation (see Table 2 for
the examples of product and process fragments of the DSDM used at the
business-study level). Modeling techniques are not included in DSDM since
they are often a part of modeling tool sets that are not themselves part of the
method. In this way, DSDM is highly adaptable: It is possible to use fully
fledged DSDM, but individual techniques or just the terminology are still
valuable on their own. To this end, an instrument called a suitability filter is
available in the manual (DSDM Consortium, 2003). The filter considers the
critical success factors for DSDM and the characteristics of projects that will
make DSDM especially effective. Each potential project should be judged
individually using the filter. If the project provides a good match with the
filter, then DSDM can be considered as a suitable method. If the criteria
results are not satisfied, then the method can be modified.

Table 2. Examples of product and process fragments of the DSDM used at
the business-study level
Business-Study Level
Product Fragments
Process Fragments*
Main Products
Business area Definition
Outlined prototyping plan
System architecture definition

Models
Business functions Data/
relationships/rules
Business events
Business scenarios
Business architecture
System locations

Visionary
Ambassador user(s)
Project manager

Note: *Only roles-related fragments are provided here. See the complete list of fragments in DSDM (2000).

Copyright © 2007, IGI Global. Copying or distributing in print or electronic forms without written permission
of IGI Global is prohibited.


Adaptaton of an Agle Informaton System Development Method 

Important DSDM techniques are time boxing, facilitated workshops, prioritization, and prototyping. Time boxing refers to setting a deadline by which
a predefined objective must be met rather than describing when a task must
be completed. To prioritize requirements of the system, the MoSCoW technique is used; the term is an abbreviation for the phrase “must have, should
have, could have, and want to have, but won’t have this round.” We assume
that the concepts of facilitated workshops and prototyping are known. For
more details of DSDM, one should refer to the DSDM Consortium document
(DSDM Consortium, 2003).

The Situation at Hand
Recently, DSDM has become the method of choice for all information system

development projects in the department. The main motivation for this decision was to ensure time-to-market systems development in order to achieve
substantial product and process improvements, and to use one terminology
in all projects. The DSDM implementation in the department focused on
coaching project managers in adapting the method in the organization and
at project levels with the help of experts. The experts, known as coaches,
had extensive project experience and were subject-matter experts in DSDM
use. They coached project managers on how to make better decisions on
the suitability of DSDM and on the degree of adaptation DSDM would
require for each project. Basically, there were two essential, important roles
in DSDM adaptation: the project coaching role and the project management
role. The DSDM coaches assisted project managers in adapting DSDM to
their project context, whereas project managers were fully responsible for
the project execution. They were the final decision makers in terms of the
use of DSDM fragments.

Case-Study Procedure
The field research consisted of three stages: the preliminary study stage, the
actual research stage, and the posterior study stage (see Table 3).
We conducted the research in cooperation with a sponsor and a method engineer from the case organization. The sources of knowledge were, in this
empirical setting, informants, direct observations, and documents. Since

Copyright © 2007, IGI Global. Copying or distributing in print or electronic forms without written permission
of IGI Global is prohibited.


0 Aydn, Harmsen, Hllegersberg, & Stegwee

Table 3. Summary of the case-study procedure
Time

Stage

Event / Activity
Field-study preparation

Preparation

Jan 2002

May

May

Preliminary Study

Feb

Objectives

Involved People

• Uncovering all aspects of
the phenomena that has
been studied so far in the
literature regarding two
theoretical views

Academics, including one
primary investigator and three
senior researchers (professor,

assistant professor, and a
subject-matter expert)

• A high-level description of
the research method is to
be used
Conducting, codifying, analyzing, and reporting interviews

Explained in the Appendix

Discussion of the reflections
of interview results within the
organization

Explained in the researchmethod section
All research team members
and method engineers

Explained in the Appendix

Research team members

• Second-round interviews

June

Determining research scope,
and research design variables

Explained in the Appendix

Explained in the Appendix

• Validation of findings

Explained in the Appendix

• Third-round interviews
• Direct observation
• Artefacts analysis (route
maps, instruments such
as the ESRL, advice documents, etc.)

June
July
Sept

Actual Study

See Appendix for other activities
Three checkpoint meetings

• To agree on the level of
abstraction and degree of
generalization
• To agree on the depth
and breath of the research
scope
A number of discussion
meetings with a broad

audience

Explained in the Appendix

Explained in the Appendix

Nov

Closing up and writing a
draft version of the case
protocol

To document findings in a
scientific way

Academics

Dec 2002Mar 2003

Several iterations for the
case protocol

Quality improvement by
peer reviews

Academics (internal and
external)

Follow-up communications
with the organization

Explained in the Appendix

Explained in the Appendix

Informal meetings

Monitor the evolving
practice specific to method
adaptation

Explained in the Appendix

Dec 2002June 2003
Sept 2003

Posterior Study

July
Sept

Copyright © 2007, IGI Global. Copying or distributing in print or electronic forms without written permission
of IGI Global is prohibited.