Some Fundamental Assumptions About Agility

by Lou Mazzucchelli and Tim Lister, Fellows, Cutter Business Technology Council

We think of agile methods as a family of approaches aimed at dealing with uncertainty. If there is a high level of uncertainty about what exactly you will end up building, then the agile approaches (all of which call for multiple short iterations with ongoing customer feedback) make enormous sense. With the agile methods, we incrementally steer our way to a useful system. On the other hand, if there is a clear and explicit definition of what needs to be built, then the iterative approach significantly decreases in value, and a preplanned, classic, phased approach may be sensible.

In examining the data from a recent Cutter survey (see Cutter Benchmark Review, Vol. 8, No. 4), we separated the respondents into two camps: those who responded "yes" and those who responded "no" to the question, "Does your organization explicitly consider the need for IT agility in its IT strategy and plans?" Basically, two-thirds of the survey respondents are in the "yes" camp, and one-third are in the "no" group.

We then looked at predictability of requirements as a key indicator that an organization would be more likely to report agile behavior. The assumption is the more uncertainty you have in your requirements, the more likely you are to use an agile method. We focused on the question, "How easy is it to predict the requirements for your organization's IT systems looking three years ahead?" For our analysis, we chose to divide the responses to this question into two main groups: "predictable" and "uncertain." The predictable group is made up of the combined respondents who chose "very predictable" (5%) or "mostly predictable" (36%); the uncertain group represents those combined respondents who chose "mostly uncertain" (23%) or "very uncertain" (1%). We then further segregated these survey results and the responses to the question mentioned earlier regarding IT agility being considered in the IT strategy. Table 1 shows the relationship between those who have and do not have agility as part of their strategy and the level of predictability in requirements.

Table 1 -- Survey Data Segregated by IT Agility in Strategy and Predictability of Requirements

Yikes! According to this data, higher predictability leads us to agility, while higher uncertainty leads us away from it. As it is sung in The King and I musical, this is "a puzzlement."

So then we thought that maybe those who are actually doing their own application development work report agile behavior, while those who are outsourcing have little need for agility since they are willing to be at an arm's length with the actual construction process.

Again, we separated the same "yes/no to agility in strategy" groups and then looked at the question, "What percentage of your organization's application development work is outsourced?" We looked specifically at those who had significant outsourcing; for this, we set the bar at 50% outsourced or higher (see Table 2). We even made a category for those 100% outsourced.

Table 2 -- Survey Data Segregated by IT Agility in Strategy and Percentage of Outsourcing

Yowzers! (Lou disclaims this exclamation, but agrees with its intent.) Again, this shows the opposite of what we thought we'd find. Heavier numbers reported outsourcing in the agile population, and even four organizations that explicitly consider the need for IT agility have sold the ranch: they are 100% outsourced. Did they explicitly consider the need for IT agility and reject it?

Desperate to leave this "Mad Hatter's Tea Party," we then looked at our yes/no populations in terms of the question, "In projects that use an agile process, does your organization adopt a uniform agile methodology?" Responses could either be "yes," "no," or "none of our projects use an agile process." (In the sample as a whole, of those reporting use of an agile methodology, about half reported a uniform methodology and half did not. A bit over a quarter of all respondents used no agile process.)

We assumed that the truly agile would not be lockstepped into a single uniform process; their process itself would be agile. So we also looked at those who reported "75% or more of their projects" in response to the question, "What percentage of application development projects in your organization use an agile process?" (see Table 3).

Table 3 -- Survey Data Segregated by IT Agility in Strategy, Adoption of Uniform Agile Methodology, and Percentage of Projects that Use an Agile Process

So much for our assumption: there is a clear bias toward a uniform process for those heavily involved in agile development (when we looked inside that group, Scrum seems the hands-down winner of all the named processes). This apparent process uniformity might spring from immature agile teams who have not yet learned to tweak their process. But we are at a loss to explain the results from 12 respondents in the "yes" population who explicitly consider the need for IT agility but respond that they have no agile projects. One possible explanation for this would be an assumption that an outsourced project was not agile by definition. The overall IT strategy might be considered agile, but the projects are not.

We welcome your comments on this issue of the Cutter Edge and encourage you to send your insights on the market in general to comments@cutter.com.

-- Lou Mazzucchelli and Tim Lister, Fellows, Cutter Business Technology Council