31 INFORMATION SYSTEMS MANAGEMENT SUMMER 2006 CAN AGILE AND TRADITIONAL SYSTEMS DEVELOPMENT APPROACHES COEXIST? AN AMBIDEXTROUS VIEW Vishnu Vinekar, Craig W. Slinkman, and Sridhar Nerur Emerging evidence seems to indicate that most systems development organizations are attempting to utilize both agile and traditional approaches. This study aims to understand the reasons organizations feel the need for this unlikely juxtaposition and the organizational chal- lenges in sustaining the opposing cultures. Drawing on the extensive literature in organiza- tional theory and management, we advocate ambidexterity as a viable solution to systems development organizations attempting to harness the benefits of both agile and traditional development. HE LOW RATE OF SUCCESS IN THE FIELD of systems development (Standish Group, 1994, 1999, 2001, 2003, 2004) provided the impetus for the development of sev- eral new methods and practices. These meth- ods include eXtreme Programming (Beck, 1999), Scrum (K. Schwaber & Beedle, 2002), Dynamic Systems Development Method (Sta- pleton, 1997), Adaptive Software Development (Highsmith, 2000), Crystal (Cockburn, 2002), and Feature-Driven Development (Palmer & Fels- ing, 2002). The Agile Manifesto articulates the common principles and beliefs underlying these methods (Cockburn, 2002).The fundamental no- tions behind the manifesto are: 1. The ingenuity and competence of people as well as their interactions and collaborations are of greater value than tools and processes. 2. Delivering a high-quality working system to the customer is more important than pro- ducing copious documentation. 3. The active participation and constant involvement of the customer in systems development yields greater benefits than the fulfillment of predetermined require- ments specified in a contract. 4. Recognizing the inevitability of change and embracing it, rather than attempting to cope with it through extensive planning, provides the nimbleness needed to survive in a turbulent business world. The early adopters of agile methods believe that their use may positively affect their suc- cess rate (Berinato, 2001; Larman, 2004; Lind- strom & Jeffries, 2004). Followers of more traditional methodologies believe that agile methods are chaotic and lack the formal proce- dural rigor that the former possess. One of the most important differences is that traditional development attempts to minimize change in the course of the project through rigorous up- front requirements gathering, analysis, and T VISHNU VINEKAR is a doctoral candidate in information systems at the University of Texas at Arlington. His research interests include systems development, IT value, collaborative work processes, and knowledge management. He can be reached at [email protected]. CRAIG W. SLINKMAN is an associate professor of information systems at the University of Texas at Arlington. SRIDHAR NERUR is an assistant professor of information systems at the University of Texas at Arlington. CONTEMPORARY PRACTICES IN SYSTEMS DEVELOPMENT
Transcript
31I N F O R M A T I O N S Y S T E M S M A N A G E M E N T
S U M M E R 2 0 0 6
CAN AGILE AND TRADITIONAL SYSTEMS DEVELOPMENT APPROACHES COEXIST? AN AMBIDEXTROUS VIEW
Vishnu Vinekar, Craig W. Slinkman, and Sridhar Nerur
Emerging evidence seems to indicate that most systems development organizations are attempting to utilize both agile and traditional approaches. This study aims to understand the reasons organizations feel the need for this unlikely juxtaposition and the organizational chal-lenges in sustaining the opposing cultures. Drawing on the extensive literature in organiza-tional theory and management, we advocate ambidexterity as a viable solution to systems development organizations attempting to harness the benefits of both agile and traditional development.
HE LOW RATE OF SUCCESS IN THE FIELDof systems development (Standish Group,1994, 1999, 2001, 2003, 2004) providedthe impetus for the development of sev-
eral new methods and practices. These meth-ods include eXtreme Programming (Beck,1999), Scrum (K. Schwaber & Beedle, 2002),Dynamic Systems Development Method (Sta-pleton, 1997), Adaptive Software Development(Highsmith, 2000), Crystal (Cockburn, 2002),and Feature-Driven Development (Palmer & Fels-ing, 2002). The Agile Manifesto articulates thecommon principles and beliefs underlying thesemethods (Cockburn, 2002). The fundamental no-tions behind the manifesto are:
1. The ingenuity and competence of people aswell as their interactions and collaborationsare of greater value than tools and processes.
2. Delivering a high-quality working system tothe customer is more important than pro-ducing copious documentation.
3. The active participation and constantinvolvement of the customer in systemsdevelopment yields greater benefits thanthe fulfillment of predetermined require-ments specified in a contract.
4. Recognizing the inevitability of change andembracing it, rather than attempting tocope with it through extensive planning,provides the nimbleness needed to survivein a turbulent business world.
The early adopters of agile methods believethat their use may positively affect their suc-cess rate (Berinato, 2001; Larman, 2004; Lind-strom & Jeffries, 2004). Followers of moretraditional methodologies believe that agilemethods are chaotic and lack the formal proce-dural rigor that the former possess. One of themost important differences is that traditionaldevelopment attempts to minimize change inthe course of the project through rigorous up-front requirements gathering, analysis, and
TVISHNU VINEKAR is a doctoral candidate in information systems at the University of Texas at Arlington. His research interests include systems development, IT value, collaborative work processes, and knowledge management. He can be reached at [email protected].
CRAIG W. SLINKMAN is an associate professor of information systems at the University of Texas at Arlington.
SRIDHAR NERUR is an assistant professor of information systems at the University of Texas at Arlington.
design; the intent is to attain higher quality re-sults under a controlled schedule. Agile meth-ods, on the other hand, assume that change overthe development process is not only inevitable,but also necessary, and aim at achieving innova-tion through individual initiative (Cockburn &Highsmith, 2001; Highsmith, 2003; Zhiying,2003). The focus, therefore, is on adaptation andinnovation rather than prediction and control.
Agile methods emphasize short iterations,in which the entire project is broken up intoseveral small projects, each lasting betweenone and six weeks (Larman, 2004). Each itera-tion deals with only a few prioritized featuresand ends with a working system as a deliver-able. The end of each iteration provides an op-portunity to elicit user feedback, to assess thesuitability of the delivered solution, and to re-flect on what worked and what did not. Devel-opers and users dynamically prioritize featuresat the beginning of each iteration, and theproject grows through evolutionary develop-ment (Gilb, 2004). In agile development, therequirements for each iteration are primarilyclient-driven priorities. Therefore, the require-ments that the client perceives as having thehighest business value for the project will beincluded in the first iteration; the remainingfeatures will be reassessed and prioritized forinclusion in future iterations. Although agilemethods have been in use for over a decade,substantial debate exists in the industry regard-ing their effectiveness.
Adoption of agile systems development isincreasing in the industry (C. Schwaber &Fichera, 2005). A few industry surveys seem toindicate that most systems development orga-nizations are trying to use both approaches.For example, even though 96.4 percent ofShine Technologies (2003) respondents intendto adopt or continue to use agile methods, only16 percent believe those methods are suitablefor all projects. Although the majority of adopt-ers believe that the adoption of agile systemsdevelopment has improved productivity, quali-ty, and business satisfaction, they also feel thatother methodologies are necessary. ShineTechnologies concludes, “[agile methods]should be applied only where it will deliverbenefit. … Agile processes should be used onlyfor the right projects, and that there is room forother methodologies to sit along side Agile andbe used on a project-by-project basis as appropri-ate.” Similarly, the Methods & Tools (2005) surveyshows that, of the organizations that have adopt-ed agile approaches, only 17 percent are using
them for all new projects. This raises our firstresearch question:
If agile adopters believe that adoptionhas improved productivity, quality, andbusiness satisfaction (Shine Technolo-gies, 2003), why do they still feel theneed for other approaches?
The results of the surveys mentioned abovestrongly suggest the need to balance agilemethods with other approaches. However,both academics and practitioners agree that ag-ile systems development requires a suitable or-ganizational culture (Boehm & Turner, 2004;Lindvall et al., 2002; Nerur, Mahapatra & Man-galaraj, 2005), and changing an organizationalculture takes several years (Adler & Shenhar,1990). This raises our second research question:
How can organizations overcome theobstacle of changing their organization-al culture to sustain both agile and tradi-tional systems development?
This article addresses these questions andmakes the following four contributions: First,we examine why the capabilities of both agileand traditional development are needed by sys-tems development organizations. Second, weelaborate on the organizational challenges insustaining these two opposing cultures. Third,we propose an ambidextrous form of organiza-tion as a viable solution to balance agile and tra-ditional systems development while maintainingthe necessary organizational cultures for eachapproach. Fourth, we examine how the ambi-dextrous structure can dynamically address keyIS project characteristics as well as the clientorganization’s characteristics.
THE NEED FOR SIMULTANEOUSLY MANAGING AGILE AND TRADITIONAL SYSTEMS DEVELOPMENTAgile systems development has attracted a lotof attention in recent times. The Agile 2005conference was replete with positive experi-ences organizations have had with agile meth-ods (Agile Alliance, 2005). The benefitsreported, such as increased productivity, fasterturnaround, shared learning, and higher devel-oper satisfaction, are consistent with earlier ev-idence cited by proponents such as Cockburn(Cockburn & Williams, 2001). These make for acompelling case for the adoption of agile meth-ods. Nevertheless, does this mean that tradi-tional development built around a traditionof predictability and control has to give way to
lthough the majority of adopters believe that the adoption of agile systems development has improved productivity, quality, and business satisfaction, they also feel that other methodologies are necessary.
33I N F O R M A T I O N S Y S T E M S M A N A G E M E N T
S U M M E R 2 0 0 6
CONTEMPORARY PRACTICES IN SYSTEMS DEVELOPMENT
agile methods that assume an unanalyzableworld fraught with uncertainties? We contendthat there is a need to maintain “dual struc-tures” that accommodate both approaches be-cause they each have their benefits, andpractical considerations may preclude the sim-ple replacement of one by the other.
Organizations engage in a wide variety ofsystems development projects. The variationsin these projects could be considerable, andthe degree of variety is a function of many fac-tors. Boehm and Turner (2004) convincingly ar-gue that there is a pragmatic need to balancestability and agility. They analyze the “homegrounds” of agile and traditional approachesbased on application characteristics, manage-ment characteristics, technical characteristics,and personnel characteristics. Further, they as-sert that the choice of traditional or agile meth-ods for a given project is largely contingent onfive factors:
❚❚ The size of the systems development projectand team
❚❚ The consequences of failure (i.e., criticality)❚❚ The degree of dynamism or volatility of the
environment❚❚ The competence of personnel❚❚ Compatibility with the prevailing culture
In essence, they offer a strategy for choosing aparticular approach for a particular projectbased on the risks posed by the five factorsmentioned above, implying the simultaneouspursuit of agile and traditional development ap-proaches.
It may be difficult and inefficient to strictlyadhere to all agile practices in projects thathave stable requirements, involve a lot of lega-cy code and heterogeneous tools/languages(e.g., COBOL, Java, C++), and mainly comprisemaintenance tasks with little or no need forsearch and discovery. Boehm and Turner(2004) point out that traditional developmentis desirable when the requirements are stableand predictable and when the project is large,critical, and complex. Agile development, onthe other hand, is suitable when there is a highdegree of uncertainty and risk in the project,arising from frequently changing requirementsand/or the novelty of technology used (Boehm& Turner, 2004; Highsmith, 2003). Large andcomplex projects more suited to the traditionalapproach may impede the transfer of tacitknowledge as well as entail significant rework,making agile development a suboptimalchoice.
Stability brings with it the advantages of dis-cipline and automation and the disadvantage ofbeing overly restrictive. Agility, on the otherhand, brings with it the advantages of flexibilityand human initiative while inhibiting repeat-able processes perceived to contribute to thematurity of an organization (Zhiying, 2003). Bysystematically codifying the various artifacts ofsystems development, the traditional approachallows for the exploitation of existing knowl-edge. On the other hand, much of the knowl-edge in agile development is tacit (Boehm,2002). Therefore, an essential tension exists be-tween the goal of optimization to which thetraditional orthodoxy of systems developmenthas aspired and the objective of learning andadaptability that agile approaches emphasize. Al-though agility is necessary for organizational ad-aptation, stability is necessary for organizationaloptimization, which results in higher assurances.Hence, systems development organizations needto strike a balance between the two conflictinginterests: agility and stability.
In this section, we argued for the simulta-neous pursuit of traditional and agile systemdevelopment approaches. However, the twoapproaches differ in many respects and entailconflicting organizational, people, and techni-cal demands that might make the concurrentpractice of these methods problematic. Thenext section discusses the challenges that con-front organizations that plan to follow both ap-proaches at the same time.
OBSTACLES TO BEING BOTH AGILE AND TRADITIONALAn organization that is attempting to use bothagile and traditional development on differentprojects faces several challenges. This is be-cause although project characteristics and cli-ent characteristics vary, it may be very difficultto change the systems development organiza-tion’s own characteristics from project toproject. These challenges can be viewed as oc-curring at four levels: management and organi-zational, people, process, and technology(Nerur et al., 2005).
The framework for organizational changearticulated by Adler and Shenhar (1990) is use-ful for assessing the effort required to meetthese challenges (see Figure 1). Of the four lev-els that Nerur et al. (2005) discuss, technologi-cal and process changes occur at the skills andprocedures levels, where, relatively speaking,the magnitude of change is small, the level oflearning needed is low, and the time to adjust
t may be difficult and inefficient to strictly adhere to all agile practices in projects that have stable requirements.
is short. However, the people and manage-ment/organizational changes occur at the lev-els of culture, strategy, and structure, wherethe magnitude of change is relatively large, thelevel of learning required is high, and the timeto adjust is long. Therefore, we focus below onthe challenges that these latter two levelspresent to systems development organizationsthat are pursuing agile methods for someprojects and traditional methods for others.
People LevelAgile systems development places a premiumon people and their interactions. The empha-sis is on teams and on the intense dynamics ofteam interactions. The roles of agile team mem-bers are interchangeable, and developers oftenchoose roles that are not in their area of spe-cialty (Martin, 2003). Self-organization is one ofthe key traits of such systems developmentteams. The traditional role of a project manageras planner, organizer, and controller disap-pears, and the role of a facilitator or coach whoeffectively manages the collaborative efforts ofteam members without stifling their creativitytakes its place (Highsmith, 2003). Proponents
of agile methods argue that processes shouldbe flexible and dynamic enough to moldaround the competencies of people, and notthe other way around (Cockburn & Highsmith,2001). This focus on people is a significant de-parture from the traditional systems develop-ment’s focus on processes.
Management and Organizational LevelAgile and traditional systems developmenthave conflicting organizational cultures, man-agement styles, organizational forms, and re-ward systems (Nerur et al., 2005). Theinfluence of organizational culture on shapingthe assumptions and biases of its employees iswell documented (Charette, 2003). In fact, de-partments within companies may developtheir own “mini-cultures” that become in-grained in the work habits and actions of theirpersonnel (Cockburn, 2002). Organizationalforms that have supported a culture of hierar-chical control for several years may find it par-ticularly difficult to accommodate some of thecharacteristics of agile development, such asself-organizing teams, pluralistic decision-mak-ing contexts involving stakeholders with
FIGURE 1 Framework for Organizational Change (Adler & Shenhar, 1990)
35I N F O R M A T I O N S Y S T E M S M A N A G E M E N T
S U M M E R 2 0 0 6
CONTEMPORARY PRACTICES IN SYSTEMS DEVELOPMENT
diverse interests and goals, and a collaborativeenvironment fostered by strong leadershiprather than strict authority. Organizations alsoneed to reevaluate their reward systems to en-courage agile practices, where collective goalssupersede individual accomplishments.
It is apparent from the preceding discussionsthat factors related to people, organization, andmanagement pose significant challenges to thesimultaneous pursuit of agile and traditional de-velopment. Systems development organizationsface the methodological dilemma of achievingoptimization while fostering an environment ofagility to respond quickly to changes. However,the problem that confronts systems develop-ment organizations is not unique. There is alarge body of literature in organizational man-agement that has extensively studied the essen-tial tension and trade-offs between stability andagility. These include the conflicting demandsand organizational dilemma related to exploita-tion and exploration (March, 1991; Benner &Tushman, 2003; Gibson & Birkinshaw, 2004;He & Wong, 2004).
More specifically, organizations generallypursue two types of innovation behaviors;namely, exploitation and exploration (March,1991; Katila & Ahuja, 2002). Exploitation be-haviors focus on core competencies, efficien-cy, routines, incremental changes, and the like(He & Wong, 2004), which are often associatedwith alignment with a stable environment. Ex-ploration behaviors, on the other hand, assumea changing environment that demands fre-quent experimentation, learning by doing, risk-taking propensity, innovative behaviors, and soforth. Exploitation and exploration behaviorsare not mutually exclusive, and it is considereddetrimental to pursue one at the expense ofthe other (March, 1991). Rather, these two be-havioral dimensions together enable an organi-zation to be innovative, flexible, and effectivewithout losing the benefits of stability, routini-zation, and efficiency (Katila & Ahuja, 2002).
He and Wong (2004, p. 481) make the fol-lowing observation:
In general, exploration is associatedwith organic structures, loosely coupledsystems, path breaking, improvisation,autonomy and chaos, and emerging mar-kets and technologies. Exploitation isassociated with mechanistic structures,tightly coupled systems, path depen-dence, routinization, control and bu-reaucracy, and stable markets andtechnologies.
These apparent differences between ex-ploitation and exploration are also consistentwith the contrasts between agile and tradition-al systems development presented by Nerur etal. (2005). The insights into reconciling the dif-fering structures, cultures, strategies, workhabits and roles of people, information scan-ning and decision-making processes, tools andtechniques, and inherent processes associatedwith exploitation and exploration (He & Wong,2004) are valuable to organizations endeavor-ing to pursue both traditional and agile systemsdevelopment methods simultaneously.
Further, the literature on organizational the-ory and learning also provides a persuasive rea-son for reconciling the differences betweenthe two approaches, and for providing an orga-nizational climate conducive to the simulta-neous practice of agile and traditionaldevelopment (He & Wong, 2004; Tushman &O’Reilly, 1996). Recent empirical evidence sug-gests that the notion of ambidexterity, whichpermits the simultaneous pursuit of these con-trasting approaches, is an effective and viablesolution to the stability–agility dilemma (Katila& Ahuja, 2002; He & Wong, 2004; O’Reilly &Tushman, 2004). The ability to be both alignedwith the existing environment as well as adap-tive to cope with the dynamics of a changingworld is positively associated with superiorperformance (Gibson & Birkinshaw, 2004; He& Wong, 2004).
SUSTAINING THE DUAL CULTURES OF STABILITY AND AGILITY THROUGH AMBIDEXTERITYExploitation and exploration are among themany paradoxes organizations need to managein order to survive (Gibson & Birkinshaw,2004). Indeed, the truly successful organiza-tions foster an environment that encouragesthe simultaneous presence of paradoxical andcontradictory forces, such as differentiationversus integration (Lawrence & Lorsch, 1967),stability and change, alignment and adaptabili-ty (Gibson & Birkinshaw, 2004), variation-re-ducing versus variation-increasing (Burgelman,1991, 2002), loose and tight coupling (Weick,1976; Zaltman, Duncan, & Holbeck, 1973), andso forth. The acceptance of paradox as a ubiq-uitous organizational phenomenon has ledsome theorists to recognize that it is detrimen-tal to view opposing elements such as exploita-tion and exploration as being mutuallyexclusive. Rather, organizations that facilitatetheir simultaneous presence have much to gain
gile systems development places a premium on people and their interactions.
The fact that different structures influencedifferent innovative behaviors (such as exploit-ative and explorative) has long been recog-nized in the management literature. Forexample, Burns and Stalker (1961) characterizestructures as mechanistic and organic, theformer being suitable for the attainment ofgoals related to stability, routinization, and effi-ciency, whereas the latter is necessary if flexi-bility and adaptability are the primaryconcerns. The origins of ambidexterity may betraced to the work of Duncan (1976), who pro-posed a dual structure to deal with the paradoxof stability and change. However, the recent re-surgence of interest in ambidexterity as well asthe elucidation of its form and characteristicsin an organization may be largely attributed tothe works of Tushman and O’Reilly (O’Reilly &Tushman, 2004; Tushman & O’Reilly, 1996). Inlight of recent empirical evidence on the effica-cy of ambidexterity and its positive influenceon an organization’s performance (He & Wong,2004; Jansen, Van den Bosch, & Volberda,2005), we focus here on the ambidextrousform proposed by Tushman and O’Reilly(1996).
The ambidextrous organization has sub-units that are highly coupled within subunitsand loosely coupled across subunits but aretightly integrated at the senior executive level(O’Reilly & Tushman, 2004). The task, culture,individuals, and organizational arrangementsare highly consistent within each subunit andhighly differentiated from the other subunits(Benner & Tushman, 2003). Case studies sug-gest that ambidextrous organizations (such asUSA Today and Ciba Vision) can be superior toother organizations (O’Reilly & Tushman,2004). Empirical evidence has also demonstrat-ed that the interaction between explorative
and exploitative strategies positively affectsperformance, whereas an imbalance betweenthe two strategies negatively affects perfor-mance (He & Wong, 2004).
This suggests that an ambidextrous IS devel-opment organization may be able to simulta-neously pursue and reap the benefits from bothtraditional and agile development. Such an or-ganization would consist of at least two sub-units: an agile subunit and a traditional subunit.The traditional subunit would have a more hi-erarchical structure, with the project manageras the planner, segregating and delegating re-sponsibility between a large team of special-ized developers working individually. The agilesubunit, on the other hand, would have a moredecentralized, flexible structure, in whichsmall teams of developers with multidisci-plinary skills work closely with customers anddiverse stakeholders. Separating the two unitsand buffering them from each other would en-sure that they preserve their own cultures. Thismay also be necessary because having collocat-ed agile and traditional systems developmentteams may create elitist attitudes between theteams and hinder progress (Nerur et al., 2005).However, a single, tightly integrated IS gover-nance structure above both subunits is alsoneeded (Figure 2). This IS management team as-sesses the relative feasibility of both develop-ment methodologies for each project anddelegates project work accordingly. This struc-ture also allows IS management to learn fromthe successes and failures of both subunits andto modify them as needed.
The composition of the two subunits, agileand traditional (plan driven), would differ fun-damentally along the four levels of manage-ment/organizational, people, process, andtechnology (Nerur et al., 2005). Table 1 sum-marizes the opposing characteristics of thesetwo subunit types.
37I N F O R M A T I O N S Y S T E M S M A N A G E M E N T
S U M M E R 2 0 0 6
CONTEMPORARY PRACTICES IN SYSTEMS DEVELOPMENT
Further, an ambidextrous form may be wellsuited to enable a traditional systems develop-ment organization to incorporate agile devel-opment without disrupting its existingorganization. Instead of changing the manage-ment style of the entire organization, it couldcreate a structurally buffered, agile subunit.Employees who are more tolerant of ambiguityas well as those who work better in teamscould be part of the agile subunit. Leaders, col-laborative decision makers, and developerswith multiple skills potentially perform to their
fullest capability in such units. Managers andemployees long accustomed to a hierarchicalstructure that emphasizes command and con-trol, role specialization, solitary work habits,and a high degree of formalization may be morecomfortable and effective in a traditional sub-unit. Thus, an ambidextrous organizationpromises to be an effective way to achieve thebenefits of stability without compromising itsability to dynamically respond to changes inthe environment (Figure 3).
TABLE 1 The Ambidextrous Systems Development Organization
Agile Subunit Traditional/Stable Subunit
Management and organizational Leadership and collaborationCooperativeFlexibleManager as facilitatorTacit knowledgeTeam reward systems
Command and controlAutonomousDisciplinedManager as plannerExplicit knowledgeIndividual reward systems
People Collaborative workMultidisciplinary skillsPluralist decision makingHigh customer involvementSmall teams
Individual workSpecialized skillsManagerial decision makingLow customer involvementLarge teams
Process People centricSpeculativeAssess progressEvolutionary developmentWrite tests prior to codeIndividual approach to projectsAdaptableIterativeShort durations
Process centricStandardizedMeasure progressLife-cycle developmentWrite code prior to testsUnified approach to projectsPreplannedLinearLong durations
Technology Object orientedTools for iteration
Structured or object orientedStandardized tools
FIGURE 3 The Relationship between Explorative Abilities and Exploitative Abilities for Systems Development Organizations
hig
h Agile Ambidextrous
Ex
plo
rati
ve
abil
ity
low Ad-hoc Traditional
low high
Exploitative ability
38 W W W . I S M - J O U R N A L . C O M
S U M M E R 2 0 0 6
CONTEMPORARY PRACTICES IN SYSTEMS DEVELOPMENT
DYNAMICS OF THE AMBIDEXTROUS ORGANIZATIONAL STRUCTUREEmerging evidence seems to indicate that agilesystems development is gaining acceptanceamong systems development organizations(Methods & Tools, 2005; C. Schwaber & Fichera,2005; Shine Technologies, 2003). Some propo-nents of agile development claim universal ap-plicability of their methods, and others believethat it is only suitable in particular situations.Boehm and Turner (2004) identify five criticalfactors to assess the suitability of agile or tradi-tional development: size, criticality, dynamism,personnel, and culture. However, the effective-ness of their framework depends on the extentto which the systems development organiza-tion understands how its personnel and cultur-al factors differ from those of the clientenvironment. Therefore, we analyze the dy-namics of the ambidextrous structure by ad-dressing these five factors as relevant acrossthree levels:
1. Systems development organization: Theseinclude the systems development organiza-tion’s culture and personnel, which it hasdirect control over.
2. Information systems project: These includethe information systems project’s size, crit-icality, and dynamism, which the systemsdevelopment organization attempts to con-trol through its actions.
3. Client organization: These include the cli-ent’s culture and its ability to communicaterequirements for systems functionality,which the systems development organiza-tion has no direct control over.
Systems Development Organization FactorsWithout an ambidextrous structure, the sys-tems development organization’s culture andpersonnel are critical constraints (Boehm &Turner, 2004) that limit the organization’s abil-ity to use agile or traditional development. Withan ambidextrous structure, the systems devel-opment organization turns these constraintsinto strengths. Through its pursuit of dual cul-tures and personnel, the ambidextrous organi-zation provides enhanced capabilities tohandle critical factors of the information sys-tems project and of the client organization.
Information Systems Project FactorsThe ambidextrous organization increases thesystem development organization’s flexibility
to address three project factors associated withthe choice between agile and traditional meth-ods: size, criticality, and dynamism.
Size. Whereas some developers report diffi-culties with using agile approaches for large de-velopment teams (Boehm & Turner, 2004),others report successes, including a 40-personteam using agile modeling, distributed teams of80 people, a 150-person team divided intosmaller teams each with its own methodology,and an 800-person team organized into a“scrum of scrums” (Lindvall et al., 2002). Theseexperiences may indicate that it is not that ag-ile development does not scale to largeprojects, but that very few developers have at-tempted this.
An ambidextrous organization may be par-ticularly well suited to use agile methods forlarger projects. Because experience with usingagile development for large projects is limited,the organization may continue to assign its larg-est projects to its traditional development sub-unit but assign incrementally larger projects toits agile subunit. Using agile methods for largeprojects essentially involves breaking down theproject into smaller development teams. Thisraises the issue of coordination between teams.Scaling agile development therefore involveslearning to use coordination mechanisms be-tween systems development teams (Lindvall etal., 2002), including regular team leader meet-ings and core teams to handle coordination is-sues. The agile subunit with an explorativeculture (March, 1991) and double-loop learn-ing (Argyris, 1977), can gradually learn to scaleagile methods to larger projects. The agile sub-unit can apply its learning to increasingly largerprojects until it feels that it has reached a com-fortable upper limit, which may vary among or-ganizations.
Dynamism. Adopters of agile developmentbelieve that its most useful feature is its abilityto respond to change (Shine Technologies,2003). However, some “heavy” approaches,such as the Rational Unified Process (RUP), arealso iterative, incremental, and evolutionaryand can allow a traditional development cul-ture to handle project dynamism. The main dif-ference between agile development and RUP isthat the latter is more dependent on up-front,explicit, and documented plans (Cantor, 2001).RUP sacrifices some speed and flexibility sothat changes in the system can be explicated,agreed on, and finalized formally before imple-mentation. Agile development gains speed by
n ambidextrous organization may be particularly well suited to use agile methods for larger projects.
39I N F O R M A T I O N S Y S T E M S M A N A G E M E N T
S U M M E R 2 0 0 6
CONTEMPORARY PRACTICES IN SYSTEMS DEVELOPMENT
depending less on procedure and more on theon-site customer. However, this dependenceon the on-site customer may cause project fail-ure if the on-site customer is misaligned withthe stakeholder goals. Similarly, RUP’s depen-dence on following procedure and formal, doc-umented changes may result in developmentfailure if the client is unable to articulate needsthrough formal documents. Therefore, we seethat dynamism is less of a constraint relative tothe client’s ability to communicate require-ments through formal documents vis-à-vis itsability to provide a CRACK customer (collabo-rative, representative, authorized, committed,and knowledgeable). We elaborate this issueunder client organization factors.
Criticality. Boehm and Turner (2004) believethat agile development may not be suitable forsafety-critical projects. However, other adopt-ers of agile approaches believe that some of ag-ile development’s methods make it easier toaddress critical issues (Lindvall et al., 2002;Turk, France, & Rumpe, 2002). First, test-firstdevelopment ensures rigorous testing of safety-critical features. Second, continuous clientfeedback may refine safety-critical features thatwere poorly defined earlier. Third, the practiceof pair programming may help catch deficien-cies that formal reviews may miss. The differ-ence between these opposing views may bethat Boehm and Turner (2004) believe that theclient is able to specify safety-critical require-ments up-front, whereas Turk et al. (2002) be-lieve that the on-site customer is able to refinesafety-critical requirements through iterativefeedback. As with dynamism, we see that thechoice to use agile or traditional developmentis less dependent on the criticality of theproject and more dependent on the ability ofthe client to communicate safety-critical re-quirements through explicit specifications vis-à-vis tacit collaboration. We elaborate this issuebelow.
Client Organization FactorsFrom the above, we see that an ambidextroussystems development organization can use theculture and personnel characteristics of its ag-ile and traditional units to mitigate the con-straints imposed by the project characteristicsof size, criticality, and dynamism. Therefore, ithas the added flexibility of addressing the cli-ent’s organizational culture and abilities to im-prove customer satisfaction.
Client Culture. The client’s culture may bethe deciding factor in using agile or traditionalmethods for a project. First, clients may be un-comfortable with agile systems development’sflexible budgets and schedules and may preferan up-front contractual obligation to specificfeatures, deadlines, and costs. Second, using anagile approach entails formidable responsibili-ty on the client’s part. Agile methods requireidentifying and prioritizing features and contin-uous, active collaboration throughout the de-velopment. The client may be unwilling to takeon this amount of responsibility. Third, the cli-ent’s management and IT departments may dis-like having their organization constantlyinterrupted by frequent implementations ofdeliverables for user feedback. Similarly, it mayalso be possible that the client organization hasa highly flexible, adaptive culture that is un-comfortable with the up-front, explicit, formal,and detailed specification that traditional devel-opment entails. In these cases, an ambidex-trous system development organization may beable to derive greater customer satisfaction byassigning the project to the subunit morealigned with the client organization’s culture.
Client’s Ability to Communicate SystemFunctionality. Agile methods are highly de-pendent on the on-site customer to identifyand prioritize features, provide feedback, andguide change through the course of the devel-opment. This reliance on the customer can failif the on-site customer goals are misalignedwith other stakeholders’ goals. For example,the Chrysler Comprehensive Compensation(C3) System, which was developed using eX-treme Programming (Paulk, 2001), went overtime and over budget and was canceled beforeit was completed. The project was reportedlycanceled because the on-site customer kepttweaking the existing payroll system, whereasthe goal of other stakeholders was to replacethe existing legacy systems handling the com-pany’s payroll with a new, integrated payrollsystem (Cunningham & Cunningham, Inc.,n.d.; Hendrickson, 2001; Deursen, 2001). Thisexample indicates how pivotal the on-site cus-tomer is to agile systems development. Agilemethods require a CRACK customer (Boehm &Turner, 2004; Nerur et al., 2005) to succeed.The client organization may not have such aperson who is expendable enough to be con-tinuously involved with the development(Highsmith, 2004). Traditional development,on the other hand, is highly dependent on theclients’ abilities to specify requirements
he client’s culture may be the deciding factor inusing agile or traditional methods for a project.
up-front. This can cause development failure be-cause the clients may be unable to articulatetheir needs clearly (Ackoff, 1967). Therefore, wesee that the clients’ ability to specify system func-tionality becomes a critical factor in deciding be-tween agile and traditional development. If theclient is able to articulate functionality throughformal requirements, traditional development ismore suitable. If the client is able to provide aCRACK customer, agile development is moresuitable. However, if the client does not haveeither ability, the project is highly likely to fail.
IMPLICATIONSThe vast majority of adopters of agile systems de-velopment methods believe that their adoptionhas resulted in increased business satisfaction, in-creased quality, and increased productivity(Shine Technologies, 2003). Yet, while indicat-ing that they will continue using these meth-ods, these organizations also believe that agilemethods are not suitable for all projects (Meth-ods & Tools, 2005; Shine Technologies, 2003).Instead, the majority of organizations are at-tempting to use both agile and traditional sys-tems development, on a case-by-case basis.
There is consensus among academics andpractitioners that agile systems developmentneeds a suitable organizational culture to sus-tain it, one that is very different from the orga-nizational culture needed for traditionalsystems development (Boehm & Turner, 2004;Lindvall et al., 2002; Nerur et al., 2005). Yetchanging an organizational culture is extremelydifficult and may take several years (Adler &Shenhar, 1990), and these opposing culturescannot coexist within the same organizationalstructure (March, 1991). Therefore, new organi-zational structures are needed to sustain theseopposing cultures so that systems developmentorganizations can reap the full benefits of bothagile and traditional systems development.
As the main contribution of this article, wesuggest an ambidextrous form of organization(Tushman & O’Reilly, 1996) to overcome thechallenges of sustaining the dual cultures. Theambidextrous organization essentially has twotypes of subunits — one with an organizationalculture that sustains agile systems developmentand another with an organizational culture thatsustains traditional systems development. Thesetwo subunits of the organization diverge alongfour dimensions: management, people, process,and technology. To maintain these two opposingcultures, the two subunits are structurally
buffered from each other, allowing each to co-exist separately. However, IS management overthe two subunits needs to be tightly integratedto enable a common organizational vision andto prevent the subunits from working againsteach other’s interests.
We describe how such an organizationalform overcomes the critical factors that havebeen argued to constrain other systems devel-opment organizations (Boehm & Turner, 2004).An ambidextrous organization benefits from itsown organizational characteristics of cultureand personnel. It is less constrained by the ISproject characteristics of size, criticality, and dy-namism. It is therefore able to maximize custom-er value by choosing agile or traditional systemsdevelopment based on the client’s characteris-tics — namely, the client organization’s cultureand the client’s ability to specify requirementsthrough formal means vis-à-vis its ability to pro-vide a CRACK customer for a project.
For researchers, there are several avenuesof future work. Aside from anecdotal evidenceand consensus among small groups of practitio-ners, we found no empirical studies addressingthe challenges that traditional systems develop-ment organizations face in adopting agile meth-ods. Future research needs to identify factorsthat may affect organizations that have attempt-ed this adoption. In addition, the efficiency ofthe ambidextrous form of organization in eas-ing the adoption of agile systems developmentneeds to be tested empirically.
CONCLUSIONAlthough agile methods are gaining accep-tance among traditional systems developmentorganizations, the majority of these organiza-tions seem to indicate a preference to sustainboth forms of development. In the rhetoric ofthe superiority of one development methodol-ogy over the other, very little has been learnedabout the challenges faced by organizationsthat attempt both and even less about any suc-cesses in sustaining the opposing cultures. Thisarticle prescribes adopting an organizationalform that may enable this duality. We detail theform that this organization should take andhow it can dynamically address differences inkey IS project characteristics as well as the cli-ent organization’s characteristics. Through anambidextrous organizational structure, sys-tems development organizations can reap thebenefits of both agile and traditional systemsdevelopment. ▲
ew organizational structures are needed to sustain these opposing cultures so that systems development organizations can reap the full benefits of both agile and traditional systems development.
Benner, M. J., & Tushman, M. L. (2003) Exploitation, exploration, and process management: The productivity dilemma revisited. Academy of Management Review (28)2, 238–256.
Berinato, S. (2001). The secret to software success. CIO, July 1, pp. 76–83
Boehm, B. (2002). Get ready for agile methods, with care IEEE Computer (35)1, 64–69.
Boehm, B., & Turner R. (2004). Balancing agility and discipline: A guide for the perplexed, Boston: Addison-Wesley.
Burgelman, R. A. (1991). Intraorganizational ecology of strategy making and organizational adaptation: Theory and field research. Organization Science, 2, 239–262.
Burgelman, R. A. (2002). Strategy as a vector and the inertia of coevolutionary lock-in. Administrative Science Quarterly, 47, 325–357.
Burns, T., & Stalker, G. M. (1961). The management of innovation, London: Tavistock.
Cameron, K. S., & Quinn, R. E. (1988). Organizational paradox and transformation. In R. E. Quinn, and K. S. Cameron, (Eds.) Paradox and Transformation, Cambridge, MA: Ballinger Publishing Company, 1–18.
Cantor, M. (2001). The Rational Unified Process for systems engineering. The Rational Edge. Retrieved February 1, 2006 from www.ibm.com/developerworks/rational/library/content/RationalEdge/dec01/RUPSEDec01.pdf
Charette, R. (2003). Challenging the fundamental notions of software development. Agile Project Management, Arlington, MA: Cutter Consortium.
Cockburn, A. (2002). Agile software development. Boston: Addison-Wesley.
Cockburn, A., & Highsmith, J. (2001). Agile software development, the people factor. [Electronic version]. IEEE Computer (34)11, 131–133. Retrieved October 18, 2004, from the IEEE Xplore database.
Cockburn, A., & Williams, L. (2001). The costs and benefits of pair programming. In Extreme programming examined. Boston, MA: Addison-Wesley.
Cunningham & Cunningham, Inc. (n.d.) Cthree project terminated. Retrieved from Wiki Wiki Web on February 17, 2006. http://c2.com/cgi/ wiki?CthreeProjectTerminated
Deursen, A. V. (2001). Customer involvement in extreme programming: XP2001 Workshop Report. ACM SIGSOFT Software Engineering Notes, Nov. 2001, pp. 70–73.
Duncan, R. B. (1976). The ambidextrous organization: Designing dual structures for innovation. In R. H. Kilmann, L. R. Pondy, & D. Slevin (Eds.), The management of organization, vol. 1: 167–188. New York: North-Holland.
Gibson, C. B., & Birkinshaw, J. (2004). The antecedents, consequences, and mediating role of organizational ambidexterity. Academy of Management Journal, 47(2), 209–226.
Gilb, K. (2004). Evo — Evolutionary project management & product development Retrieved on October 4, 2004 from http://www.gilb.com/ Pages/2ndLevel/gilbdownload.html#Whirl-Wind
He, Z., & Wong P. (2004). Exploration vs. exploitation: An empirical test of the ambidexterity hypothesis. Organization Science, (15)4, 481–494.
Hendrickson, C. (2001). Will Extreme Programming kill your customer? Position Paper, OOPSLA 2001. Retrieved February 17, 2006 from http://www.coldewey.com/publikationen/conferences/oopsla2001/agileWorkshop/hendrickson.html
Highsmith, J. (2000). Adaptive software development: A collaborative approach to managing complex systems. New York: Dorset House.
Highsmith, J. (2001). Order for free: An organic model for adaptation. In L. L. Constantine (Ed.), Beyond chaos: The expert edge in managing software development (pp. 251–257). Boston: Addison-Wesley.
Highsmith, J. (2003). Agile project management: Principles and tools. Agile Project Management, (4)2. Cutter Consortium.
Highsmith, J. (2004) Objections to agile development. Agile Project Management, May 2004. Cutter Consortium.
Jansen, J. J. P., Van den Bosch, F. A. J., & Volberda, H. W. (2005). Exploratory innovation, exploitative innovation, and ambidexterity: The impact of environmental and organizational antecedents. Schmalenbach Business Review, 57, 351–363.
Katila, R., & Ahuja, G. (2002). Something old, something new: A longitudinal study of search behavior and new product introduction. Academy of Management Journal, 45(6), 1183–1194.
Larman, C. (2004). Agile and iterative development: A manager’s guide. Boston: Addison-Wesley.
Lawrence, P. R., and Lorsch, J. W. (1967). Organizations and environment. Homewood, IL: Irwin.
Lindstrom, L., & Jeffries, R. (2004) Extreme programming and agile software development methodologies. Information Systems Management, (21)3, 41–52.
Lindvall, M., Basili, V., Boehm, B., Costa, P., Dangle, K., Shull, F., et al. (2002). Empirical findings in agile methods. Presented at the Extreme Programming and Agile Methods — XP/Agile Universe, Chicago, IL, USA.
March, J. G. (1991). Exploration and exploitation in organizational learning. Organization Science, (2)1, 71–87.
Martin, R. C. (2003). Agile software development: Principles, patterns, and practices. Upper Saddle River, NJ: Prentice Hall.
Methods & Tools (2005). Software development poll archives. Retrieved February 13, 2006 from http://www.methodsandtools.com/dynpoll/oldpoll.php?Agile
Nerur, S., Mahapatra, R., & Mangalaraj, G. (2005). Challenges of migrating to agile methodologies. Communications of the ACM, (48)5, 73–78.
O’Reilly, C. A., III & Tushman, M. L. (2004). The ambidextrous organization. Harvard Business Review (82)4, 74–81.
Palmer, S. R., & Felsing, J. M. (2002). A practical guide to Feature-Driven Development. Upper Saddle River, NJ: Prentice Hall PTR.
Paulk, M. C. (2001). Extreme programming from a CMM perspective. Paper for XP Universe, Raleigh, NC, 23–25 July 2001.
Schwaber, C., & Fichera, R. (2005). Corporate IT leads the second wave of agile adoption. Forrester, November 30, 2005. Retrieved February 7, 2006 from http://www.forrester. com/Research/Document/Excerpt/0,7211,38334,00.html
Schwaber, K., & Beedle, M. (2002). Agile software development with Scrum. Upper Saddle River, NJ: Prentice Hall.
Shine Technologies (2003). Agile methodologies survey results. Retrieved November 21, 2004 from http://www.shinetech.com/download/ attachments/98/ShineTechAgileSurvey2003-01-17.pdf
Standish Group (1994). The CHAOS report. Retrieved February 17, 2006 from Sample Research from The Standish Group Web site: http://www.standishgroup.com/sample_research/PDFpages/chaos1994.pdf
Standish Group (1999). CHAOS: A recipe for success. Retrieved February 17, 2006 from Sample Research from The Standish Group Web site: http://www.standishgroup.com/sample_ research/PDFpages/chaos1999.pdf
Standish Group (2001). Extreme CHAOS. Retrieved February 17, 2006 from Sample Research from The Standish Group Web site: http://www. standishgroup.com/sample_research/PDFpages/ extreme_chaos.pdf
Standish Group (2003). CHAOS Chronicles Version 3.0, Yarmouth, MA: The Standish Group International.
Standish Group (2004). CHAOS demographics and project resolution. Retrieved February 17, 2006 from Sample Research from The Standish Group Web site: http://www.standishgroup.com/ sample_research/PDFpages/q3-spotlight.pdf
Stapleton, J. (1997). DSDM, Dynamic Systems Development Method: The method in practice. Harlow, Eng: Addison-Wesley.
Turk, D., France, R., & Rumpe, B. (2002). Limitations of agile software processes. Proceedings of the Third International Conference on eXtreme Programming and Agile Processes in Software Engineering, pp. 43–46, May 26–29, 2002, Alghero, Sardinia, ITALY.
Tushman, M. L., & O’Reilly, C. A., III (1996). Ambidextrous organizations: Managing evolutionary and revolutionary change. California Management Review (38)4, 8–30.
Weick, K. E. (1976). Educational organizations as loosely coupled systems Administrative Science Quarterly, (21)1, 1–19.
Zaltman, G., Duncan, R., & Holbeck, J. (1973). Innovations and organizations. New York: Wiley.
Zhiying, Z. (2003). CMM in uncertain environments. Communications of the ACM (46)8, 115–119.
