Agile project management is a meaningless term.
Intrepid developers put their blood, sweat, and tears into the original agile manifesto. Sure, the idea of continuous delivery was not new. The Sagrada Familia was an obvious example of the idea, for over a hundred years. But new or not, the application to software development project management was revolutionary. Software development didn’t fit the Gantt chart based, heavy approach of traditional project management. With agile, there was a better fit: a way to manage the complexity to success.
As we all know, that’s not where it ended. Somewhere along the way, a solution for a particular outlier somehow became the gold standard for the industry as a whole. Today, as a recent survey showed, agile is either the method used, or a significant part of nearly everyone’s project management systems. This has not been without results, either. Surveys report that projects managed with agile are nearly 28% more successful than projects managed traditionally.
And yet, you ask, I say agile project management is a meaningless term.
You bet I do.
Agile is a meaningless term because it’s being used to describe everything from using task management software to incorporating a Kanban board in your workflow management. Using agile for project management is a buzzword today, the new “leveraging synergies.” Management puffs out their chest, proudly insisting they’re an agile organization. What it comes down to is calling meetings “standups” and calling customer support tickets “stories.”
Agile is a meaningless term because the chaotic, creative, decentralized, bottom-up approach runs counter to the culture in most organizations. Agile is meant to be almost democratic. Everyone has a degree of autonomy, a degree of responsibility, and a degree of freedom to problem solve on their own. Most organizations don’t want Daryl from the back end making decisions on the UI that will affect the entire company. They’ll say they’re agile, but they’re not.
Agile is a meaningless term because…hey, I’m not alone in saying this.
Ron Jeffries, one of the original signatories of the heralded original agile manifesto, said so in 2018. Andy Hunt, another original signatory, said so in 2015. Dave Thomas, a third original signatory, said the same thing – in 2014. Thomas insisted that you could sum up agile in four bullet points:
- Find out where you are
- Take a small step towards your goal
- Adjust your understanding based on what you learned
You could even argue that number three is the main point. Agility is about incorporating lessons learned into the project while it is ongoing – no more, no less. It’s a feedback mechanism. It’s a process for continuous optimization. And if there’s one thing that isn’t going on for most ostensible agile practitioners, that’s the one. If “agile” doesn’t mean the incorporation of lessons learned during the ongoing process, then agile is a meaningless term in project management.
There was an Anti-Agile Manifesto published, for a time. It read, simply:
We have suffered through countless consultants and hours of meetings. Through this we discovered that Agile is simply the obfuscation of common sense – the bewitchment of the mind through language. We have learned that
epics are really just projects
stories are really just use cases
sprints are really just work
stand-ups are really just meetings
iterations are really just versions
backlogs are really just to do lists
backlog grooming is really just planning
burn-down charts are really just earned value charts
velocity is really just output
and that tasks, in fact, are really just tasks.
That is, while the concepts on the left are often presented as groundbreaking or unique, they are merely weakly defined versions of those on the right.
That’s it. That’s the entire anti-agile manifesto. And it says it all. This is certainly the case in institutions that are mimicking agile, using the terminology while plodding along with a culture that stifles creativity, bottom up processes, and change. Yes, in almost all cases, agile is a meaningless term.
So why are people flocking to a term they use out of context?
The answer has nothing to do with agile, itself. It has everything to do with timelines and workflows.
There’s a powerful catch-22 hiding in project management tools. The issue is, the standard visual project plan is a Gantt chart – and Gantt charts are spectacularly useless for managing projects. They’re barely effective for planning projects, and whatever utility they offer during the planning phase is wiped out, and then some, once the project goes live. Gantt charts are bar chart schedules, and they are incredibly static. They’re not responsive, they’re not interactive, and they’re definitely not tools built to handle ongoing change. Which means when it comes time to manage the project, getting work updates from your team is a Sisyphean task of checking task updates against a massive bar chart.
Where Did This Come From?
As project managers looked on at the upstart agile teams, way back when, they were jealous. No hard deadlines. Optimized workflow management – tasks flowed from “to do” through “closed” without backlogs and task delay cascades. Project managers noticed that the removal of the timeline had a big effect – it let workflow management flow naturally. And they began to adapt the agile approach, not as an actual method of project management, but a method for removing its biggest problem – the pesky Gantt chart. The Gantt was a problem because of the catch-22: your workflow management is easier without a timeline…and you can’t plan that workflow in a project without a timeline. With this superficial adaptation of agile, the problem was “solved”. The Gantt becomes some kind of high level planning tool, to be checked on every so often, while the management phase is operated with task management tools.
Except this didn’t solve the problem, it just moved it elsewhere.
Task Management Timelines Are An Oxymoron
The problem now lies in week three and beyond of the project timeline.
The timeline of a project is simply the graphical representation of the tasks needed to get the project from here to there. When the project plan and the project management phase are separated, as they are in the “agile” approach described above, the timeline is only as accurate as the tasks put into it. This is generally a few weeks at a time, max. The timeline quickly becomes useless, as it is utterly inaccurate outside of the coming few weeks which are fully mapped out. Now, instead of a workflow problem, there’s a planning problem – no one has any idea of what’s coming in a month from now. One big surprise, and the project can get easily derailed, because no one (literally) saw it coming.
Even software development teams, who tend to practice agile more accurately than other project teams, use a timeline in Jira. If the real agile guys use a timeline for their project management, it’s a good sign the timeline is a key planning tool and can’t be overlooked. And that is a good sign that agile is a meaningless term the way it is used in project management.
Agile Can Now (Apparently) Mean Personal Task Management For Projects
There’s no accident glorified task management systems that are perfectly suited to managing someone’s personal workflow/to-do list are now billing themselves as project management solutions for global-sized companies. They slap a timeline onto their list and board functions, and voila. This is the result of the project management industry’s derailment by this half-hearted adaptation of agile in name only.
At the end of the day, project management is a top down planning process. The order and structure are mapped, and then tasks are fit to the scaffold of the project plan. Task management and workflows are a bottom up process. Tasks are used to define the order of the project. Agile is a bottom up process. Project management is not. And the catch-22 now occupies the space where a bottom up process that is no longer working intersects with a top down process that isn’t there at all. For most projects, that’s three weeks out.
Where Do We Go From Here?
There’s no accident that nearly everyone is fed up with the literally thousands of project management solutions in the market. They all contain this catch-22. These project management tools require you to either use the Gantt chart that doesn’t work, or a task management timeline that doesn’t work. They either push you into inefficient workflows and heavy handed management of the project, or they force you into managing projects three weeks at a time without any long term planning ability. Forward thinking companies’ change management specialists are already tasked with finding a solution to this catch-22.
Projects require a top down planning process. Task management requires a bottom up management process. These can be contradictory, and they can also be complimentary.
The change needs to come where people no longer see a timeline as just a visual representation of the project, but as a project blueprint. The project plans aren’t just a bar chart schedule, they’re both the instructions for what to do, and a guide for how to do it. Blueprints allow for bottom up creativity and responsiveness to change. Blueprints aren’t static, and they can be adaptable when necessary. Project management of the future will be the creation of the top-down project plan, with the flexibility and agility for task management to flow, bottom up, from an empowered and autonomous team.
And it looks something like this.
Your project plan doesn’t have to be a Gantt chart. It shouldn’t be a bar chart schedule of tasks. Project planning should be as simple, clear, and intuitive as the plan above.
Want to learn more? No problem. See the next generation Gantt chart that’s already here.
Or click this button, sign up, and try it for yourself.