It is this lack of comprehension of what project management truly is that makes people (left brainers mostly) who try agile methods so dangerous to a stable system. Agile techniques are nothing more than an adaptation of RAD and borrowing UML tools, but using “live code” as opposed to prototyping. It was what we used to go after the “dumb money” during the dot bomb…it causes far more harm than good and is full of more holes than swiss cheese.

When you reward constant change you are guaranteed to get even more of it. Agile is a great technique to rip off customers by meeting “wants” over “needs” and “needs” to have adult supervision if deployed.

Kelly, I should have replied to this a couple months ago …

If the purpose of the release is SOLELY for the customer to use it in a production environment (for real work), then you have a good point.

However, for “ground-up” projects, the PRIMARY purpose of early releases is for the customer to get a working “prototype” (for lack of a better word) from which they can provide meaningful feedback on whether or not the features delivered thus far are on the right track. If you hold back your releases to your customer until a year or more has gone by, then that’s tantamount to following a waterfall (for lack of a better word) methodology.

For Agile to work effectively, you need tighter feedback loops. 1-4 months is about the max, IMHO.

Also, I think the team needs to go thru a few “fire-drill” releases so that when Version 1.0 is ready to be released, it runs smoothly – because you got most of the kinks out in the earlier releases.

Kirk Bryde, CSM, CSP, PMP

Kelly.

For the past ten years I’ve taught a PMP exam prep course. For the past three years I’ve been deeply immersed in designing, implementing, and rolling out my company’s approach to planning and executing agile software development projects. One thing has become clear……we need to quit thinking PMBOK describes “traditional” project management because doing so allows a lot of folks to get off the good practice hook, saying “Well, that’s my grandfather’s project management and it doesn’t apply to me (or my project/industry)”.

It does. If you go beyond PMBOK’s mechanistic description of processes, tools, and techniques to think about the concepts on which those processes, tools, and techniques are based, you’ll quickly realize those concepts apply to all projects, its only the mechanics that are different:

Line Items are sort of like User Stories.
Schedule Activities are sort of like Iterations.
Resources are sort of like Team Members.
Budgets are sort of like Budgets.

And any project not planned and executed on a sound conceptual foundation is doomed.

I agree the whole team has to take responsibility, not solely the PM, but part of the PM’s role is certainly to help unify the team and in that way I think they are ‘directing and managing’. Ideally they would do that in a soft, collaborative, democratic, consultative, empowering way, not autocratic, dictatorial and controlling.

Your comments about the release cycle are interesting, because I think the release cycle exists completely independently to sprints or iterations. I think the length of the release cycle completely depends on your context and, whereas sprints are fixed, the release cycle should vary based on whatever is necessary. For web site changes, we might release multiple times throughout a single two week sprint. For a ground-up build of a back-end system, even every 1-4 months might be challenging in terms of being able to deliver a full working system that has enough value to the users. So I totally agree that there should be a release plan (or ‘roadmap’) sitting over the iterations to give the team purpose across multiple sprints, and to give the business owners visibility of the bigger picture, and I certainly believe that the release cycle should generally be as short as practically possible.

Kelly.

I also think that you should mention the release cycle, which should occur every 1-4 months. Any Agile team should release their software to their customer at least that often. Even though each iteration is technically shippable, in practice it’s often not.

If you include the release cycle, then your last paragraph: “These processes are repeated for each iteration until the project’s objectives are achieved, or until it is decided that the objectives are no longer worth pursuing.” won’t sound so open-ended.

I think the important point to make here is that Agile teams don’t miss release deadlines. Instead, come hell or high water, they do whatever must be done (sometimes cutting scope) to deliver on a fixed schedule (every 1-4 months). Since the schedule is fixed, release dates can be set as part of each Release Plan – at the start of each release cycle. This is much more comforting to stakeholders and customers than saying that you just keep going until you’ve either met scope or can the project.

Kirk Bryde, CSM, CSP, PMP

Unfortunately I can’t find it now, but I recently ready somewhere that PMBOK will be introducing a section on people skills in the next edition. I think that’s a very good idea. I believe the people skills needed by a project manager are similar for any method of project management, agile or not, but I believe the style of management and leadership is very different, so I hope it emphasises leadership more than it emphasises control…

Kelly.

http://agile-pm.pbworks.com/w/page/1526573/FrontPage

I think there is a key element missing here. The section is labeled “direct and manage” but if someone was to do this in agile the team dynamic would be stressed and would not allow the team to reach their full potential.

PMI implies that resources (not team members in PMI) are very good at doing their specific task, but not so good at any of the other things such as communication to other team members. Therefore, they need some (project manager) to direct and manage their work. Think of it as building a house. The electrician is good at the electrical and can manage that part of the building, but without a project manager, there would be no one to tell the drywallers that they could put up drywall.

Agile depends on the team members taking up a large portion of the direct and manage, leaving the project manager to focus more on roadblocks, release planning, and process improvement functions.

I have seen first hand how assigning a strong project manager to an agile project as either a scrum master or an overall project manager can essentially break agile before it starts. A strong project manager won’t allow the amount of unknowns that are an accepted approach in agile. They will look to establish a risk plan for the entire project and work to mitigate as many of those risks as possible. Things like poorly defined scope will show up in this risk plan.

I agree the PMBOK can include agile addendum to clarify a few of these items and I very much agree with the inputs in outputs noted above.

Perhaps the first place to start on the PMBOK is to define a new section on People Management. Once the project manager accepts the team dynamic, there is not a section called “direct and manage project execution” but rather “support and assist sprint execution”.