Agile Project Managers — an Ill-Fated Union?
Yes, sorry!
This is already more controversial than the first post (Projects and Agile, 5 min), which should be considered a prerequisite reading.
Most project managers probably feel threatened by the above statement.
I can’t blame them for it.
Bear with me and allow me to explain, it isn’t as intimidating as it may sound at first.
Most importantly, just because I say we don’t require project managers anymore doesn’t mean we don’t need the individuals who so far identified as project managers. We do need many of their skills, and that doesn’t change just because the role disappears.
Furthermore, not all product development in an organization has to be done agile. If you can understand the system and with a relatively high certainty say that there won’t be any surprises regarding the requirements for the product you’re building, we would call that system complicated¹. In that case, a Big Design Up Front (BDUF) approach like waterfall might be more efficient. Making a project manager responsible for the coordination between delivering units (specialized people and teams) could be an adequate option. When repairing a car, a mechanical watch, building a house or digging a tunnel through a mountain, BDUF would still be my preferred option.
When operating in a complex¹ context, however, you’ll need to remain much more adaptable and a centrally coordinating person would quickly become a bottleneck, decrease flow and slow things down substantially.
In the following, let’s look at the situations where you’d be better off doing agile product development. I maintain that this will be the case mostly, certainly in the context of product or more specifically software development.
Projects
Let me repeat what a project is:
A project is a temporary endeavor undertaken to create a unique product, service, or result. It has a specific start and end date, with a defined scope, objectives, and resources. Projects typically involve a series of tasks, activities, and milestones that need to be accomplished in order to achieve the desired outcome. They are often managed by a project manager, who coordinates the efforts of a team of individuals with various skills and expertise to ensure that the project is completed on time, within budget, and meets its objectives.
This time I’ll focus on the second half of the definition. The one where the project manager is mentioned.
Remember, we agreed (maybe we didn’t?) that in agile product development we have loads and loads of projects because each single user story can be considered a project.
Given we have hundreds of small or even tiny projects (backlog items, epics, features, user stories — whatever you call them), do we need a project manager for each single one of them? Could it be the same individual then for all of them? Hey, is that what a product owner is?
No, not exactly.
The rub lies in the word “coordinates”.
A project manager apparently does that. In my book, however, an excellent project manager has always had a lot more skills than just being good at coordinating work between specialized individuals and teams.
Great Project Managers
A great project manager …
- has a good understanding and vision for the product that is being built and how it creates value to the users.
- is a good communicator who knows how to negotiate with stakeholders and manage expectations. Enjoys their trust. Knows how to deal with conflicts.
- is a leader and somebody who helps the team perform by removing process impediments, things that impede flow and make the team move slowly.
- is a strong decision-maker and understands that minimizing decision latency is crucial for the success of a project, particularly in the context of complex product development.
- strives for making reversible decisions and defers commitment whenever possible at low cost.
- understands various types of risks and the importance of dealing with them (or not) at the right time.
- is flexible and recognizes that changing requirements are a good thing in that they provide a chance to deliver more value than originally anticipated.
- thinks like an entrepreneur and takes financial ownership.
- understands how to balance long-term and high-quality solutions with short-term constraints.
- sometimes has technical knowledge.
All these competencies are also required in the context of agile product development. I won’t go into each one of these. However, I will mention, that in Scrum² the scrum master (together with the developers) takes responsibility³ for the efficiency⁴ of the Scrum Team⁵, while the product owner is accountable for identifying the most effective way to build the product. As an exercise, for each of the items above, you might want to ask yourself whether it is a question of efficiency (build more stuff) or effectiveness (building the right stuff). Thus, whether it would fall into the responsibility of the scrum master, the product owner, and/or the developers?
But, what about the following tasks, which a classic project manager also performs and often spends substantial amounts of time on?
- Detailed long-term planning up front.
- Assigning work to people and ensuring they are utilized fully.
- Centrally coordinating work between these people and controlling that it gets done.
Who does that in an agile setup, if not the project manager?
Planning
Some people still believe that agile teams don’t plan. It couldn’t be further from the truth. In fact, agile teams plan continuously. What they don’t do is plan in great detail up front and far into the future — because that is futile. Instead, they “plan the plannable” which usually means a few weeks ahead.
Ordering the product backlog is planning done by the product owner. So is the creation of a road map. Then there is the Sprint Planning meeting itself. The Developers meet daily to plan what they will be doing the next 24 hours. You see, agile teams plan a lot. Everybody on the team does. Not just one person. And certainly not all up front.
If there was a good reason for making a medium- or even long-term prediction as to what will be delivered when, then yes, that would be the product owner's job.
Assigning work
Having work assigned, while focusing on a high utilization, creates bottlenecks and requires substantial amounts of communication. Agile teams understand that pulling work (made popular by Toyota) is more efficient than having it pushed.
Instead of a project manager who assigns work to developers, we create a common source of prioritized work (typically a backlog of sorts) and let the developers pull their next work item when capacity allows them to do so. Who can better judge capacity than people themselves?
Coordinating work
Small cross-functional independent teams focusing collaboratively on a few user stories every sprint do not need somebody from the outside to coordinate work for them.
In those instances where several developers are working on the same user story, somebody within that group of people may take the informal responsibility to coordinate work between them. That somebody is now the project manager for the given work item. Thus, every developer will at times be a project manager (or coordinator, really), if you like.
Another bottleneck removed.
More flow is the result. Flow is a synonym for high efficiency and what we ultimately strive for.
Too much work for the Product Owner?
Frequently, one argument for having a project manager is that the product owner can’t do everything she⁶ is accountable for.
A straw man argument in my view. We can agree that this will be the case every so often. Just like, we can probably agree that there also will be situations where it won’t be an issue that the product owner has too many things to tend to.
But that’s not the point of this discussion here. The point is the confusion and inefficiencies that are created when you have multiple roles that overlap. For each of the aforementioned accountabilities — who will take it? When there only is a scrum master and a product owner, I believe it is pretty clear. But when you add a project manager to the mix — what then?
Anyhow, I will mention the solution to the question of this section: Self-management.
The team should be encouraged to experiment in finding a working solution for them. Every so often, this might mean they will agree to have an additional person with clearly defined responsibilities. And yes, this could be a project manager. It also could be a business analyst, or a tester, or an entirely new role which nobody has heard of before. Frequently, the developers will pick up some tasks to free the product owner of some work. It doesn’t say anywhere, that writing stories has to be done by the product owner, for instance. The same goes for testing or validation. Or talking to stakeholders.
What happens to the project manager?
What happens to the project manager as you become more agile?
Organizations struggle with answering this question and often take the easy but also both expensive and ineffective path of keeping all “legacy” roles while supplementing new ones like product owner, scrum master, epic owner, and Release Train Engineer.
I’ll handle the question of what happens to project managers in more detail in a separate article.
For agile teams, I’m suggesting taking the difficult step of getting rid of the role of a project manager — not the person!
Conclusion
What is it going to be? Make your choice. Traditional product development with large big bang projects and a project manager, which is fine if it works for you. Or agile product development with a backlog containing many tiny projects (aka user stories) and an individual owning that backlog.
If you go for the latter, agile version, don’t make a bad compromise when it comes to the roles. Think long-term and strive for a brilliantly simple setup. Definitely consider keeping the person who previously identified as project manager — but not the role.
This all sounds dogmatic, I know, and it isn’t meant to be. It is to drive home a point. The point that in a complex system, a few simple guardrails combined with intelligent people that self-manage beat overly complicated rules every time.
Unless you believe you have the wrong people. If so, none of the frameworks will solve your problem.
Of course, there will be situations where my conclusion isn’t true, but those will be the exception, and you and your organization are probably not one of them. Sorry.
Project Managers and Agile — an Ill-Fated Union? The short answer is: Yes!
But let me end on a more positive note.
If you consider yourself a good project manager, imagine what you could become for an agile team if you played the role of a “True” Product Owner or scrum master (or any scaled version thereof). You and the team could have much more clarity as to who is accountable for what. Fewer bottlenecks, more flow, more engagement, more ownership — for everybody.
Always …
Any feedback is welcome, even tiny things like spelling mistakes or sentences which are hard to understand.
I enjoy discussing. I enjoy being challenged. I enjoy learning about and experiencing new perspectives.
Thanks to my brother Dirk Bucka-Lassen for providing valuable feedback and input to this article. And to all project managers who have discussed this topic with me — and who certainly didn’t always agree with my perspective. Most recently Claudia Chini, Ramon Grunder, and Bertrand Schwendeler. That made for interesting conversations and helped me understand the matter better.
[1] Complicated vs. complex — a potential blog post. For now, you can google for it or look up Dave Snowden and Cynefin. Generally, something is considered complicated if an expert, given enough information about the system, can understand and thus predict its behavior. Complex systems are different. Their behavior can’t be predicted exactly, no matter how much information we collect about them. Traffic, for instance, is complex. A car or mechanical watch is complicated.
[2] No, Scrum doesn’t make you agile automatically, just like stepping on a scale every morning doesn’t make you lose weight. And being agile doesn’t automatically mean you’ll be doing Scrum. But, Scrum is the de facto standard and the Scrum terminology is widespread, which is why I am using it in many of my articles.
[3] I might also write an article on responsibility and accountability. I believe many organizations have gone too far and defined too granular and inappropriate accountabilities. This often leads to loss of sight for the whole and creates silos.
[4] Efficiency and effectiveness, yet another potential article I will write. For now, “building the right things” (effectiveness) over “building things fast” (efficiency) must suffice. Or, you can check out this keynote of mine, where I explain the terms and how they relate in more detail.
[5] The Scrum Guide actually could be interpreted differently, but that is the topic of yet another post 😉.
[6] … or he. I feel that writing gender-neutral makes my texts less legible. I can’t get used to adopting “them” as an alternative (yet). That’s why I decided to refer to everybody as a female. It could just as well have been a male, of course.
