Sometimes I think of the traditional PM methods that we've been practicing and improving for the past decades---since really WW II when a lot of the science of PM was invented---as one of the two "grand strategies" for doing projects; the other is the Agile evolution, some say revolution.
Two grand strategies: is there a unifying idea that reconciles their approaches? Does there need to be such a reconciliation?
Glen Alleman may have hit upon a pretty decent reconciliation in his posting at
HerdingCats. As an example of what I mean, he writes:
Planning of all work scope for the project to completion
- For traditional projects this means a master plan and master schedule for the planned work, the sequence of that work, the dependencies between the sequenced work.
- For an Agile project this means some way of knowing what done looks like in terms of User Stories or Use Cases bounded by a period of time. The planning of an Epic or a Release can be that bound.
Not a bad start in my estimation. His post goes on to complete his thinking on performance measurement on these two approaches.
Actually, I think of agile as just a risk response plan to a particular situation of unstable user requirements. Think of the usual requirements deck:
- There are foundation and non-functional requirements that are derived from the project narrative or vision. These are usually pretty stable
- There are interface requirements to existing systems, products, and processes; again, pretty stable
- And then there are user requirements that are like a fuzzy cloud floating on top of these more or less stable layers. That's where agile really comes in. And, as Glen shows, these methods, each applied to their own, are reconcilable.
Indeed, many (most?) that practice agile really synthesize a bunch of practices and fit them to the existing project model. Why? Well, other people's money to start with; and second: it's just common sense to take advantage of what you know that works in some situations.
Two grand strategies! How nice.
