- Introduction
- Who is Donald McNaughton?
- Managing product management
- What is product management?
- How are products managed?
In case you didn't already know this, part of the reason that I blog is to figure out things that I don't already know about.
While Donald McNaughton outlined his thirteen steps to manage a product, I received a tweet from Val Workman:
@empoprises #PMV any idea on how this applies to Agile?
I responded:
@valworkman i confess i'm not knowledgeable on agile and can't evaluate mcnaughton's described process vs. agile #pmv
Now that the presentation's over, it behooves me to figure out what this danged Agile thing is all about. The best place to start is with the Manifesto for Agile Software Development.
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
The Wikipedia writers contrast Agile with the waterfall model with which I am more familiar:
The waterfall model is the most structured of the methods, stepping through requirements-capture, analysis, design, coding, and testing in a strict, pre-planned sequence. Progress is generally measured in terms of deliverable artifacts: requirement specifications, design documents, test plans, code reviews and the like.
The main problem with the waterfall model is the inflexible division of a project into separate stages, so that commitments are made early on, and it is difficult to react to changes in requirements. Iterations are expensive. This means that the waterfall model is likely to be unsuitable if requirements are not well understood or are likely to change in the course of the project....
Agile methods, in contrast, produce completely developed and tested features (but a very small subset of the whole) every few weeks. The emphasis is on obtaining the smallest workable piece of functionality to deliver business value early, and continually improving it and adding further functionality throughout the life of the project. If a project being delivered under the waterfall method is cancelled at any point up to the end, there is nothing to show for it beyond a huge resources bill. With the agile method, being cancelled at any point will still leave the customer with some worthwhile code, that has likely already been put into live operation.
But regardless of what Agile is, Donald McNaughton made a significant point later in the presentation. Specifically, an organization should become EFFECTIVE before it becomes EFFICIENT.
This parallels the thinking behind the SEI-CMM and related processes, and probably just about every other process out there. If you don't know what you're doing, how can you do it better? Work on figuring out what you're doing - write down a process, measure yourself against it - and then you can figure out how to improve. McNaughton's implication was that Agile addresses efficiency rather than effectiveness, and that you have to do other things before you can decide whether Agile is right for you.
Which brings us to James R. Chapman's project management principles.
