case study 1 54 A+ Writers |

You will read the assigned case discussion at the end of the chapter and use the questions as a guideline for each submission. All case studies should include an introductory and concluding paragraph, as well as headings. All Case Studies should include an introductory and concluding paragraph, as well as headings. All Case Studies should include a biblical perspective with scripture included relevant to the topics covered in the Case Study scenario. Case Studies 1, will be in current APA format, 4–5 pages in length, not including the cover, abstract, or reference pages.


Read “Blue Cloud Gets Agile,” and prepare answers to the following questions:

  1. What was the trigger event that led Shel Skinner to adopt Agile?
  2. What is your evaluation of the change implementation steps followed by Skinner?
  3. What behavioral changes, if any, does Agile require of employees?
  4. How do you account for such widely varied responses to Agile among Blue Cloud employees?
  5. What should Skinner do now?

Blue Cloud Gets Agile

After attending a conference on a new methodology for software development known as Agile, Shel Skinner, CEO of Blue Cloud Development, a small software development company located in Mountain View, California, hired consultants to introduce the methodology.

At its core, Agile emphasized multiple iterations and short time frames. Created by a group of software developers, the Agile Manifesto (2001) declared:

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

In addition, Agile held 12 principles:

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

“These principles spoke to me on a very fundamental level,” said Skinner. “These folks were saying out loud for what I’d been thinking most of my career.”

Blue Cloud’s traditional developmental cycle emphasized a deliberate sequence of development, with verification (testing and debugging) often occurring after a year’s worth of work. “Why waste a year to find out whether our product is working,” Skinner wondered. No more alpha and beta testing of new software: “Our new motto around here is, ‘Release early, release often!’ ”

What appealed to Skinner was Agile’s emphasis on teamwork, collaboration, and monthly releases. Cross‐functional development teams held a daily “scrum” to ensure that all members were fully onboard with the progress and that all questions and concerns were raised in a timely manner. Skinner provided a description of the Scrum:25

Scrum is an agile method for project management developed by Ken Schwaber. Its goal is to dramatically improve productivity in teams previously paralyzed by heavier, process‐laden methodologies. Its intended use is for management of software development projects as well as a wrapper to other software development methodologies such as Extreme Programming.

Scrum is characterized by:

  • A living backlog of prioritized work to be done.
  • Completion of a largely fixed set of backlog items in a series of short iterations or sprints.
  • A brief daily meeting (called a scrum), at which progress is explained, upcoming work is described, and obstacles are raised.
  • A brief planning session in which the backlog items for the sprint will be defined.
  • A brief heartbeat retrospective, at which all team members reflect about the past sprint.

Scrum is facilitated by a scrum master, whose primary job is to remove impediments to the ability of the team to deliver the sprint goal. The scrum master is not the leader of the team (as they are self‐organizing) but acts as a productivity buffer between the team and any destabilizing influences.

Scrum enables the creation of self‐organizing teams by encouraging verbal communication across all team members and across all disciplines that are involved in the project. A key principle of scrum is its recognition that fundamentally empirical challenges cannot be addressed successfully in a traditional “process control” manner. As such, scrum adopts an empirical approach—accepting that the problem cannot be fully understood or defined, focusing instead on maximizing the team’s ability to respond in an agile manner to emerging challenges.

By bringing together business people, developers, customers’ representatives, and other concerned parties in a disciplined, face‐to‐face encounter, Agile methodology was intended to simultaneously increase efficiency and improve quality.

After a year of applying Agile, Skinner asked his engineers to evaluate the effort. “Wonderful,” said some, “what’s new?” asked others, and “this is a definite step in the wrong direction,” complained a few. Skinner remained unsure about whether to continue with the Agile methodology or look for a new approach to software development.


  1. 1. Information in this case is based on Jon N. Meliones, Richard Ballard, Richard Liekweg, and William Burton, “No Mission No Margin: It’s That Simple,” Journal of Health Care Finance 27 (Spring 2001); Jon Meliones, “Saving Money, Saving Lives,” Harvard Business Review (Nov.–Dec. 2000); and (Jan. 1, 2001).
  2. 2. Robert S. Kaplan and David P. Norton, “Trans‐forming the Balanced Scorecard from Performance Measurement to Strategic Management: Part I,” Accounting Horizons 15 (Mar. 2001), p. 87; Robert S. Kaplan and David P. Norton, “Using the Balanced Scorecard as a Strategic Management System,” Harvard Business Review (Jan.–Feb. 1996), p. 3; Robert S. Kaplan and David P. Norton, Integrating Shareholder Value and Activity‐Based Costing with the Balanced Scorecard In Context (Boston, MA: Harvard Business School Publishing, 2001), p. 4.
  3. 3. These essays and others are collected in Kurt Lewin, Field Theory in Social Science: Selected Theoretical Papers (New York: Harper & Row, 1951).
  4. 4. Ibid., p. 226.
  5. 5. Emily Thornton, “A New Order at Nissan,” Business Week (Oct. 11, 1999), p. 54.
  6. 6. Lewin, Field Theory in Social Science, p. 229.
  7. 7. Ibid, p. 231.
  8. 8. Critiques of Lewin’s theories can be found in Ralph Stacey, “Management and the Science of Complexity: If Organizational Life Is Non‐linear, Can Business Strategies Prevail?” Research and Technology Management 39 (1996), pp. 2–5; Wanda J. Orlikowski and Debra Hofman, “An Improvisational Model for Change Management: The Case of Groupware Technologies,” Sloan Management Review 38 (Winter 1997), pp. 11–21; Alexander Styhre, “Non‐linear Change in Organizations: Organization Change Management Informed by Complexity Theory,” Leadership and Organization Development Journal 23 (2002), pp. 343–351.
  9. 9. Based, in part, on Michael Beer and Bert Spector, “Human Resource Management: The Integration of Industrial Relations and Organization Development,” in Kendrith M. Rowland and Gerald R. Ferris, eds., Research in Personnel and Human Resources Management: A Research Annual, Vol. 2 (Greenwich, CT: JAI Press, 1984), pp. 261–297.
  10. 10. That perspective on conflict is fully explored in Richard E. Walton, Interpersonal Peacemaking: Confrontations and Third‐Party Consultation (Reading, MA: Addison‐Wesley, 1969).
  11. 11. Kenneth W. Thomas, “Conflict and Conflict Management,” in Marvin D. Dunnette, ed., Handbook of Industrial and Organizational Psychology (Chicago, IL: Rand McNally, 1976), pp. 889–935.
  12. 12. Michael Beer and Bert Spector, “Organizational Diagnosis: Its Role in Organizational Learning,” Journal of Counselling and Development 71 (1993), pp. 642–650.
  13. 13. On the importance of process‐driven change, see Beer, Eisenstat, and Spector, The Critical Path to Corporate Renewal; Richard P. Rumselt, “How Much Does Industry Matter?” Strategic Management Journal 12 (1991), pp. 167–185; Robert Macintosh and Donald MacLean, “Conditioned Emergence: A Dissipative Structures Approach to Transformation,” Strategic Management Journal 20 (1999), pp. 297–316; Richard H. Axelrod, Changing the Way We Change Organizations (San Francisco: Berrett‐Koehler, 2000); L.C. Harris and E. Ogbonna, “The Unintended Consequences of Culture Interventions: A Study of Unexpected Outcomes,” British Journal of Management 12 (2002), pp. 31–49.
  14. 14. Bert Spector, “From Bogged Down to Fired Up: Inspiring Organizational Change,” Sloan Management Review 30 (Summer 1989), pp. 29–34.
  15. 15. Beer, Eisenstat, and Spector, The Critical Path to Corporate Renewal, p. 40.
  16. 16. Ibid., pp. 45–46.
  17. 17. This case is detailed in Beer, Eisenstat, and Spector, The Critical Path to Corporate Renewal.
  18. 18. Ibid., p. 52.
  19. 19. Robert H. Schaffer and Harvey A. Thomson, “Successful Change Programs Begin with Results,” Harvard Business Review (Jan.–Feb. 1992), p. 83.
  20. 20. The framework presented here builds on one presented earlier, in Beer, Eisenstat, and Spector, The Critical Path to Corporate Renewal.
  21. 21. Meliones, Saving Money, Saving Lives, pp. 59–60.
  22. 22. James C. Collins, Good to Great: Why Some Companies Make the Leap and Others Don’t (New York: Harper Business, 2001).
  23. 23. Meliones is quoted in (Jan. 1, 2001), p. 1.
  24. 24. The concept of mutual engagement is developed in José Santos, Bert Spector, and Ludo van‐der‐Hayden, “Toward a Theory of Corporate Business Model Innovation,” Northeastern University College of Business Administration Working Paper, (2008).