The Agile CEO: A Blog About Agile Management

Steve Blank has an article in the May 2013 edition of HBR entitled Why the lean startup changes everything. It is an excellent example of the crossover of Agile principles from the software domain to the much broader context of business management. The fact that it is published in HBR and not Computerworld is significant.

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…

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.