Do agile projects typically have project managers?
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. Are the functions similar?
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
Requires Free Membership to View
When you register, you'll receive targeted emails designed to keep you informed of the most relevant information on Agile development, application security, testing & QA, software requirements, and more.
Hannah Smalltree, Editorial Director
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)?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?
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?
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?
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?
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?
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).
Join the conversationComment
Share
Comments
Results
Contribute to the conversation