The Agile CEO: A Blog About Agile Management

The challenge of scaling Agile can be posed quite simply: How do you extend the power and magic of a high-performing Agile team to a larger group of people?

Check out this ruling from the United States District Court of California sanctioning attorneys for predatory behavior and abuse of copyright law. You don’t expect to be entertained by reading a court document but then court docs usually don’t quote Spock:

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.