| QUESTION & ANSWER |
How to be an agile project manager (PM) |
 |
By Colleen Frye, News Writer
15 Dec 2008 | SearchSoftwareQuality.com |
|
|
In this Q&A, Michele Sliger, consultant and co-author of The Software Project Manager's Bridge to Agility, talks about the role of project managers in an agile environment.Do agile projects typically have project managers?
Michele Sliger: It depends. In Scrum there is a Scrum Master -- is that a project manager? In XP there is an XP coach -- is that a PM? Most large organizations I've consulted with have decided on their own version of agile from XP, Scrum [and] Lean and still have PMs on the HR books. The job titles are still "project manager" but the role might be something different.
|  | | Michelle Sliger, Owner, Sliger Consulting Inc.
| |
Are the functions similar?
Sliger: No, they're fundamentally different. A project manager in the traditional sense was there to run the job and take the blame should things go wrong. As a result of having to take the blame, they were often very command-and-control in leadership style. In agile, you're truly looking for a coach/guide/leader, not to micromanage and tell us what each person on the team should do, but to tell us what we need and to give us the protection we need to keep from getting distracted.
The PMI [Project Management Institute] talks about how 90% of project management is just communicating, and indeed that's true for agile project management. The bulk of the job is mediating between team members to help them achieve consensus, negotiating with the organization to help them understand how their actions affect the team. They function as a liaison, as a guide -- it's just leadership 101 and you're providing the vision. Not so much from the business standpoint, but the agile PM is there to repeat and remind folks of the vision [of the project]; you almost become the keeper of process and vision.
Must PMs use waterfall to keep their PMP certification and follow PMBOK (A Guide to the Project Management Body of Knowledge)?
Sliger: If you look at Dr. [Winston] Royce's original paper [on managing the development of large software systems], we're not even following waterfall correctly. I think what we do to every new process is take 20% and understand it and implement it. I think it's the same thing with the PMBOK. We've forgotten that it's not written solely for software but for all project management. The PMBOK says these are generally recognized good practices, so what people have done is read this and thought this is something I must do. PMBOK is a guide. When you take it as a must-have then you must erect a framework around it like waterfall, and the next thing you know everyone is using waterfall. The birth of the misconception is that you have to do waterfall to be in keeping with PMBOK and it's just not true.
So what are some similarities and differences between PMBOK and agile practices?
Sliger: One thing PMBOK mentions is progressive elaboration, which is what agile requirements definition is all about. Progressive elaboration takes a high-level view of requirements and only gets down to details when you're ready to work on them. Also with PMBOK is the idea of using rolling wave planning -- you plan to a certain point, go through a few iterations, take a look and plan for the next time frame, as opposed to the traditional view of planning at the beginning of a project.
The main difference is [agile doesn't] use all of the practices [in PMBOK]. We use some, like rolling wave planning. [Another difference is] not doing the types of formal documentation that PMBOK alludes to but does not require … and PMBOK puts quite an emphasis on quantitative analysis, which agile doesn't tend to do as much.
Do agile project managers use traditional PM tools?
Sliger: I haven't touched a Gantt chart in a decade. They were designed for long-term projects that weren't being worked iteratively. The tools agile uses tend to be more clear and appropriate for iterative development. They don't have the idea, like in a Gantt chart, that a project can be 90% complete for weeks at a time. You look at a burndown chart where there's no 90% -- it's either done or not. And if you're done with that feature it means it's potentially shippable. When you look at a burndown chart you can tell more quickly how close you are to meeting your commitment. It's a clear picture on the real status.
If you're not colocated, you must have some kind of tooling and an infrastructure to support that tooling. You're working at a very fast clip, so you will need tools like Skype, IM, some shareware like CardMeeting.com for brainstorming, or XPlanner, which helps with agile project management. All agile PM tools provide these basics: a place where the product backlog is maintained, a place that holds iterations, features being worked on, test results and often the tests themselves.
How will a PM's responsibilities change with agile?
Sliger: They'll have to inspect their leadership style. If they've been command and control, they will have to move away from that, to where their No. 1 thing should be, how can I help my team today? Once the team is self-organizing and high-performing it's not like their jobs end. They still have to be concerned with agile adoption throughout the organization. Their role may be more strategically focused as opposed to more on the ground with the team. They can turn their energy to helping the organization adapt to agile.
Is the PM still held accountable for the success or failure of the project?
Sliger: In Scrum, Ken Schwaber has said the single wringable neck belongs to the product owner, not the project manager. The product owner is the business rep and has the authority to make decisions about the product. You could think of [responsibility] as a triad: the product owner who owns the product backlog, the team that owns the estimates and is responsible for delivery, then the Scrum Master/agile PM who's responsible for helping the team to meet commitments and protecting the team from outside distractions. The PM is there to protect the team and fight for the team in terms of making procurements, budgets, etc.
Are there common mistakes to avoid in the transition to agile PM?
Sliger: Don't think that transitioning to agile is simply a matter of tool substitution. Don't think you can put down the Gantt chart and pick up a burndown chart, and poof, you'll be agile. Agile is a philosophy, and [it's] value-driven instead of plan-driven. You have to understand that paradigm. The biggest mistake I see people making everywhere, regardless of company size, is they think it's a new methodology with specific rules, and these are the tools they're using. That's not going to make you an agile team -- that will make you a waterfall team using agile tools.
Michele Sliger is co-author, along with Stacia Broderick, of the 2008 book The Software Project Manager's Bridge to Agility. Sliger is the owner of Sliger Consulting Inc., which helps teams with agile adoption, and helps organizations prepare for the changes that agile adoption brings. She is a certified Project Management Professional (PMP) and a Certified Scrum Trainer (CST).
|
|
|
|
