There is a very common trope in the agile community that agile and project management — and by extension project managers — do not mix, or are even in direct conflict with each other. Let’s unpack this.
At its core, project management is about controlling delivery risk in projects such that their objectives are met within acceptable timeframes and cost (aka “on time, on budget”). If these objectives pertain to an expected increase in business value (such as increased marginal revenue, reduced operating costs, reduced business risk or enablement of a market opportunity) then, in theory, project management aligns nicely with at least the Scrum (if not agile) mantra of maximising value (so long as the project objectives align with the product objectives).
The focus in agile development (as distinct from Scrum) is on the continuous delivery of value for the customer, not “the business”. Which is not to say that the agile manifesto authors didn’t care about business value when they described their highest priority as satisfying the customer — I can’t speak for them, but it’s probably truer to say that they saw the focus on the customer as the most effective path to said business value.
As such, there is often a conflict in what “the business” sees as the objectives of a project and what the product development team sees. Further, the iterative and incremental nature of product development and delivering value (identifying and learning what value actually is over time by delivering what we think it is in short cycles) is at odds with the conventional way of describing value and cost upfront and sticking to those numbers (the ROI method).
These key challenges, along with the enduring prominence of “traditional” style project management (such as “adding resources to late projects” and working long hours / weekends to “get everything done”), are at the heart of the #NoProjects movement and perhaps go some way to explaining the general disdain for project management / managers in the agile sphere.
In my view, agile values and principles bring a different lens to how project management should be done rather than being at odds with it or making it irrelevant.
Agile also introduces a new decision into the landscape — what container should we use to deliver value (rather than defaulting to “project”)?. The bone of contention here is that the “project” vehicle is arguably not well suited to the continuous pursuit of customer value, where it perhaps makes more sense to fund teams rather than projects, keeping them together rather than disbanding them when the project is complete such that they can deftly move from one valuable pursuit to the next.
A software product is never “complete” — there will always be support, maintenance and enhancements needed, both technically and in capability for the customer (i.e. “features”). The project view of the world sees those activities become “BAU” and absorbed into daily operations, meaning the work needed to sustain the maximising of value gets juggled with other, newer projects (and people) — priorities get diluted, and there is no longer a focus on a particular customer or value stream.
In such a paradigm, having confidence that we are “maximising value”, and actually doing so, becomes extremely hard, even impossible.
It’s a huge topic and I could go on writing about it for hours(!) so I’d better stop, but you can find out more about the #NoProjects book and movement here.