Spoiler Alert: Agile is a software product management framework.
Many companies read about the benefits of Agile software development and want to employ it as a project management methodology. Somehow, they overlook the obvious point that it is not only not a project management methodology, it is antithetical to it.
Agile is a loosely structured self-organising approach to software product development. Sure, one might receive benefits applying it outside of software development. In principle, I encourage this extension of application. What I don’t encourage is to attempt to adopt it as a project management process—in fact, I am vehemently opposed to the idea.
Let’s review the Agile manifesto:
- Individuals and interactions over processes and tools.
- Working software over comprehensive documentation.
- Customer collaboration over contract negotiation.
- Responding to change over following a plan.
There is nothing here to suggest that it might be adopted as a project management framework. Let’s parse the four directives.
If anything, this is antithetical to project management. Project management is at its core about process and tools. It’s a top-down approach that does not value the individual. The central focus is the project.
Agile is not anti-process, per se. This is where the notion of self-organisation comes into view. This is also where talent and maturity come into play. Obviously, a dozen professional footballers can better self-organise a football match than a dozen grade-schoolers. The team need to have individually seasoned members with enough process awareness to self-govern. Self-governance does not mean having a task master. Decisions are communal.
There are specified roles within the broader Agile space. A product owner owns the vision for the product and establishes the priority of feature functionality—of outputs, but the product owner does not drive velocity or throughput. This is a dynamic function of the team members, which is governed by the cohesiveness of the team and their individual abilities to contribute. An extension to this is that the team decide who does what. This is not imposed or assigned. Team members communicate amongst themselves and draw from the well.
Although this point is about individuals, it is also about interactions. A team need time to bond and figure themselves out. Like a reality TV survivor series, they need to be able to vote members off the proverbial island if they aren’t living up to the perceived capability. And whilst this is not a project management discipline, in time one should expect to be able to measure and rely on throughput and velocity, so long as the product context and team composition don’t change. Following another sports analogy, a football team have performance expectations, but if we swap out a few players because of trades or injuries, we can’t really predict how they will perform. The same is true for Agile teams. We can’t continually swap team members and or disrupt team composition and expect congruent results.
Project management not only expects copious volumes of documentation, it expects every I to be dotted and every T to be crossed. Project management is a process, a function if you will. Documentation is a key input to this function. It’s the flour in a cake recipe. Substitute documentation and flour at your own peril.
Agile does not instruct you to eschew documentation, but it is not the privileged part of this pair. The Agile team should be participants in the requirements and design conversations, so they would already be aware of the requests, and they need to document what they feel is necessary to follow through on the implementation and assure they’ve captured the essence of the request.
This edict is poorly written. What this is attempting to communicate is that team engagement with the customer—with the end users—is more important than having an iron-clad scope. This will dovetail nicely into the next item. The customers are proxied by the product owner. Features will be developed and delivered. Overlaying some flavours of Design Thinking, we may apply aspects of testing and learning. Although we entertain hypotheses, we don’t presume that we’re necessarily right. And it’s OK to be wrong. Our fully-imagined product may have some fatal flaws causing us to deviate from our intended course, which leads us into the last item.
Yet again, this is antithetical to project management that wants determined outcomes by following a plan. Although as with many things, Agile has dependencies and precedencies, they don’t need to be captured in a Gannt chart. A fundamental meta-concept of Agile is that development should be over-indexed versus documentation and planning. As with documentation, we need enough of a plan, but we don’t need to have all of the I’s dotted and T’s crossed. In fact, far enough past the horizon, we don’t even know what alphabet we might be employing.
Why the confusion?
First and foremost, enterprise planners want to find a better solution, a more reliable solution for project management. Others have positioned Agile as a veritable panacea. Consultancies may be the worst offenders, but it’s difficult to judge. But there is more than this, so let’s dig a little deeper.
There are requirements for inputs and products as outputs. And product development can be project managed, so why not use Agile?
As we’ve already mentioned Agile is meant to manage delivery velocity. A mature Agile team with domain knowledge, connected to a product owner can reliably estimate effort in story points and deliver on the promise. This connection is more of a mind-meld, a hive-mind. They’ve already executed a few sprints on this product.
If they’ve worked together with the same team composition, we can employ a Bayesian approach to estimate the first sprint. We may be off by orders of magnitude, but each subsequent sprint will regress to the mean for that team, for that product. Eventually, the team can be expected to develop X story points per time interval, say, 60 story points per two-week sprint cycle.
Effectively, this is all there is to manage. The product owner can expect that if she puts 60 story points into the funnel, the team will develop 60 story points during the sprint. If the product isn’t feature-complete until it’s reached 120 story points, then the product can be released after two sprints.
Considering this scenario, what will the project manager have done? Agile does have a sprint master role. To some extent, they share some domain space with the project manager. In particular, unblocking blockers. Perhaps running reports. Like a PM, a sprint master is there to motivate and mentor the team in the chosen methodology, but that’s about it. The product owner has already prioritised the feature functionality, and this has already been estimated. Again, what value would a project manager add to this equation?
What managers want, are promised delivery timelines, scope management, and budget conformity. Agile makes none of these promises, expressed or implied. If one feels these are inherent in Agile, QAnon may have some openings and some spare tinfoil hats. And I’ve got a bridge for sale. Cheap!
Summary and conclusion
Agile is a product development framework, originally conceived out of observations that digital development had different challenges and offered opportunities to reorganise how to approach the development of these products. The digital world of pixels and bits was a paradigm shift to the physical realm. Although some of the learnings from Agile software development can be leveraged back to the material world and perhaps even to other domains such as operating models and marketing, it is clearly anathema to project management in a manner similar to mixing ammonia and bleach. Don’t try this at home. Don’t try this at work. Not even if you’re a professional—especially if you’re a professional.