Is Agile Project Management an Oxymoron?

Is Agile Project Management an Oxymoron? A few years ago, I attended a presentation by a well-known agilist who said that “Agile Project Management is an Oxymoron”. That kind of perception is based on a lot of stereotypes about Project Management that need to be changed. Here are some of those stereotypes that exist:

  1. Project managers are very command-and-control oriented
  2. Project managers are heavily associated with plan-driven “Waterfall” processes and document-centric methodologies where you need a plan for almost every aspect of any project and you also need a document, checklist, or a form for almost anything you do; and there is no role for a Project Manager in an Agile environment that requires a much more adaptive approach

There are certainly project managers who have some of those characteristics, but it’s unfair to make a judgment that all project managers are that way or to write-off the whole project management profession as being irrelevant to Agile because some project managers may be that way. However, we in the project management profession need to recognize the impact of Agile and recognize that a shift in thinking is needed to broaden our perspective on project management to correct these stereotypes that do exist. Here are some of those shifts in thinking that I believe need to take place.

  • Command-and-Control Orientation

Project managers are noted for getting things done and as a Project Manager, I’ve been in numerous situations where a customer has expected me to “ramrod” a project to get it done to meet time and budget constraints. That’s the way Project Managers have operated for many years and it naturally leads to a very assertive role where the Project Manager takes total responsibility for the success of the project and drives everyone on the project team to deliver results to achieve success. Both project managers and their companies need to recognize the limitations in that approach.

The Project Management profession needs to go through some changes that I saw the Quality Management profession go through a long time ago. In the early 1990’s I worked in the Quality Management profession. What I learned at that time was that it is self-defeating for a Quality Manager to take on too much ownership for quality. An effective Quality Manager has to be somewhat of a “missionary” and engage others in the effort to own responsibility for “quality” to be successful. If the only people who are responsible for “quality” are the people in the Quality Management department or the Quality Assurance department, it’s not going to be very effective.

The same thing also applies to project management. The project management responsibility for an Agile project should be shared by everyone on the team – even a developer has to be a little bit of a project manager to plan, organize, and manage the tasks that he/she is responsible for. Operating in this environment calls for more leadership than management – a leader sets the vision as well as goals and objectives to be accomplished; puts in place the people, process, and tools to get it done; and then steps out of the way as much as possible.

That approach is counter-cultural for many project managers because project managers are noted for getting things done and many companies expect that of their project managers. So it requires a shift in thinking in both project managers and the companies who manage them to bring about this change in orientation. There is also a natural resistance to this in some instances because if you do it successfully and really empower the teams you manage, you can eliminate the need for a project manager and put yourself out of a job and that might be the right thing to do – there is no defined role for a Project Manage in an Agile team that is working as it should be. The key thing is that it requires a change in thinking in project managers to let go of that role that they may have played in the past and move up to playing a higher-level role that provides more value-added. It’s ironic, that as I think back on some of the recent projects I’ve managed, if I’m asked what I did to make it successful, the answer is “I did as little as possible”.

  • Association with “Waterfall” Methodology

    Project managers are also heavily associated with plan-driven, document-centric approaches like the “Waterfall” methodology that can be extremely cumbersome and bureaucratic and there is no need for a project manager in an Agile environment. Unfortunately, I think this stereotype is somewhat legitimate and I know a number of project managers who are still holding on to a traditional PMBOK-style, plan-driven, document-centric, “Waterfall” approach to project management. I think there are a number of possible reasons for that:

    • Job Security – Many project managers have been heavily trained in traditional project management skills and PMBOK and it’s a big risk to give that up because that’s what their knowledge is based on and that’s the value-added that they have been trained to deliver. The role of an Agile Project Manager is also very undefined and uncertain at this point and might require a significant amount of retraining. It’s understandable that some project managers might not feel comfortable making that leap of faith to re-orient their career around Agile Project Management
    • Binary, All-or-nothing Thinking – A lot of people on both sides of the fence have the perception that it is a binary choice between a totally plan-driven and heavily controlled approach (e.g. “Waterfall” and a totally unplanned approach with no control (e.g. “Agile”) and that is not the case. I’ve previously written a couple of articles on that subject:

      Many project managers and many companies do not see that there is a lot of middle ground between extreme Waterfall and extreme Agile…those alternatives may not be well-defined and it can take more skill to figure out how to develop an approach that blends the right proportion of Agile and traditional project management principles and practices to fit the situation but it definitely can be done. Unfortunately, many people make the mistake of force-fitting their business and their projects to one of these extremes rather than fitting the methodology (or combination of methodologies) to their business and to each particular project.

What is the solution to this? This is basically a change management problem and I’ve learned over the years that there are three elements that are essential to any significant change management initiative:

  1. “Burning Platform” – There has to be a sufficient level of “pain” associated with the current situation to recognize that it is untenable and making a change is crucial. People have to get past the “denial” stage and recognize that Agile has a profound impact on the project management profession and in the not-too-distant future, project managers who only know how to do traditional project management PMBOK-style Project Management and don’t know how to take a more Agile and adaptive approach when it makes sense are going to be at a serious disadvantage in the job market.
  2. Vision for the Future – The next step in any successful change management initiative is that there has to be a vision for what the future looks like after the change has taken place. To do that, we need to better define what an Agile Project Manager is and what role he/she will play. I’ve tried to help develop that vision with the two books I’ve published but there’s still work to be done in that area to better define that vision. I’m currently working on developing a graduate-level course on Agile Project Management with a major university in the Boston area that I’m hoping will also help fill this need.
  3. Progress in the Right Direction – In any change management initiative, there will always be some hold-outs and laggards who will wait on the sidelines to see if the change is going to be successful or not before jumping on board. I’m sure that there are a number of project managers who don’t want to take the risk of becoming Agile Project Managers until that role is much more well-defined and proven and they will wait until more people have actually demonstrated success in that role.

That will obviously take time and isn’t going to happen overnight, but the first step is to recognize the problem. I hope this blog post helps others see this problem as I do. I welcome your comments and thoughts on this!

4 thoughts on “Is Agile Project Management an Oxymoron?”

  1. Interesting post.

    I would like to add the following:
    – Almost all PMs who I met are insecure. Unless the PM role is secondary to a main role, for example product owner.
    – Many organizations are not having structure for Agile delivery. For example a new team is formed when a project is initiated who are partially allocated, and reporting to different managers. Such setup will need PM.
    – Scrum Master role is to large extent overlapping with the role of PM.
    – Depending on the organization, but in high tech companies, PM can be perceived easily as coordinator especially if he is not a a manger.

    The roles of PM, coach, business Analayst and Scrum Master are highly overlapping and confusion happen when they are played by different people in the same project.

    1. Good comments…I agree that there is a lot of confusion about roles in an Agile project (PM, Scrum Master, Product Owner, etc.) and that many companies try to implement a “hybrid” Agile approach without a clear idea of how it should work and what the roles are. It is totally understandable that a PM would be insecure in that kind of environment.

  2. This is a very interesting topic to me because I’ve been figuring out what an Agile PM is for about ten years now. I started when I was given the “project manager” role on a team that had recently adopted Extreme Programming. The team had been floundering before this, not able to release anything on any kind of schedule. So, adopting a promising methodology and assigning a project manager (me) was the way the problem was addressed.
    Over the years my role morphed in activity sets and emphases. At one point I championed Scrum over XP and became the Scrum Master and Scrum Coach. At another point I took traditional PM courses and examined how traditional tools and techniques might help solve some of our challenges. Lately I have been helping our organization adopt Lean-Agile portfolio planning. I was also recently asked to come on board a troubled project. Traditional PM practices were needed in that case – and yet an Agile mindset flavored the way that I applied them.
    All in all, I would say an Agile PM needs to adopt the Agile mindset and be well versed in both traditional and Agile methodologies. Understanding why each methodology works is just as important as understanding the mechanics. That way the best approach can be applied for any given challenge.
    A metaphor I think of when thinking about the value of the Agile PM is flying altitude. Whereas implementation teams work in the detail level (“the trees”) most of the time, the Agile PM works more in the big picture level (“the forest”). I find that the greatest value I offer is to help teams stay focused on delivery targets, support scrum masters and product owners, and be the liaison between delivery teams and the rest of the enterprise.
    Some very specific things from the traditional PM world that our Scrum teams have benefited from: risk analysis, stakeholder analysis, value analysis, more formalized chartering. Some specific things from the Agile mindset that the enterprise has benefited from: Lean-Agile proposal analysis, Just In Time planning and decision making, self-organized teams, end-to-end visibility and empowering people to fix bottlenecks. An Agile PM can help all of these things happen so that everyone works more effectively.

    1. Great comment, Rob…it sounds like a lot of people are trying to figure out this role and it is clear that there is value-added from the PM role if we can learn how to blend it together with Agile in the right proportions.

Leave a Reply

Your email address will not be published. Required fields are marked *