Agile Principles and Project Management

I attended my PMI chapter meeting last evening. The presentation was about agile principles and project management. Since agile project management is such a hot topic I thought I’d give a quick critique of the presentation and the topic in general.

Let’s start with the things that annoy me about this topic and then get to the good stuff. My biggest complaint is that people who present this topic seem to slam the traditional form of project management. I don’t suggest that the traditional form is fantastic. Like I’ve said, project management has changed over time and continues to evolve, much like the manufacturing processes have changed. I am not sure what the value is to the audience, since most of the audience practices traditional project management it can be a bit offensive. Next up is that there is not context given to the agile principles that they believe can be adapted for traditional project management nor do they mention that some of the principles have been used, to some extent, in traditional project management in the past. There is no mention of the fact that agile requires the principles to work. That being said, the practices that the speaker mentions are good practices for traditional project management.

The two fundamental points that formed the basis of the presentation are that agile represents a more active management approach than traditional project management. I’m not sure I agree. Either I’ve been managing projects incorrectly or counter to the suggested method or that is an agile message that folks who practice agile use to provide the perspective that they are agile. Second, the premise is that agile is meant to help project teams “fail faster” and accentuated four points; closed feedback loop, increased control, a strong and well maintained team structure and identification of issues sooner.

Some principles were omitted and should be mentioned because their supporting concepts differentiate agile software development from traditional delivery. A couple of the principles have to do with the management style and how the team is viewed. First, the team members are considered motivated and should be trusted to do the next right thing and the team members are self-organizing, they are not assigned work as much as they assign themselves work. The second group of principles has to do with the technical aspects of delivery, which are to have rapid continuous delivery of useful working software and to ensure that technical excellence and design are part of the rapid delivery (can’t cut corners). These principles are more difficult to adapt to a traditional project management method, and I believe they deserve some exploration in future posts.

Ride On, Manage On