I recently published the article below on the Project Management.com website (see Project Managers Still Don’t Get Agile). The point that I was trying to make is that while there may be a few middle and project managers who get it, the majority of project managers don’t understand agile or agile project management.
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
Those traditional project managers who practice Scrum or agile project management 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 otherwise well-meaning middle managers and project managers. Stop it.
I understand why they do it. These days, they can’t afford to say that they 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…they 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.
Traditional PMs Need Firsthand Agile Experience
Unless project managers have firsthand experience on an agile team (not as a project manager), they won’t really understand agile. They will continue to treat agile approaches as just another version of what they have always done.
The challenge is that their previous experience acts as a filter or lens that limits their understanding. They will translate agile concepts into terms they know. As an example, they translate the daily Scrum into a status meeting and the ScrumMaster into a project manager.
Though a project manager will read “sustainable pace” and think it’s great, they 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 undermine 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.
PMs Should Master Scrum and Agile Project Management
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 that project managers have 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.
For those project managers that don’t buy-in to the mindset and benefits of agile, stop. Don’t practice agile in name only. Get out. Go work somewhere else where they don’t use agile.
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.
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 19 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.
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.
Finally, apply frameworks like Scrum the way they were intended to work. Don’t break the rules. 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.
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 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.