When the Agile frameworks were first introduced, they were presented as some kind of emancipation against management, since they were meant to be self-managed development teams.
In this new era, developers should work directly with the business representatives to define and develop new products or functionalities in an iterative manner to deliver value fast, according to the business needs.
Project managers — and management in general — were seen as obstacles to the development team, and they were told to refrain from interfering.
This change was seen as a revolution, mostly for software projects, and in many cases it was a positive evolution. However, something was missing.
In fact, Agile practices worked very well when it came to adding functionalities to existing software. But they often struggled to deliver complex new solutions — especially those requiring multiple development teams working in parallel or those involving significant business transformation.
Agile teams tend to share ownership of the solution, which is great for collaboration, but not always ideal for governance. Business executives still need someone accountable for the big picture — someone who can consolidate status, manage risks and dependencies, and answer questions about schedule and cost projections. These aren’t straightforward responsibilities within Agile team structures.
Without upfront alignment on architecture, requirements, and technical constraints, Agile teams often make early decisions that later prove unfit as the solution grows. This leads to rework, delays, and frustration — not because teams are poorly managed, but because no one is coordinating decisions at a higher level.
Agile focuses on building the product incrementally — but what about preparing the rest of the organization to adopt and use it? Stakeholder alignment, training, documentation, communications, business readiness — these are critical to successful adoption but are often ignored or assumed to be “someone else’s problem.”
Agile teams don’t typically take responsibility for procurement, infrastructure deployment, or vendor management. These are essential to delivering end-to-end solutions but tend to fall through the cracks without someone overseeing the whole project context.
Executives need clarity on progress, forecasts, dependencies, and outcomes — especially when business activities like marketing, legal, or finance depend on delivery timelines. Agile team metrics (like story points or burndown charts) don’t always translate into meaningful insights for senior stakeholders.
Rather than viewing Agile and Project Management as mutually exclusive, many organizations are adopting hybrid models — blending Agile practices at the team level with traditional project management principles at the program or initiative level.
This might mean Scrum teams operating within a broader framework like Disciplined Agile Delivery (DAD), SAFe, or a Stage-Gate overlay. It might mean assigning a Project Manager to coordinate dependencies across several Agile squads or to manage non-development deliverables (such as legal approvals or procurement timelines).
In hybrid approaches, Project Managers focus on the why, when, and how it all fits together, while Agile teams focus on the how and what’s next within their scope. This synergy preserves the benefits of agility — speed, adaptability, continuous improvement — while adding the structure and foresight needed for complex or high-stakes projects.
Agile is here to stay — and that’s a good thing. But even in the most Agile environments, project management is not obsolete. In fact, it’s more important than ever to bridge the gap between empowered development teams and the broader organizational ecosystem.
Agility without alignment can lead to fragmentation and wasted effort. Project Managers — especially those who understand how to work with Agile, not against it — are essential to turning iterative progress into meaningful outcomes. Hybrid models may be the key to making this collaboration work at scale.