The Need for Agile Project Management

One of the common misperceptions about agile processes is that there is no need for agile project management, and that agile projects run themselves. It is easy to see how an agile process’ use of self-organizing teams, its rapid pace, and the decreased emphasis on detailed plans lead to this perception. In a recent egroup, a project manager at a company that was implementing agile had been moved to another area because, “…agile doesn’t require management.” However, agile processes still require project management. In this article we will look at the reasons why and the types of management.

The Need for Agile Project Management

Project management is critical to the success of most projects, even projects following agile processes. Without management, project teams may pursue the wrong project, may not include the right mix of personalities or skills, may be impeded by organizational dysfunctionality, or may not deliver as much value as possible. We are beginning to formalize these management responsibilities. In the process, we hope that they become clearer to those beginning to implement agile processes, without those people losing the feeling for people, collaboration, and interactions that underlie all agile processes. The below table summarizes these Agile project management responsibilities.

Agile Project Management and Shared Vision

For a team to succeed with agile development it is essential that a shared vision be established. The vision must be shared not just among developers on the development team but also with others within the company. Most plan-driven processes also advocate the need for a shared vision; however, if that vision isn’t communicated or is imprecise or changing, the project can always fall back on its detailed (but not necessarily accurate) lists of tasks and procedures. This is not the case on an agile project and agile project participants use the shared vision to guide their day-to-day work much more actively.

The formation of the project vision is not the responsibility of the agile project manager; usually the vision comes directly from a customer or customer proxy, such as a product manager. The project manager, however, is usually involved in distilling the customer’s grand vision into a meaningful plan for everyone involved in the project. Rather than a detailed command-and-control plan based on Gantt charts, however, the agile plan’s purpose is to lay out an investment vision against which management can assess and frequently adjust its investments, lay out a common set of understandings from which emergence, adaptation and collaboration occur, and establish expectations against which progress will be measured. The project manager works with the customer to layout a common set of understandings from which emergence, adaptation and collaboration can occur. The agile project nurtures project team members to implement the vision

Agile Project Management and Obstacles

Imagine yourself on a bicycle pedaling along a road some warm summer day. After the ride is done you may look back on it as having been relatively free of surprises; however, while riding you probably had to avoid a number of obstacles: the glass in the road, the narrow shoulder, the car turning left in front of you, and so on. Most of these obstacles are easily avoided by a little forethought and by looking ahead on the road. You don’t need to plan the entire trip in advance (“At 9:43 a.m. remember to avoid the pothole on 95th Street”) but paying attention and glancing down the road help you avoid obstacles or even head-on collisions. Participating in an agile project is much the same way: a little forethought and looking ahead go a long way toward improving the journey.

Most agile processes prescribe a highly focused effort on creating a small set of features during an “iteration” or “sprint” after which the team quickly regroups and decides on the set of features for the next iteration or sprint. While an iteration is ongoing the team members are expected to focus exclusively on the current iteration.

While this sharp focus leads to greater productivity during the current iteration it can cause a bit of a billiard-ball effect as the conclusion of one iteration can bounce out the start of the next. A project manager who spends a small amount of time looking forward at the next iteration is an excellent buffer against this effect. For example, many organizations have travel restrictions that require plane tickets to be purchased two weeks in advance. If a team could benefit from having a remotely located employee on site during the coming iteration the time to plan for that is during the current iteration.

Another type of obstacle may be a team member.

While agile processes such as Extreme Programming and Scrum rely on self-organizing teams, an agile project manager cannot simply turn a team loose on a project. The agile manager must still monitor that corporate policies or project rules are followed. Participation on an agile team does not turn all developers into model employees. In most cases the team itself will employ some form of sanctioning on an employee who is not working hard enough or is exhibiting other performance or behavior problems. However, in the most severe cases the collective team usually cannot be the one to terminate or officially reprimand an employee. Performance feedback can always be expressed in terms of team views of the individual’s contribution to the team (e.g., “I’ve discussed it with members on the team and we do not think you are being careful enough in your unit testing”). But if a counseling or coaching session is necessary it is usually best when between just the project manager and the team member.

Agile Project Management and Organizational Dysfunctionality

Many companies have at least one dysfunctional area. This may be the “furniture police” who won’t let programmers rearrange furniture to facilitate pair programming. Or it may be a purchasing group that takes six weeks to process a standard software order. In any event these types of insanity get in the way of successful projects. One way to view the project manager is as the bulldozer responsible for quickly removing these problems.

The Scrum process includes a daily meeting during which all team members are asked three questions. One of these questions is, “What is in the way of you doing your work?” The agile project manager takes it on himself to eliminate these impediments. Ideally, he or she becomes so adept at this that impediments are always removed within 24 hours (that is, before the next daily meeting).

Participate in enough agile projects and you begin to hear the same impediments brought up time after time. For example:

  • My ____ broke and I need a new one today.

  • The software I ordered still hasn’t arrived.

  • I can’t get the ____ group to give me any time and I need to meet with them.

  • The department VP has asked me to work on something else “for a day or two”





  •  
  •  
  •  
  •  

The project manager is responsible for optimizing team productivity; this means it’s his responsibility to do whatever possible to minimize obstacles. Most organizations will not want every developer calling the ordering department to follow up on delivery dates for software. Similarly, a project manager who can know when to push the IT manager for quick setup of a new PC and when not to push (perhaps saving a favor for later) will be more effective than every programmer calling that same IT manager.

Agile Project Management and Politics

Politics are at play in almost every organization. Most organizations have only limited funds that may be applied across a spectrum of competing projects and new project ideas. Projects compete for budget dollars (team size, tools, etc.), personnel (everyone wants the best programmer), resources (time or access to the large database server), and attention from higher level managers. Too many projects fail for political reasons. A project manager uses the various agile mechanisms to minimize politics and keep everything visible and obvious.

For instance, the project manager works with the customer to ensure that the product backlog (Scrum) or stories (XP) is visible and everyone understands that it directs the team to the most profitable and valuable work possible. The project manager uses product increments and demonstrations of working functionality to keep everyone aware of real progress against goals, commitments, and visions, thereby minimizing opportunities for rumors, misinformation, and other weapons of political maneuvering. Working with the customer, the project manager helps the customer and organization to value results instead of reports.

Agile Project Management Conclusions

Robert Greenleaf has introduced the concept of the “servant-leader.”1 Perhaps this is the most appropriate way of thinking of the agile project manager. On an agile project the project manager does not so much manage the project as he both serves and leads the team. Perhaps this is one reason why, anecdotally, it seems much more common to see an agile project manager also function as a contributor to the project team (whether writing or running tests, writing code or documentation, etc.).

Plan-driven software methodologies use a command-and-control approach to project management. A project plan is created that lists all known tasks. The project manager’s job then becomes one of enforcing the plan. Changes to the plan are typically handled through “change control boards” that either reject most changes or they institute enough bureaucracy that the rate of change is slowed to the speed that the plan-driven methodology can accommodate. There can be no servant-leadership in this model. Project managers manage: they direct, administer and supervise.

Agile project management, on the other hand, is much more about leadership than about management. Rather than creating a highly detailed plan showing the sequence of all activities the agile project manager works with the customer to layout a common set of understandings from which emergence, adaptation and collaboration can occur. The agile project manager lays out a vision and then nurtures the project team to do the best possible to achieve the plan. Inasmuch as the manager represents the project to those outside the project he or she is the project leader. However, the project manager serves an equally important role within the project while acting as a servant to the team, removing their impediments, reinforcing the project vision through words and actions, battling organizational dysfunctionality, and doing everything possible to ensure the success of the team. The agile project manager is a true coach and friend to the project teams.

1 Servant Leadership, Robert K. Greenleaf.


Get Your Free Scrum Cheat Sheet

Get Your Free Scrum Cheat Sheet

Sign up below to receive this FREE reference.

21 Comments:

Suzie Nguyen said…

Hi Mike
I was recommended by a friend who knows about Agile Project Manage software well

We are from the University of Technology Sydney. Projects are things that we do everyday.

We manage several projects concurrently using Ms Project Management methodology. I agree with your comments that sometime it isn’t the best solution for team and knowledge collaborations.

I am keen to share this with my team tomorrow morning and was hoping if you could let me access to a trial version?

I am keen to do some more home work tonight!

Hope to hear from you soon.

Kind regards
Suzie Nguyen

Mike Cohn said…

Hi Suzie—
I am not sure what you are looking for a trial version of. We don’t produce any software for managing agile projects. The only tools we produce are all free and are available at http://www.mountaingoatsoftware.com/tools

Christophe said…

Hi Mike,

Quite a few people including Jim Highsmith (Envision, Speculate, Explore, Adapt, and Close) have described a project framework from initiation to closure of a project. Different terms have been used such as “inception” or “sprint 0” for early stages of a project before starting the first sprint. We also have DSDM atern v2 (even adapted to scrum). Construx are describing a stage-gate process.

So my questions: would you recommend a light-weight but still formal way you get ready a team to start their first sprint? How are you handling a “sprint 0”? Would that be the PO to “run” these stages or a project manager?

Quite a long topic tough!

PS: I like Diana Larsen’s project chartering approach before release planning.

Mike Cohn said…

HI Christophe—
Sprint 0 works but I’ve never been a fan of that generally. It’s often used as an excuse for a variety of things (to relax for a few weeks, to think too far ahead, etc., depending on the team). I do completely support the concept though when it is truly necessary.

Mostly I talk about there being a “project before the project.” The “project before the project” is a project to decide if the real project is worth taking on. Often that requires the analysis and architecture type activities that would occur in a Sprint 0. A big problem with calling it “Sprint 0” though is doing so implies you can only have one such sprint. Sometimes we need more than one sprint—a “project before the project” (run using Scrum itself) allows for that on the occasions when more is necessary.

Jeff Godart said…

Great article and overview of Agile Project Management.

thanks
Jeff

Mike Cohn said…

Thanks, Jeff.

Roberto Colferai said…

Thank you for your useful article. I’m “on the bridge” from waterfall PM and related Gantt and Agile project. In a snap I steer to servant.leader (I hope…)

mikewcohn said…

You’re welcome, Roberto. Good luck getting across that bridge quickly!
Speaking of bridges, you may want to check out the book, “Software Project Manager’s Bridge to Agility” by Michele Sliger and Stacia Broderick since it covers exactly what you’re dealing with. My review of it is at http://

Kapil said…

Hi,
I read this article quite late :(.
I have followed Sprint 0 in couple of my projects and it has worked brilliantly. The business requirements were quite high level in terms of domain as well as architectural needs.
We utilized time boxed Sprint 0 to do some R & D on tools and got better clarity on functional needs. This was fitting well with organization processes as well.
We kept Sprint 0 duration to be around one month in complete project duration of approx 8 months.
Regards

mikewcohn said…

Hi Kapil—
A lot of people are fundamentally opposed to Sprint 0. I’ve got some concerns with it (it’s often used as an excuse to slow down; which I’d rather just admit the need for). But it sounds like you had a very justified sprint 0 in your case.

Kapil said…

Thanks Mike and Point taken well.
Regards

Honorio Daboin said…

Hello Mr. Cohn,
Thank you for posting the article. I really like the way that you grouped the information about the Agile project manager responsibilities. I started three weeks ago a class of Agile process, and I think this is a good summary in order to get a clear picture between Agile project management and traditional project management. I really believe that the more clear the information is presented to the individual; the easier to understand and move forward for the next topic. In my opinion, as a Project manager in transition to Agile Project Manager, understanding the processes from the beginning is an important key for success.
Thank you again for providing this article of Agile Project Management.
Best regards,

Mike Cohn said…

Thanks. I’m glad you found this helpful.

Charles T. Betz said…

Mike, thanks for posting this. There is a trend lately to question whether project management is still relevant, if an organization commits to a product-centric approach. Speaking as adjunct faculty in a large SEng/IS program, deprecating project management would be a significant move, curriculum-wise. Trying to get various folks’ opinions. Thoughts?

Mike Cohn said…

Hi Charles—
I remember being involved in some discussions about this around 2001, right after the Agile Manifesto. Some people were claiming then that projects were dead and that we were instead in a world of (mostly) steady-state development. An example today could be something like Google AdWords. Someone could get a job on that at the age of 21 and work on AdWords for the next 40 years. Could that then be called a “project”?
Well, I still think it can because there would be discrete things being done to (in this case) AdWords. I think things generally progress in a series of projects even though a big picture may view it as a steady-state development effort.

Charles T. Betz said…

Hi Mike, I think that Google would consider AdWords a “product.” If we take the PMI definition of project seriously, they are temporary. Products on the other hand exist as long as needed. Writing on this here: http://dm-academy.github.io/ai…. Much written by others on project vs product.
What I am trying to determine is when do we need a true project, with the formalized PMI approach, vs just steady state flow of features? Certainly, if I were doing a big asset refresh or data center realignment, I’d probably use a project plan, because many dependencies in such work *can* be known in advance, analyzed in detail, and you really need to do so. But iterative, software-based products? I’m hearing rumor of multiple PMO shutdowns…  More here: http://tdan.com/the-digital-tr…

zhao shufeng said…

Hi Mike
In our company we have a PMO department which have most our project managers/scrum masters, each scrum master are running 2-3 teams now. We’ve been trying to adopting agile for about 3 years, after a recent scrum training in our company’s leadership team the ‘self organize’ become a very popular words in our company.
People start to talk about the career of scrum master, since people are expecting if a scrum master really well, he/she will coach the team to be well self organize so that our organization do not need that many scrum masters
What do you think of the scrum master’s career path? Do you think some of the project management work such as planning and tracking and reporting status are still scrum master’s work? what’s the future of the scrum masters?
Thanks

Vishal Patidar said…

Dear Mike,
Thank you for sharing such an amazing insights on Agile project management. They are so relevant even though you wrote them long time ago.

Shiju Joseph said…

This was just what i wanted to read today as I help with a transformation project. Merci!

jay anderson said…

I am so glad to come across such an informative & engaging write-up about Agile project management. At the same time, we all must know about the major benefits of using Agile.
https://