See The Hidden Headaches of Agile Project Management
According to the Project Management Institute (PMI), the Agile Project Management approach exists to provide “maximum value in uncertain problem domains where high quality and speed to market are your primary business drivers.”1
In my experience, hearing how much joy participants in Agile projects get from the lack of documentation, accountability, schedule & financial constraints all contribute to Agile’s popularity. But perhaps what they don’t see are the headaches Agile causes, too. Or, if they do, they believe the headaches aren’t worth as much as the approach.
Here are a couple of headaches Agile causes:
1. Agile’s dilemma with documentation
Let’s get real: Agile is primarily useful for software projects, not for constructing bridges (Adolfo Uzabel tries unconvincingly to convert a program’s stages into Agile, but conveniently disregards the vast majority of Agile techniques, methods, tools and requirements. Nice try).
One of the purposes of Agile is to eliminate as much documentation as possible.
My dad worked in the UK’s Ministry of Defense as a project manager. Governments love documentation. And the military is where formal project management was birthed2 (Depending on whose version of history you choose, of course – it’s been hard to keep up these past few years). Dad’s last project was both software and hardware based, and he had to document everything.
Traditional (a.k.a. Waterfall) project management documents everything to make sure that:
- Everyone knows what’s happening
- As people leave the project, others can pick up where they left off
- Budget, schedule and quality can be tracked
- Participants are held accountable for their choices, actions and even behaviors.
Agile minimizes documentation to the bare necessities – a one page “epic” brief, a feature user story, and maybe a cost-benefit analysis.
That causes headaches when trying to convince organizational leaders of what they can expect, when, and for how much. It also causes headaches when folks leave an organization and new hires have to be trained from scratch focusing on project content (what) as opposed to organizational culture (how).
I have usually found it best to adopt a hybrid approach: practitioners work in Agile, and leadership works in Waterfall. I sure am glad to have three PMI certifications:
- Project Management Professional (Traditional)
- Disciplined Agile Scrum Master
- Agile Hybrid Project Pro (working both together)
2. A cost consequence of Agile flexibility
I’m a big fan of the “Pick two” approach for just about everything in life:
- Fast, Good, or Cheap.
You can have any combination of two of those options, but you’ll never get all three.
Agile is no different, but mostly focuses on fast (deliver something now) and good (i.e. it works).
And that doesn’t come cheap.
Some proponents argue that Agile eliminates overhead and allows less valuable work to be pruned.
This causes a headache when it comes to producing outcomes promised to customers, especially when there is a budget. Agile budgets are rarely static. Because Agile focuses just on producing value quickly, outcomes and resource requirements are actually unknown and can very quickly and easily explode well beyond the original project’s schedule and budget. Please don’t argue that they shouldn’t, because they do. Of the 26 projects I’m managing right now, almost three-quarters have “added value” that has also added time and resource needs. As our customer expects delivery by a specific date, we’ve added contracted resources in order to get the work done.
Why pay a teammate $120 an hour when you can get it done sooner with a consultant at $450 per hour?
(Because leadership has more organizational strategy insight when presented with the options.)
One team I work with just switched wholeheartedly to an Agile approach. They have 14 requests in front of them. Every two weeks I am asked “which would you like us to focus on?” I ask them to finish the one they’re on. “Oh, that will take another couple of months,” they say. “What can we begin working on in the meantime?”
Huh?
How about working on the project you’ve got now?
The downstream activities relying on the outcome of this project are all on hold, costing us more wasted money (i.e. less value), and waiting for the project’s end result to magically appear with much fanfare at its announcement, no doubt.
There is no opportunity to adjust – or even plan for – launches, training, future developments, even growth, because we simply don’t know when the project will be complete. In fact, that’s almost the point of Agile… it’s never quite complete. Just the current iteration will produce some sort of working outcome. That’s all we can expect.
And that’s quite a headache!
The project itself might cost less, but the overall impact is costing the organization way more in lost opportunities, inefficiencies, and pure… waiting.
It’s great for exploring
If you don’t have much of a budget, and you don’t really care or want to know where your software project ends up, Agile is great. Really! It works. I love it.
But in the wider context of business, operations, sales, and survival, Agile really does cause many others more headaches than the project team seems to appreciate, understand, or care about.
The solution?
Definitely work together. See both sides. Be transparent.
Explain the Why, not the expectation.
My way may not be the best solution, but I know why I choose to do something in a specific way. If I share that with you, it’s up to you to decide whether or not you agree to let me do it that way. And if you know why you choose your solution, tell me and I’ll adjust if I deem it appropriate.
Assuming my way is best, or assuming your way is best, and trying to convince the other, doesn’t work.
We’re seeing that in our social environments now.
And that’s definitely causing headaches.
Do you have a pro- or con- story about Agile project management? I’d like to hear it. Share it with me here.
- Cottmeyer, M. (2009). Agile PMP®: managing software projects in the face of uncertainty. Paper presented at PMI® Global Congress 2009—North America, Orlando, FL. Newtown Square, PA: Project Management Institute. ↩︎
- Snyder, J. R. (1987). Modern project management: how did we get here—where do we go? Project Management Journal, 18(1), 28–29. ↩︎
