For years, management thinkers assumed that there were inevitable trade-offs between efficiency and flexibility — and that the right organizational design for each was different. But it’s possible to design an organization’s work in ways that simultaneously offer agility and efficiency — if you know how.

You can hardly pick up a business publication without reading about the ever-increasing pace of change in technologies and markets and the consequent need for more adaptable organizations. Given the imperative of adaptability, it is not surprising that few words have received more attention in recent conversations about management and leadership than “agile.”1 Organizations ranging from large corporations like General Electric Co. to tiny startups are trying to be both flexible and fast in the ways that they react to new technology and changing market conditions.2

The word “agile” appears to have been first applied to thinking about software by 17 developers in 2001.3 Having experimented with more iterative, less process-laden approaches to developing new applications for several decades, the group codified its experience in an agile manifesto. “We are uncovering better ways of developing software by doing it and helping others do it,” they wrote. In software development, agile now has a variety of manifestations, including scrum, extreme programming, and feature-driven development.4 The results have been significant. A variety of studies show that agile software development methods can generate a significant improvement over their more traditional predecessors.5

But what does this mean outside of software? Can agile methods be successfully applied to other types of work? Many proponents (a number of whom started in the software industry) argue that the answer is yes, and a growing collection of books, papers, and blog posts suggests how it might be done.6 The evidence, however, remains limited to date, and a recent article by two of agile’s founders cautions against applying agile indiscriminately.7 The blogosphere is also replete with discussions of an ongoing agile backlash.

To provide some practical advice to business leaders trying to understand what agile might mean for their organizations, we take a different approach. Our research suggests that in applying agile methods from the software industry to other domains, managers often confuse practices and principles. When agile methods work, they do so because the associated practices manifest key behavioral principles in the context of software development. But, successful as those practices can be when developing software, there is no guarantee that they will work in other contexts.


1. A quick trip to the web reveals multiple manifestations, including “agile principles,” “enterprise agile,” “agile organizations,” and a variety of suggestions, including the charge to “apply agile development to every aspect of business.” See, for example, S.D. Goldstein, “Apply Agile Development to Every Aspect of Business,” Mint, Dec. 4, 2016,

2. D. Leonard and R. Clough, “How GE Exorcised the Ghost of Jack Welch to Become a 124-Year-Old Startup,” Bloomberg, March 17, 2016,

3. See their manifesto here:

4. For a summary, see F.S. Glaiel, A. Moulton, and S.E. Madnick, “Agile Project Dynamics: A System Dynamics Investigation of Agile Software Development Methods,” Massachusetts Institute of Technology, Engineering Systems Division working paper, October 2014, available at

5. See C.J. Stettina and J. Hörz, “Agile Portfolio Management: An Empirical Perspective on the Practice in Use,” International Journal of Project Management 33, no. 1 (January 2015): 140-152; J. Sutherland and J.J. Sutherland, “Scrum: The Art of Doing Twice the Work in Half the Time” (New York: Crown Business, 2014); and D. West and T. Grant, “Agile Development: Mainstream Adoption Has Changed Agility,” Forrester, Jan. 20, 2010,

6. See, for example, M.E. Moreira, “Being Agile: Your Roadmap to Successful Adoption of Agile” (New York: Apress, 2013).

7. D.K. Rigby, J. Sutherland, and H. Takeuchi, “Embracing Agile,” Harvard Business Review 94, no. 5 (May 2016): 40-50.

8. The classic descriptions of contingency theory can be found in T. Burns and G.M. Stalker, “The Management of Innovation,” rev. ed. (Oxford, U.K.: Oxford University Press, 1994) and in P.R. Lawrence and J.W. Lorsch, “Organization and Environment: Managing Differentiation and Integration,” rev. ed. (Boston: Harvard Business School Press, 1986). An updated summary can be found in several textbooks, including R.M. Burton, B. Eriksen, D.D. Håkonsson, and C.C. Snow “Organization Design: The Evolving State-of-the-Art” (New York: Springer Science+Business Media, 2006).

9. F.W. Taylor, “The Principles of Scientific Management” (New York and London: Harper & Brothers, 1911).

10. T. Brown, “Change by Design: How Design Thinking Transforms Organizations and Inspires Innovation” (New York: HarperBusiness, 2009).

11. J. Liker, M. Hoseus, and the Center for Quality People and Organizations, “Toyota Culture: The Heart and Soul of the Toyota Way” (New York: McGraw-Hill Education, 2008).

12. See, for example, N.R. Repenning and J.D. Sterman, “Capability Traps and Self-Confirming Attribution Errors in the Dynamics of Process Improvement,” Administrative Science Quarterly 47, no. 2 (June 2002): 265-295; and N. Leveson, “A Systems Approach to Risk Management Through Leading Safety Indicators,” Reliability Engineering and System Safety 136 (April 2015): 17-34.

13. K.T. Ulrich and S.D. Eppinger, “Product Design and Development,” 6th ed. (New York: McGraw-Hill Education, 2016).

14. Sutherland and Sutherland, “Scrum”; and Scrum Guides,

15. L.A. Perlow, “The Time Famine: Toward a Sociology of Work Time,” Administrative Science Quarterly 44, no. 1 (March 1999): 57-81.

16. See Sutherland and Sutherland, “Scrum”; and J. Kamensky, “Digging Out of the Digital Stone Age,” Government Executive, March 9, 2017,

i. N. Epley and J. Kruger, “When What You Type Isn’t What They Read: The Perseverance of Stereotypes and Expectancies Over E-Mail,” Journal of Experimental Social Psychology 41, no. 4 (July 2005): 414-422.

ii. L. Argote and D. Epple, “Learning Curves in Manufacturing,” Science 247, no. 4945 (Feb. 23, 1990): 920-924.