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:
- Project managers are very command-and-control oriented
- 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:
- “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.
- 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.
- 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!