The Agile CEO: A Blog About Agile Management

Last week we explored how inventory and waiting, two of the original seven lean manufacturing wastes, have analogs in software development.

In the first in a 5-part series that explores how Lean principles are applied through the practice of Agile, we discussed how the differences between Lean and Agile in software development are more about when particular practices might be best applied under particular conditions and less about how the two approaches are fundamentally different. In fact, Agile and Lean hold many guiding principles in common.

Ever since Mary and Tom Poppendiek wrote their book Lean Software Development: An Agile Toolkit, there has been a lot of discussion about Lean and Agile in the world of software development. Sometimes we hear about how Agile and Lean are different and sometimes we hear about how they are the same.

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…

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 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.”