Having some side conversations about the Agile PM / Agile SWDev topic. There's a book on my shelf at home (I'm out on assignment) about the "myth of the new." They (Harvard Profs) contend there is a proclivity to detach from the past and attach to the future processes that failed in the past because we did not actually follow the process. Replacing the failed process with a new one that we again have problems following.
There are great attributes to the agile software development processes. And I've experienced them directly. Much better than the linear approaches of the past. Better for the customer. Better for the developers. Better for the managers of both the customer and the developers.
Moving these discoveries to a more general project management realm without first understanding the paradigm of project management is naive. The book speaks to this is in narcissistic terms. "What works for me must also work for you, even though your problem is different." Add to that the zealot approach of "I have great experience in this and your concerns are baseless," brings out the defenses on both sides.
Project Management as a Profession
Most of the "hacking" in project management starts with the ignorance of the underlying principles and processes of project management itself.
- Define what done looks like - this is a negotiated description between the customer and the provider?
- Define the units of measure used to speak about done - what does it mean when we say we're making progress. Is this measure first meaningfully to the customer and then is the shared meaning understood by the provider?
- Define the processes to correct the "less then acceptable" performance toward done - what management intervention will take place and when they will be instituted?
These project management activities can be fulfilled by linear approaches or agile approaches. They should be independent of the processes by which they are fulfilled