Papers

Validity and Reliability of Comparative Agility Survey

Tue, 10 Nov 2009 14:58:53 -0800

This paper is a research proposal - the purpose was to learn to write an academic dissertation proposal.

In the fall of 2009, I contacted Kenny Rubin, author of the Comparative Agility survey. He said that although the survey had not yet been studied for validity and reliability that they were going to start this fall. I did my research proposal for a class project, not in conjunction with the Rubin and Cohn.

Proposal to investigate the Validity and Reliability of the Comparative Agility Instrument to measure Agile Software Development Behaviors
David Koontz
Chapman University College

Proposal to investigate the Validity and Reliability of the Comparative Agility Instrument to measure Agile Software Development Behaviors

Agile is a growing movement in software development methodology. Given the Agile movements short history but large industry buzz, the question on many leader’s mind will be if a company adopts an Agile methodology will it see a benefit to the cost of training and change required? Simply put, is there a return on investment (ROI)?
To answer this question one must have answers to many other basic and fundamental questions. One standard technique that may lead to a measure of ROI is to apply Kirkpatrick’s Model of Training Evaluation (Kirkpatrick, 1998). Kirkpatrick’s model with Phillips additions have 5 levels of evaluation, with ROI as Phillips additional level. These levels are: “Reaction and Planned Action,” “Learning,” “Application and Implementation,” “Business Impact,” “Return on Investment” (Phillips, 2003, p. 12).
This proposal is concerned with just one important step in the chain of events leading to a measure of ROI. The validity and reliability of the instrument measuring the behavioral aspects, the 3rd level, “Application and Implementation” in Phillips’ (2003) model. Social and behavioral sciences build upon a foundation that reliable and valid instruments are used throughout to measure phenomenon. In this proposal, the instrument used to measure the behavioral aspects of applied learning of the Agile methodology will be assessed for construct reliability and validity.
This chapter describes the background of the study, the statement of the problem, the purpose of the study, the research questions, the hypothesis of the study, the significance of the study, assumptions of the proposal, and limitations of the proposal, concluding with a summary of the proposal.

Background of the Study
Today software development practices vary as much as the terrain of the Grand Canyon.
 Grandview Point on the Rim of the Grand Canyon 1
The imagery of the analogy may be appropriate when considering that there are vastly differing opinions on how to manage and develop software projects currently in use in the software industry. On one side of the chasm there is the traditional structured methodologies, rigorous in process and consisting of phases described by the software development lifecycle, or SDLC. On the other side are the Agile methods characterized by barely sufficient methodologies (lightweight), iterative and incremental development life cycles, with evolving architectures and embracing changing requirements as the organization learns.

Waterfall
In the 1960s President Kennedy, launched the U.S. into the space race with his vision of sending men to the moon.
“I believe that this nation should commit itself to achieving the goal, before this decade is out, of landing a man on the moon and returning him safely to the earth.”
-- President John F. Kennedy, May 25, 1961. Address to Congress.
This required great vision, excellent communication to share this vision with the nation and the world, and fortitude to follow through in the face of disasters, along with commitment to fund the unknown exploration of space. NASA defined a phase-gate approach to develop the vast technology required to put a man on the moon. One aspect of this approach was high formality and oversight which reduced risk. There was more than money and lives at risk, there was also national pride and self-respect at risk. This methodology set the standard for much of the next 25 years, and is referred to generically as the waterfall method. The phases of the waterfall method are: Conception, Initiation, Analysis, Design, Construction, Testing and Maintenance. Like the Colorado River flowing through the Grand Canyon the phases of this methodology build up and then release into the next phase like a river flowing over a waterfall. There is no paddling back up stream, there is only one direction, down stream, no opportunity to change the design after construction has begun.
In the 1960s, the early days of the software industry, there was an alternative to the structure of the waterfall methods, it could be generalized as the ad hoc method. The ad hoc method would be used by small groups of developers working on small projects with a cohesive group of developers, with a characteristic nature of code and fix. From the Grandview Point vantage on the rim of the Grand Canyon, this method would equate to a pointed butte that juts up from the canyon floor toward the sky but is alone in space and unsupported. Much great software was written in this fashion, but it was unpredictable as a process and unreliable for a business.
One of the first to describe the importance of an iterative method of development was Barry Boehm in his article “A Spiral Model of Software Development Enhancement” (1988). This method has been adopted by the US military for large scale modernization projects which rely on hardware and software with networked complex systems development. The iteration length for the United States Army’s Future Combat Systems program was a two-year spiral. The project was canceled after six years ("Future Combat Systems," in press).
The Project Management Institute (PMI) defines the lifecycle phases as: Initiate, Plan, Execute, Monitor and Control, Close (Duncan, 1996). The typical phases are sequential and follow a rigid process of completion of one phase before the next phase begins.

Chaos
The Chaos Report (1994) by the Standish Group (Johnson, 1995) shocked the software industry in the late 1990s. This most often citied report series investigates the success and failure rates of 175,000 software projects (Hartmann & Johnson, 2006). Success rates form the 1990s were abysmal; “only 9% of projects in large companies were successful. At 16.2% and 28% respectively, medium and small companies were somewhat more successful” (Johnson, 1995, p. 2). The late 1990s saw the rise of new and extremely different software development processes. The methodologist were well aware of the failure rates of large projects with their heavy weight processes and big up-front designs.
Rise of Agile
Before the term Agile was coined, the various methodologist had begun experimenting with new processes. In 1993, Jeff Sutherland (2004) began using the Scrum process for teams at Easel Corporation with influences from Takeuchi and Nonaka’s (1986) The New New Product Development Game article in Harvard Business Review. Scrum also used the systems thinking of Peter Senge’s The Fifth Discipline. A few years later in 1996, Kent Beck came to the Chrysler C3 project as a leader where he “asked the team to crank up all the knobs to 10 on the things [he] thought were essential and leave out everything else” (Beck, 2001, p. 1). Beck’s book detailing the process used for the C3 project, Extreme Programming Explained was published in 1999. Other methodologist developed their processes in the 1990s such as Crystal, Dynamic System Development Method, Feature Driven Development and others.

Time for a Manifesto
In the winter of 2001, seventeen anarchists methodologist met at Snowbird, Utah to discuss the similarities of their various lightweight processes. By coming together face to face in open honest conversation they found they had much in common. The result was the Manifesto for Agile Software Development (Highsmith, 2001).

Manifesto for Agile Software Development
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools  Working software over comprehensive documentation  Customer collaboration over contract negotiation  Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more. (Beck et al., 2001)
The seventeen individuals were delighted they could agree on substantive value statements, and all signed the manifesto. Later 12 principles (Appendix A.) that underly the value statements were added, and this group called itself the Agile Alliance (Highsmith, 2001). These principles concern embracing changes in requirements, numerous planning levels, continuous re-planing, frequent product deployments, customer collaboration, technical excellence and human centric practices, all focused on delivering customer value.
Defining the Agility constructs such that they may be accurately assessed and are a sufficient measure of the broad term and meaning of Agile software development will be valuable resource for the Agile community. Once sufficient dimensions of Agility are defined the next logical step is to investigate the existing survey. The focus of this proposal is the Comparative Agility survey instrument, is it reliable and a valid measure of Agility.

Statement of the Problem
The growing Agile software industry has very few measures of knowledge, skills and abilities. The Comparative Agility survey is one instrument that attempts to measure Agility in the industry. However, it has not been studied for validity and reliability. The opportunity this proposal presents is the necessity for an evaluative tool that reliably assesses the individual and teams attitudes toward Agile methodologies and their behaviors as related to Agile values and principles.
Purpose of the Study
The purpose of this study is to assess the reliability and validity of an existing instrument that purports to measure the comparative agility of a team of software developers. The instrument was developed by Mike Cohn and Kenny Rubin in the summer of 2007. Participants may take the survey free of charge on the web (http://www.comparativeagility.com/). As of this writing (September, 2009) the survey has over 800 respondents (Cohn & Rubin, 2008) and is growing approximately 30 per month. Determination of the instrument’s reliability and validity will serve the Agile community and the software industry.
Research Questions
1. Are the constructs (factors or dimensions and sub-scales or characteristics) currently used by the instrument necessary and sufficient to determine a teams/organizations Agility?
2. What is the validity of the Comparative Agility instrument?
3. What is the reliability of the Comparative Agility instrument?

Hypothesis of the Study
1. The 7 dimensions (Teamwork, Requirements, Planning, Technical practices, Quality, Culture, Knowledge creation) of the Comparative Agility survey are sufficient measures of Agile Software Development methodologies.
2. The instrument is valid.
3. The instrument is reliable.
Significance of the Study
The purpose of the study is to insure that a leading measure of Agility does what it purports to do (Allen & Yen, 2001). The proposal and the study will provide valuable feedback to the authors of the survey in refining the instrument. The authors have provided a valuable resource to the Agile community, assuming that the instrument is a valid measure of the Agile philosophy put into action, that it accurately measures the constructs of Agile methodologies, and that it is reliable. The instrument is construct valid if it discriminates between teams of varying Agility in the software development industry. This survey is a reliable instrument if it is dependable, consistent and stable, and predicts within its limits of measurement level the relative observations of stronger teams above weaker teams (Salkind, 2008).
Assumptions
The following assumptions server as a basis for the conduct of the proposed study:
1. Respondents answer the survey questions honestly with respect to their knowledge of Agile terms and with respect to their experience upon the team.
2. Respondents answer the survey questions independently and do not collaborate or collude on the responses given.
3. Respondents are voluntary participants, and are not rewarded for scoring performance by their organizations.
4. Respondents have an adequate level of understanding of technical terms; an ample depth knowledge of Agile technical practices to judge their behavior.
Limitations
The following limitations apply to the proposed study:
1. The survey uses questions with only one type of ordinal response (6 point Likert scale) and may not capture the full spectrum of responses on each test, because the behavior was not directly addressed by a specific question.
2. The survey may not identify all behaviors related to Agility in software development, and therefore not be sufficient to quantify all aspects of Agile methodologies.
3. The study may not include all potential variables that might be related to Agile software development behaviors exhibited by a team.
4. The population sample is not controlled for biasing of any type, such as sampling bias or self-selection bias.
Summary of the Proposal
Chapter 2 provides a review of literature investigating the origin and philosophy of Agile software development. The Agile term will be defined and proposed definitions will be compared with the survey instrument’s dimensions of Agile software development. The 7 dimensions of the survey are decomposed into multiple characteristics which will be reviewed for completeness. A review of literature investigating measurement theories for psychometrics specifically focused upon the measurement of a self-report survey instrument of behavioral characteristics is also included. The various methods and steps necessary to develop a valid instrument based upon psychometric principles are discussed and related with the existing survey instrument.. The ROI model by Phillips (2003) guides the literature review because the ultimate measure by business of the effectiveness of a methodology is its effect upon profitability and sustainability of the business.
Chapter 3 describes the methodology of the proposed study. It includes a description of the research and sampling techniques, and the data collection procedures. It provides descriptions of the processes of developing and validating survey instruments of this nature. It identifies the data analysis methods proposed to conduct reliability studies.

CHAPTER 2  REVIEW OF LITERATURE
This chapter provides a review of the conceptual and empirical research literature relevant to the assessment of attitudes toward Agile Software Development, based on best practices in program evaluation and instrument design. Divided into two sections, this chapter first focuses upon Agile Software Development history and its roots. Second, theories of assessment and measurement theories pertaining to the assessment of organizational behaviors.
History of Agile Software Development
Software development is a very young industry. Just six decades old. Consider the birth of the industry to be the Manchester Small-Scale Experimental Machine (SSEM) which ran its first program in June of 1948 (Computer Resurrection, 1998, p. 9). In the article “The Original Original Program” by Geoff Tootill (1998) the first program was a test of some nature. Professor Tom Kilburn, one of the authors of the program recalled:
“The problem was to find the highest factor of an integer. We selected this problem to program because it used all seven instructions, and also combinations of instructions. It was of no mathematical significance, but everybody understood it” (Computer Resurrection, 1998, p. 7).
This program’s intent was to test the SSEM (the hardware) on a complex program with a known result. This first program could also be called the first unit test. Good engineering practice (test first development) was alive at the dawn of the industry. However, some of the worst aspects of software development were also apparent. “The designers of the original [computer and program] were too busy building it and getting it to work to have time to produce drawings or circuit diagrams (lack of documentation has been a problem since the very dawn of the computing age!)” (Computer Resurrection, 1998, p. 6).
Before the software industries Golden Jubilee, there were many signs of an industry in trouble. The famous CHAOS Report by the Standish Group (1995) begins with an analogy of software project and the construction of bridges. It concludes that within the thousands of years of bridge building that failures are public events and are studied which results in learning. The software industry however, is capable of hiding its mistakes and rationalizing the failures. “As a result, we keep making the same mistakes over and over again” (1995). The report notes the United States spends over $250 billion (in 1994) on application development per year (p. 1). The report may have shocked many business leaders.
“The figures for failure were equally disheartening in companies of all sizes. Only 9% of projects in large companies were successful. At 16.2% and 28% respectively, medium and small companies were somewhat more successful” (Johnson, 1995, p. 2).
The report continues with recommendation for increasing project success.
“Shorter time frames result in an iterative process of design, prototype, develop, test, and deploy small elements. This process is known as “growing” software, as opposed to the old concept of “developing” software. Growing software engages the user earlier, each component has an owner or a small set of owners, and expectations are realistically set.” (Johnson, 1995, p. 4)
These recommendations of an iterative process and growing software are very much at the core of the industry movement called Agile.

Foundation of Agile
The introduction of Extreme Programming (XP) is widely acknowledged as the beginning point of Agile methods. Other methods belonging to the Agile umbrella term are, e.g., Adaptive Software Development (Highsmith, 2000), Feature-Driven Development (Palmer & Felsing, 2002), Crystal Clear (Cockburn, 2005), Scrum (Schwaber & Beedle, 2001), Dynamic Systems Development Method, Pragmatic Programming (Hunt & Thomas, 2000) and others.
The foundations of the Agile software development movement are a lose collections of processes developed in the 1990s. The methodologist that were experimenting with new processes were very much aware of the ills in the industry. Many were consulted because of their skills in reviving projects on life support. One early methodology that saw much success was Extreme Programming (XP). Kent Beck developed and refined the XP process while on the Chrysler Comprehensive Compensation (C3) system. Like many large software development project the C3 project had failed. Chrysler brought in Beck who’s philosophy was considered a bit extreme. Beside focusing on engineering practices “like testing and reviews”, he “asked the team to crank up all the knobs to 10 on the things [he] thought were essential and leave out everything else” (Beck, 2001, p. 1). Using the XP process, “the C3 team was able to start over on a very difficult problem and deliver a high-quality application on time and within budget (Anderson et al., 1998, p. 28). The original four values attributed to XP were “simplicity, communication, testing, and aggressiveness” (Anderson et al., 1998, p. 25). Later these values were refined to simplicity, communication, feedback, and courage. These values prevail in the Agile community.
When reviewing lessons learned from implementing the first Scrum process at Easel Corporation in 1993, Dr. Jeff Sutherland acknowledged the background of software development. He writes: “authors Peter DeGrace and Leslie Hulet Stall reviewed the reasons for failure of the waterfall approach to software development” (Sutherland, 2004, p. 1) in their book Wicked Problems, Righteous Solutions. Sutherland (2004) summarizes these reasons as:
• “Requirements are not fully understood before the project begins.”
• “User know what they want only after they see an initial version of the software.”
• “Requirements change often during the software construction process.”
• “New tools and technologies make implementation strategies unpredictable.”
(p. 1)
Describing the success of the first Scrum to deliver a product in a fixed amount of time, with more features that expected, Sutherland (2004) notes four reasons the company would never return to waterfall practices, these were:
• “The waterfall method could not predict,”
• “It could not deliver on time,”
• “It produced less functionality per developer unit of time,”
• “User satisfaction was terrible when the product was delivered, since waterfall approaches did not lend themselves to customer involvement or alteration of specifications required by rapidly changing market condition.”
(p. 5)
Agile software development is a family of methodologies based on iterative and incremental adaptive practices, with lightweight process controls. It values highly collaborative environments, with disciplined technical practices while focusing on delivering value frequently to the customer. By delivering products to the customer and receiving feedback on those product increments, Agile embraces changing requirement as needs evolve.

Agile Across the Chasm
In Geoffrey Moore’s (2002) influential book Crossing the Chasm, he uses Diffusions of Innovations model from Everett Rogers to explain the chasm that exist between the early adopters of a product or new technology and the early majority. Agile adoption has crossed the chasm. “Forrester’s Business Technographics® September 2006 North American And European Enterprise Software Survey indicates that 17% of North American and European enterprises currently use Agile processes and that another 29% are aware of them” (Schwaber, Leganza & D’Silva, 2007, p. 3). This survey concludes that their methods may underestimate the number of firms using Agile methods. By 2008 the Agile adoption rate was estimated by Scott Ambler (2008) to be holding steady over 2007 and 2008 at 69% (p. 1). Ambler does not believe his survey underestimates the adoption rate. In further analyzing his data he found that developers (61.4%) were less likely to report they were doing Agile than the IT management (78.2%) (p. 2). His “fear is that management may be motivated to water agile down to earn their ‘agile gold star’” (Ambler, 2008, p. 2).
In a 2008, Dr Dobbs Journal survey of business respondents reported higher productivity, greater product quality, greater business customer satisfaction, with equal or lower cost of development. This survey reported drastic improvements in project success rates of Agile teams. Success for teams exceeding 80%. Forty-five percent of the respondents reported iteration lengths of 2 weeks or less. The author, Scott Ambler (2008), concludes: “In short, becoming more agile appears to be low-risk decision for senior IT management” (p. 4).

Defining Agility
Defining software development Agility has not been easy. The Agile movement was started as an Alliance of methodologist, each with their distinctly different methodology. However in the Snowbird, UT meeting in 2001, they found common ground, and created their manifesto. This manifesto with its four comparative value statements, and the 12 principles that are published along side the manifesto must be taken as the definition of Agile. In a review of successful distributed Agile case studies, Bose (2008) used the manifesto’s values and principles to analyze how closely the project adhered to the Agile methodology. However, that definition may be lacking in its ability to be quantified and measured. Many others have tried to apply their definitions of software development Agility.
In an early article on Agile software development, Highsmith and Cockburn (2001) state:
“Agile development is not defined by a small set of practices and techniques. Agile development defines a strategic capability, a capability to create and respond to change, a capability to balance flexibility and structure, a capability to draw creativity and innovation out of a development team, and a capability to lead organizations through turbulence and uncertainty.” (p. 8)
Miller (2001) describes Agile software process as having nine characteristics: modularity, iterative, time-bound, parsimony, adaptive, incremental, convergent, people-oriented, and collaborative. Highsmith and Cockburn (2001) describe the changing environment that Agile has created, one of satisfying the customer at delivery time compared to satisfying the customer’s purchasing agents at project initiation.
In a review of nine of the top Agile methods, Abrahamsson, Salo, Ronkainen and Warsta (2002) use a quasi-formal comparison method of defining a meta language as a frame of reference and then describing each process studied against that framework. They noted: “Despite the high interest in the subject, no clear agreement has been achieved on how to distinguish agile software development from more traditional approaches. The boundaries -- if such exist -- have thus not been clearly established” (Abrahamsson et al., 2002, p. 8). By synthesizing the existing literature, Abrahamsson, et. Al (2002) were attempting to answer the question: “What makes a development method an agile one?” (p. 98). Their conclusion:
“when software development is:
• Incremental (small software releases, with rapid cycles),
• Cooperative (customer and developers working constantly together with close communication),
• Straightforward (the method itself is easy to learn and to modify, well documented), and
• Adaptive (able to make last moment changes).” (p. 98)
The review allowed them to characterize many methods “in terms of process, roles and responsibilities, practices, adoption and experiences” (p. 98).

Goals of Comparative Agility Survey
The authors of the Comparative Agility survey are well known in the industry. Kenny Rubin was a director of the Scrum Alliance, a thought leader in Object Technology and the Smalltalk community and is a Certified Scrum Trainer (CST). Mike Cohn is the author of several books on Agile development, a co-founder of both Agile Alliance and Scrum Alliance and a Certified Scrum Trainer. The primary question they seek to answer with the survey is the question a company six months after adopting Agile wants to know: “How are we doing at adopting agile?” (Rubin & Cohn, 2008, p. 3). Specific question relative their competitors or other in similar situations may also be addressed. Such as: Where do we excel and what areas do we need to improve? The instrument Rubin and Cohn (2008) seek to deliver is one that will measure agility via “multiple dimensions” and “lead to actionable recommendations” (p. 5). Their philosophy in creating the instrument was not to measure absolute maturity of a process such as the Software Engineering Institute’s Capability Maturity Model Integration (Pikkarainen & Mäntyniemi, 2006) appraisal tools. Rather, they wished to create a relative measure. “Organizations do not need to be perfect, only better than their competitors” (Rubin & Cohn, 2008, p. 17).
The instrument has seven dimensions with multiple characteristics per dimension. Each characteristic is measured by multiple questions (~125 in total) (p. 7). The seven dimensions of the Comparative Agility survey are:
• Teamwork
• Requirements
• Planning
• Technical practices
• Quality
• Culture
• Knowledge creation
(Rubin & Cohn, 2008, p. 8)
Theories of Assessment
Assessing someones knowledge, skills, and abilities can be a difficult proposition. The Agile community believes in the value of continuous learning, and that knowledge is gained in the pursuit of an achievement. Aristotle said, “What we have to learn to do, we learn by doing.” Assessing someone’s knowledge of a particular process would be trivial, assuming the process is well defined. Assessing skills may be slightly more difficult, evolving test or observations. Abilities are even more difficult to properly assess.
The Comparative Agility survey is an attitude type test. It is assessing the individuals feelings about the Agility of their team or organization. Assessments are generally categorized by four distinctions: formative or summative, objective or subjective, basis of comparison (criterion-referenced, norm-referenced, ipsative), informal or formal. The Comparative Agility survey is a formative, subjective, norm-referenced, formal assessment. By this categorization, it means the assessment is used during a learning process (formative), answers are influenced by personal opinions (subjective), the outcome is an estimation of the individual’s position within the population (norm-referenced), and that is is performed via a written document (formal) ("Assessment," 2009). It is possible to use the survey in a temporal comparison of an individual at several points in time. The authors also see the survey being used in longitudinal studies.
Formative evaluation is one of several evaluation types, however the purpose of a formative evaluation is to improve the program under evaluation. Donald Kirkpatrick, (1998), past president of the American Society for Training and Development (ASTD), is best known for his influential model of evaluation. Kirkpatrick’s model measures at four levels: reaction, learning, behavior, and results. In the first level, reaction -- the students thoughts and feelings about the training are measured. At the second level, learning -- the increase in knowledge is measured. The third level, behavior -- change in behavior, or knowledge implementation is measured. The fourth level, results -- the effect upon the business by the trainee’s performance is measured. Phillips (1996) adds an additions fifth level, ROI -- the conversion of results into monetary value with consideration to there cost.
Nickols (1992) identified five levels for evaluation measurements to optimize the effectiveness of training programs. These are: 1) before training, 2) during training, 3) after training and before reentry into the workforce, 4) in the workplace, 5) upon exiting the workplace/job.

Measurement, Reliability and Validity
Within the field of measurement theory “a test is a device for obtaining a sample of an individual’s behavior” (Allen & Yen, 2001, p. 1). A well designed test for a complex human behavior is not as straightforward as asking a series of simple questions and scoring the answers, right or wrong. Test may be used for many purposes -- for example, employee selection, or classification such as obsessive-compulsive disorder, or ranking a skill set such as design. “A useful test measures accurately some property of behavior. To evaluate the usefulness of a test, we need to have a more precise statement of the meaning of the term measure” (Allen & Yen, 2001, p. 2). “Measurement is the assigning of numbers to individuals in a systematic way as a means of representing properties of the individuals” (Allen & Yen, 2001, p. 2). Allen and Yen (2001) continue by describing measurement theory: “a branch of applied statistics that attempt to describe, categorize, and evaluate the quality of measurements, improve the usefulness, accuracy, and meaningfulness of measurements, and propose methods for developing new and better measurement instruments” (p. 2). Measurement theory gives science the tools to describe and quantify two essential qualities of a test -- reliability and validity. “A test is reliable if it produces consistent measurements; it is valid if it measures those properties that it is designed to assess” (Allen & Yen, 2001, p. 4). For a survey instrument to provide value to the industry it must be studied for these two qualities. “Reliability and validity are your first lines of defense against spurious and incorrect conclusions” (Salkind, 2008, p. 109). The instrument must be reliable and valid to generalize any results to the population or to make valid prediction from hypothesis.

Item Format and Rating Scales
Questionnaires are the most common form of self-assessment used in psychometrics. They are relatively inexpensive to administer and with computer-aided-testing provide almost instantaneous scoring and reporting. To be effective questionnaires make basic assumptions: 1) the survey does not make unreasonable participant time demands, 2) the survey has an obvious and forthright agenda, 3) the respondents have the necessary knowledge to comprehend the questions, 4) the questions are straightforward, 5) the selectable responses are comprehensive (Salkind, 2008). Questions must be forthright and impartial.
Likert-type scales are frequently used in attitude tests and are suitable for factor analysis. Frequently a five-point Likert scale is used with response options labeled: 1) Strongly Disagree, 2) Disagree, 3) Neither Agree nor Disagree, 4) Agree, 5) Strongly Agree. The granularity of the response scale effects overall reliability of the test, discrimination ability, and participant satisfaction. All important issues and actively studied for optimization.
“The rating scales that yielded the least reliable scores turned out to be those with the fewest response categories. Test-retest reliability (stability) was lowest for two-point, three-point, and four-point scales and was significantly higher for scales with more response categories; the most reliable scores were derived from scales with 7, 8, 9, or 10 response categories.” (Preston & Colman, 2000, p. 11)
Preston and Colman (2000) found “discriminating power was lowest for the scales with two, three, or four response categories and statistically significantly higher for scales with 9 or 101 response categories” (p. 11). Preston and Colman’s (2000) conclusion: “The superiority of scales with around seven response categories is in line with Miller's (1956) theoretical analysis of human information-processing capacity and short-term memory, subsequently refined by Simon (1974) in his characterization of information ‘chunks’ ” (p. 12). However, “where considerations of face validity are regarded as paramount, it may be important for the respondents to perceive the scales as allowing them to express their feelings adequately, and in such cases 10-point scales may be most appropriate” (Preston & Colman, 2000, p. 13).

Reverse-scored Items
Psychometric experts disagree about items using reverse-scoring or negativity worded statements in attitude test. One concern is that the meaning may be changed in deriving the reverse-scored item. Nunnally (1978) argues that reverse-scored items reduce responses set bias of respondents with agreement response tendency. This acquiescence to the positive bias of the items may be balanced by reverse-scored items. However, effort in design must be used to reduce the cognitive challenges in negative worded items.

CHAPTER 3
METHOD
This chapter discusses the areas of instrument development, data collection procedures, and study sample as related to the Comparative Agility survey instrument. It describes the psychometric principles and methodology used to study an instrument for reliability and validity.

Instrument Development
Developing a measurement instrument requires several stages: conceptualization stage, development stage, and analysis stage. In the conceptualization stage the designers of the instrument are experimenting with the concepts and attributes under investigation. An exploration of the concepts will result in underlying dimensions. Literature review and review of similar instruments or surveys may enlighten this stage. However when attempting to create a new measure of newly defined and conceived notions, there may not be defined paths. An experimental model, where an attempt is made and then measured and evaluated is the recommended approach. To achieve perfection on the first attempt would be astounding.
The instrument development stage consist of several steps, concerned with: item selection, response format, review with subject matter experts to establish content validity, item scrutiny for ambiguity or unclear instructions, and pilot study. The purpose of this stage is to develop the initial instrument, use it in field-test and by its use develop a sense of its weaknesses and strengths. Changes in item selection, item phrasing, and obvious mistakes or clarification in procedures or instructions may be resolved before the instrument is used in large-scale data acquisition.
The last stage of instrument development is psychometric testing consisting of three steps: 1) determining statistical properties of item scores, 2) construct validity studies and, 3) conducting the reliability study.

Stage 1: Concept Clarification
This stage of instrument development has been completed for the Comparative Agility instrument. In the Overview of the survey, Cohn and Rubin (2008) define the relativity of Agility concept “determine how good you are compared to your competitors” (Overview para. 3). The authors have defined the seven dimensions they believe are concerned with a groups Agility when used to compare themselves to the larger industry or market segment. These dimensions are: “teamwork, requirements, planning, technical practices, quality, culture, knowledge creation” (Rubin & Cohn, 2008, p. 8). Each of these dimension have multiple factors, that Rubin and Cohn have referred to as characteristics.
Teamwork
• Teamwork composition
• Teamwork management
• Focus
• Communication
• Team member location
Requirements
• Communication focus
• Level of detail
• Emergence
• Technical design
Planning
• Planning levels
• Critical variables
• Progress tracking
• Sources of dates and estimates
• When do we plan
Technical Practices
• Test-driven development
• Pair programming
• Refactoring
• Continuous integration
• Coding standards
• Collective code ownership
Quality
• Automated unit testing
• Customer acceptance tests
• Timing
Culture
• Management style
• Response to stress
• Customer involvement
• Title and salary alignment
• Infrastructure
• People
Knowledge Creation
• Reflection
• Timeboxes
• Team learning

Stage 2: Item Development
For the Comparative Agility instrument the item development stage has been completed. The 7 dimensions are composed of a total of 32 characteristics and the survey consist of 127 items (questions) of these dimensions as well as 15 respondent demographic questions. Each characteristic is measured in multiple ways via several items. The items are formatted in a six-point Likert scale with responses coded as: 0) “Not Applicable”, 1) “False”, 2) “More False than True”, 3) Neither True nor False”, 4) “More True than False” and, 5) “True” (Cohn & Rubin, 2008).
Including the option of “Not Applicable” may increase the validity of items, specifically when there is concern that respondents may use the neutral response “Neither True nor False”, avoiding the cognitive decision (Nunnally & Bernstein, 1978). This response format may be viewed as a 5-point scale with an opt-out per item facility. Some researches prefer 7-point scales, or 10-point scales to achieve greater discrimination. John Dawes (2008) studied 5, 7 and 10-point scales in his paper “Do data characteristics change according to the number of scale points used?” He was largely interested in the ability to scale data to compare results, and in scaling the data “are there any differences in terms of mean, variance, kurtosis, and skewness” (Dawes, 2008, p. 68). He found little difference in the statical characteristics when data was scaled (Dawes, 2008). This would allow the authors of Comparative Agility study to scale there 5-point (with Not Applicable) scale to a higher point Likert scale gaining greater ability to discriminate responses and still maintain integrity of comparison.
Reverse-scored Items
The authors have not used reverse-scored items on any of the characteristics. Although reverse-scored items typically require extra attention in the scoring and coding of survey instruments, this instrument is perfectly capable of dealing with reverse-scored items. Select items using reverse-scoring could easily be integrated into a future version. These items would reduce the response set bias of individuals with agreement response tendencies, thereby increasing validity (Nunnally & Bernstein, 1978). With very little effort reverse-scored items could be added to the survey; such as:
• Teams typically include 10 or more people on them.
• Features that are code complete, but not fully tested at the end of an iteration are accepted by the Product owners.
• Failing test within the CI system are ignored during daily activity.
Number of Items per Characteristic
A large number of items on a characteristic tend to lead to higher reliability by decreasing the contribution of random error. However, too large a number of items on the same characteristic may lead to response bias caused by boredom and fatigue. Several of the characteristic in the survey have only two items, which may not be enough to have significant results.
Sample Size
A large representative sample for a field test of the survey would require 800 - 1300 respondents. The online survey is now meeting that minimum bar (over 800 respondents, September, 2009) (Cohn & Rubin, 2008). Gable and Wolf (1993) recommend a sample size of six to ten times the number of questions in the survey. The Comparative Agility survey has 127 items.
Data Collection Procedures
The survey is designed as a web-based form. Data entered into the form is stored in a database and programs have been written to process the data and generate individual reports for each respondent in real-time. This data is also stored for subsequent analysis. The web-form scores the item responses as it is submitted to the database. Further analysis may be done with the data, such as analysis for validity.
Identify the Study Population
The population the survey intends to serve would be vast, a group of software developers worldwide that use any form of Agile Software Development practices or processes, or may be considering an adoption of Agile. The U.S. Department of Labor (2007) reports 857,000 computer software engineers in 2006. Some estimates for software programmers are over 10 million worldwide. One study of Agile adoption rates reported 69% (corporations reporting one or more Agile projects) in 2007 and 2008 (Ambler, 2008).
For the purpose of studying the validity and reliability of the survey instrument itself the population sample may be selected as the number of completed survey responses. There may need to be some culling of the data to remove obvious incomplete or mischievous respondents from the data set, since the survey is open to the general public. An investigation of the cleanliness of the data will give guidance on criteria for exclusion.

Stage 3: Data Analysis
This paper proposes to proceed with the data analysis stage. The use of a statistical software package such as SPSS is typically used to determine item scores, mean, standard deviation, and conduct a principal component factor analysis.
Determine Statistical Properties of Item Scores
An analysis of the existing items should be performed allowing further refinement of the item pool. Several methods may be used by instrument designers to determine statistical properties of item scores, including mean and standard deviation and item discrimination indexes (Gable & Wolf, 1993).
Item Discrimination Index
When using Likert scales the Pearson product moment correlation coefficient is used to correlate each item score with its dimension score for item discrimination index purposes. This illustrates the extent in which an item represents its underlying dimension. A high positive correlation indicates the item constitutes the dimension where as a negative correlation may indicate issues with the item (Allen & Yen, 2001). Low correlations indicate (below 0.20) indicate the items do not represent the dimension well (Gable & Wolf, 1993). These items may need to be removed or rewritten and retested.
Mean and Standard Deviation
The mean and standard deviation for each item will be calculated. This will give an indication of the items ability to discriminate. Items with high or low means may need to be adjusted to allow for better discrimination. Items with low standard deviation may need to be rewritten or removed.

Validity Study
The instrument should be studied for content validity. C. H. Lawshe has developed a widely used method that may be used to study content validity. This requires a panel of subject matter experts (SME) to rate each item as essential, useful - but not essential, or not necessary in relation to the construct (dimension). Then statistic may be calculated for each item and a content validity ratio calculated. This is just one method of establishing content validity.
Additional validity studies may now be done with field test data. Construct validity consists of finding evidence that the instrument items actually reflect the constructs (dimensions) that have been established by the survey’s objectives. Several types of studies support construct validity. Although construct validity is a never-ending process. These studies start with a prediction and then a test of that prediction. A Group Differences study may be conducted by creating two groups - one group known (assumed) to possess Agile skills and processes, and another group known (assumed) to not be using Agile skills and process. Each group is assigned to complete the survey and the statistical test of the two groups may be compared. Theory predicts that the Agile group would score higher on the survey than the non-Agile group. This study test the ability of the survey instrument to discriminate between the two groups.
A Change study may be conducted by creation of a group that will be studied over time, before, during and after an experimental intervention is conducted. For example, a team may be tested at the beginning of a planned training on several Agile practices, such as Test-Driven Development, Pair Programming, Continuous Integration. Then tested again one-month later, and again six-months later.
A Correlational study may be conducted. Theory would predict that Agile teams will be more productive and more successful than waterfall groups within the same company or industry segment. A study groups that transform from waterfall to Agile may be conducted that measures project success rates of the company or industry correlated with the Comparative Agility study.
“A test is valid if it measures what it purports to measure. The major types of validity are content validity, criterion-related validity, and construct validity” (Allen & Yen, 2001, p. 113).
Reliability
Reliability is the instruments ability to repeatedly give the same results for a consistent observation. One method of testing reliability requires the true-score. Since there is no way to obtain the true-score for Agility, this cannot be used. Another method is to correlate two parallel but independent test. However, studying test to prove they are parallel is very difficult. Therefore reliability is typically estimated (Allen & Yen, 2001).
Test/Retest Reliability
One estimation technique is a test/retest procedure. The same test is given to the same individual multiple times and then the two results are correlated. If the results of each test are exactly the same, then the test has perfect reliability for that one instance. Using multiple instances of test/retest, one may plot the relationship and calculate the correlation coefficient (Allen & Yen, 2001).
One downfall of the test/retest method is the carry-over effect. This effect describes the influence that the individual has upon taking the test a second time. They may remember how they answered the question of the first instance and repeat the answer. When this happens the reliability coefficient will overestimate the true reliability. The practice-effect may also influence the correlation. Changes in the individuals knowledge and attitudes may also cause carry-over effects. For example if the individual has a training course on Test-Driven Development (TDD) and learns the technique, between test and retest this may cause them to be more critical of past performances in TDD, thereby creating carry-over effects on the reliability test.
The length of time between the two tests influences the various types of carry-over effect. Some types will be increased by short time intervals, like memory or practice. While other types will be increased by long intervals, like knowledge gain. “Different lengths of time can affect the reliability estimate in different ways, sometimes overestimating and sometimes underestimating the real reliability” (Allen & Yen, 2001, p. 77).
The proposed test/retest study for the Comparative Agility survey is to create a group of individuals that have completed an Agile project, wait 2 - 4 months after the project is complete before the first test with the survey. Then retest the same group after 2 - 3 months, reflecting on the same completed project. The correlation of these two test should give a fair estimate of the reliability of the Comparative Agility survey. The nature of the existing test and its infrastructure for assigning unique codes to individuals makes this technique very easy to accomplish. The difficulty will be in selecting a sample population and qualifying the individuals for the selection criteria and then following up for the second test. The selection would be facilitated by posting announcements on various social media sites (LinkedIn, Google Groups) for study participants that meet the criteria.
Instruments typically provide a range of results that tend to cluster around the true value, some lower and some higher. Their degree of scattering around the true value is the reliability of the instrument. A tight cluster is more reliable than a lose clustering of measurements. Correlations describing the co-variation between two variables assume that the measures are reliable (McDavid & Hawthorn, 2006). When the cluster is skewed about the true value then the measure is biased. Bias is an issue with validity, not reliability. A clock that has been purposely set fast by 15 minutes is reliable, but its validity is in question.
REFERENCES
Abrahamsson, P., Salo, O., Ronkainen, J., & Warsta, J. (2002). Agile software development methods review and analysis. Finland: VTT publications.
Allen, & Yen (2001). Introduction to measurement theory (illustrated ed.). Waveland Press.
Ambler, S. W. (2008). Has agile peaked. Dr. Dobbs Journal: The World of Software Development, 3(6), 52-54.
Anderson, A., Beattie, R., Beck, K., Bryant, D., DeArment, M., Fowler, M., et al. (1998). Chrysler goes to" extremes. Distributed Computing, 1(10), 25-28.
Assessment. (2009). Assessment. [Web page] Wikipedia. Retrieved October 16, 2009, from http://en.wikipedia.org/w/index.php?title=Assessment&oldid=313036309
Beck, Beedle, Bennekum, Cockburn, Cunningham, Fowler, et al. (2001). Manifesto for agile software development. [Web page].
Beck, K. (2001). Interview with kent beck and martin fowler. [Web page] Addison-Wesley.
Boehm (1988). A spiral model of software development and
enhancement. Computer, 61-72.
Bose (2008). Lessons learned from distributed agile software projects: A case-based analysis. Communications of the Association for Information Systems, 23, 619-632.
Cockburn, A. (2005). Crystal clear. Addison-Wesley.
Cockburn, A., & Highsmith, J. (2001). Agile software development, the people factor. Computer, 34(11), 131-133.
Cohn, M. & Rubin, K. (2008). Comparative agility survey. [Web page]
Dawes, J. (2008). Do data characteristics change according to the number of scale points used?. International Journal of Market Research, 50(1), 61-77.
Duncan, W. R. (1996). PMBOK--A guide to the project management body of knowledge. ZDA: Project Management Institute (PMI).
Future Combat Systems. (In press). . Wikipedia, the Free Encyclopedia. Retrieved October 7, 2009, from the Wikipedia database, http://en.wikipedia.org/wiki/Future_Combat_Systems
Gable, R. K., & Wolf, M. B. (1993). Instrument development in the affective domain : Measuring attitudes and values in corporate and school settings (2, illustrated ed.). Boston : Springer.
Hartmann, & Johnson (2006, August 25). Interview: Jim johnson of the standish group. [Web page]. InfoQ.
Highsmith, J. (2001). History: The agile manifesto. [Web page] agilemanifesto.org.
Highsmith, J. (2000). Adaptive software development. Dorset House New York NY.
Highsmith, J., & Cockburn, A. (2001). Agile software development: The business of innovation. Computer, 120-122.
Hunt, A., & Thomas, D. (2000). The pragmatic programmer : From journeyman to master . Reading, Mass : Addison-Wesley.
Jewell (2001). The new oxford american dictionary (illustrated ed.). Oxford University Press.
Johnson (1995). The CHAOS report (1994). Standish Group. Retrieved September 24, 2009, from http://www.standishgroup.com/sample_research/chaos_1994_4.php
Kirkpatrick, D. L. (1998). Evaluating training programs: The four levels. Berrett-Koehler.
McDavid, J. C., & Hawthorn, L. R. L. (2006). Program evaluation & performance measurement : An introduction to practice (illustrated ed.). Thousand Oaks : SAGE.
Miller, G. G. (2001). The characteristics of agile software processes. In Proceedings of the 39th international conference and exhibition on technology of object-oriented languages and systems (TOOLS39).
Moore (2002). Crossing the chasm (Paperback ed.). New York, NY: HarperCollins.
Nickols, F. (1992). Evaluating training: There is no cookbook approach. ASTD Tool Kit.
Nunnally, J. C., & Bernstein, I. H. (1978). Psychometric theory. New York, NY: McGraw-Hill
Occupational Outlook Handbook, . (2007). Occupational outlook handbook, (2008-09 Edition ed.). Retrieved October 1, 2009, from http://www.bls.gov/oco/ocos267.htm
Palmer, S., & Felsing, M. (2002). A practical guide to feature driven development. Upper Saddle River, NJ: Prentice Hall.
Phillips, J. J. (2003). Return on investment in training and performance improvement programs (Illustrated ed.). Boston: Butterworth-Heinemann.
Phillips, J. J. (1996). How much is the training worth?. Training and Development, 50(4), 20-24.
Pikkarainen, M., & Mäntyniemi, A. (2006). An approach for using CMMI in agile software development assessments: Experiences from three case studies. In SPICE 2006 conference. Luxemburg.
Preston, C. C., & Colman, A. M. (2000). Optimal number of response categories in rating scales: Reliability, validity, discriminating power, and respondent preferences. Acta Psychol (Amst), 104(1), 1-15.
Principles Behind the Agile Manifesto. (2001). Principles behind the agile manifesto. [Web page] AgileManifesto.org. Retrieved September 25, 2009, from http://agilemanifesto.org/principles.html
Computing’s Golden Jubilee. (1998). Resurrection: The bulletin of the computer conservation society, 20.
Rubin, & Cohn (2008, November 13). Assessing your agility: Introducing the comparative agility assessment [PDF - Slide deck].
Salkind, N. J. (2008). Exploring research (7, illustrated ed.). Upper Saddle River, N.J. : Prentice Hall.
Schwaber (2009). Scrum guide. [Pamphlet]
Schwaber, C., Leganza, G., & D’Silva, D. (2007). The truth about agile processes. Forrester Research, Inc. .
Schwaber, K., & Beedle, M. (2001). Agile software development with scrum. Prentice Hall PTR Upper Saddle River, NJ, USA.
Sutherland, J. (2004). Agile development: Lessons learned from the first scrum. Cutter Agile Project Management Advisory Service, 5(20).
Takeuchi, H., & Nonaka, I. (1986). The new new product development game. Harv Bus Rev, 64(1), 137-146.

APPENDIX A.
PRINCIPLES OF AGILE MANIFESTO
• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
• Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
• Business people and developers must work together daily throughout the project.
• Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
• The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
• Working software is the primary measure of progress.
• Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
• Continuous attention to technical excellence and good design enhances agility.
• Simplicity--the art of maximizing the amount of work not done--is essential.
• The best architectures, requirements, and designs emerge from self-organizing teams.
• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
("Principles behind the Agile Manifesto," 2001)
APPENDIX B.
DEFINITION OF TERMS
Agile software development - A family of methodologies based on iterative and incremental adaptive development with lightweight process controls featuring highly collaborative environments with disciplined technical practices focusing on delivering frequently and embracing changing requirements.
Burn-down chart - a information radiator depicting the progress made toward a goal.
CMMI - Carnegie Mellon, Software Engineering Institute’s Capability Maturity Model Integration - a measure of process maturity (5 being the highest level).
Construct - An abstraction defined by its common properties, which cannot be directly measured (Allen & Yen, 2001).
Lightweight process - generalization of Agile processes; relative to highly formal processes or heavyweight processes.
Methodology - “a system of methods used in a particular area of study or activity” (Jewell, 2001).
Product Owner - a role on the Scrum team responsible for prioritizing the work to be done, to optimize the return on investment.
Scrum - a lightweight process framework, based in empirical process control theory, which uses an iterative and incremental approach to “optimize predictability and control risk” (Schwaber, 2009, p. 1).
Scrum Master - a role on the Scrum team responsible for optimize the process and productivity.
Scrum meeting - a short focused daily plaining meeting for the team, also called the standup meeting (because no one is allowed to sit).
Sprint - a time-boxed iterations of product development (typically one month or less).
Time-box - a fixed time duration in which a task is performed.
Velocity - the amount of work a Scrum team performs in one sprint (may be measured in unit-less value of story points).
Waterfall - a generic term applied to heavy-weight formal sequential phased development methods.

APPENDIX C.
SURVEY QUSTIONS
Comparative Agility(™) Copyright © 2007, Cohn & Rubin (2008)
Version 304.

Teamwork Questions
Teamwork Composition
Teams have 5-9 people on them.
Testers and programmers are on the same team.
Team members are kept together as long as possible.
Everyone required to go from requirements to potentially shippable product is on the team.
Specialists are willing to work outside their specialties to achieve team goals.
People are not on more than 2 teams
Teamwork Management
Teams can determine who is on or off the team.
Team members choose which tasks to work on.
We don't need to work on non-value-adding tasks.
Management sets goals but doesn't tell us how to achieve them.
Focus
Management rarely changes our priorities during an iteration.
During an iteration, it feels like we're all headed toward the same goal.
Communication
Standup meetings take less than fifteen minutes.
We communicate mostly face-to-face.
Standup meetings are effective at synchronizing work.
Teams have a stand-up meeting everyday.
Agreements between the team and the product owner are made and perhaps documented but not enforced by signoff.
All team members meet in person at the start of the project.
Formal written documents are used to supplement rather than replace faster, more informal communication.
Team Member Location
Team members are located in the same city.
Team members work in a shared physical environment.
Team members are located within the same time zone.
Team members are located in the same building.
Team members work hours that overlap substantially.
Team members are located on the same campus.
Team members are located on the same floor.

Requirements Questions
Communication Focus
The details of a feature are fleshed out in just-in-time discussions.
We acknowledge that not all details can be conveyed in written specifications.
Written requirements are augmented with discussion.
Our product owner is available to discuss features during the iteration.
Level of Detail
Requirements are represented at different levels of detail based on how soon we expect to implement them.
During an iteration the specific details of some features are negotiable.
Teams are able to start projects with incomplete requirements.
Emergence
Product owners acknowledge that sometimes features turn out to be bigger than anyone thought.
Product owners can change requirements without a lot of fuss.
Change is a natural part of our business; we accept it and embrace it at resonable times.
Development teams can request and negotiate requirements changes with product owners.
Technical Design
Projects to not begin with a big, distinct technical design phase.
Technical design occurs iteratively throughout a project.
Technical design is a team activity rather than something performed by individuals working alone.

Planning Questions
Planning Levels
At the start of each iteration we create a plan showing the tasks that we'll work on during that iteration.
Before the first iteration, we create an initial plan that shows an incremental release of features and update this plan during the project.
Critical Variables
One or more of scope, schedule, or resources is allowed to change during a project.
Product owners prioritize work for teams.
Product owners are willing to discuss tradeoffs between scope and schedule.
Progress Tracking
At the end of each iteration, we create a release burndown chart, which
shows how much work remains in the release.
Teams know their velocity.
We create an update iteration burndown charts, which shows how estimated
work is remaining each day.
Features are either complete or not; no partial credit it given.
Sources of dates and estimates.
Estimates are created collaboratively by the people who will do the work.
Developers are included in the planning process in a way that they can meaningfully and appropriately affect scope and deadlines.
When do we plan?
Teams communicate the need to change release date or scope as soon as they are discovered.
Team members leave planning meetings knowing what needs to be done and have confidence they can meet their commitments.
Effort spent on planning is spread approximately evenly throughout the project.
Upfront planning is helpful without being excessive.

Technical Practices Questions
Test-driven Development
Programmers always write a failing test before writting production code.
All production code is written using test-driven development.
Pair Programming
When someone goes on vacation we don't worry about who will cover his or her work.
People switch pairing partners at least once a day.
Production code is written using pair-programming.
We have a physical and computer infrastructure that supports pair programming.
Refactoring
Any code can be refactored; no code is too dangerous to touch.
Refactoring is performed whenever needed.
There are enough automated tests that we can refactor without worrying about breaking existing functionality.
Code contains little or no duplication.
Continuous Integration
Developers check in code at least once per day.
Unit and acceptance tests are run as part of each automated build.
The entire system is built automatically at least once per day.
Source code is stored in a configuration management system.
Coding Standards
Coding standards are known and used by the whole team.
We have a coding standard for each language we use.
Coding standards are effective at helping support collective code ownership.
Collective Code Ownership
Anyone is allowed to change any code.
There are enough automated tests that everyone feels safe changing any code without worrying about breaking existing functionality.

Quality Questions
Automated unit testing
The entire suite of unit tests is run in an automated way.
All unit tests are run and pass before code is checked in.
Running all unit tests is fast, so we run them frequently.
Programmers always write automated unit tests.
Customer acceptance tests
A feature is not complete until its acceptance tests pass.
Product owners provide the acceptance criteria for each feature.
Acceptance testing is automated and run at least once a day.
Timing
All types of testing (performance, integration, scalability, and so on, for example) is performed each iteration.
All bugs are fixed during the iteration in which they are found.
There is no big handoff between programmers and testers either during or at the end of an iteration.
At the end of each iteration the is little or no manual testing required.
Testers are productive right from the start of each iteration.

Culture Questions
Management style
Management allows team members to make the decisions that should be theirs to make.
Teams feel an appropriate amount of pressure to meet deadlines.
Product owners understand that sometimes solving 20% of the problem delivers 80% of the value.
Product owners are willing to consider delivering less than a 100% of a solution.
We maintain a high rate of productivity without being overworked.
We don't cancel training, holiday, and vacation time when behind schedule.
Developers and product owners participate equally in determining what features will be included in a given release (i.e., release planning).
Response to stress
We avoid people having to work long stretches of evenings and weekends to meet deadlines.
When faced with a stressful situation, our initial reaction is to prioritize and explore tradeoffs.
We rarely add people when changing scope or schedule might be better solutions.
Customer involvement
Product owners are co-located with teams.
Product owners respond to team requests in a timely manner.
Product owners and other stakeholders are consistently involved throughout the entire project.
Teams have reasonable access to their product owners.
Title and salary alignment
Titles are not significant in how team members interact with one another.
Bonuses, annual reviews, and compensation promote team behavior.
Infrastructure
Our telecom systems (phones, VOIP, video conferencing, conference calling) help us be agile.
Our physical environment (office space, conference rooms, access to white boards, etc.) help us be agile.
We aren't forced to use software tools that don't help us.
Our software tools help us be agile.
People
Team members have the appropriate skills and knowledge to do agile development.
Team members know who their ScrumMaster or project manager is.
Product owners are good at their job.
Our ScrumMaster or project manager is good at their job.
Team members know who their product owner is.
Our default answer is 'yes' rather than 'no, it can't be done.'

Knowledge-Creating Questions
Reflection
Iteration retrospectives lead to refinements in our process.
Iteration reviews are attended by product owners, stakeholders, and team members who actively participate.
We get actionable feedback from our iteration review meetings.
We do iteration reviews at the end of each iteration during which we solicit feedback on the state of the software.
We hold retrospective meetings at the end of each iteration during which we evaluate how we're doing and discuss how to get better.
Iteration retrospectives are attended by all team members.
Timeboxes
At the end of iterations, we have working software that could be given to friendly first users.
All work is done in iterations of no more than 30 days.
Within our iterations work such as design, coding and testing overlay rather than being performed sequentially; this is, no mini-waterfalls.
We agree on how much testing and how much deployment must be done within the iteration.
Team learning
We value learning new approaches, technologies, skills and practices.
Teams exhibit courage in discussing problems.
We are willing to acknowledge and adopt other options.
We share a set of common principles.
We ask questions of each other as often as we advocate positions.

Demographics
As you respond to this survey will you be thinking mostly about your:
Does your project need to meet any regulatory requirements (ISO 9001, Sarbanes-Oxley, etc.):
How long had this 'group' (as identified above) been doing agile development prior to starting this project?
Which best characterizes this project?
About how many people were or are on the project being assessed (or your last project)?
About how many teams were on the project being assessed (or your last project)?
What industry best describes the project being assessed?
What best describes your role on the project? (pick one)
Does this project involve outsourced Agile development?
What is your company's name?
What was the project's name?
Where were employees on the project located?
What is your name?
What is your title?
Would you like to be contacted with further information about this research?

Job Satisfaction Cannot Predictably Increase Job Performance

Wed, 21 Oct 2009 20:00:36 -0700

Job Satisfaction Cannot Predictably Increase Job Performance
David Koontz
Chapman University College

Job Satisfaction Cannot Predictably Increase Job Performance
The link between job satisfaction and job performance has been a favorite research topic for 100 years or more. It has yet to be identified. This relationship is more complex than science is currently able to penetrate. A business must measure the return on investment for its initiatives. Investing in job satisfiers alone is a poorer bet than investing in direct performance improvements. Managers looking to increase performance via the system thinker’s lever of job satisfaction will have better luck playing a slot machine. With such a complex dynamic relationship, business would be wiser ignoring job satisfaction as a method of increasing performance.
Historical Relationship
Researchers have long been in search of industrial-organizational psychology’s holy grail{Judge 2001 @376}. The connection between job satisfaction and job performance is elusive and waxes and wanes over the years. Perhaps first studied by the scientific method in the famous Hawthorne studies at Western Electric in the 1920s which concluded “happy workers are productive workers” {Jamrog 2004 @54}. The next several decades of research revolved around the industrial line workers feelings and morale as correlated to production of assembly line work, or task work {Jamrog 2004}. This theory became know “as the ‘Pet Milk Theory.’ Based on a commercial for the Pet Milk Company indicating that their contented cows produced better milk” {Jamrog 2004 @54}. The analogy of cows in a milking barn with line workers being measured on a piece work rate is very appropriate. This reflects the attitudes of the period of industrialization of production. During the depression years the unrest of workers resulted in the passing of the Wagner Act (1935) {Jamrog 2004 @54}. This law gave much more power to the unions, the workers legal representative in collective bargaining. Job satisfiers, would be high on the list of union bargaining representatives during contract negotiations.
Satisfaction Dichotomy
Frederick Herzberg proposed his Two-Factor theory in 1959, stating a dichotomy in the assumed continuum of satisfaction. His theory suggest that factors that lead to extreme job satisfaction (motivators) are distinct and different factors than those that lead to extreme dissatisfaction (hygiene). Herzberg built his theory upon Maslow’s Hierarchy of Needs theory{Robbins 2009}. Herzberg’s motivators were seen to meet Maslow’s higher-order needs (esteem and self actualization) whereas the hygiene factors were associated with Maslow’s lower-order needs (physiological and safety). This dual continuum of satisfaction, becomes much more pronounced in the transition from the industrial workforce of the early Twentieth Century into the knowledge workforce of the Twenty-first Century. Motivation factors such as achievement, recognition, responsibility, advancement and the intrinsic value of work itself are now seen to be as important as the merely satisfying factors of working conditions, salary, peer relationships, status, and policy and administration {Robbins 2009}.
Meta-Analysis
Vroom, in 1964 reviewed 20 studies and found a very low correlation between satisfaction and performance {Iaffaldano 1985}. Twenty years later with over 200 studies to analyze a similar result was reported. Iaffaldano and Muchinsky {Iaffaldano 1985} described the perceived job satisfaction - job performance relationship as “an illusory correlation, a perceived relation between two variables that we logically or intuitively think should interrelate, but in fact do not“ (p. 270). This however did not appear to dampen the belief in this behavior relationship. In the 1970s and 1980s the up and coming theory was systems thinking. A conceptual holistic approach to organizations that emphasized the interrelated nature of events, systems, and groups of people, and their behaviors. System thinking suggests that because job satisfaction is a factor in the organizational system along with job performance the two must be related in some dynamic fashion. Judge, Thoresen, Bono and Patton {Judge 2001} did a larger and more comprehensive meta-analysis in 2001 with the opposite conclusion from Vroom and Iaffaldano and Muchinsky. Judge et al. {Judge 2001} concluded that there was a correlation (.30) between overall job satisfaction and job performance (p. 376).
Figure 1. Scatter plots of select correlation coefficients.
A plot of various correlation coefficients are show in Figure 1 for relative comparison {Wikipedia 2009}. Iaffaldano and Muchinsky also pointed out various reasons to doubt the previous studies, and encourage future research. Their integrated model of the relationship is proposed as a unifying framework for future studies (Figure 2) {Judge 2001 @390}.
Judge et al. suggest that measuring at higher aggregate levels are necessary. They also note that matching granularity is important. An appropriate measure of satisfaction of a group must be matched with a performance measure at that level. Taking this argument to the national level the trend in U.S. Job satisfaction is down, 8 percentage points in 20 years {Blanchflower 1999}. However job performance measures have a rising trend in the U.S. {InternationalLabourOrganization 2003}. That would imply a negative correlation.
Conclusion
With the best data to date the correlation between job satisfaction and job performance is small at best. When the correlation is zero it does not mean that there is no relationship, just that the relationship if there is one, is not linear. That leaves managers to wonder; intuitively there appears to be a relationship, if it is not linear then it must be a much more complex relationship. When plotted on a graph, most managers would see the 0.30 correlation as a shotgun blast, not a slightly linear relationship. So in reality, if one can induce a positive movement of satisfaction the result in performance may be rather random, and even degrade performance. The elusive link between job satisfaction and job performance may be found with further research, better methods, and broader aggregation of the indicators. However business looking to spur higher incremental productivity from their workforce by addressing job satisfaction measures alone will receive little return on investment. Investments in increasing satisfiers would better be put to increasing direct production or stimulating performance indicators directly. This is not a call to ignore those aspects of satisfaction completely. Many theories relate to the woes of an unhappy, dissatisfied workforce. Managers not expect to dangle a few lunches, office parties, and bonuses, as a carrot, to bump productivity into overdrive.
References
Blanchflower, D. G., & Oswald, A. J. (1999). Well-Being, insecurity and the decline of American job satisfaction. NBER Working Paper.
Correlation. (2009, September 6). Correlation. [Web page]. Retrieved September 6, 2009, from http://en.wikipedia.org/wiki/Correlation
Iaffaldano, M. T., & Muchinsky, P. M. (1985). Job satisfaction and job performance: A meta-analysis. Psychological Bulletin, 97(2), 251-273.
Jamrog, J. J., & Overholt, M. H. (2004). Building a strategic HR function: Continuing the evolution. Human Resource Planning, 27(1), 51-63.
Judge, T. A., Thoresen, C. J., Bono, J. E., & Patton, G. K. (2001). The job satisfaction-job performance relationship: A qualitative and quantitative review. Psychological Bulletin, 127(3), 376-407.
New ILO Study Highlights Labour Trends Worldwide: US Productivity Up, Europe Improves Ability to Create Jobs. (In press). International Labour Organization.
Robbins, S. P., & Judge, T. A. (2009). Organizational behavior. Upper Saddle River, N.J. : Pearson Prentice Hall.

Coaching in the Agile Context

Tue, 20 Oct 2009 22:16:17 -0700

Coaching in the Agile Context
David Koontz
Chapman University College

Coaching increases an organization’s ability to transform in any circumstance. Modern organizations are turning to coaching as an effective means of learning and developing their key resources, people. As our industries move into the information age, knowledge creation becomes a key competitive advantage. Coaching facilitates knowledge creation and organization adaption to new capabilities. The software industry is undergoing a transformation to new methodologies and many of these newer lightweight processes fall under the Agile umbrella, or family of processes. Agile software development methodologist recognize the need for training and development in these new techniques. Coaching at many levels in the organization is paramount for successful Agile transformation to occur. Organization transformation have been studied and demonstrate a life-cycle of phases. Kotter’s model of organizational transformation and Agile transformation are overlaid in this paper with an emphasis on coaching. Coaching at all levels in the organization is most advantageous to the software development group’s transformation into a learning organization.
Coaching in the Modern Organization
“Coaching is the process of equipping people with the tools, knowledge, and opportunities they need to develop themselves and become more effective” (Peterson & Hicks, 1996, p 14). Seen as a process, coaching is not an occasional conversation, or a single event, it is a continuum of events and conversations that guide people to learn how to perceive their current reality and the tools, resources, opportunities they have to produce a desired outcome in a future reality. The tools a coach engages are the tools of inquiry, reflection, analysis, and imagination (Peterson & Hicks, 1996).
Coaching in the modern organization is a hot topic. Many of our leading companies are training managers by the thousands to become coaches (Hargrove, 1995). This proliferation of coaching is a means to an end. The goal of organizations training coaches and supporting coaching throughout the ranks is to achieve success for the company. Leaders recognize the imperative of creating new knowledge in the Twenty First Century information age. Coaching fulfills an important development force in the knowledge worker’s environment. A coaches sphere of influence is a just-in-time method of development training.
Hargrove (1995) describes three rites of passage that businesses have experienced in the evolution of companies and our market places. The change from crafts to high-volume production lines around the turn of the Twentieth Century is the first passage; standardization. Production lines required standardization to achieve high-volume throughput of parts assembled into a whole product. In this era the assembly line worker was seen as just another replaceable part in the machine. The second rite of passage is the quality era, lead by W. E. Deming in the mid Twentieth Century. In this era the company had to produce high quality goods as well as high volume. Deming’s techniques for achieving consistent quality resulted in social changes in the workplace. These quality techniques empowered the line workers. The workers became more that just a means of production, they became an integral part of the quality of production. In Hargrove’s third rite of passage the company must concern itself with innovation and creating new products. This creative process requires knowledge, complex problem solving skills, and collaboration. Hargrove (1995) sees the successful companies in this new era with “a special kind of management culture, one that is based on creating new knowledge” (p 6). Further the “crucial player in this new management culture is the transformational coach” (p 6). There is no doubt that a software development company is operating within this third era.
An innovative company traditionally contains a research and development department to create products giving the company a competitive advantage. In the knowledge era the company must also maintain competitive advantage with its human capital. Coaching and development are “integral to leveraging an organization’s strategies and core competencies” (Peterson & Hicks, 1996, p 9). This leader “translate[s] the rhetoric of ‘people are our most important asset’ into real investment in people's growth” (Peterson & Hicks, 1996, p 9). Peterson and Hicks argue that every leader in the organization must close the gap in perceptions of the lip service given to human development, if the goals are to become reality. Their argument is that; “change is inevitable,” “people must learn and adapt quickly,” “employees want to grow,” and “people are the real source of competitive advantage” (Peterson & Hicks, 1996, p 11-12).
Coaching others is a discipline that can be enormously powerful in personal satisfaction and pride for the coach. However, there are other benefits for the coach. Personal motivations are important to recognize, and lead to self-sustaining models with virtuous cycles. The personal payback for the coach are stronger teams with highly capable people. Dedication and excitement are beneficial byproducts of a person growing in their role. Talented people seek growth opportunities. A reputation as a leader that helps people grow and learn creates an influx of talent. As talented people influenced by the coach move on to new opportunities the coach’s network expands. Cultivation of this social network, of people with uniquely skilled competencies has value for the coach and the business. This social network creates an exponential growth in knowledge that may be tapped by the coach. The coach does not need to personally know every problem domain to be effective within the solution space. One secret of effective and efficient coaches is, only a small amount of energy is required if focused on the highest priority opportunities. This creates extreme leverage for the coach and the company (Peterson & Hicks, 1996).
Peterson and Hicks (1996) give many strategies to target the common barriers to development. The basis is trust. Partnerships are founded on trust, and coaching is a partnership. All parties must understand the motives of the others. Understand that the coach also has something to gain from the partnership. The coaches motives should be made visible to the team. Inspiring commitment to self development becomes easier when people understand how the development will personally effect them. Developing new skills requires practice. Coaching helps grow new competencies by disciplined consistent practice. Measuring progress is a vital aspect of growth. Recognizing barriers to learning and suggesting methods to overcome these barriers, and teaching the skills for future meta-cognition is coaching at its best. Observing misalignments of personal and organizational goals and making these observations visible to all parties is a key competency. Finally coaches are concerned with the team environment. Shaping the environment to encourage and reward new behaviors makes change regenerative.
Coaching the Agile Transformation
Augustine (2005) describes the Agile manager as a change agent who aspires to transformational leadership. The Agile manager believes in the people with whom they work, such that delegation and shared responsibility is a natural outcome of the relationship. They maintain high moral and ethical standards. Lifelong learning is the Agile manager’s way of dealing with the constant change, complexity and ambiguity in the industry. They are experimenters, exploring and analyzing the effects of actions. Agile managers are visionaries, capable of articulating a shared vision, and influencing others.
The Agile software development movement is redefining the methodology for producing software. Agile development is a systems approach of managing a creative sometimes chaotic process. Agile transitions require time and energy, and a shepherding of the transformation. With any organizational transition there is risk of never achieving the goal. Coaching significantly increases success rates of Agile transformations. Agile transformation is an organizational change from command-and-control, highly rigorous processes with detailed plans and up-front designs to methods of collaborative work environments, lightweight processes, evolving architectures and designs intended to embrace changing requirements.
The Agile Context
The Standish Group’s (1995) famous Chaos Report noted that only 9% of software development projects were successful in large companies, with slightly higher rates for medium and small companies (p 3). In this era of software development companies were using highly formal linear design then construct methods. The foundations of the Agile software movement are the various “lightweight” processes of the 1990s. This new development process, resulted from an era of failed “heavyweight” software projects utilizing process methodologies that required large investment of time and energy in planning, design, and documentation of the project goals as well as the process steps. The new alternative was a response by some in the industry to correct systemic problems. Scrum, Extreme Programming (XP), Feature-Driven Development (FDD), Pragmatic Programming, Dynamic Systems Development Method (DSDM), Adaptive Software Development, Crystal Clear, and others were the processes that grew out of the stressful failures of the large number of failed software projects of the 1980s and 1990s. In early 2001, seventeen leaders of these various lightweight methods came together to define their common characteristic and values (Fowler, Highsmith, 2001). What resulted from this meeting was the Agile Alliance and their manifesto:
Manifesto for Agile Software Development
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools  Working software over comprehensive documentation  Customer collaboration over contract negotiation  Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
(Fowler, Highsmith, 2001, p 35)
The alliance of methodologist use these core values and principles to redefine the software development industry. Coaching is an organizational process that will support these values.
Coaching the Agile Development Team
Coaching is recognized as a key role within the development group. Extreme Programing (XP) identified a specific role on the development team, the XP Coach. Among other duties, the XP coach “helps the individuals with less experience find directions to grow in that are relevant to the business and the project unfolding” (Cunningham, 2005, p 1). Extreme programming utilizes specialized skills such as; pair-programming, consensus decision making, test-driven development and continuous integration. Developers new to Agile practices will need to learn these XP skills. These XP skills rely on well developed interpersonal skills that many software development personnel will need to develop. Development of team building and group dynamics, as well as training in the technical competencies require coaching and development effort.
The Scrum methodology does not define a formal coach role. However the role of the Scrum Master is to ensure the Scrum process is followed and the various team members are functioning to the best of their abilities. Ken Schwaber described one aspect of the Scrum Master’s role: “Improve the lives of the development team by facilitating creativity and empowerment” (Schwaber, 2004, p 7). Much like a coach the Scrum Master has no authority or hierarchical control over the team. A Scrum Master uses their influence, knowledge of the Scrum process, the general knowledge of the software development best practices, and the systems thinking embodied in the Agile values to guide the team. The Scrum Master to Scrum team relationship is based upon trust, respect, a commitment to learning and courage for inquiry that manifest in well functioning Scrum retrospective meetings each sprint (development iteration).
In Yahoo’s Agile transformation, the role of the coaching group was recognized, as playing a vital role in the change process (Benefield, 2008). Yahoo describes its transformation as a grassroots effort; although the Agile coaches had executive support and VP level budgetary oversight. In hindsight Benefield saw the benefit of concurrently introducing XP engineering practices such as pair-programming and test-driven development at the team level, while engaging the Scrum process, which is focus at the team organizational level (Benefield, 2008). A large challenge for Yahoo was growing the coaching team at the acceleration rate of teams wishing to adopt Scrum. The demand for training and coaching far exceeded the supply. A significant portion of the coaching team’s effort was diverted into justification of their own existence, and collections of metrics to justify the transformation. Both management and teams desired proof of success before they were willing to commit. Therefore a large amount of coaching energy went into measurements and surveys of the transformation to Agile. This behavior is indicative of lacking vision. The vision of Agile transformation was not urgent and shared by all the organization. Groups of people needed proof to buy-in to the change process. With extra effort the small coaching team was able to overcome these disfunction and grow the adoption from a few teams to over 150 Agile teams with 81% of the individuals happy with the Scrum process (Benefield, 2008, p 272).
Coaching through the Eight Steps to Transformation
In John Kotter’s paper “Leading Change - Why Transformation Efforts Fail,” he describes the lessons learned from observing hundreds of companies in transformation processes. From these successes and failures he draws the conclusions that there are a series of phases that require considerable time for the company to progress through. Short cutting the phases (or steps) harms the overall process. A critical mistake in any of the phases has far reaching negative affects reducing the chance for the long-term successful transformation. One factor that pressures businesses to short-cut phases is the lack of capable people experience in transformations (Kotter, 2007).
Many software development organization are adopting Agile processes to improve their companies development groups. To be successful the development group must negotiate a transformation, from existing practices typically rooted in “waterfall” process mentality to Agile practices and mentality. Modeling Agile transformations using Kotter’s eight steps for transformation gives insights into how experienced Agile coaches improve the chances for success. For the purposes of this paper we will use the Agile process of Scrum as a management framework with XP engineering practices for developers, a typical conglomeration of process methods.
Kotter’s primary step in transforming the organization is to “establish a sense of urgency” (Kotter, 2007, p 99). This step is the initiation of the change. Creating this sense of urgency is the primary responsibility of the company’s leadership. Kotter sees that 50% of companies fail with this first phase. The reason: “executives underestimate how hard it can be to drive people out of their comfort zones” (Kotter, 1995, p 97). Yahoo found this to be true, in their bottom-up approach to Agile transformation. The coaching staff at Yahoo worked to overcome the rut of traditional development practices (Benefield, 2008).
At a team level Scrum creates a sense of urgency to complete the sprint and deliver working software in just weeks. Agile processes such as Scrum, reduce the developers timeframe of concern from years until project completion, to weeks for sprint completion. This sprint deadline creates Kotter’s sense of urgency at a team level within the organization. To be successful a Scrum team must deliver working product in a matter of weeks. There will be no time to waste.
Leadership is required for transformation change, not management. Management by definition is about control. Agile processes are about empowerment, self directed teams capable of self-organization to solve complex problems. This requires a servant leadership style of interaction with the team. Agile coaches empower the organization to overcome the fear of change. Creating a sense of urgency that change is required. Support and renew this understanding that business as usual, allowing a large majority of projects to fail is unacceptable.
The second step is to form coalitions capable of leading the change. Empowering the group with the authority required to make changes in the organization. Kotter notes that this coalition consist of managers and various key individuals from all levels of the company. The coalition may be small at first but it must grow in size and influence as the transformation progresses. This is a top down vision of the transformation change. In the bottom-up Scrum model there is also a coalition of the willing. A Scrum team is a cross-functional, self-organizing and empowered group. However, a team does not exist within a vacuum. It must forge relationships with other teams and groups within the organization to achieve the goal of producing working software. Typically the relationships at the boundary area of a Scrum team are the responsibility of the Scrum Master. This is a coaching role for the Scrum Master. Coaching the team to work well with other groups, to set expectations, and to met their commitments. Also coaching the organization and the other groups in how to effectively interact with a Scrum team. These coalitions are foundational to building trust across people and teams.
The third and forth step in Kotter’s model are the steps of creating a vision and communicating that vision. For Agile transformations this vision is one of creating new ways to develop software that meets the customer current needs and is capable of evolving to met their future needs. The focus for the Agile transformation is on processes that allow the organization to create quality software effectively, while embracing the changes required by market forces. The Agile coach fulfills a vital role in creating the vision of better processes, developing strategies for achieving and measuring progress toward that vision. They are the evangelist for the Agile process, the exemplar of Agile philosophy in action.
The fifth step is to empower others to act on the vision. This is the essence of the role of Scrum Master. Kotter observes that a major error in transformation processes is not removing obstacles to the new vision. “Too often, an employee understands the new vision and wants to help make it happen. But an elephant appears to be blocking the path” (Kotter, 2007, p 101). Scrum has recognized this disfunction and has specifically charged the Scrum Master with responsibility to remove these impediments. Many impediments are resolved by just raising the visibility of the blocking issue to the level of awareness, then creating a plan to focus attention and changing behaviors. Quite often these impediments are of an organizations nature and cannot be resolved without the intervention of other department leaders. This is when the Scrum Master must facilitate understanding of the issues and offer coaching in seeing the cost of the organizational impediment, and the benefits of resolving these systemic issues.
Kotter’s sixth step is to create short-term wins. Success breads success. Planning for and recognizing the small success toward the larger vision is a powerful tool. Agile processes create this opportunity through the iterative process of incremental changes to the software application within the Scrum sprint. The sprint is a short timeframe in which the development team plans the work to be accomplished and then executes the plan. Resulting in a small increment to the overall feature sets of the application. This increment may be releasable to the customer, resulting in speedy return on investment. In these short timeframes (one to four weeks) the teams and stakeholders begin to see real success.
Consolidating improvements and institutionalizing these practices while still allowing and encouraging continued change is the seventh step required for transforming the organization. The increased credibility that Agile teams with successful processes create in changing system structures and policies will enhance the progress. Kotter warns not to declare victory too soon. Time is required for the new system structures and ways of doing to become the norm. Rituals such as the daily Scrum meeting help to reinforce new habits and build practice of key disciplines into the work life and social fabric. However too frequently change efforts revert to the old ways; therefore it is imperative that change agents reinvigorate the process by celebrating achieved milestones and then setting new goals.
In the eighth step, Kotter notes that articulating the reasons for new behaviors and tying them to corporate success, institutionalizes the new approaches. Helping people to see the right connections between cause and effect requires communication and vigilance. Institutionalization also requires an eye toward succession planning. Promoting from within will anchor the change in the culture. Insuring that new players coming into the company are committed to the transition especially in the top ranks is vital.
Just as Agile process of software development are iterative in nature, so to are Kotter’s phases of transformation. One is never done with transformation, for there is always more to be done to secure the transformation within the organization fabric.
Conclusion
The Agile software movement is a transformational method of correcting a culture that has allowed high rates of failed projects. Agile development is a systematic view of managing a chaotic process through empirical process controls. The transformation to Agile processes require time for people to internalize new ways of acting. The Kotter model of organizational transformation phases are facilitated by a coach that has experience in Agile transformations. Agile coaching at both the team level and above are key factors of success in transforming the organization. Agile coaches develop the team and their skills to perform within new frameworks that deliver quality constantly while adapting to ever changing conditions. Coaches develop processes that encourage innovation and reward knowledge creations. Agile coaching is a very important factor in success rates of Agile transformations, and thereby software development projects.

References
Augustine, S. (2005). Managing agile projects. Upper Saddle River, NJ: Prentice Hall.
Benefield, G. (2008). Rolling out agile in a large enterprise. Hawaii International Conference on System Sciences, pp. 462, Proceedings of the 41st Annual Hawaii International Conference on System Sciences.
Cunningham (2005). The coach. Cunningham & Cunningham, Inc. Retrieved June 17, 2005, from http://www.c2.com/cgi/wiki?TheCoach
Fowler, M., Highsmith, J. (2001). The agile manifesto. Software Development, 9(8), 28-35. Retrieved July 12, 2009, from http://agilemanifesto.org/
Hargrove, R. A. (1995). Masterful coaching: Extraordinary results by impacting people and the way they think and work together. San Francisco: Pfeiffer.
Kotter, J. (2007, January). Leading Change. Harvard Business Review, 85(1), 96-103. Retrieved July 24, 2009, from Business Source Premier database.
Peterson, D. B., & Hicks, M. D. (1996). Leader as coach: Strategies for coaching and developing others. Personnel Decisions International, Minneapolis, MN.
Schwaber, K. (2004). Agile project management with Scrum. Redmond, WA: Microsoft Press
Standish (1995). Chaos report. The Standish Group. Retrieved July 18, 2009, from www.projectsmart.co.uk/docs/chaos-report.pdf

Shock Therapy: Good for the Team

Mon, 19 Oct 2009 21:22:46 -0700

Shock Therapy: Good for the Team
David Koontz
Chapman University College

Shock Therapy: Good for the Team
Building new teams is very difficult, getting a team to come together and gel is an art that has been studied in group dynamic and other team building efforts. Bruce Tuckman’s model of group development (Forming, Storming, Norming, Performing) is the basis of team building. Scrum is an Agile software development framework based upon empirical process control theory. Using an inspection and adaptation feedback loop Scrum allows a team to self-manage while constantly improving its process and methods of work. Many teams require months to reach the performing stage. A method to reduce this startup cost is a controversial technique named Shock Therapy. With skilled and competent leadership Shock Therapy will produce the desired results: a productive team with Agile knowledge and experience delivering the desired product. A great value to the company and the team.
Self-Organizing Groups
Starting a team is always challenging. A group of individuals will take considerable time to form a tight cohesive team. In the forming stage of team development there are many aspects to distract the team from a quick transition to the performing stage. Businesses desire high return on investment for projects, and are always searching for cost cutting measures. Reducing startup cost of team development will have cost reduction benefits for the business. For businesses that have many projects starting up, like software development companies, a cost reduction can have a significant affect on profitability and sustainability.
Scrum is a software development framework that is focused on a team of cross-functional developers that are allowed to self-organize within the team to design solutions. Sutherland refers to Scrum as an ecosystem, “based on complex adaptive systems theory” (Sutherland, Downey & Granvik, 2009, p. 1). Within this ecosystem it is natural for the team to find the path of least resistance, to compromise on aspects of practice, and to misunderstand the reasons underlying practices and their synergic nature of support.
Many influences act upon the formation of the team, one of the major influences is the Scrum Master. The Scrum Master is a team leader and is responsible for the team’s process. “Theorists have argued that leadership is necessary for self-managing groups to perform at high levels (Klein, 1984; Letize & Donovan, 1990; Manz & Sims, 1987)” (Sy, Côté & Saavedra, 2005, p. 1). Although Scrum can be taught in a few hours, Sutherland et. al have found that novice leadership allows teams to “[focus] on aspects of the framework rather than on delivering value to the customer” (Sutherland et al., 2009, p. 2). At MySpace, Scott Downey has used a bootstrapping technique referred to as Shock Therapy to reduce team startup times by as much as 50% (Sutherland et al., 2009, p. 1). Downey requires the complete team, including Product Owner, Delivery Team and Scrum Master to participate in an Introduction to Scrum training course. Teams are then required to practice Scrum within a tightly constrained set of rules. Rules designed to stabilize the environment. These rules define an initial team profile regarding: sprint length, definition of done, acceptance of sprint backlog items, effort estimation, progress tracking, duration of meetings, and respect for the team’s time and process (Sutherland et al., 2009). Self-organization is seen as a privilege that must be earned by the team. The measure of achievement to earn that privilege is not completion of the training course and the formation of the team, but a traditional value of Agile, delivering customer value. The teams are only allowed self-organization after they “complete three consecutive, successful Sprints, demonstrate a 240% increase in Velocity, and have a solid business reason to make a change that was agreed to by all team members” (Sutherland et al., 2009, p. 3).
MySpace and other companies have used this Shock Therapy technique to launch new Scrum teams. The teams spend less time in the forming, storming, and norming stages of team development. Initial constraints on the team’s self-organization appear to have a benefit regarding formation. These teams reach two and three times the productivity in a matter of weeks (Sutherland et al., 2009, p. 1). Creating a group experience and achieving productivity is the desired goal of the bootstrapping technique.
One aspect of Downey’s experience with these teams is that he does not have the time to coach them through project completion. He has therefore maintained a strict rule to foster self-sufficiency within the team. As a coach that will turn over the reins to someone else, he does not take on any fundamental tasks, he cedes power and leadership as the team assumes those roles. When the team demonstrates that it has knowledge of the process, is delivering customer value each sprint, and is highly productive, it then deserves the privilege to self-organize.
Interactionist View of Conflict
The Shock Therapy technique is consistent with the interactionist view of conflict in group dynamics. Constraints imposed upon the group bind the group to a well defined process. Constraints upon the team’s stated value of self-organization act to reduce the process conflict that the team will naturally have in their formation stage. The interactionist view proposes that there are functional and dysfunctional types of conflict. Task conflict at moderate to low levels are considered a “positive effect on group performance because it stimulates discussion of ideas that helps groups perform better” (Robbins & Judge, 2009, p. 486). While process conflict should be kept low, and “relationship conflicts are almost always dysfunctional” (Robbins & Judge, 2009, p. 486). The Shock Therapy introduction of the Scrum model allow the team to assimilate the new process behaviors over a period of time while reducing the stress induced by the drastic changes of the Scrum framework to the developers traditional processes. Removing the process changes from the debate, the team focuses upon the remaining two types of conflict, relationship and task conflict. This reduction in conflict types also allows the Scrum Master to focus on these areas. The result is quicker stabilization of the Scrum ecosystem in the high energy productive state.
By reducing one of the three types of conflicts the Scrum Master has decreased the storming stage over process issues and quickened the transition to a highly performing team. The remaining two types of conflict, personal and task conflict will be that much easier to manage. When these types of conflict are well within bounds and the team has proven its ability to produce customer value, removing the constraints on process conflict will be easily managed also.
“Aggregates of Strangers” (Hall & Williams, 1966, p. 214)
In an early study of group dynamics Hall and Williams (1966) studied the decision-making abilities of groups. There basic research question being asked was; did an ad hoc group that was typically studied generalize to the population of a well-established group? In this landmark study the researches found strong evidence that “established groups were significantly superior to ad hoc groups in decision performance relative to several criteria” (Hall & Williams, 1966, p. 214). The criteria of interest here is the difference found in the study for resolution of conflict. The established groups treated conflict objectively as a task type conflict and worked toward creative solutions and “adopt[ed] procedures designed to bring about constructive resolution of differences” (Hall & Williams, 1966, p. 221). The tendency of the ad hoc groups was to view conflict “among strangers as having potential affective consequences which preempt the importance of the task (Hall & Williams, 1966, p. 221). “[A]d hoc groups were likely to resolve differences through compromise procedures whereas established groups responded with increased creativity” (Hall & Williams, 1966, p. 214).
In the software development industry, the dynamic nature of the work allows companies to form many project teams. The industry has a transient nature, developers are hired as contractors for projects because of specialized skills required. Project teams are constantly formed, reformed and disbanded. A technique for quickly transitioning a newly formed group (an aggregate of strangers) into a well established team has tremendous value in the industry.
Functional Conflict is Situational
It has long been held in management theories that some level of functional conflict is beneficial. Conflict is assumed to reduce the disfunction of group-think. Many organizations practice formal or informal devil’s advocacy. “When in conflict, people confront issues, learn to take different perspectives, and need to be creative” (De Dreu & Weingart, 2003, p. 741). In a meta-analysis De Dreu and Weingart (2003) contradict this long held view of task type conflict as beneficial. They studied both task conflict and relationship conflict as related to team performance. Relationship conflict and task conflict were found in the meta-analysis to “both have a moderate and negative correlation with team performance” (De Dreu & Weingart, 2003, p. 748).
Given the mixed results on task conflict and its correlation to positive performance it would be wise to keep a close watch on the levels of task conflict. Scrum allows the watchful Scrum Master the tools to empirically measure performance and task conflict. Scrum’s sprint retrospective is a great opportunity to gauge the task conflict of stories completed during the sprint. This can then be correlated with the team’s velocity. Allowing the Scrum Master the opportunity give feedback to the team about their task conflict’s impact upon velocity, and instruction upon self-regulation of this aspect.
Socialization
Forming a Scrum team is a team building exercise. Team building is largely a socialization function. During the formation stages of a team the members will undergo an adaptation process. The Marines call this process boot camp, where the new recruit’s level of commitment is challenged and the drill instructor molds the recruit. This indoctrination process is use by many organization to introduce the companies values and culture. Schein (2004) defines culture as: “A pattern of shared basic assumptions that the group learned as it solved its problems of external adaptation and internal integration, that has worked well enough to be considered valid and, therefore, to be taught to new members as the correct way you perceive, think, and feel in relation to those problems” (p. 17).
Contrary to Wall Streets common warning about stock performance, past performance is no indication of future performance; for people past performance appears to a great predictor of adoption of company culture, and future performance. Robbins and Judge (2009) describe a three-stage socialization process as: “prearrival”, “encounter”, and “metamorphosis” stages (p. 561-562). The prearrival stage recognizes that people arrive with expectations, attitudes and behaviors based in their past performances. This is why the selection process is so very important to company culture. The encounter stage is when the team member confronts the reality of the current situation and compares it against the expectations. Decision to conform, or to challenge the status quo, or perhaps opt-out by leaving the company are then made. Significant resources will be committed and expenses expended by the team to socialize the newcomer. This cost is often seen in teams adding individuals to increase capacity. In the worst case the addition of individuals overwhelms the team’s ability to absorb and socialize new members, which has been well described as the death march in The Mythical Man-Month (Brooks Jr, 1995). The metamorphosis stage describes the new team member’s process of resolving the major discrepancies in perspectives. The team and leadership can facilitate this process by providing formal and informal roles such as mentors and friendships. With the nature of dynamic teams in many businesses today, one could easily argue that the socialization process never ends. Van Maanen and Schein (1977) stated, “if one takes seriously the-notion that learning itself is a continuous and life-long process, the entire organizational career of an individual can be characterized as a socialization process (Schein, 1971a; Van Maanen, 1977a)” (p. 3).
Good Stories Lead to Culture
Employees learn the company culture through the stories, rituals and language (Robbins & Judge, 2009). “It is with language, metaphors, and stories designed through the language-in-use, that people, organizations, and countries become who they are. The conscious use of language as a component of development serves a vital function in setting the stage for change processes to be more effective and long lasting” (Ricketts & Seiling, 2003, p. 41). A common story is the Chicken and Pig story which has pervaded the Scrum community. Told to differentiate between roles in the development process and their commitment levels.
A chicken and a pig are together when the chicken says, "Let's start a restaurant!" The pig thinks it over and says, "What would we call this restaurant?" The chicken says, "Ham n' Eggs!" The pig says, "No thanks, I'd be committed, but you'd only be involved!” (Schwaber, 2009, p. 4).
Scrum teams use the notion of chickens and pigs to distinguish roles and use the labels to denote the rules of the Scrum meeting. Pigs are the Scrum team members, fully committed to delivering an increment of product during the iteration; whereas chickens are others who are interested in the project but are not actively engaged in production, such as management. Chickens are not allowed to speak in the Scrum meeting because they lack ‘skin in the game’.
Another common story involves the teams velocity. Velocity for a Scrum team is defined as the amount of work effort the team can perform to a set standard of completeness in a given time interval (sprint). Velocity is used in all levels of planning and in predicting project success. It can be accurately measured, but one part of velocity is effort estimates and therefore constitute imprecision in the aggregate measure. This is highly debated because it is a fundamental measure of team performance.
The scenario concerns how one would predict the weather with very little knowledge of meteorology. The typical response is that one would use yesterday’s weather as the best predictor of tomorrow’s weather. This meme becomes shorthand for an idea that there is value in consistency of performance and predicting future performance is best done based upon past performance. This adage is used by Scrum teams to suggest that the best predictor of next sprint’s velocity will be last sprint’s velocity.
The veteran Scrum Master will encourage the Agile culture that allows stories and rituals to pervade. “Stories in the workplace often underlie the implicit assumptions within the workplace community” (Ricketts & Seiling, 2003, p. 39). This jargon once assimilated by a new team member unites them in the organizational culture. Much of the stories and jargon will be learned on the job and does not need to be taught upfront to create the processes. However, this language helps to maintain the processes and the culture surrounding the team.
What About Trust?
For the newly forming team this culture will develop as the team is forming. The Scrum Master’s role is to optimize the process and enforce the rules, but also to foster a positive culture. “Three pillars uphold every implementation of empirical process control” (Schwaber, 2009, pp. 1-2). Scrum is an empirical process control framework and is therefore built upon these pillars; transparent processes, frequency of inspection, and ability to adapt (Schwaber, 2009). A culture must embrace these pillars and be willing to make changes. There are risk inherent in the dissonance associated with restricting the newly forming team’s right to self-organize with respect to the Scrum process. Trust that the team is capable of self-management must also be given to the team. One person to point this out is Tobias Mayer. In his response to the Shock Therapy article he wrote: “I fear the concept of hyper-productivity, represented by Shock Therapy, will run rough-shod over the essential human values of enjoyment and passion, and the empowering feeling of self-organization, fueled by trust” (Mayer, 2008, p. 1). Shock Therapy is not seen by all in the community as a positive method of building a team.
Zhou and George (2003) would argue that the effectiveness of Shock Therapy would depend greatly upon the leader’s emotional intelligence. There study of leader emotional intelligence recognizes the inevitable tensions, conflicts and debates in an organization attempting complex endeavors. Their findings reveal that employee creativity may be awakened via five routes described as: “identification, information gathering, idea generation, idea evaluation and modification, and idea implementation” (Zhou & George, 2003, p. 545). Based upon earlier work and the theory that some task type conflict may be beneficial to group behavior and performance. Their findings are that “leaders high on emotional intelligence will be able to sense this frustration and importantly to create favorable conditions to channel it into creative problem solving” (Zhou & George, 2003, p. 564). A Scrum Master with high emotional intelligence will serve the team well by facilitating creativity and positive moods.
Conclusion
Scrum is a framework for optimizing productivity of a software development team and reducing project risks. Team development requires time and energy, which cost businesses money. A technique of reducing startup cost for new Scrum teams is Shock Therapy. This technique restricts the Scrum team’s self-organization principle by imposing well defined rules for the Scrum process. Shock Therapy is a means to an end. Its use may stress the Agile values of trust in individuals and self organization. A competent leader (Scrum Master) with high emotional intelligence, skilled in team building, and well grounded in Agile philosophy will mitigate these risks. As the team progresses through the Tuckman stages of group development into the performing stage the Scrum Master will relinquish authority and the team will regain the abridged self-organization ability. The ability of leaders to guide teams to the performing stage quickly is one measure of leadership. A highly performing team creates self-worth for the team members and is a core value of software development companies.

Definition of Terms
Agile software development - A family of methodologies based on iterative and incremental adaptive development with lightweight process controls featuring highly collaborative environments with disciplined technical practices focusing on delivering frequently and embracing changing requirements.
Lightweight process - generalization of Agile processes; relative to highly formal processes or heavyweight processes.
Methodology - “a system of methods used in a particular area of study or activity” (Jewell, 2001).
Scrum - a lightweight process framework, based in empirical process control theory, which uses an iterative and incremental approach to “optimize predictability and control risk” (Schwaber, 2009, p. 1).
Scrum meeting - a short focused daily plaining meeting for the team, also called the standup meeting (because no one is allowed to sit).
Sprint - a time-boxed iterations of product development (typically one month or less).
Time-box - a fixed time duration in which a task is performed.
Velocity - the amount of work a Scrum team performs in one sprint (may be measured in unit-less value of story points).
Waterfall - a generic term applied to heavy-weight formal sequential phased development methods.
Yesterday’s weather - a meme in Agile terms relating to predicting future performance based upon past performance.

References
Brooks Jr, F. P. (1995). The mythical man-month (anniversary ed.). Addison-Wesley Longman Publishing Co., Inc. Boston, MA, USA.
De Dreu, C. K. W., & Weingart, L. R. (2003). Task versus relationship conflict, team performance, and team member satisfaction: A meta-analysis. Journal of Applied Psychology, 88(4), 741-749.
Hall, J., & Williams, M. S. (1966). A comparison of decision-making performances in established and ad hoc groups. Journal of Personality and Social Psychology, 3(2), 214-222.
Jewell (2001). The new oxford american dictionary (illustrated ed.). Oxford University Press.
Mayer (2008, September 15). Shock therapy... Or compassion? Agilethinking.Net blog [Web page]. Retrieved October 1, 2009, from http://agilethinking.net/blog/2008/09/15/shock-therapy-or-compassion/
Ricketts, M., & Seiling, J. G. (2003). Language, metaphors and stories: Catalysts for meaning making in organizations. Organization Development Journal, 21(4), 33-43.
Robbins, & Judge (2009). Organizational behavior . Upper Saddle River, N.J. : Pearson Prentice Hall.
Schein, E. H. (2004). Organizational culture and leadership. Jossey-Bass.
Schwaber (2009). Scrum guide. [Pamphlet]
Sutherland, Downey, & Granvik (2009). Shock therapy: A bootstrap for hyper-productive scrum. 2009 Agile Conference.
Sy, T., Côté, S., & Saavedra, R. (2005). The contagious leader: Impact of the leader's mood on the mood of group members, group affective tone, and group processes. Journal of Applied Psychology, 90(2), 295-305.
Van Maanen, J. E., & Schein, E. H. (1977). Toward a theory of organizational socialization.
Zhou, J., & George, J. M. (2003). Awakening employee creativity: The role of leader emotional intelligence. The Leadership Quarterly, 14(4-5), 545-568.

Proposal to Adopt Agile Development Methods

Wed, 14 Oct 2009 23:16:16 -0700

Proposal to Adopt Agile Development Methods
David Koontz
Chapman University College

Proposal to Adopt Agile Development Methods

Welcome to the Twenty First Century. We have amazing technology, a complex ecosystem of global industry, and a systems-thinking learning organization. However, we are using antiquated software development methods. Our home-grown methodology based upon a manufacturing model of large up-front detail designs, construction, then verification, and finally production is a phased or largely sequential software development process. This process does not work well for software - a very malleable product. Our project success rate of 32% is slightly better than the industry average of 28% (small companies) reported in the CHAOS Report (Johnson, 1995). However, if we continue to fail two-thirds of the time, we may find ourselves at the back of the pack, and possibly in the bankruptcy courts.
Agile software development is a family of methodologies based on iterative and incremental adaptive development with lightweight process controls featuring highly collaborative environments with disciplined technical practices. It focuses on delivering frequently and embracing changing requirements. Many more companies are adopting Agile software development practices. The trend is no longer a fad. The results of Agile Transformation are clearly higher productivity, greater product quality, greater business customer satisfaction, with equal or lower cost of development (Appendix A) (Ambler, 2008). The success rates of Agile teams exceed 80% (Ambler, 2008). This is a drastic change from one in three successful projects to four out of five project successes.
Vision
An Agile Culture
An Agile organization, at the company level or at the project team level would exhibit the values of the Agile Manifesto:
Manifesto for Agile Software Development
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools  Working software over comprehensive documentation  Customer collaboration over contract negotiation  Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more. (Beck et al., 2001/2001)
The 12 principles of the Agile Manifesto (Appendix B) could be used to assess the organization as it transitions into a more Agile organization.
Business cultural changes are notoriously difficult. It is one thing to pronounce that the company will adopt an Agile method or even that we wish to have an Agile philosophy; it will however be a completely different thing to manage a longterm transition toward those goals. One lens through which we may view radical changes of this nature is the Bridges Transition model. This model reminds us that changes may be as simple as announcing the goal. The transition, however, is more complex. The transition is the path of growth that will lead to the goal, “composed of (1) and ending, (2) a neutral zone, and (3) a new beginning” (Bridges, 2004, p. 4). Viewed through the lens of the Transition model the first phase is the ending. That would be the point at which the organization decided to change to an Agile organization, and announce the vision. To end the waterfall of phased development. The neutral zone is the gap between our old well known process and the new beginning when our new Agile processes are well known. A feeling that for a period of time the company may be lost, and misdirected, a feeling that may be greatly amplified as we learn and grow into this new organization and become the new company. Bridges (2004) notes that the neutral zone is a time of learning. The new beginning, is marked by the point at which we naturally start to think of ourselves as an Agile organization, not questioning if we are, but knowing that we are Agile. The beginning will mark new and unknown opportunities for the organization. The ability to quickly recognize market shifts and respond to changing requirements by delivering high quality applications and software services that meet customer’s current needs. Along with an ability to evolve our solutions as new needs arise. Responding to valuable feedback from customers and incorporating that into new features while rapidly delivering those solutions will make our company successful.
Behaviors of an Agile Organization
Delivering frequent customer value is the hallmark of an Agile company. To continually provide working software to our customers we must have processes that allow for last minute changes that add value. Development processes that embrace change, rather than resist change, are goals of an Agile organization; for life is the act of constant change.
Agile development practice allow for evolving designs rather than planning for static designs implemented in construction phases. Spending less time in up-front requirements gathering and specification elaboration phases requires trust. Trust that the team can and will turn a requirement, even poorly specified, into actual working software. Trust that the business will manage the resources well. Build the most valuable assets early, not wasting energy on bells and whistles that customers do not desire. Our development teams must collaborate with the business groups on a daily basis throughout the design. This will require commitments on both sides, as detailed plans will not be developed; therefore constant input and feedback must be part of the process. Mistakes must be allowed to happen, even encouraged, for it is in errors that we learn the most. Risk of large mistakes will be mitigated with short duration iterations (time-box) of design and development. The result of each iteration will be a functional product, demonstrated to the project stakeholders for evaluation and feedback. Adjustments will become the norm; adjustments in project scope, features, release plans, and timeframes. These adjustment may be as large as the cancelation of a project; but when successful these adjustments will be the minor corrections that one makes to navigate the highway while driving a car.
Leadership in an Agile Organization
Agile development requires that the management assemble a group, give the group some clear goals, support the group, negotiate with the group on all aspects of constraints, and then leave the group to self-organize, and allow the power of motivated individuals joining with other individuals into a team resolving and solving the problems required to achieve the goal. In these work groups leaders will emerge. Given clear concise goals the group will form into a team. A typical solution for team leadership and Agile process control is the Scrum framework. Scrum is a lightweight process framework, based in empirical process control theory, which uses an iterative and incremental approach to “optimize predictability and control risk” (Schwaber, 2009, p. 1). The Scrum framework defines only three roles for the process, a team of developers responsible for the product, a Product Owner ultimately responsible for the project return on investment (ROI), and a Scrum Master responsible for the process. Scrum is one of many Agile processes. It is recommended as the cornerstone of our Agile transformation because it is widely known, well defined, simple, and easy to learn. Although it may be considered very hard to master; like riding a wild mustang on the range, it requires constant attention to the nuances of the team, processes, and product. A Scrum Master may play a leadership role for the team, however there is no direct authority over the team members except for process authority. The Scrum Master will be a facilitator for the Scrum process teaching other team members, the Product Owner, and stakeholders their responsibilities and roles. The Scrum Master does not lead the team, they allow the team to develop its own leadership. Emergent leaders in self-directed teams have greater emotional connection with the group, and exhibit empathy for the context surrounding the group. This context allows emergent leaders greater effectiveness in directing group performance (Cohen & Bailey, 1997).
Scrum can be successfully applied outside of a software or product development environment. We may find upon a successful transition of the development practices that Scrum is a valuable tool in higher levels of our organization. Aspects of empirical process control with its emphasis on inspecting actual progress and adapting the next iteration to be incrementally better is inherent in organizational development methods also. Opportunities await us along the path to Agile Transformation.
The Feel of an Agile Organization
Our current perception of a world where technologies change so fast as to leave us all behind will change when we can keep pace with the industry. When we have made significant progress toward our goal of becoming an Agile software development group we should be capable of taking rapid advantage of emerging technologies. The strategic vision of transitioning our legacy products to a Service Oriented Architecture (SOA) will benefit from the ability to adapt to rapidly evolving standards in the new paradigm. The development teams will be capable of using new Web 2.0 techniques that allow our User Experience designers more freedom in user interface interaction delivering a richer experience to our customers.
Product design will become a richer collaborative process, using the broad skills of many team members across our diverse organization. A more cohesive, inclusive, and participatory product development environment should result in higher quality and insanely great products.
One principle of Agile is the sustainable pace. We need to maintain a development pace that does not require late-nights, weekends, and a “death march” (Brooks Jr, 1995) to production. With the addition of Agile skill sets from the Extreme Programing (XP) methods we expect developer job satisfaction to increase. The XP practices of Continuous Integration (CI), Test-Driven Development (TDD), and Pair Programming (PP) will change the nature of the daily work of the software development group. This will require training, coaching, and experience for our people. The physical space will also change. Working alone in a cubicle from specification documents written 16 months prior is a practice of past eras. A project team room that concentrates the software development group along with the product development group will increase just-in-time communication. Teamwork will build tacit knowledge of who knowns what details and problem solving skills. We will use techniques such as pair programming to build knowledge, skills, and abilities (KSA) within our Scrum teams. The use of TDD will create a suite of tests (a safety net) that provides value to the development team (including the embedded quality assurance specialist). Tests will prove that the product functions as desired. The CI system and the automated build system will allow push-button deployment of our products to System Test Servers. Allowing frequent (almost anytime) deployment of our SOA products allowing the Product Owner to quicken the return on investment (ROI).
Benefits
Dr. Dobb’s Journal article reporting on Scott Ambler’s Agile adoption and success rate survey (Feb. 2008) concluded: “In short, becoming more agile appears to be low-risk decision for senior IT management” (Ambler, 2008).
The Value Bottom Line
The value of a transition from our waterfall process to an Agile process will deliver both intrinsic values and extrinsic benefits. Our recent effort in Triple Bottom Line (TBL) accounting, summarized by SustainAbility’s “people, planet, profit” phrase, will resonate with Agile’s people-centric view of our human capital. A list of Agile’s intrinsic values are:
• Employee job satisfaction (motivation, sustainable pace, enjoyment)
• Humanistic values (trust in people and collaboration)
• Maximize project success rates (78% overall success rate; 83% co-located)
• Quicker time to market (releasable “barely sufficient” products)
• Reduction in the Cost of Change (less requirement defects, less bug fixes)
• Quicker time to project ROI (via more frequent release to production)
• Greater Productivity (82% of respondents perceived higher productivity)
• Higher Quality (77% of respondents perceived higher quality)
• Higher Stakeholder Satisfaction (78% of respondents perceived higher satisfaction)
• Lower Development Cost (37% of respondents perceived lower cost)
(Ambler, 2008, statistics from survey).
The extrinsic benefits will be realized as we transition to an Agile organization, these may include: customer loyalty due to great products, ease of recruiting due to improved work environment, status in the industry and the Agile community, etc.
Expected Results
The Agile transformation will require time and patience, as well as skilled coaching. It is expected that results in team work environments and project quality will be the first benefits to be realized. New Scrum teams learn quickly but must be given the opportunity to make and correct their own mistakes along the Agile path. At Yahoo Sutherland (2009) reports using a technique to jump start Scrum teams when “properly coached delivered 300-400% improvements” (p. 1). “The best Scrum teams in the world average 750% gains over the velocity of waterfall teams with much higher quality, customer satisfaction, and developer experience” (Sutherland, 2009, p. 1). A team at Jayway in Sweden “doing two week sprints achieved 375% of initial velocity in six sprints” (Sutherland, 2009, p. 4). Other benefits of Agile adoption will take longer to materialize, and largely depend upon the attitude of the company at large. “Scrum was institutionalized at Systematic over a period of approximately six months” (Jakobsen & Sutherland, 2009, p. 1). Systematic was found to be CMMI level-5 compliant in 2005, and adopted Scrum in 2006 (Jakobsen & Sutherland, 2009, p. 1). Many of the corporate level benefits are only seen in the later stages of complete transformation to an Agile corporation.
Consequences of Inaction
The status quo of failing projects after months and even years of development are in store for the long run, unless, we act to change. Some project are bound to fail, we take risk and judge the rewards worth the cost. However, even the Agile concept of a success when we fail fast, saving the cost of further investment in a poor idea, is a benefit that we do not currently have with our software development lifecycle. We must invest upwards of 80% of the total project cost before we can make go no-go decision based upon functional working software.
Action Plan
First Steps
Training is the first step after a decision by corporate management. We must all speak a common language regarding the Agile philosophy and lexicon. Scrum training is the easiest Agile training obtainable and is offered at reasonable cost for ad hoc attendance of two day seminars, or a Certified Scrum Trainer may be engaged to come on site. This would be considered initial training for key personnel and valuable for further organizational change development planning stages. Educating ourselves on the Agile values and methods and then developing our organizational change action plans within a Scrum model of inspecting and adapting will be a great experience for our management team. A further step will be to hire an Agile coach, a person to guide the organization, to mentor future Scrum Masters, Product Owners as well as Team Members. This person will be tasked with oversight of the change initiative, and report to the VP of Product Development.
The Map is Not the Terrain
In the Robert DeNiro film “Ronin”, DeNiro's character Sam expresses the need to actually see the place, to physically be in the space: “The map, the map, the map. The map is not the terrain.” An action plan is not the Agile path we will traverse. Dwight D. Eisenhower said, “The plan is useless; it’s the planning that’s important.”
Kurt Lewin’s Action Research model of organizational development and change will be to overarching approach. It meshes well with the Scrum framework. Action Research is a cyclic process model facilitated by an Organizational Development (OD) Practitioner, which relies heavily upon the collaboration of a client group (transformation team) for exploration of data, problem space diagnosis, action planning, implementation, evaluation of interventions, and further cycles of planning, actions, and post action assessment (Jackson, 2006).
In the cyclic process of Action Research we have reached step (3) preliminary diagnosis. A problem has been perceived (step 1), and collaboration with an OD practitioner (step 2) has commenced. The preliminary diagnosis (step 3) is to institute an Agile transformation of the software development group. With a possible larger transformation of the company as an organization in the future. The future steps are: (4) gather data from the transformation team, (5) data feedback to the team, (6) team exploration of data and problem domain, (7) team action planning, (8) team takes action, (9) post action evaluation and data gathering, (10) new action planning by team, (11) new action taken by team, (12) post action assessment, then a repeating of the cycle (Jackson, 2006, p. 140). However, let us take first steps first. The Scrum training of key personnel would be the preliminary recommendation of an action. The transformation team and executive management should take this proposal under consideration and decide if this is the proper course of action. In other words, will they commit the company to this Agile course of action? Knowing full well that our plans may need to be adjusted, and being responsible for evaluation of the action, and any future adjustments necessary.
Resonance with Organization Development Theories
The cultural change that an Agile transformation requires may be analyzed via Force Field Analysis. “In planning for change, it is advantageous to identify those conditions that will help or hinder the change initiative” (Jackson, 2006, p. 145). The transformation team may use this tool to identify the driving and restraining forces for the Agile transformation initiative. After identifying all forces both pro and con the forces are assigned relative weights (or points). The weights allow some subjective measure of the effort the force applies to the current situation (status quo). Analyzing these forces the team will try to strengthening the driving forces while weakening the restraining forces, and possibly devising strategies to flip a force from restraining to driving. This will allow the team to identify impediments to the initiative and seek management support in removing the impediments (a role of the Scrum Master).
Action Research Becomes Scrum
The team members trained in Scrum will recognize may of the aspects of Organizational Development methods such as Action Research. Scrum and many of the Agile processes draw on years of research and studies of team dynamics, process workflow, continuous improvement, systems-thinking, and organizational learning (Sutherland, 2004). Scrum uses very small iterations and feedback loops on many levels to plan work over a short duration, inspect the progress of the work done, to expressly define the standards of completed work, and to reflect upon the work, processes, and techniques to constantly improve and move forward.
Methods to Facilitate Transition
Many Agile development groups have embraced more humanistic values for work, attempting to capitalize on knowledge workers innate desire to enjoy their work and their internal motivation. Herzberg’s Two-factor theory is applicable to this situation. Also referred to as the Motivation-hygiene theory, it describes the factors that lead to worker satisfaction (motivators) and factors that lead to dissatisfaction (hygiene) if not attended to well. Herzberg concluded that the satisfaction scale was not a single continuum. The factors that lead to dissatisfaction (work conditions, salary, relationships, supervision) when poorly managed, did not lead to satisfaction when expertly managed. There are very different factors that lead to satisfaction. These motivating factors are: growth, advancement, responsibility, recognition, achievement, and work itself (Robbins & Judge, 2009). Agile methods support these motivational factors in the work place. Additionally many Agile teams use Appreciative Inquiry during retrospectives. Appreciative Inquiry “seeks to identify the unique qualities and special strengths of an organization, which can then be built on to improve performance. That is, it focuses on an organization’s successes rather than on its problems” (Robbins & Judge, 2009, p. 632). Scrum requires a team retrospective each sprint (iteration), this is a process inspection and a chance for adaption. Using Appreciative Inquiry builds on teams ability to learn and improve, recognizing that perfect execution may be a goal, but rarely attainable on the first several attempts.
Organizational Change was studied by Kotter, who developed an eight step change model largely from the failures of companies engaged in change initiatives. “A few of these corporate change efforts have been very successful. A few have been utter failures. Most fall somewhere in between, with a distinct tilt toward the lower end of the scale” (Kotter, 2007, p. 96). Kotter’s recommendation are: “(1) Establish a sense of urgency; (2) Create the guiding coalition; (3) Develop a vision and strategy; (4) Communicate the change vision; (5) Empower broad-based action; (6) Create short-term wins; (7) Consolidate gains and produce more change; (8) Anchor new approaches in the culture - make it stick” (Jackson, 2006, pp. 166-167). Kotter (2007) warns that skipping steps or not given proper attention to a step is the typically mistake made by failing corporations. There are valuable lessons to learn from these mistakes.
Recognizing Success - Metrics
Scrum uses very simple tools for measuring iteration success. These metrics are the Scrum task board with task to be done, the in-process task, and the done task. The task board will be the center of activity during stand-up meetings each morning. A quick look at the board allows everyone to see progress being made and the work remaining during the sprint. It is the Scrum team’s job to manage this and radiate the information to all. Another information radiator is the release burn-down chart showing the completed work and remaining work required for a product release. The physical changes in Agile adoptions will be easy to recognize. These will be groups of strangers forming teams, teamwork and group discussions, “big visible charts” used as information radiators (burn-down chart), stand-up meetings, product demonstration, application test suite pass/fail monitors, project build charts, broken build email notifications, the list goes on and on. One specific example; on some teams the engineers wire-in a flashing red light to the build machine, if a build fails the flashing light alerts everyone in the room. Quick action by the developer that broke the build by committing the defective code is the result. This “stop the line” behavior will become obvious to management that takes the time to understand the Agile process.
Agility of our development organization may be measured by several instruments. Cautions using these instruments should be used as they are not as well studied as may psychometric test such as IQ test or Myers-Briggs Type Indicator for example. The simple 10 question Nokia Test is one example. “The Nokia test is a similar to a maintenance check on your car. It looks at whether your tires have air, your tank has gas, all cylinders are firing, and makes sure there are no critical missing pieces to your car. You should perform it before you go out for a drive with your Scrum team” (Sutherland, 2009). A more comprehensive measure that allows organizations to perform longitudinal studies of improvement in Agility is the Comparative Agility™ survey by Cohn and Rubin (2008). This survey is available free of charge on the web (http://www.comparativeagility.com/). However, it has not been studied for reliability and validity. Of course, the Action Research transformation team will evaluate every intervention, and use any instrument that is deemed appropriate.
More subtle successes will be rates of project success, measured over much longer periods of time. Greater return on investment for projects, as well as quicker cost recovery and lower investment cost. These will come after Agile process are in place and the corporation begins to take advantage of Agile’s many secondary benefits. The measures will be typical business metrics already in place at our company.
Challenges
Agile transformations do not happen overnight. They are not without trials and tribulations. In a systems-thinking view of our organization a change in the development process will ripple outward effecting other departments. Scrum does not offer to fix our problems, it is no silver-bullet. A core value of Scrum is transparency. “Transparency ensures that aspects of the process that affect the outcome must be visible to those managing the outcomes” (Schwaber, 2009, p. 1). We will not be able to solve problems of which we do not have knowledge. We must trust others motivates when they raise issues and collaborate on solutions. Our Agile coaches will have faced many of the issues our transformation will conjure up, some may be unique to our organization. An Agile philosophy is that making decisions and then monitoring the outcome, even if a mistake, is much better than postponing the decision past the last responsible moment.
Many Agile adoptions start with pilot projects and with tentative steps toward half measures. These attempts have been labeled “Scrumbut” processes. Agile practices work as an orchestra producing a symphony, to remove one section of the orchestra will mute a portion of the symphony. The expected results will not be achieved with half measures.
Cost for Certified Scrum Master training is $18,000 (plus expenses) for up to 20 participants on site. Agile coaches salaries are approximately $130,000. We may lose some employees who do not wish to transition to Agile work methods. There are also indirect cost associated with every change. Infrastructure cost will be incurred to retrofit our software development work bay of cubicles into team rooms with modern pairing stations and a more flexible organic work space. Details will be studied by the transformation team and evaluated when the time comes for those decision.
Conclusion
Change is the nature of our business. If we do not change our business methods and adjust then change will be force upon us. Adopting an Agile stance will allow us to change with the industry, to seize opportunities before challengers, and to outperform competitors. It will provide for a people-centric development practice, that is at our companies core beliefs. Many other companies have seen higher productivity, higher quality, greater job-satisfaction and overall cost reduced using Agile methods.
The first step towards this cultural transformation is for the Executive Management Team to approve this proposal, to join the Agile community, to communicate the new vision, and begin the transformation into an Agile organization.

Appendix A. Agile Adoptions Rate Survey Results
Agile Adoption Rate Survey Results (February 2008) published in “Has Agile Peaked?” Dr. Dobb’s Journal (June 2008) by Scott Ambler: (http://www.ambysoft.com/surveys/agileFebruary2008.html used with permission).

Appendix B. Principles of Agile Manifesto
• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
• Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
• Business people and developers must work together daily throughout the project.
• Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
• The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
• Working software is the primary measure of progress.
• Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
• Continuous attention to technical excellence and good design enhances agility.
• Simplicity--the art of maximizing the amount of work not done--is essential.
• The best architectures, requirements, and designs emerge from self-organizing teams.
• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
(Beck et al., 2001/2001)

Appendix C. Definition of Terms
Agile software development - A family of methodologies based on iterative and incremental adaptive development with lightweight process controls featuring highly collaborative environments with disciplined technical practices focusing on delivering frequently and embracing changing requirements.
Burn-down chart - a information radiator depicting the progress made toward a goal.
CMMI - Carnegie Mellon, Software Engineering Institute’s Capability Maturity Model Integration - a measure of process maturity (5 being the highest level).
Lightweight process - generalization of Agile processes; relative to highly formal processes or heavyweight processes.
Methodology - “a system of methods used in a particular area of study or activity” (Jewell, 2001).
Product Owner - a role on the Scrum team responsible for prioritizing the work to be done, to optimize the return on investment.
Scrum - a lightweight process framework, based in empirical process control theory, which uses an iterative and incremental approach to “optimize predictability and control risk” (Schwaber, 2009, p. 1).
Scrum Master - a role on the Scrum team responsible for optimize the process and productivity.
Scrum meeting - a short focused daily plaining meeting for the team, also called the standup meeting (because no one is allowed to sit).
Sprint - a time-boxed iterations of product development (typically one month or less).
Time-box - a fixed time duration in which a task is performed.
Velocity - the amount of work a Scrum team performs in one sprint (may be measured in unit-less value of story points).
Waterfall - a generic term applied to heavy-weight formal sequential phased development methods.

References
Ambler, S. W. (2008). Has agile peaked. Dr. Dobbs Journal: The World of Software Development, 3(6), 52-54.
Beck, Beedle, Bennekum, Cockburn, Cunningham, Fowler, et al. (2001). Manifesto for agile software development. Retrieved november [Web page]. (Original work published 2001)
Bridges, W. 1. (2004). Transitions : Making sense of life's changes . Cambridge, MA : Da Capo Press.
Brooks Jr, F. P. (1995). The mythical man-month (anniversary ed.). Addison-Wesley Longman Publishing Co., Inc. Boston, MA, USA.
Cohen, S. G., & Bailey, D. E. (1997). What makes teams work: Group effectiveness research from the shop floor to the executive suite. Journal of Management, 23(3), 239.
Cohn, & Rubin (2008). Comparative agility survey. [Web page]
Jackson, J. C. (2006). Organization development : The human and social dynamics of organizational change (illustrated ed.). Lanham, MD : University Press of America.
Jakobsen, C., & Sutherland, J. (2009). Scrum and cmmi--going from good to great: Are you ready-ready to be done-done?. Agile 2009.
Jewell (2001). The new oxford american dictionary (illustrated ed.). Oxford University Press.
Johnson (1995). The CHAOS report (1994). Standish Group. Retrieved September 24, 2009, from http://www.standishgroup.com/sample_research/chaos_1994_4.php
Kotter, J. (2007). Leading change: Why transformation efforts fail. Harv Bus Rev, 96-127.
Robbins, & Judge (2009). Organizational behavior . Upper Saddle River, N.J. : Pearson Prentice Hall.
Schwaber (2009). Scrum guide. [Pamphlet]
Sutherland (2009, August 25). Nokia test: Where did it come from? Scrum log (Jeff Sutherland's Blog) [Web page].
Sutherland, J. (2004). Agile development: Lessons learned from the first scrum. Cutter Agile Project Management Advisory Service, 5(20).

Apple - Innovation is Key

Fri, 31 Jul 2009 22:58:12 -0700

Apple-Innovation is the Key

David Koontz, Sumalee Mahaguna, Daniel Stiles

Chapman University

OLCU 602

Organizations have many distinguishing factors that make them successful in their field. However, one factor that is apparent in great organizations is vision. Organizational vision is necessary for an organization to be successful because creative energy begins with vision. Creative tension is the driving force which organizations use to make their vision a reality. “Visionary companies are premier institutions…in their industries, widely admired by their peers and having a long rack record of making a significant impact on the world around them” (Collins & Porras, 2004, p. 2). According to Peter Senge author of the Fifth Discipline, vision is distinct from purpose. Purpose is abstract, leading towards a general heading whereas vision is a specific heading that is concrete (Senge, 2006). Apple is a visionary organization that has a clear vision and purpose that can be seen through their innovative products over the years. Apple’s original vision was, “to make computers for the rest of us,” while their purpose is, “to make a contribution to the world by making tools for the mind that advance humankind” (Collins & Porras, 1991, p. 39). A purpose without a vision prevents forward mobility in an organization. Conversely, a vision without a purpose is also futile; they go hand in hand.
Besides having a vision and a purpose, organizations need to take further steps to implement their corporate vision and ensure that this plan of action is known and practiced throughout the organization. John Kotter, a professor at Harvard Business School and author of the book Leading Change list eight important steps for change. The eight steps for organization change parallels the steps needed to implement vision within and organization. These steps include: establishing a sense of urgency, forming a powerful coalition, creating a vision, communicating the vision, empowering others to act on the vision, planning for and creating short term wins, consolidating improvements and still more change, and institutionalizing new approaches (Kotter, 2007). Since the initial start of the organization, Apple has had both successes and failures in the implementation of their visions while striving to fulfill their purpose, creating tools for the mind to advance humankind.
Establishing a Sense of Urgency
In Kotter’s model for transforming an organization, the top priority for establishing a powerful “sense of urgency”, Kotter notes that many companies start to change when someone or some group in the company sees the impending doom of a market position, or competitive opportunities. This type of opportunity was seen by Steve Jobs when Apple was founded in 1976. The cofounder of Apple Steve Wozniak said, “It never crossed my mind to sell computers. It was Steve who said, ‘let’s hold them up in the air and sell a few’” (Westley & Mintzburg, 1989, p. 25). This insight resulted in the personal computer industry (Jackson, Mandeville, & Potts, 2002, p. 328). The mainframe computer manufactures of the day did not see a need for a home computer. Prior to Apple’s home built kit Apple I computer, the industry for personal computer did not exist (Jackson, Mandeville, & Potts, 2002, p. 326-327).
During Apple’s thirty years of existence, Steve Jobs has established several changes because of competitive opportunities. In the 1980s Macintosh development era, Jobs created a race to market. The Lisa team had started work on their product years before the Macintosh team had started their project. Steve Jobs made a bet that his team which featured the Macintosh would be the first to market. Unfortunately, Jobs lost the bet; the Lisa did launch before the Macintosh. However, Jobs was the true winner because the Macintosh won the longer race in the market place.
In the decade (1987-1997) without Steve Jobs leadership, Apple continually lost market share and failed to execute a clear product vision under the direction of CEO Sculley (West, 2007, p. 7). Apple culture was out of Sculley’s control. Apple was able to regain their footing on the path to creating “insanely great” products (West & Mace, 2007, p. 6) upon the return of Steve Jobs in 1997. Jobs reasserted his leadership in many areas and the first thing he did upon his return to Apple was announced a deal with Microsoft who invested $150 million in Apple stocks (Kawamoto, et al. 1997). This move shocked the industry.
Forming a Powerful Guiding Coalition
Apple’s internal coalition of executives and leaders are much harder to ascertain; the company is known for its secrecy. Certainly, tight groups of people have formed around the various shared visions of products. Early on, Jobs “organized Apple office as a circle of work areas around a central foyer. There stood a grand piano and a BMW. ‘I believe people get ideas from seeing great products,’” Jobs claimed (Wise, 1984, p 146; Westley, 1989, p. 20). Apple may have been one of the first companies to use evangelism marketing. This ability of the company to enroll and develop a very strong relationship with customers is another form of coalition building where Apple has excelled. Customers become voluntary representatives of the company, advocating for the products and services, an early form of viral marketing (Apple Evangelist, 2008).
Apples success in creating a coalition of business partners has been questioned by many and recognized as a short coming by Jobs. In a joint interview with Bill Gates, Jobs said, “Because Woz and I started the company based on doing the whole banana, we weren’t so good at partnering with people” (Gates, et al., 2007, p. 25). Jobs had recognized that Microsoft’s success was partly contributed to the coalition they were able to foster. Microsoft is Apple’s longest running successful partnership. The two companies worked together in the early days of Applesoft BASIC built into the Apple II which was credited with making the computer successful (Linzmayedr, 1999, p. 15). Notably, they have been rivals in the eyes of many; however, the Macintosh platform was a large portion of Microsoft’s revenue (Linzmayer, 1999, p. 239).
A holy grail for the telecommunication industry for the last 20 years has been “convergence of communication and computing” (West, 2007, p. 10). Apple CEO John Sculley was a big proponent of convergence and championed the Newton MessagePad, creating the niche market for the personal digital assistant (PDA) (West, 2007). Although Steve Jobs terminated the Newton product upon his return to Apple in 1997, Apple was learning to partner with other companies. In the last decade, Apple has worked successfully with the music industry on iTunes store and digital rights management for songs. They have also established partnerships with telecommunication companies worldwide to market the iPhone in over 90 countries (Apple, 2009). Apple has learned to join and build communities for its products that foster organizational mission.
Creating a Vision
Apple was created on a vision that Steve Jobs, Steve Wozniak had in 1976 in a garage. Their vision was to create computers that the average consumer could use without possessing the technical knowledge or skills. Computers at the time were only limited to a certain market niche and the average homemaker or sales clerk were not a part of this niche. Apple founders saw that their technology could bring enrichment into the lives of people. These computers would be affordable yet different enough to stand apart from all the other computers sold on the market. The idea was to have an “Apple computer on every desk” (Ditlea, 1981, p. 1). This idea became the foundation for which their vision was built upon. Their vision was extremely radical compared to the other computer companies at the time. As radical as their ideas may seemed, their vision attracted many other computer enthusiast into their business and completely set them apart.
Having a vision is extremely important to the success of an organization because without it, there is nothing pulling the organization forward. “Vision is a specific destination, a picture of a desired future” (Senge, 2006, p. 138). The organization was founded on a vision and this vision propelled the founders to continually innovate computers. Initially, their vision was quite simple, to make computers that everyone can use. Their vision has evolved over the years to communicate an even greater need to change the world through their innovation. This desire lead to establishing purpose for their existence and that is “to make a contribution to the world by making tools for the mind that advance humankind” (Collins & Porras, 1991, p. 39). Apple felt that they had more to contribute to society than just computers. They have expanded their technology into the music industry and the phone industry. In a special review by Business Week, Steve Jobs made a statement saying, “We have just begun” (Business Week, 2000, p.1) as a prelude to his plans for the future.
Communicating the Vision
Apple started life as a business, not as a company. The gradual change from a bloated garage operation into something resembling a corporation was arduous and protracted (Moritz, 1984). What was even more arduous than the transformation was the communication of the founder’s vision to the rest of the organization. Originally, the idea of creating computers that a normal person would be able to use was the driving force behind the organization. Apple employees had strong feelings about this because it set Apple apart from the other computer companies. They were even successful in recruiting employees from various companies such as Intel, National Semiconductor, and Hewlett Packard (Moritz, 1984). These employees readily resigned from their current position at these various organizations for Apple because they saw that Apple had something different to offer.
Initially, communicating the vision to other Apple employees was not hard because the organization was founded on a vision. However, as more people flocked to Apple, the harder it became to communicate this vision. The glue that once held the organization together began to fall apart as the company grew at an exponential rate and the vision was lost amongst the new faces that continually showed up on a daily basis. Hiring from other organizations also brought discontinuity into the organization because employees from IBM or Hewlett Packard would bring culture from these various organizations that were not compatible with Apple. Eventually, Apple’s success became their enemy and Apple found themselves operating similarly to organizations such as IBM. This was something they tried extremely hard to avoid but with so many people working in the organization, bureaucracy was the only way to manage everyone. “By 1980 the company was too large and too scattered for any one manager to cover on a daily stroll to take the air and test the waters. So for most of the employees, the corporate hand was invisible” (Moritz, 1984, p. 257). Apple tried limiting some of these discontinuity within the organization by establishing a committee whose main purpose was to “reduce the abstract into the concrete and codify all the conflicting impulses and intentions, the clashes between individual enterprise and teamwork, between autocracy and democracy, that make up a company” (Moritz, 1984, p. 257). The committee set out to turn the company around which included the culture and the working environment. The idea was to get the organization into an alignment in order to start working cohesively again. One of the methods used to reach alignment was to reestablish their cultural values throughout the organization.
There was no doubt that Apple employees were employed because of their passion for computers so Apple founders found that the best way to communicate this value was thought their products. Apple started a new policy for their office procedures. No more typewriters were to be purchased or leased and the existing ones were banished. Apple believed that before they could communicate their vision to the public, they should fully believe in their products first by utilizing it in the workplace. Shortly after Apple did away with typewriters, the term secretary was also abolished to reflect the varied responsibilities that could be accomplished by the personal computer. The term area associate took the place of secretary. Apple also started a program that gave Apple employees their own personal computer once they had demonstrated minimal efficiency. They also offered classes for family members and large discounts to friends and family members. Apple founders wanted the work place to be more than just a place to come to, do what you had to do, then go home. He wanted the work place to be a place where people could innovate and have the freedom to do more rewarding and enriching tasks.
Empowering Others to Act on the Vision
The Macintosh group was formed to examine the feasibility of developing an extremely low cost computer for the public. Steve Jobs took over the program and “was determined to build a computer that was in his words, ‘insanely great’” (Nonaka & Kenney, 1991, p. 75). Early on, the Macintosh team did not have an exact idea of what the computer would be like and were not given a development schedule. An engineer in the project said that, “Steve allowed us to crystallize the problem and solution simultaneously” (Nonaka & Kenney, 1991, p. 75). Jobs and his predecessor as group leader “set out only basic principles; it was the personnel of the team who would concretize these. “The Mac team was self organizing” (Nonaka & Kenney, 1991, p. 76), they were empowered to innovate.
Another example of empowerment of their employees is the loan to own program. Apple offered employees voluntary classes on their computer applications. When an employee demonstrates proficiency in at least two applications, they can then participate in a loan to own program. An Apple personal computer is given to the employee to use at home after one year, it is given to them free of charge. The employee is thus better skilled at work, and it helps to promote the vision of computer for everybody.
Planning for and Creating Short Term Wins
One of Apple’s significant achievements has been “the implementation of the office workplace of tomorrow” (Ditlea, 1981, p. 3). Apple “inaugurated the workplace of the future by putting computers on most of its employee’s desks” (Ditlea, 1981, p. 1). Mike Scott, Apple president at the time said, “Apple is an innovative company. We must believe and lead in all areas. If word processing is so neat then let’s all use it. We believe the typewriter is obsolete. Let’s prove it inside before we try and convince our customers” (Ditlea, 1981, p. 1). This internal move increased employees effectiveness, improved job satisfaction, and led to very little turnover. It freed managers from doing mundane and time consuming paperwork tasks. This newly available time allowed them to coach employees leading to a much improve workplace atmosphere.
In this case, Apple was able to lay the foundation for the realization of a long term goal and vision of having the general public use their computers. They were able to start it on a small scale with a short term goal for their own employees. As a result, some of the lowest level employees were able to begin contributing on a higher level. Steve Jobs stated, “Not only do our area associates (secretaries) have the freedom to do more rewarding, enriching tasks, they have a chance to get involved in solving problems that ultimately affect the success of the entire company” (Ditlea, 1981, p. 2). Apple created a long term external winning situation for itself with consumers by creating a short term internal winning situation with their employees.
Consolidating Improvements and Producing Still More Change
The computer industry has inherently understood and acted upon this aspect of Kotter’s model. Much of the industries success and blinding pace of improvements are attributable to the ability of a company to make refinements to their products, building faster, and more powerful computers. In building these superior computers, the company may change the nature of its core business. Many companies of the past have failed to manage the transition from the mainframe era to the personal computer era (e.g. Burroughs, Control Data, Data General, Digital Equipment, Sperry-Univac, Wang) (Jackson, et al., 2002, p. 330). The companies that have excelled at keeping pace with these changes are some of the fastest growing companies in history (e.g. Apple, Dell, Cisco, Microsoft, Oracle) (Jackson, 2002, p 330). Many of the companies that have failed did not understand the shifting dynamics of the industry and clung to outdated paradigms. “Paradigms are a source of both strength and weakness- strength in that they tend to reinforce successful patterns of behavior, and weakness for the same reason” (Jackson, et al., 2002, p. 331).
Apple’s ability to change paradigms as an industry leader is obvious in the history of the short lived personal computer industry. Apple created the personal computer industry; then they innovated the graphical user interface (GUI). Adopted by the industry the GUI, innovated the desktop and file folder metaphor that has predominated the industry. Apple is now innovating appliance model in computing products that integrate vertically from device to network to content. The iPod and iPhone product lines are examples of Apple’s ability to envision a paradigm change, put that vision into action and achieve game changing results. Kotter’s seventh step is evidenced by “using increased credibility to change systems, structures, and policies that don’t fit the vision” (Kotter, 2007, p. 7). Apple has used its very successful music industry changing iPod product line with iTunes music store credibility to also change the smart phone application market, achieving 1.5 billion downloads in the first year of App Store operation (Elmer-DeWitt, 2009). Apple has used the “core competencies that the company has acquired over its thirty year history, notably in product marketing and innovation” to redefine market segments (West, 2007, p. 24). On the success of the iPod and iTunes music store, Apple launched its iPhone, creating the most successful convergence device. The iPhone has proven that Apple can both consolidate their core competencies while continuing to innovate.
Institutionalizing New Approaches
In Kotter’s eight step model, Apple’s ability to articulate the connections between the behaviors that have lead to corporate success are apparent in one word, innovation (Kotter, 2007). Kotter is concerned that the corporate vision be institutionalized as opposed to being carried by a leader. Apple’s vision is to create products that enhance people’s lives and make the use of computers in all their forms easy, intuitive, with a seamless coherent experience. The recent success of the iPod in the music player market space is an example of the execution of this vision. Apple recognized that the music player market was a disjointed experience for the consumer. They built a music player device that used Apple’s core competencies in computer, networking, product design and user experience. They partnered with the music industry creating coalitions that learned a new method for product delivery, drastically changing the music industry. This is an example of one product line that fulfills the vision of Apple’s purpose may appear to be a fluke. However, each of these Apple products were innovations that changed the industry: Apple I computer, Apple II computer, Macintosh, iMac, iPod, and most recently, the iPhone. Apple has proven that it is capable of changing the institutions that it deals with externally while adapting to the required business processes and organizational change that paradigm shifts require.
Over the past thirty years, Apple has met with many successes and failures. They have proven time after time that they are able to overcome challenges and rise above any disparities that may come their way. Apple was built on a vision, yet vision alone is not enough for organizational growth or success. An organization needs to be able to communicate their vision throughout the company and they need to empower their employees to act on this vision in order to make it a reality. In order for organizations to achieve their vision, they have to be receptive to change and provide an environment that promotes change; only then can an organization grow. John Kotter’s eight step model for change outlines the way Apple implements their vision throughout the organization.
When Apple saw the opportunity in the market place for personal computers, they established a sense of urgency. Initially, Apple did not have strong coalition in the organization but soon learned that in order to survive, they needed to form a coalition and of the biggest step they took was by partnering with Microsoft. Creating a vision is the third step in the model but Apple already had a vision. Communicating this vision was a harder task for the organization because it was growing so fast, but in the end, they were able to do this by redefining values. Apple empowered their employees by allowing them to partake in decisions that could ultimately affect the success of the company. Apple also empowered their employees to innovate and do more fulfilling tasks by providing them with their own computers. This was also a big step towards creating short term wins. Before Apple could sell computers that were supposed to improve lifestyles, they had to believe it themselves so they provided their employees with free computers and classes. Apple is continually consolidating improvements and implementing more change because the market is always changing. An organization that wants to survive needs to be able to keep up with these changes and they need to keep making improvements. Institutionalizing new approaches is the last step in Kotter’s model and Apple is continually experimenting with new approaches. They have mastered the personal computer industry only to move into the music industry and then to communications. Apple’s ability to implement their vision, innovate, and adapt to change makes them a true visionary organization.

References
Apple. (2009). IPhone around the world. Retrieved July 15, 2009 from http://www.apple.com/asia/iphone/countries/
Apple Evangelist. (2008, December 16). In Wikipedia: The Free Encyclopedia. Retrieved July 11, 2009, from
http://en.wikipedia.org/w/index/php?title=Apple_evangelist&oldid=258267587
Business Week. (2000, September 25). Apple’s steve jobs: Our vision is we have just begun. Retrieved July 22, 2009, from http://www.businessweek.com/2000/00_39b3700122html
Collins, J., & Porras, J.I. (1991). Organizational vision and visionary organizations. California Management Review. 30-52. Retrieved July 22, 2009, from Business Source Premier database.
Collins, J., & Porras, J.I. (2004). Built to last: Successful habits of visionary companies. New York: HarperCollins.
Ditlea, S. (1981). An apple on every desk. Inc. Magazine. Retrieved July 22, 2009, from http://www.inc.com/magazine/19811001/20033
Elmer-DeWitt, P. (2009). CNNMoney.com Apple 2.0 How Apple’s App Store got to 1.5 billion downloads. Retrieved July 14, 2009, from http://apple20.blogs.fortune.cnn.com/2009/07/14/how-app-store-got-to-1-5-billion downloads/
Jackson, M., Mandeville, T., & Potts, J. (2002). The evolution of the digital computation industry. Prometheus, 20(4), 323-336.
Kawamoto, D., Hesket, B., & Ricciuti, M. (1997). Microsoft to invest $150 million in Apple. CNET New, August 6, 1997. Retrieved July 11, 2009, from http://news.cnet.com/2100 1001-202143.html
Kotter, J. (2007). Leading Change. Harvard Business Review, 85(1), 96-103. Retrieved July 11, 2009 from Business Source Premier database.
Linzmayer, O.W. (1999). Apple confidential: The real story of apple computer, inc. No Starch Press. Retrieved July 9, 2009 from http://www.eziozi.co.uk/Downloads/Media/Dox/Apple_Conficential_Extracts/The_Forg tten_Founder.pdf
Moritz, M. (1984). The little kingdom: The private story of apple computer. New York: William Morrow and Company.
Nonaka, I., & Kenney, M. (1991). Towards a new theory of innovation management: A case study comparing canon, inc. and apple computer, inc. Journal of Engineering and Technology Management, 8, 67-83.
Senge, P.M. (2006). The fifth discipline: The art and practice of learning organization. New York: Doubleday.
Swisher, K. & Mossberg, W. (2007). Transcription of Interview: Steve Jobs and Bill Gates. D5 Conference. All Things Digital. New York: Ubiqus Reporting Inc.
West, J., Mace, M. (2007). Entering a mature industry though innovations: Apple’s iphone strategy. DRUID Summer Conference. Copenhagen.
Westley, F., & Mintzberg, H. (1989). Visionary leadership and strategic management. Strategic Management Journal, 10, 17-32.