When I’ve helped organizations adopt Agile software development, there are three groups of people who seem to get the most concerned: development managers, project managers, and business analysts.
All three of these groups take a look at the popular frameworks, primarily Scrum, and see that their role is not mentioned. You could interpret that lack of mention as the framework leaving it up to organizations to figure out where those roles fit in. Some organizations interpret the failure to mention those roles to mean they are no longer needed and just get rid of them altogether.
I’d suggest the truth is probably closer to the first option than the second. Although it’s easy to see where people get the impression that project managers are no longer needed. The team ends up taking responsibility for a lot of the things that project managers find themselves doing, such as estimating and planning. In a lot of cases, that makes sense. The people who are going to do the work are generally in the best position to assess how long that work will take and which things should be done to deliver a given solution.
That doesn’t mean that if you’re a project manager you no longer have a job. You just need to consider how you prefer to approach project management work, and what type of domain you work in.
If your project management relies on a servant-leadership approach, you’ll find it a very easy switch to go into the coaching realm as a scrum master or Agile coach.
If you’ve always preferred to think about the outcome your product was trying to produce and you’re a domain expert, you may find that being a product owner is a good fit.
If you work in a large organization that has multiple teams working on the same effort, there is still a need for coordination. If that’s where your expertise lies, chances are you’ll still have opportunities to do project management, just at a bit larger scale.
And if you really enjoy building things but got into project management because you thought it was the natural next step on your career path, you could always go back to building things and take an informal leadership role on a team. The one unspoken assumption in the above discussion is that the relevant domain is Agile software development. In that particular arena, there is a decreasing emphasis on project management. This is due to organizations adopting Agile frameworks such as Scrum, and because organizations are adopting more product thinking than project thinking. (More about that below.) In both cases, those changes are ways to deal with uncertain and volatile environments.
The idea that project management is going away entirely reveals a very myopic view. There are plenty of domains outside of software development where the project paradigm is the main way to organize work. If you enjoy project management, there are still plenty of opportunities. You may just not be as involved with software development as much.
Will project managers have to give up one of the three project management items of cost, scope, or time when using an Agile methodology?
Not necessarily. All three sides of the “iron triangle” are still relevant, but how you treat them is different.
Time may still be treated as a constraint of one form or another. Several Agile frameworks use the idea of a time-boxed iteration to help your team focus on a specific item or set of items.
Your budget is also treated as a constraint because you’ll generally have a stable team working on your effort. You don’t want to necessarily change the makeup of that team too much because it messes with the team dynamics.
The biggest change in how you handle the triple constraints is with scope. In order to have a constrained time and cost and still have a chance of being effective, you need to have a flexible scope. Most Agile frameworks build the assumption of flexible scope into their practices. For example, the product backlog in Scrum is not a fixed list of scope items; it’s a constantly changing set of options you can use to deliver a solution. Those options get adjusted during backlog refinement and sprint planning.
The way you define scope is different as well. You still establish a target that you’re trying to reach, but that target is not a list of outputs (i.e. scope items) you need to get done. It’s a specific outcome you want to accomplish.
Thinking of scope in this way acknowledges that you can’t possibly know enough at the beginning of an effort to identify exactly what you need to do to solve a given problem.
Identifying an outcome and allowing a flexible scope allows you to learn as you start developing your solution and learn more about the problem and your potential solution. The outcome you seek does not change. The scope, in terms of the items you deliver to get to that outcome, does change.
Scope, time, and costs are still relevant. The way you treat them changes.
Agile Alliance and Project Management Institute (PMI) collaborated on the creation of the Agile Practice Guide, which is especially useful for project managers accustomed to a more traditional environment to adapt to a more Agile approach.
Get the best content on Agile Alliance:
Sign up for our Q&A curated content newsletter.
![[Case Study] Lessons from descaling 25 Scrum teams](https://www.agilealliance.org/wp-content/uploads/2024/12/descaling-teams-1200x630-1-150x150.jpg)
![[Case Study] Lessons from descaling 25 Scrum teams](https://www.agilealliance.org/wp-content/uploads/2024/12/descaling-teams-1200x630-1-300x158.jpg)
