PM Articles > Kent McDonald > Do Project Managers Have a Role in Agile?

Do Project Managers Have a Role in Agile?

by Kent McDonald

Organizations moving to agile methodologies naturally have to embrace self-organized teams, which can leave managers wondering where they fit in. While introducing teams to agile, I often have the opportunity to help these lost managers figure out their new role. One organization I worked with recently had one manager for the developers on the team -- we'll call this the Technical Manager -- and another managing the relationship with the business stakeholders -- the Account Manager. Both managers were new to these roles; the organization had split responsibilities between technical ownership and the business relationship just a few months before. Both managers were having difficulty figuring out where they fit in the grand scheme of things, but for different reasons.

Life as an Agile Account Manager

The Account Manager's (AM) biggest question was "What do I tell the business?" He struggled with how to convey information to the team's stakeholders. The AM thought he needed to provide the stakeholders with their accustomed status information -- for example, how long specific features would take to deliver -- even though the delivery team often struggled to provide that type of information. Part of the problem was that the team had difficulty sizing their work and breaking it down into consumable chunks of work. More importantly, though, no one introduced the stakeholders to agile approaches and explained how the new approaches would impact their experience. Over the years, the delivery team had done a very good job of training their stakeholders to expect hour and dollar estimates, so the stakeholders didn't know how to react when they no longer received that type of information.

Most stakeholders in enterprise-driven efforts do not live in a project-focused world. Their knowledge of project work comes from the project teams they work with. They have been taught to expect hours and dollars. When the project team changes that up, stakeholders naturally rely on the delivery team to explain the difference. Otherwise, they expect the same type of information they have always received.

In this situation, many of the problems were of the organization's own making. The AM belonged to an IT area that played a big part to play in establishing stakeholder expectations to begin with. Like all IT departments, they had trained their stakeholders to expect certain things. Likewise, the delivery teams had conditioned their stakeholders to provide very specific details about what they wanted, often details that they weren't knowledgeable enough to provide.

Teams reinforce this behavior (sometimes even in agile) because they tend to want very specific details to start from, instead of starting at a broad perspective and gradually discovering what the stakeholders want to accomplish. This is what an account manager, product owner, or business analyst should really be doing, not working as an intermediary between the team and the people whose needs they are supposed to meet. So the AM's role may change in an agile environment, but it's actually returning to what it should have been in the first place: helping the stakeholders understand what they are really trying to accomplish, and getting stakeholders and teams together to come up with the simplest, most elegant solution to make that happen.

If your organization is making the shift to an agile approach, tell your stakeholders what you are doing and why. Explain how things will look different for them, and that if you do it right, things will actually improve. Agile at its core (and hopefully we get to the point where we don't have to label it as such) is about delivering solutions in a way that makes sense. What stakeholders really need to know, whether they will admit it or not, is not how long various features will take to produce, but when they will be able to do certain things with the solution.

Our AM's other challenge was that one of his employees was acting as product owner and didn't seem to be giving the AM the information he needed to keep the stakeholders informed. In an ideal situation, one of the key stakeholders would act as the product owner, but in many enterprise-driven situations someone belonging to the IT organization (often a titled project manager or business analyst) fills the role. These enterprise product owners do not necessarily make the key "product" related decisions, but they facilitate the process to make those decisions happen.

In this particular case, this role shift caused a bit of difficulty because, effectively, it was supposed to be a function of the AM role, at least as far as I could tell. Part of the problem was that the AM role itself was new to the organization, so adding an agile approach and establishing a separate product owner caused a great deal of confusion.

Life as an Agile Technical Manager

The Technical Manager (TM) had a different problem. She was confused about what her role should be. She was used to spending most of her time on "resource planning" -- an organizational euphemism for moving people project to project, resulting in overloaded people and a complete lack of continuity. Her direct reports, often callously referred to as "resources," were constantly reassigned, and often overloaded with 6 to 8 projects at once. Her time was spent analyzing the project pipeline to figure out what new "resources" she needed or where she could pull "resources" from one project to staff another.

I don't like the term "resource" because it reinforces the cog-in-the-wheel perception that pervades traditional project thinking. People cannot multi-task, and they are not effective when trying to do so. When you assign people to many different tasks, they will be forced to do a lot of context switching, and will waste more time in the process.

The move to agile shifts the atomic planning unit for a project from the individual to the team. If you truly build cross-functional delivery teams, you don't have to move people to where the work is. Instead, you bring the work to the team. This reduces context switching by people working on the project. Perhaps more important, it frees up managers to work on things that deliver more value, like figuring out how to develop their team members and remove as many productivity obstacles as possible.

In this organization, the TM felt that she didn't have a place with agile, but truth be told, she had a very important role to play. She helped remove obstacles for the team to keep them effective. Plus, under agile approaches she could focus more attention on helping her team members improve.

In effect, managers in this situation are actually able to become leaders. If you still insist on using the resource term, managers can keep the "project resources" in good working condition by supporting them and helping them to improve their skill sets. I'd argue this is what managers should be doing. Unfortunately, people are just now starting to realize that if they trust their employees more, they do not have to do things that their staff is certainly capable of doing, such as planning work and problem solving.

Many managers believe they have to do those things because their staff can't. Ironically, they'll never really know unless they give their staff a chance to try it and fail -- which, by the way, is the best learning experience someone can have. Middle managers often complain of being overworked and in very difficult situation, but it's often a problem of their own making. Generally speaking, managers do not actually produce tangible work product, so they have to demonstrate their value through other means (like ordering their team around).

Adopting agile usually does not cause the dysfunctions that arise during the process. Instead, agile shines light on dysfunctions that have been there for a while. Luckily, agile may also provide ways to address those dysfunctions, often with a simple approach. In this case, I think agile approaches help managers get back to the type of work they should have been doing from the start.

Mike Cohn recently wrote a blog post about The Role of Leaders on a Self-Organizing Team that provides some other perspectives on how leaders may want to interact with their teams, and how team members can influence that interaction. Jeff Weiner also wrote a blog post on The Importance of Scheduling Nothing that provides managers in this situation with a way to use some of their newly discovered "free time" to make themselves more effective and be in a position to better help their teams.

Not all comments are posted. Posted comments are subject to editing for clarity and length.

The comments to this entry are closed.

©Copyright 2000-2017 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail
Terms of Service and Privacy Policy

Stay Connected
Get our latest content delivered to your inbox, every other week. New case studies, articles, templates, online courses, and more. Check out our Newsletter Archive for past issues. Sign Up Now

Got a Question?
Drop us an email or call us toll free:
7am-5pm Pacific
Monday - Friday
We'd love to talk to you.

Learn more about ProjectConnections and who writes our content. Want to learn more? Compare our membership levels.