Controls in Flexible Software Development

Controls in Flexible Software Development

Michael Harris, Alan R. Hevner, and Rosann W. Collins Information Systems and Decision Sciences

University of South Florida Tampa, FL 33620

{mharris, ahevner, rcollins}@coba.usf.edu

Abstract Control and flexibility may appear an unlikely pair. However, we propose that effective flexible software development processes must still provide clear control mechanisms to manage the progress and quality of the resulting software products. This paper presents our initial research to understand the types of control found in flexible software development processes. Control theory is used as a lens to study the control mechanisms found in plan-driven and flexible processes. We extend current thinking to include emergent outcome controls and clan controls for team coordination in our taxonomy of control mechanisms. Several popular flexible processes are analyzed for control mechanisms. We conclude with a brief discussion of our future research directions.

1. Introduction Flexible1 software development processes include

subtle, yet essential, control mechanisms to manage the progress and quality of the resulting software products. To better understand the controls found in flexible processes, we use control theory as a lens to examine the central tension between control and flexibility in managing software development. It is generally understood that a key managerial responsibility is to exert controls that guide employees’ behaviors to ensure compliance with organizational goals. The challenge for software development managers today is how to appropriately employ controls when dynamic environments require more flexibility. In addition, the need for explicit and formal controls is increased when development is distributed and/or developers come from multiple organizations [6, 11, 12, 31]. This control versus flexibility tension is evident in the software industry’s long running debate over the relative merits of plan-driven development approaches versus flexible approaches [5].

1 The term flexible was chosen over agile to be more inclusive.

Many development organizations may not use formal agile methods, but may use controlled, flexible processes that manage towards emergent outcomes instead of managing towards a pre-defined specification.

From the earliest days, the software industry has recognized that uncontrolled development can result in software delivery problems. The search for a structured process led to the creation of the waterfall development methodology. However, experience has shown that the strict controls inherent in the waterfall process inhibit developers’ ability to react to changing conditions [23].

In a recent study, 85% of CIOs indicated that agility was part of their core business strategy [32]. As a case in point of the need for flexibility consider the FBI Virtual Case Project that was cancelled after $170 million in expenditures. According to SAIC, the contractor, the problem was an evolving design [13]: …And what the FBI called software deficiencies were really more changes in requirements. And users kept rejecting SAIC's software designs, taking what one SAIC executive complained was a "trial-and-error, we-will-know-it-when-we-see-it approach to development."

The article’s author offered his opinion: And in the frantic days after Sept. 11, SAIC should have spotted that stable requirements for this project just weren't in the cards. The FBI needed results in the face of a crisis. SAIC should have shifted gears and methodologies to start producing working deliverables right away, no matter how far the project was from a complete set of requirements.

One interesting part of this article was that the SAIC executive dismissed the FBI’s design process as a “trial-and-error” approach. Although this instance may have been an example of trial-and-error development, the quote highlights a problem with flexible methods; managers may not be able to identify and affect flexible control mechanisms and, thus, they may not be able to differentiate between a flexible approach and an ad hoc development approach.

MacCormack et al. [22] provide another example that illustrates the confusion over the workings of flexible controls. The researchers asked managers at a company to identify a successful project and an unsuccessful one. Analysis revealed that the ‘successful’ project was a well structured project with no changes and no surprises once the design was locked down. In contrast, the

Proceedings of the 39th Hawaii International Conference on System Sciences - 2006

10-7695-2507-5/06/$20.00 (C) 2006 IEEE

‘unsuccessful’ project underwent continual change in response to market and competitive changes. However, surprising news was revealed when objective measures of success were examined. The ‘unsuccessful’ flexible project had higher quality levels and took fewer resources relative to its level of complexity.

The field of software development has no clear definitions of the different development processes that are in use. We can roughly describe three types of processes. Plan-driven processes, such as the waterfall approach, use formal plans and written documents to drive development. Controlled flexible processes, such as the agile methods, use learning processes that allow the software to systematically evolve as new information is gathered. Ad hoc or pure trial-and-error approaches do not use any formal controls. In the latter situation, developers work on their own with very little clear guidance or structure.

The differences between flexible (e.g. agile) and plan-driven processes have been well documented, but the differences between a controlled flexible approach and an ad hoc approach have been less thoroughly discussed. As an example, consider the agile manifesto [3]. The manifesto clearly differentiates agile approaches from plan-driven approaches but it does not explicitly describe the common characteristics of agile approaches that differentiate them from ad hoc approaches.

In practice, as an organization adopts a development process it also adapts the process to its own idiosyncratic needs [5]. Preliminary interviews conducted for this study suggested that many organizations end up with processes-in-practice that consist of tradeoffs between the process choices. Since there is no language for understanding and comparing processes and their control mechanisms, it is difficult for adopting organizations to understand whether an appropriation of a process is faithful [10].

Much of the existing research on software process improvement focuses on a single process and uses assertions and proofs of concept as evaluation techniques [33]. Research on agile processes is no exception to this trend. There is no established framework for comparing, analyzing, and evaluating flexible processes.

A research objective of this study is to develop a common language for analyzing and comparing flexible processes based on their use of common control mechanisms. The current dialog centers on individual mechanisms recommended by specific agile processes. It is difficult to know whether these separate concepts are complementary or if they are substitutes for one another when there is no established theoretical base to explain the purposes of various mechanisms. By drawing on the control theory literature, we hope to provide a taxonomy

for understanding controls in flexible processes. In addition, we expect to aid practitioners who seek to adopt flexible processes. This study can help adopting organizations achieve a better understanding of the role and purposes of the control mechanisms in a flexible development method.

2. Control Theory The initial work in control theory has established three

types of controls that organizations use to manage towards their objectives [27-30]. These control types can be briefly defined as: • Behavioral control: Appropriate when the behaviors

that transform inputs to outputs are known. • Outcome control: Appropriate when an individual’s

output can be measured. • Clan control: Appropriate in ambiguous circumstances

where neither the behaviors nor outputs can be predicted a priori. Clan members belong to a common organization and share values, beliefs, and attitudes [7, 28].

The relationships among the types of control are shown in Table 1. Two factors determine the proper control approach: the availability of outcome measures and the knowledge of the transformation process. Outcome measures are useful if an outcome can be specified a priori and if the individual’s contribution can be tied to the outcome. Alternatively, behavioral control can be exercised by prescribing the transformation behaviors that produce the end product and measuring adherence to those behaviors. This behavioral control approach not only requires well known transformations that will result in success, but it also requires that behaviors be observable. Furthermore, the controller must be knowledgeable enough to understand the appropriate behaviors in order to observe them [19].

Some researchers have labeled outcome and behavioral controls as ‘formal’ controls [1, 4, 16, 19]. Such formal controls establish explicit rules that are enacted through

Table 1: Organizational Use of Control Types. Adapted from Ouchi [27, 29].

Knowledge of Transformation Process Perfect Imperfect

High Behavioral or Output Output

Ava

ilabi

lity

of O

utco

me

Mea

sure

s

Low Behavioral Clan


2

the actions of an individual with legitimate power [17]. In contrast, clan control is an informal control. With clan control an individual’s attitude and values are aligned with others of his or her clan. Individuals are expected to determine the appropriate behaviors based on their shared attitudes and values. Since Ouchi’s original work, researchers have suggested a new type of informal control, called self-control [8, 18]. Via self-control individuals select personal goals and self-monitor activities to achieve these goals.

The problem with formal controls is that each desired circumstance must be encapsulated in a rule or control mechanism. In a study of retail sales personnel, Ouchi [29] found that an over reliance on sales commissions (outcome control) resulted in a lack of support for non-sales activities such as restocking. On the other hand, informal control allows the individual to derive a limitless set of rules to cover unexpected situations [26]. As jobs become more complex and more ambiguous it is more difficult to specify appropriate behaviors or outcomes. Thus, in complex work environments, such as in software development, control mechanisms shift to include clan controls [19, 28].

3. A Taxonomy of Dynamic Controls Prior research has shown that managers use a portfolio

of controls rather than just relying on one type of control [8, 14, 19, 20, 25, 26]. Based on a thorough study of the prior research on control theory, we built a base control taxonomy. This taxonomy was then extended to encompass controls essential to the management of flexible software development processes. These extensions were based upon an analysis of existing agile processes. In this section, we briefly describe the resulting flexible control taxonomy. 3.1. Outcome Control Mechanisms

According to control theory, outcomes are deterministic: produce to this specification and you will produce an acceptable product. In plan-driven development the design document becomes an a priori specification and is used to establish outcome control. Traditional outcome control is less useful for flexible methods since the final specification is typically unknown until development is finished. Surprisingly, however, control of outcomes is a primary concern of the flexible approaches. The difference is that the flexible methods are concerned with emergent outcome controls, not with a priori specifications.

3.1.1. Emergent Outcome Controls The term ‘emergent outcome’ describes the way that

agile processes gradually build towards a final outcome (software deliverable). In the agile process, the developer is given freedom to create the best solution as new learning is uncovered; however, this freedom is

constrained to insure that the developer satisfies organizational objectives. Two types of mechanisms are utilized in emergent outcome control: scope boundaries and ongoing feedback. Scope boundaries define the area the developer should work within. The developer may be limited by an overall architecture or by the amount of time they have to work on a feature. Ongoing feedback provides continuous course corrections by providing user reactions as the design evolves. 3.2. Behavior Control Mechanisms

Behavioral control focuses on behaviors that transform inputs to desired outputs. In the software development context, this kind of control includes the assignment of developers to tasks and the specification of work methods and procedures [14]. While the flexible development approach is congruent with this traditional definition, in flexible development there is a very short term focus for work assignments. As the agile manifesto states, the focus is on ‘working software’ and the goal is to be able to demonstrate progress as development proceeds. Therefore developers must work toward daily software builds and, possibly, weekly product releases. Bugs are fixed immediately instead of being added to bug lists. Development is planned in bite-sized chunks that can easily be added to the daily software build. 3.3. Clan Control Mechanisms

Ouchi [27, 28] explains clan control as a process of selection, training, and acculturation to attain common attitudes and values. According to the theory, achievement of common attitudes addresses any problems of goal incongruence. The importance is in development of common values, not in monitoring the actual work product. Once this attitude alignment is achieved, it is expected that the individual’s decisions will be consistent with the interests of the organization.

It appears that self-control, suggested by other researchers [8, 18], has some correspondence with Ouchi’s vision of clan control. Consider that the entire purpose of control theory is to manage towards organizational objectives [29]. How then should an organization insure that an individual’s self-control decisions are consistent with the company’s objectives?

The answer that makes sense is that companies must insure that the individual’s objectives are congruent with company objectives. This can be achieved by selecting the correct individuals and by socializing them to share the organization’s values and objectives. Once we recognize this need for goal congruence, self-control becomes identical to Ouchi’s original conceptualization of clan control [28].

This leads to the question of why the concept of self-control was created in the first place. Close examination of the prior studies [14, 18] reveals a difference between clan control and self-control at the operationalization


3

level. These researchers operationalized clan control to consist of team (peer) control over tasks, not just attitudes. This suggests the need for team level control to coordinate interdependent tasks.

In our research, we recognize team control as a facet of clan control since it involves influence techniques by peers who do not have legitimate power [17]. This is consistent with earlier researchers who operationalized team control as clan control. Based on this reasoning, we reconceptualize clan control to consist of two facets: 1) task-orientated control (clan-team based) and 2) attitude control (clan-attitudes via self-control). 3.4. Dynamic Control Taxonomy

In summary, our proposed control taxonomy, as adjusted to account for emergent controls is: • Outcome controls: measure performance against a

priori specifications. o Emergent outcome controls: manage outcomes in

an evolutionary fashion. Scope boundaries: constrain creativity to

insure focus on key areas Ongoing feedback: provides corrective

feedback as development occurs. • Behavior controls: measure adherence to behaviors

that transform inputs to outputs. • Clan Controls

o Team: Team members provide task feedback to support coordination and communication.

o Attitude: Individuals make decisions based on attitudes and values that are congruent with organization’s attitudes and values.

4. Control in Flexible Processes We apply the control mechanism taxonomy to analyze

the controls found in three popular flexible processes: Extreme Programming, Synchronize and Stabilize, and the Rational Unified Process. Our goal is to better understand where control mechanisms exist in these flexible processes in order to support improved management of flexible software development. For completeness, we also analyze the controls found in the waterfall process. These analyses are depicted in Tables 2-5, with the control mechanism taxonomy developed from the control literature as categories for the key practices of each development process. 4.1. Control in Extreme Programming

The analysis begins with Extreme Programming (XP). We used XP to guide development of the dynamic control taxonomy. The XP key practices [2] are classified according to the taxonomy in Table 2. As the table reveals, the XP mechanisms are consistent with the expectations of the dynamic taxonomy. The emergent outcome mechanisms, behavior controls, and clan-team

controls are the primary forms of control used by the process.

Although XP developers are given freedom to create new solutions, scope boundaries limit technological wandering [24]. For example, XP iterations of one to three weeks limit the amount of change developers can introduce. XP also utilizes user stories to define broad requirements and further bound creativity. These mechanisms define the area within which developers will create the solution. Detailed feedback lets XP developers constantly gauge progress. A user co-located with the development team provides one source of continuous feedback. However, XP also realizes that a single user may not be representative of the market as a whole. Another important reason for the short release cycle is that it allows the team to continually check their evolving design against the needs of the broader market of users.

As suggested earlier, XP’s behavior controls all have a focus on immediacy. Daily builds mean that bugs must be fixed as they are found, not added to bug lists. Weekly releases mean that a one day slip can result in a 20% schedule overrun. Ten-minute builds make it quick to compile the system. This sense of immediacy works with the short cycle times to keep the team on course. Although the team has freedom to create, they do not have time for idle wanderings. Compare this to a large, plan-orientated approach where the next milestone may be weeks away. XP epitomizes the adage: ‘don’t put off until tomorrow what you can do today’.

The analysis indicates that control theory with emergent outcomes provides a useful way of thinking about the activities of extreme programming. 4.2. Control in Synchronize and Stabilize

The Synchronize and Stabilize (S&S) [9] approach provides an interesting contrast to XP. In many ways, the S&S approach is similar to a plan-driven method. S&S has been used to manage large teams of hundreds of developers. Projects begin much like plan-driven development methods. Functional specifications are built, major milestones are established, and feature teams of three to eight developers are established. Standards, such as user-interface design rules, are also set [15]. However, these startup processes stop short of specifying every detail. About 30% of the product design evolves from the development activities of the feature teams. Since the 70% of fixed requirements include infrastructure items, such as the system architecture, the amount of freedom given to the feature teams is considerable. Each feature team is expected to discover and implement the best possible solution for their product area. Many structures are used to guide the developers, but many feature-orientated decisions are left to the developers.

Two differences between S&S and XP relate to 1) architecture and 2) code ownership. S&S develops


4

architecture before coding begins. The architecture constrains flexibility and insures that any subsequent creative solutions are true to the overall system needs. XP uses a minimalist architecture. For XP, architecture is important but, for each iteration, the architecture only supports features in that iteration. The XP philosophy is that planning an architecture for future iterations is a waste of time since the feature set will change. The second difference relates to the ownership of code. S&S carefully segments the code. Each feature team has ownership of only its own code segment. In XP, the entire team has ownership of the entire code base.

Despite these differences, S&S and XP are both considered agile approaches. They both encourage the developers to pursue creative approaches and they both consider documentation an output of the process rather than an input. Thus, we would expect S&S to have similar characteristics to XP even though its mechanisms are quite different. Table 3 below shows how the mechanisms in S&S map to control mechanisms.

The specification list provides a scope boundary, not an outcome control. This list provides broad outlines for development but it can change as development proceeds. Scope boundaries also are evident in other areas. For example, a feature team must fit their code into the established architecture. This architecture is not an outcome control since it does not dictate what the team must build. However, it determines how the team’s code interacts with other modules and, thus, places boundaries on the extent of the changes that can be made. S&S also relies on role definitions to place boundaries on the teams. A feature team only has responsibility for a specific feature-set and ownership privileges are defined for each piece of code.

As can be seen, S&S’s use of scope boundaries is different from XP. XP relies primarily on short cycle times to reign in development. XP developers don’t have time to wander too far a field because the next release is no more than a few days away. S&S uses a partial specification, defined roles, a fixed architecture, and limits on code ownership to constrain developers. Both methods use daily builds to insure that maverick programmers do not get too far out of step with the rest of the organization. In total, all of these mechanisms can be seen as alternative ways to bound the creativity of the team. Although the team is given permission to innovate, these mechanisms insure that the innovation does not stray too far from the intent of the software.

S&S also includes mechanisms for ongoing feedback [22]. Multiple releases are offered to the market to gather user input. For example, Netscape 3.0 underwent six beta releases to gather user input before it was released to market [15]. Furthermore, the team takes any chance possible to get continuous end-user reviews of the work

in-progress. This ongoing user feedback is as important as functional/bug testing.

S&S is not quite as ‘extreme’ as XP. There is still a sense of immediacy derived from daily builds and testing that occurs in parallel with development. However, this sense is muted. Although software is built daily, an individual piece of code may go several days before being checked into a build. Since there is no user representative on each team, the feedback is less current. Slightly more structure upfront allows for a greater use of traditional outcome controls. However, this is a relative comparison between the two techniques. In general, the profile of controls is the same. They both rely primarily on emergent outcome controls, they both keep a sense of immediacy in their behavior expectations, and they both include team-orientated clan controls. 4.3. Control in the Rational Unified Process

In order to further validate the taxonomy, we next turn to an analysis of the Rational Unified Process (RUP) [21]. RUP provides an interesting contrast because it is a plan-driven approach, but it allows for learning throughout the process.

In a plan-driven process, such as RUP, the specification of the software occurs separately from the software development. Creation of the design either occurs at the front of the process (waterfall) or in spurts between development cycles (RUP). The programmer executes the plan but does not directly modify the plan. In contrast, a flexible environment requires the programmer to make real time design decisions. The developer will consider both the user needs and the technical capabilities of the environment.

When we talk about emergent outcomes we are describing a continuous design process that involves the programmer in design decisions. Although RUP does allow for evolving designs, it does not allow for emergent designs. RUP design decisions are agreed upon by a change committee before a programming iteration begins. The programmer implements the design. Any creative suggestions must wait for the committee’s action and for the next iteration.

Table 4 maps RUP development techniques onto the control taxonomy. The table shows fewer controls for RUP as compared to the agile processes. This is because of the central role of the design document in RUP. RUP includes business modeling plans, architecture plans, and a formal change management board. The results of all of these processes are embedded in the design specification. Therefore, the inclusion of this single document factors in the decisions of all of these processes.

The two shaded rows at the bottom of the table indicate that specific aspects of RUP are adaptive. However, this ability to make changes is in the hands of project management, not the developers. Between each


5

set of iterations the change management board can adjust the controls by changing the specification.

From the developer point of view, RUP is not a flexible process. It can be as rigid as a formal waterfall approach. As the table reveals, RUP leans heavily on traditional outcome control. Developers are assigned due dates and detailed specifications for each iteration. Testing helps determine if the specified outcome is successfully delivered. Certain behaviors in terms of tools and standards are also pre-specified. 4.4. Control in the Waterfall Process

The previous discussion contrasted two types of agile methods and demonstrated that, despite their differences, they contained similar approaches from the viewpoint of dynamic control theory. Then it revealed the dynamic control profile for an iterative, plan-driven approach (RUP). As a next step we analyze the waterfall method using the same approach. This will help us understand how dynamic control theory distinguishes between the agile and plan-driven approaches.

Table 5 shows how the mechanisms of the waterfall method influence development. The most significant control again is the design document. This document encapsulates the results of many detailed sub-process in one formidable control tool.

As can be seen, the waterfall approach has a significantly different control profile from the agile approaches. The waterfall approach relies primarily on traditional outcome controls. The flexible methods (XP and S&S) use a more broad-based set of controls with special emphasis on emergent outcome controls.

5. Conclusions and Future Research Our initial research demonstrates that traditional

control theory has shortcomings when applied to dynamic situations, such as new software development. Traditional control theory relies heavily on clan control for these situations. However, even if clan control is possible, it is not clear it is sufficient. The analyzed agile methods do use clan control, but they supplement it with other types of control.

The analysis suggests that extensions to control theory are needed to understand control mechanisms in dynamic situations. Specifically, it recommends the addition of emergent outcome controls. This new control mode consists of two types of mechanisms. Scope boundaries define the limits on the developer’s creativity. Ongoing feedback is used to steer the creative process.

In addition the study recommends a recategorization of informal controls. Self Control becomes clan-attitude control. It involves creation of shared attitudes and values across the clan. Clan-team control is created to capture the concept of intra-team coordination of tasks.

Further, the analysis demonstrates that the new dynamic control theory can be used to classify flexible control mechanisms. This allows researchers and practitioners to understand the relationships between controls in various methods. For example, consider the finding that one purpose of the short cycle times in XP is to limit the scope of development to minimize technological wandering. S&S does not use short cycle times, but it places scope boundaries through carefully defined developer roles that restrict developers to specific feature areas. An organization that is developing its own flexible method may consider one of these scope limitation devices, or they may come up with an approach of their own to achieve the same purpose.

The analysis supports the portfolio view of controls of software development. All the development processes analyzed employ more than one category of control. Two of the flexible processes, XP and S&S, use many more types of controls than RUP and the waterfall process do. This finding underscores the importance of understanding the nature of controls in a theoretical way. Managers adopting a flexible process need to be able to deploy a varied and sophisticated set of control mechanisms with a clear understanding of how and why they are using each key control mechanism.

A common feature of the agile approaches is the way that they create a sense of immediacy. Developers are almost continuously ready to build the system and demonstrate it. This creates continuous pressure on developers to perform. In contrast, some plan-driven approaches establish their pacing through the use of infrequent milestones. Developers may relax when the milestones are first established, and gradually increase their pace as the due dates approach.

Clan-team control is also a key practice of agile methods. Unlike clan-attitude control, this team-based approach does not require lengthy socialization. Team control involves team members directly interacting to coordinate and influence each other’s tasks. Since this is more directive than attitude control, it can even be used in relatively new teams. However, this type of control mechanism is likely to be more difficult in a distributed setting when interaction is not face-to-face but via a communication medium. The type of control may also be more challenging when members of the team come from different organizations (e.g. when consultants are used or when development is partially outsourced).

This study provides an initial test of the new conceptualization of control mechanisms in the software development context by analyzing XP, S&S, RUP, and the waterfall process. As future research, we plan to validate this taxonomy of control mechanisms in one or more field studies of industrial software development projects. This will allow us to verify the role of emergent outcomes in controlling development, establish the


6

distinction between clan-team and clan-attitude controls, and explore any boundary conditions that might suggest when the use of emergent outcomes is inappropriate.

References 1. Andres, H.P. and R.W. Zmud, A Contingency Approach to

Software Project Coordination. Journal of Management Information Systems, 2001. 18(3): p. 41-70.

2. Beck, K. and C. Andres, Extreme Programming Explained: Embrace Change. 2nd ed. XP Series. 2005, Boston: Addison-Wesley. 189.

3. Beck, K., et al., The Agile Manifesto. 2001, http://www.agilemanifesto.org/, accessed 6/14/2005.

4. Birnberg, J.G. and C. Snodgrass, Culture and Control: A Field Study. Accounting, Organizations and Society, 1988. 13(5): p. 447-464.

5. Boehm, B. and R. Turner, Balancing Agility and Discipline: A Guide for the Perplexed. 2004, Boston: Addison-Wesley.

6. Brown, C.V., Examining the Emergence of Hybrid IS Governance Solutions: Evidence from a Single Case Site. Information Systems Research, 1997. 8(1): p. 69-94.

7. Cardinal, L.B., S.B. Sitkin, and C.P. Long, Balancing and Rebalancing in the Creation and Evolution of Organizational Control. Organization Science, 2004. 15(4): p. 411-431.

8. Choudhury, V. and R. Sabherwal, Portfolios of Control in Outsourced Software Development Projects. Information Systems Research, 2003. 14(3): p. 291-314.

9. Cusumano, M.A. and D.B. Yoffie, Software Development on Internet Time. IEEE Computer, 1999. 32(10): p. 60-69.

10. DeSanctis, G. and M.S. Poole, Capturing the Complexity in Advanced Technology Use: Adaptive Structuration Theory. Organization Science, 1994. 5(2): p. 121-147.

11. Eisenhardt, K.M. and J.A. Martin, Dynamic Capabilities: What are They? Strategic Management Journal, 2000. 21(10-11): p. 1105-1121.

12. Eisenhardt, K.M. and B.N. Tabrizi, Accelerating Adaptive Proceses: Product Innovation in the Global Computer Industry. Administrative Science Quarterly, 1995. 40: p. 84-110.

13. Hayes, F., $170 Million Lesson. 2005, Computerworld. 14. Henderson, J.C. and L. Soonchul, Managing I/S Design

Teams: A Control Theories Perspective. Management Science, 1992. 38(6): p. 757-777.

15. Iansiti, M. and A. MacCormack, Living on Internet Time: Product Development at Netscape, Yahoo!, NetDynamics, and Microsoft. Harvard Business School Case Study, 1999. 9-697-052: p. 12.

16. Jaworski, B.J., Toward a Theory of Marketing Control: Environmental Context, Control Types and Consequences. Journal of Marketing, 1988. 52(3): p. 23-44.

17. Jex, S.M., Organizational Psychology. 2002, New York: John Wiley & Sons, inc. 540.

18. Kirsch, L., The Management of Complex Tasks in Organizations: Controlling the Systems Development Process. Organization Science, 1996. 7(1): p. 1-21.

19. Kirsch, L., Portfolios of Control Modes and IS Project Management? Information Systems Research, 1997. 8(3): p. 215-239.

20. Kirsch, L.J., Deploying Common Systems Globally: The Dynamics of Control. Information Systems Research, 2004. 15(4): p. 374-395.

21. Kruchten, P., The Rational Unified Process: An Introduction. 2nd ed. 2000, Reading, MA: Addison-Wesley. 298.

22. MacCormack, A., R. Verganti, and M. Iansiti, Developing Products on "Internet Time": The Anatomy of a Flexible Development Process. Management Science, 2001. 47(1): p. 133-150.

23. McConnell, S., Rapid Development. 1996, Redmond, Washington: Microsoft Press.

24. McDonough III, E.F. and R.P. Leifer, Effective Control of New Product Projects: The Interaction of Organization Culture and Project Leadership. Journal of Product Innovation Management, 1986. 3(3): p. 149-157.

25. Nidumolu, S.R. and M.R. Subramani, The Matrix of Control: Combining Process and Structure Approaches to Managing Software Development. Journal of Management Information Systems, 2003-2004. 20(3): p. 159-196.

26. Orlikowski, W.J., Integrated Information Environment Or Matrix of Control? The Contradictory Implications of Information Technology. Accounting, Management & Information Technology, 1991. 1(1): p. 9-42.

27. Ouchi, W.G., A Conceptual Framework for the Design of Organizational Control Mechanisms. Management Science, 1979. 25(9): p. 833-848.

28. Ouchi, W.G., Markets, Bureaucracies & Clans. Administrative Science Quarterly, 1980. 25(1): p. 129.

29. Ouchi, W.G., The Relationship Between Organizational Structure and Organizational Control. Administrative Science Quarterly, 1977. 22(1): p. 95-113.

30. Ouchi, W.G. and J.B. Johnson, Types of Organizational Control and Their Relationship to Emotional Well Being. Administrative Science Quarterly, 1978. 23(2): p. 293-317.

31. Teece, D.J., G. Pasano, and A. Shuen, Dynamic Capabilities and Strategic Management. Strategic Management Journal, 1997. 18(7): p. 509-533.

32. Ware, L.C., The Benefits of Agile IT, in CIO Reports. 2004, CIO Magazine.

33. Zelkowitz, M.V. and D.R. Wallace, Experimental Models for Validating Technology. IEEE Computer, 1998. 31(5): p. 9.


7

Tab

le 2

: Ext

rem

e Pr

ogra

mm

ing

and

Con

trol

Mec

hani

sms

Out

com

e C

ontr

ols

Beh

avio

r C

ontr

ols

Cla

n C

ontr

ols

Mec

hani

sm

Tra

ditio

nal

Out

com

e E

mer

gent

Out

com

e Sc

ope

O

ngoi

ng

Bou

ndar

ies

Feed

back

C

lan-

Team

C

lan-

Atti

tude

s

Sit T

oget

her

Prog

ress

obs

erva

ble

by

team

mem

bers

.

Team

mem

bers

acc

essi

ble

for a

dvic

e.

Who

le T

eam

Fe

edba

ck in

clud

ing

cust

omer

repr

esen

tativ

e

Team

is se

lf-su

ffici

ent

and

unifi

ed. N

o m

aver

icks

.

Info

rmat

ive

Wor

kspa

ce

Vis

ible

resu

lts

O

utco

mes

obs

erva

ble

Dai

ly P

rogr

ess v

isib

le.

Team

can

read

ily se

e ea

ch

othe

r’s p

rogr

ess.

Ener

gize

d W

ork

W

hen

we

are

at w

ork

we

will

do

our b

est.

Pair

Prog

ram

min

g

N

ew id

eas a

re te

sted

with

pa

rtner

. W

ork

toge

ther

. A

ctiv

ities

tran

spar

ent t

o te

am m

embe

rs.

Stor

ies

B

road

stat

emen

ts o

f int

ent

focu

s eff

orts

.

1-3

Wee

k C

ycle

Lim

it am

ount

of c

hang

e th

at c

an o

ccur

in e

ach

itera

tion.

Mar

ket f

eedb

ack

ever

y 1-

3 w

eeks

. W

ork

to sh

ort d

eadl

ines

. O

ne-d

ay sl

ips r

esul

t in

mis

s of w

eekl

y ta

rget

.

Qua

rterly

Cyc

le

Pl

ace

busin

ess c

onstr

aint

s as

wel

l as m

arke

t co

nstra

ints

.

Rev

iew

with

m

anag

emen

t. G

uard

ag

ains

t fea

ture

cre

ep.

Slac

k

Mee

ting

wee

kly

cycl

es

mor

e im

porta

nt th

an

feat

ures

.

Ten-

Min

ute

Build

M

ake

it ea

sy to

de

mon

stra

te.

Don

’t br

eak

over

all

syst

em.

Cod

e m

ust w

ork

wel

l with

ot

hers

.

Con

tinuo

us In

tegr

atio

n

A

lway

s be

read

y to

dem

o la

test

pro

duct

Fi

x bu

gs a

s the

y oc

cur.

Mus

t mai

ntai

n sy

nchr

oniz

atio

n w

ith

othe

rs. N

o su

rpris

es.

Test

-firs

t N

ot re

ally

an

exte

rnal

con

tract

.2 D

evel

op a

det

aile

d go

al

for e

ach

feat

ure.

Incr

emen

tal D

esig

n

Each

iter

atio

n fo

cuse

s on

only

a fe

w th

ings

. Ea

ch it

erat

ion

read

y to

us

e or

dem

onst

rate

to

mar

ket.

2 At f

irst g

lanc

e th

is m

ay s

eem

like

a v

ersi

on o

f out

com

e co

ntro

l, bu

t it d

oes

not f

it th

e co

nditi

ons.

This

test

is bu

ilt b

y th

e de

velo

per b

efor

e he

beg

ins c

odin

g. If

the

deve

lope

r cha

nges

dire

ctio

n, th

e te

st c

ases

can

be

chan

ged.

The

re is

no

atte

mpt

to h

old

the

deve

lope

r to

deliv

ery

base

d on

the

orig

inal

test

cas

es.

Pro

ceed

ings

of

the

39th

Haw

aii

Inte

rnat

ional

Confe

rence

on S

yst

em S

cien

ces

- 2006

8

Tab

le 3

: Syn

chro

nize

and

Sta

biliz

e an

d C

ontr

ol M

echa

nism

s

O

utco

me

Con

trol

s B

ehav

ior

Con

trol

s C

lan

Con

trol

s M

echa

nism

T

radi

tiona

l O

utco

me

Em

erge

nt O

utco

me

Scop

e

Ong

oing

Bou

ndar

ies

Feed

back

C

lan-

Team

C

lan-

Atti

tude

s

Star

t with

Vis

ion

Can

pro

vide

som

e co

ntro

l – la

cks

mea

sura

ble

deta

il.

Car

ves o

ut a

rea

of

deve

lopm

ent.

Prov

ides

som

e ba

sis f

or

feed

back

.

Spec

ify g

oals

and

non-

goal

s3 to in

clud

e up

to

70%

of t

he fi

nal f

eatu

res

befo

re d

evel

opm

ent

begi

ns.

Parti

al sp

ecifi

catio

n –

how

ever

som

e fe

atur

es m

ay c

hang

e,

so it

is to

ugh

to

mai

ntai

n ac

coun

tabi

lity.

Crit

ical

feat

ures

are

fully

sp

ecifi

ed.

Arch

itect

ure

& F

eatu

re

team

ass

ignm

ents

firs

t.

Each

team

ow

ns sp

ecifi

c ar

ea.

Dai

ly B

uild

s

Pr

ogre

ss v

isib

le

Mus

t kee

p co

de in

w

orki

ng c

ondi

tion.

D

unce

cap

if b

reak

the

build

.

Con

tinuo

us E

nd-u

ser

revi

ews

Focu

s on

deliv

ered

fu

nctio

nalit

y, n

ot c

ode.

Maj

or M

ilesto

nes

Spec

ify d

ue d

ates

for

feat

ure

bund

les.

Dev

elop

men

t & T

estin

g do

ne in

par

alle

l

Alw

ays k

eep

code

in

wor

king

con

ditio

n.

Cod

e re

view

s

In

depe

nden

t vie

w o

f pr

ogre

ss.

C

ode

mus

t be

acce

ptab

le

to o

ther

team

mem

bers

.

Che

ck-in

and

cha

nge

trac

king

Iden

tify

who

is a

llow

ed to

m

ake

chan

ges t

o a

sect

ion

of c

ode

at a

ny g

iven

tim

e.

3 A n

on-g

oal i

s som

ethi

ng y

ou d

on’t

wan

t to

do in

the

curre

nt re

leas

e.

Pro

ceed

ings

of

the

39th

Haw

aii

Inte

rnat

ional

Confe

rence

on S

yst

em S

cien

ces

- 2006

9

Tab

le 4

: Rat

iona

l Uni

fied

Proc

ess a

nd C

ontr

ol M

echa

nism

s

Out

com

e C

ontr

ols

Beh

avio

r C

ontr

ols

Cla

n C

ontr

ols

Mec

hani

sm

Tra

ditio

nal

Out

com

e E

mer

gent

Out

com

e Sc

ope

O

ngoi

ngB

ound

arie

s Fe

edba

ck

C

lan-

Team

C

lan-

Atti

tude

s

Des

ign

Doc

umen

t M

ust d

eliv

er to

the

spec

ifica

tion.

Pr

opos

ed c

hang

es

refle

cted

in

subs

eque

nt it

erat

ion.

Itera

tion

Due

Dat

es

Mea

sura

ble

outc

omes

that

can

be

track

ed.

Test

ing

Wor

kflo

w

Mak

es o

utco

mes

vi

sibl

e.

Envi

ronm

enta

l Wor

kflo

w

D

eter

min

e to

ols a

nd

stan

dard

s tha

t the

im

plem

ente

r mus

t use

.

Con

figur

atio

n M

anag

er

D

efin

e se

ctio

ns o

f cod

e a

deve

lope

r can

acc

ess.

Rul

es fo

r sha

ring

code

.

Mul

tiple

Iter

atio

ns4

Li

mit

chan

ges f

or e

ach

itera

tion

to sp

ecifi

c ar

eas.

Stak

ehol

der R

evie

ws4

Prov

ide

feed

back

th

roug

hout

the

proj

ect.

T

able

5: W

ater

fall

Proc

ess a

nd C

ontr

ol M

echa

nism

s

O

utco

me

Con

trol

s B

ehav

ior

Con

trol

s C

lan

Con

trol

s M

echa

nism

T

radi

tiona

l O

utco

me

Em

erge

nt O

utco

me

Scop

e

Ong

oing

Bou

ndar

ies

Feed

back

C

lan-

Team

C

lan-

Atti

tude

s

Des

ign

Doc

umen

t M

ust d

eliv

er to

the

spec

ifica

tion.

Proj

ect D

ue D

ates

M

easu

rabl

e ou

tcom

es

that

can

be

track

ed.

Test

ing

Mak

es o

utco

mes

vi

sibl

e. F

ocus

ed o

n te

chni

cal i

ssue

s, no

t en

d-us

er a

ccep

tanc

e.

Envi

ronm

ent

D

eter

min

e to

ols a

nd

stan

dard

s tha

t the

im

plem

ente

r mus

t use

.

Con

figur

atio

n M

anag

er

D

efin

e se

ctio

ns o

f cod

e a

deve

lope

r can

acc

ess.

Rul

es fo

r sha

ring

code

.

4 The

two

shad

ed it

ems f

rom

the

tabl

e ar

e no

t con

trols

enac

ted

on d

evel

oper

s. Th

ey a

re p

roje

ct le

vel c

ontro

ls th

at a

llow

the

proj

ect t

o re

act t

o ch

ange

.

Pro

ceed

ings

of

the

39th

Haw

aii

Inte

rnat

ional

Confe

rence

on S

yst

em S

cien

ces

- 2006

10

Documents

Controls in Flexible Software Development