The Agile CEO: A Blog About Agile Management

If Agile isn't a methodology, what is it?

What is a methodology?

A methodology is a process taxonomy designed to govern a work domain (e.g. software development). Each process is defined in terms of a set of prescriptive formulas or rules. Rules generally take on forms similar to the following:

1. Under these circumstances, do these activities.
2. When you get to this point, do this activity.
3. An activity is defined by executing this task sequence.
4. The input of this task is “X” and the output of this task is “Y”.
5. And so forth…

Here's another indication that Agile and Scrum in particular are catching on like wildfire. Agile’s radiation through the tech sector is easily explained since it fits hand-in-glove with software development, but when we hear about it in the Wall Street Journal, we witness something else: Penetration of these ideas into the business mainstream. What is a stand-up but a vital daily status meeting ruthlessly stripped of all waste? You can’t get more lean than that. Agile is a pointer to a waste-intolerant, performance-driven culture obsessed with the pursuit of excellence. What business would not want some of that?

In my last post, we discussed why software development is more like designing than building. The following diagram illustrates the point:

In my last post, I talked about why it’s really hard to produce a software specification before you start work that is as complete as the blueprint you would use to guide the construction of a building. Today we will discuss why it’s also impossible.

The principle reason that Agile development methods have caught on like wildfire is that they address the root cause of most software development project failures: Unreliability of software specifications. To put it differently, if software specifications were as reliable as building blueprints, then the principle justification for investing in Agile competencies would disappear. Agile practices might still have value, but the argument that they should be the dominant approach used by the industry would be much more difficult to make.

In my last post, I closed with the following:

The PMI has embraced Agile project management and is the first to admit that by doing so they enrich the entire project manager community of practice. Does PMBOK have anything to offer the Agile community of practice?

A great way to begin asking this question is to review The Software Project Manager’s Bridge to Agility. The authors compare the traditional (PMBOK) approach and the Agile approach to software project management. It becomes quite clear that for most of the traditional project management functions (e.g., scheduling, estimating, task management, etc.) there is a corresponding Agile approach.  However, when it comes to how, who, when and to what degree these functions are performed there are big differences.

It’s also true that project management functions generally cannot be mixed and matched between the Agile and traditional approach.

We hear a lot from our market analyst friends that Agile adoption has entered the mainstream. But how much faith can we really put in their words? After all, a big part of their mission is to make as big a market splash as possible for new ideas and concepts, especially when technology companies are eager to pay to position their latest, greatest mousetrap.

Certainly there are anecdotal signs of increasing agile adoption, but are Agile practices now mainstream practices? Has Agile crossed the chasm? And if a tipping point has been reached, how would we know? Well one big indication is the new Project Management Institute (PMI) Agile Certification.

In my last post, we discussed that when Agile values clash with the corporate culture, the effort to adopt agile practices will be impeded if not extinguished. We asked the question: Is there really anything you can do about this problem? After all, how do you go about changing the corporate culture? In this article, we will discuss what you can do to help your organization intentionally shift its values and culture.

I recently had the good fortune to discuss  scaling Agile and related topics over dinner with Esther Derby and Diana Larsen, two of the most well-established business consultants in the Agile industry. What they had to say was encouraging. Not only can managers take action to improve conditions, they have the power to transform the corporate climate. One big idea: apply simple rules.

Simple Rules

Throughout the animal kingdom, the often complex and apparently intelligent behavior of animal collectives can be accounted for by applying a few simple rules. For example, a few simple rules can be used to account for the complex behavior a flock of geese adopts to retain an optimal flying formation under ever-changing conditions. Similar rules can be used to explain the behavior of insect swarms, schools of fish, and herds. Animals evolve these rules as real-time, adaptive responses to their environments.

When we talk about scaling “Agile”, are we thinking of economies of scale? What picture comes to mind? Is it one that involves “building” or “manufacturing”? Although these mental models are sometimes useful, they may do more harm than good when it comes to Agile adoption.

If we are “building” an Agile organization, then we may be thinking of processes, technology, and people as construction materials. And if we are treating people as material, then we draw perilously close to violating a fundamental Agile tenant — that the source of all value comes from thinking, breathing, creating people. This is in stark contrast to the idea that value is extracted from people in the form of labor. Labor abstracted as a fungible asset is a cornerstone of our manufacturing legacy. We optimize the value of people by applying economies of scale that allow us to achieve the lowest possible unit cost for their labor.  

Clearing up some semantic confusion

In my last post, my attempt to answer the question “What is an Agile Maturity Model?” did not get too far before we ran into potential semantic confusion with the term “maturity model.”  We established that there are at least two types of maturity models, namely Lifecycle models and (tentatively)  evolutionary models. Although they share the attribute of progressive phases, they also have important differences. The lifecycle models maturity as the aging process: Birth, growth, decline and death. The evolutionary model advances but does not decline or if decline does occur — unlike aging — it’s reversible. Since Agility is a quality that is voluntarily acquired and does not inevitably progress, the lifecycle model appears to be a poor fit. This allows us to reduce some semantic ambiguity by tentatively replacing the term “maturity” with the more narrowly defined “evolution.” Unfortunately there are also problems with the term “evolution.”