"The contrast between the beauty of the small and the requirements of the big generates systemic tension in many software projects, organizations, and companies."

-- Israel Gat, Guest Editor

Opening Statement

"Small is beautiful" in software. While big software might not be beautiful, more often than not, it's in the nature of what needs to be accomplished. This contrast between the beauty of the small and the requirements of the big generates systemic tension in many software projects, organizations, and companies. Resolving this conflict is the focus of this issue of Cutter IT Journal.

Consider the classical long-run average cost (LRAC) curve, depicted on the left in Figure 1. Various clients of mine are actually of the opinion that this curve not only captures their economies of scale (reductions in unit cost as a result of increased size) but that it is just as representative of their economies of scope (reductions in average cost due to the production of two or more related products). The rationale for so believing is quite straightforward: one such client possesses legions of software engineers as well as a distribution network¹ in 20, 30, 50, or 100 countries around the globe. It will take a lot of time, effort, and investment for a new entrant to build a development organization and a distribution network that will be able to compete at scale. It's no wonder my client expects to beat the competition based on superior scale and scope.

Figure 1 -- Economies of scale and scope vs. diseconomies of assimilation.

Whether economies of scale and scope really apply to software, software products, and knowledge work is fodder for another day. What I typically do in engagements in which the strategic advantages of economies of scale and scope are forcefully brought up is to draw the curve showing "diseconomies of assimilation" (at right in Figure 1). Without dwelling too much on the exact mathematical definitions of the curve, I propose that my client think of diseconomies of assimilation as the "friction" of agile. When you roll agile into an unsuitable environment, even the simple thing becomes difficult. For example, a "real-time" activity such as reprioritizing a story on the backlog might become mind-boggling if/when you have to wait for 12 hours to get the decision from overseas.

In engagements in which the pros and cons of scale, scope, and assimilation are important, I suggest that the client carefully consider the effects of scale and scope on the way software is defined, developed, and deployed and how it generates value in their environment. Typical questions I bring up are:

• How is software developed across the various ponds that separate the countries in which you have development sites?

• How do you handle requirements from the 20/30/50/100 countries?

• What common artifacts tie together operations in all these countries -- software development, software deployment, marketing, sales, and customer support?

• What is your code-branching strategy for fulfilling the needs of all these countries?

• What is your deployment strategy for fulfilling the needs of all these countries?

• How do you align code ownership with the organizational structure and geographical distribution?

What the client and I most often find is that the client's ability to really utilize economies of scale and scope is counterbalanced by fairly significant deficits that such scale and scope inherently generate. These deficits are particularly painful with respect to the ability to comprehend what needs to be done at the methodical, tactical, operational, and strategic levels. For example, poor quality of the teleconferencing infrastructures voids many of the theoretical advantages of fully distributed agile. Or, the level of investment available for training developers in faraway countries is much lower than that available to their colleagues in the US. On various occasions, the difficulty in bringing things together on a grand scale is so severe that the folks in various parts of the world end up acting like members of a cargo cult.²

WHAT CAN WE DO ABOUT BIG AGILE?

Cutter Senior Consultant and friend Alistair Cockburn made the following comments on Figure 1:

Running a 100-person project is fundamentally different, calls for different strategies and methodologies, than a six-person project....

Israel's "friction" curve, however, shows ... that quite naturally, there is increasing "friction" moving left to right, increasing cost to align all the people.

This is true in all development, not just agile development.

What I wish is to show/remind people that agile does not change certain cost parameters of software development. Yes, we have evolved neat strategies and nifty tools to help distributed teams work more effectively together, but ... since what is at the bottom of the stack is still people, still bringing personal hangups and political agendas with them, the exact same friction curve STAYS when employing agile into a shop (and even more when introducing it, with the behavioral changes it calls for).³

In a way, the five authors contributing to this issue of Cutter IT Journal, all members of Cutter's expert team, reflect on Figure 1 whether they are aware of it or not:

• Scott Ambler examines the Big Agile challenge from a scaling perspective. For Ambler, scaling requires considering a broader context than "just" the software method. He identifies eight scaling factors that individual teams will inevitably face in the course of doing Big Agile. Coping with these scaling factors requires a disciplined approach that must address, and quite possibly reformulate, the entire product delivery process. In other words, to succeed with Big Agile, one needs to implement agile on an end-to-end basis.

• Dave Rooney views the incremental approach to Big Agile as inadequate. Using a construction metaphor, he highlights the need to prepare a Big Agile initiative with the same thoroughness that one would apply to preparing the foundations for a 20-story office building (as distinct from preparing a site for a single-family home). Rooney's rule of a thumb is that any agile initiative of more than three teams needs to be prepared as if it were the metaphorical site for a 20-story office building. He draws upon his consulting, training, and coaching experiences to describe how this metaphor explains the dynamics that prevailed in three agile engagements.

• David Spann sees Big Agile as a fundamental collaborative leadership challenge. He takes the reader through the ups and downs of an agile transformation embarked upon by a company that almost went under, demonstrating how leadership (or lack thereof) played a decisive role at critical junctures in the agile journey. Based on this case study, Spann offers a blueprint for large-scale agile rollout that the reader can apply (with some context-driven adaptations) in his or her own company.

• In his article "Big Anything Depends on the People," Tom Bragg takes a critical view of the gains to be made through software methods. As a factor in project success, he considers methods (agile or otherwise) a distant second to capable individuals. Specifically, Bragg conjectures that reported successes of agile projects might be due to the fact that agile is more fashionable than other software methods nowadays and thus attracts better people -- and as we all know, more competent knowledge workers produce better software than less competent ones. If Bragg's hypothesis is right, the "secret sauce" of agile is not the method per se. Rather, it is the popularity of the method that makes the difference.

• Like Bragg, John Heintz looks beyond "just" the software method. He stresses the importance of anchoring Big Agile in an underlying management theory such as evidence-based management or real options theory. Utilizing the underpinnings that such theories provide, a Big Agile initiative is much more likely to succeed than an initiative that merely replicates agile at the team level time and time again.

A common thread runs through all five articles: if you decide to "go big," you must take nonlinear effects into consideration (and, well, action). These effects require going beyond the traditional boundaries of the software method. Whether you opt to follow the good counsel of Ambler, Rooney, Spann, Bragg, and/or Heintz on the subject, you will inevitably need to do things in quite a different manner than you do at the team level. The choice of which specific advice to follow is largely a matter of your particular context.

CONCLUDING COMMENTS

In the final analysis, we need to balance the economies of scale and scope with the diseconomies of assimilation. Conceptual as Figure 1 is, it clearly indicates the need to design the various organizational structures in your company to be compatible with the philosophy of the "Optimal Zone": large enough to attain the LRAC benefits, but small enough to avoid the very real disadvantages of diseconomies of assimilation. Sizing an organizational unit significantly below the Optimal Zone poses the risk of not having the critical mass for the task at hand. Conversely, an organizational unit that is much bigger than its Optimal Zone is likely to run afoul of the friction of agile.

ENDNOTES

¹ I use distribution efficiencies here to illustrate one important form of economies of scope. Needless to say, there are other kinds of economies of scope, such as the number of products.

² In WWII, the US Air Force built airstrips on islands in the Pacific that were populated by preindustrial tribes. When the war ended and the servicemen went back to America, the natives built new airstrips and talked into abandoned communication devices in the belief that doing so would bring back the planes and their valuable cargo. The term "cargo cult" is now broadly used to describe the enactment of a ritual without having any grasp of what the ritual is about.

³ Cockburn, Alistair. "Agile After the Chasm." Alistair Cockburn, 6 October 2011 (http://alistair.cockburn.us/Agile+after+the+chasm).

ABOUT THE AUTHOR