Project Managers Still Don't 'Get' Agile

I recently published the article below on the Project website (see Project Managers Still Don't Get Agile).  The point that I was trying to make is that while some project managers do understand and apply agile approaches, most project managers don't understand it. They don't want to understand it, and they actually undermine Agile adoption in their organizations. The post received a number of comments that I was right on target, and others that indicated I was off base. What do YOU think?

Project Managers Still Don't "Get" Agile

If you are a traditional project manager practicing agile methods, chances are you don’t really “get” it. Nothing has been worse for the understanding and proper application of agile approaches in organizations today than the flawed thinking and actions of well-meaning middle managers and project managers. Stop it.

I understand why you do it. These days, you can't afford to say you don't know or use agile. Agile is so popular and in demand that not understanding and using it would indicate you are outdated and out of step. Who wants to admit they aren’t agile? So it's popular to say that you get it and use it. Everybody does it.

Only…you really don’t get agile. As a long time project manager, I can relate. I didn't always get it when I first learned about agile and Scrum. I didn't believe it when I was told in my first agile training that project managers don't make good ScrumMasters, or that the best solutions come from self-organizing teams. I had to work my way through that and unlearn many of the things I had come to believe about the best way to organize people and deliver complex technology solutions.

How You Don't Get It

Unless you have firsthand experience on an agile team (not as a project manager), you won't get agile. You will continue to treat agile approaches as just another version of what you have always done. Your previous experience will serve as a filter or lens that limits your understanding. You will translate agile concepts into terms you know. You translate the daily standup into a status meeting and the ScrumMaster into a project manager. You read “sustainable pace” and you think it's great, but you make no qualms about using overtime to make sure teams hit the scope and schedule targets someone else set for them.

It reminds me of the way that many of us in the United States treat the metric system. We don't really know what a kilogram, meter or degree Celsius is without converting them to things we are familiar with: pounds, yards or degrees Fahrenheit. The problem is that there are many agile concepts that we don't have anything familiar to translate to, like self-organizing teams. A project manager looks at a self-organizing team and thinks that they are incomplete and ready to fail without a project manager.

Another reason project managers don't get it is because the idea of a self-organizing team operating without a project manager is threatening at a deep, subconscious level. If a team operated fine without a project manager, what value would you add? So you simply don't accept it.

Project managers also assume things about agile that aren't true. They read a little about Scrum and think that it describes what they are already doing. Only it doesn't. As they read the guide, they mentally insert themselves and the project manager role into the framework when, in fact, the Scrum Guide doesn’t even mention project managers. The project manager doesn't have a role in Scrum. The activities that the project manager would do are either handled by the product owner or the Scrum team—or ignored.

Undermining the Effective Use of Agile in Organizations

This widespread misunderstanding and misuse of agile concepts undermines true agility everywhere. Here are some specific ways that project managers contribute:

1. Re-branding traditional project activities as agile. Project managers re-label what they are currently doing with agile terms. Status meetings magically become standup meetings or Scrums. Project managers insert "sprints" into existing waterfall project plans, even though each sprint is eight weeks long and contains a phase for analysis, development and testing. That's just waterfall folks, not agile.

2. Not really learning agile. Probably the most egregious re-branding project managers do is to call themselves ScrumMasters, especially when they don't understand the role or practice it with any competence. Just because you took a Certified ScrumMaster training course doesn't make you a ScrumMaster.

Zen teacher Shunryu Suzuki said, "In the beginner's mind there are many possibilities; in the expert's mind there are few.” Most PMs, perhaps for fear of embarrassment, don't act like beginners who are open to learning about agile. They act as if they already know everything.

3. Not buying in. Some former project managers who are working as ScrumMasters or product owners tell me privately that they don't believe agile is a better way of working. They disagree (though not openly) about the organization's commitment to using agile methods. They don't want to use agile.

But they stay in the role and they go through the motions. They are waiting around for agile to fail (and perhaps helping it to fail). Or they are keeping their heads down, hoping for regime change and a return to more traditional approaches. This kind of behavior is insidious and slowly eats away at the organization's effectiveness and commitment to agile.

4. Continuing to practice command and control. Project managers also continue command-and-control behavior with teams that are capable of leading themselves. They collect the task status from everyone instead of teaching the team to self-organize, or they "drive" meetings and "push" the team for higher productivity or to hit deadlines. They don't really understand team member motivation or how to create an environment for high-performing teams. Instead, they run reports of the hours team members worked on tasks or go around checking up on people so that they don't slack off.

And the project managers look down on the team. It may be subtle, but it's there. The project managers worry about all the “gotchas!” and ways the team can fail, rather than coaching the team and holding them in positive regard. They assume the team can't or won't do things for themselves, or attribute negative characteristics like laziness to them.

I've seen project managers treat team members like a parent would treat a child. Project managers don't believe that the people closest to the work can be trusted to figure out the best way to manage tasks, communicate with each other and manage dependencies.

Project managers also accept fixed deadlines and scope goals from stakeholders and then try to hold the teams accountable. They create estimates for the teams, rather than leaving the estimates to those who will do the work. Teams won't really commit to goals they feel are unrealistic and that they did not set for themselves.

What You Should Do

  1. A good first step would be to stop discrediting agile approaches by calling them "nothing new under the sun." Agile is not the same thing you've always done. Agile is a mindset change and way of working that is based on four values and 12 principles. It's a proven way of organizing teams and building high-quality solutions. 
  2. For those of you that don't buy in to the mindset and benefits of agile, don't practice agile in name only. Get out. Go work somewhere else where they don't use agile.
  3. Or if you are open to learning, suspend your disbelief about agile. Adopt a beginner’s mindset. Let go of what you think you know about agile and really strive to understand. Master the agile values and principles. Go observe others who are using agile correctly.
  4. If you are going to take on the role of ScrumMaster, then you need to really master Scrum. Taking the two-day CSM course is a small first step. Get a copy of the Scrum Guide (it's only 16 pages) and read it thoroughly. Hit the books. My Scrum trainer insists that aspiring ScrumMasters should read over 70 books on topics ranging from software development to human resource practices to systems thinking, Lean and the Toyota production system.
  5. If you are in the ScrumMaster or any other leadership role, learn and practice servant leadership. Serve the highest needs of the team. Hold the team in positive regard and support it to self-organize. Work on creating an environment where people can do their best work. Stop trying to control the team, or doing work for it that it can do for itself.
  6. Finally, apply frameworks like Scrum the way they were intended to work. There is a reason that there is no role for the project manager in Scrum. Don't assume that there is one. Don't rebrand your traditional practices as agile; calling something by agile terms doesn't make it agile.



Jonathan Lee, Founder and Managing Director of Riics Inc. 

Project Managers Still Don't 'Get' Agile

Great article. Thanks for pointing out some of the key common mistakes PMs make as they attempt to transition into Agile methods. 

I think project managers can become a great agile practitioners; however, as you stated it will require changes in their thinking and approach and it will take work to become a good or even great ScrumMaster or even a Product Owner, if they have the industry knowledge.

By work, I mean, learning to be a servant leader and taking that to their heart and helping/coaching team members to become leaders themselves, letting go of the PMs' tendency to control, be comfortable with talking in story points or T shirt sizes instead of hours in estimating, and being transparent with stakeholders and scrum team on the status of the project so that the team can make decisions that directly impact the project.

With that said, I also believe an Agile PM can exist in an agile environment. It's not a traditional PM role but rather one that practices servant leadership and provides leadership to the team and the project and be the unified voice of the project team to the sr mgmt. and/or stakeholders/client. When the agile team matures and leaders are groomed then the Agile PM moves on to other projects.


Anthony, while I enjoy your writing, I believe this article lacks empathy for anyone who finds themselves in the role of Project Manager and have spent many years developing and honing their project management skills. For years they carried the burden of delivering the entire scope on time and within budget. Now there is a new way of working that turns all that on its head - that is sending messages that they are no longer needed, what they did was irrelevant, their skill-set and tools are outdated, they are the cog in the wheel - all without showing them a path forward. If you found yourself in that position, how would you react?!? I have seen some project managers make GREAT Scrum Masters/coaches, some others make GREAT Product Owners and others have rediscovered their passion for analysis, development, testing etc. I agree with Jonathan that Agile PMs may make great delivery coaches - coaching young self-organizing teams on the project management skills that they now own (which they often lack). Yes, they need to take ownership of building their new skills - as does every role in an organization. I have heard this from other Agile coaches and I believe this to be true - we cannot force a change on people, we have to invite them into a new way of working by painting a vision of a better future where they can see themselves, and helping them muster the courage to take a leap of faith (because until you experience it work, it is a leap of faith). If we, as agents of change and servant leaders can't do that - perhaps as we point a finger in their direction, we have to be aware there are three more pointing right back at us!

With utmost respect, Tony: horse hockey. PM still exists in Agile projects, because the Triple Constraint still exists. (Berlin Agile Review, Aug.2013). The Agile Project Manager is not the Scrum Master; the SM is an embedded value-adding member of the agile Team. The Product Owner can't be held responsible for time and cost; it's a compromise against the product at best, and always a conflict of interest. So the Agile Project Manager performs the traditional functions in a new way: the invisible servant leader. And with all due respect Tony, yes, the PMI-ACP 'gets it'.

I agree with Jonathan Lee. Especially when some or many of the team members are new to Agile, the teams often spend to much time and energy trying to make sure they are adhering to what they think are the strict rules of Agile (when there are no strict rules in Agile) and miss that they are moving off course of stakeholder's needs. Someone or someones on the team needs to be able to identify when that is happening and coach the team on finding their way back. The team can solve the problem, but someone has to identify that the problem exists. That could be an Agile PM or Coach or just an experienced Agile team member. An example - the team works with stakeholders to prioritize user stories individually rather than as part of goal directed user flows. You end up with a bunch of completed stories and no completed flows. The stakeholders lose interest because they can't see any of their goals being reached. When the flows are finally completed the stakeholders don't approved them without substantial rework. The team complains that the individual stories were all approved. The team thinks it was doing proper Agile. You need someone on the "self directed team" to spot that this is happening early on and get the team understanding the importance of goal directed work flows in prioritizing user stories.