We’ve all been there — we’re talking about our upcoming projects, discussing possible timelines and resource allocations, working to align our tactical work with the company and product strategy, when it hits you like a brick thrown through your living room window in the middle of the latest Game of Thrones episode:
So, where’s the project plan?
And that’s where it goes downhill. Because we all know that what’s usually meant by “project plan” is some extremely detailed, well-defined, cascading graphic from hell known as the Gantt chart. It’s been the go-to standard for project management and project planning for decades.
And it needs to die. A miserable, screaming, Melisandre-putting-it-on-the-fire-for-the Lord-of-Light death.
Gantt is Not Agile
First off, and perhaps most importantly, we’re living and breathing and working in an agile world now. Whether we like it or not, whether we accept it or not, and whether we actively practice it or not, others in our markets are, and they’re constantly improving themselves and their products. But when we look for those classic artifacts of yesteryear — the PRD and the MRD and the Project Plan and the Gantt Chart, and the Change Control Process — all we’re doing is holding on to relics from another time.
Let’s recall one of the principles of the Agile Manifesto: “[We value] responding to change over following a plan.” If there’s anything that looks like “following a plan,” it’s our old, rusty friend the Gantt chart. A Gantt chart leaves no room for error; it has no concept of iterative work; it cannot predict how technology might change or what feedback you’ll get from your customers or stakeholders. It says, in bold and bright colors: “We’re starting here, and we’ll do all of this in order until we reach there.”
And let’s not even consider the amount of time that one can spend creating and tweaking and updating and modifying and re-editing dates so that your Gantt chart looks good. Connecting the dots, layering in dependencies, fixing the errors that your tools force on you by their “assumptions” (MS Project, I’m making the Evil Eye at you right now). All of which is time better spent working with your teams to ensure they’re working on the right priorities at the right time, and with your customers and stakeholders to ensure that you’re
Gantt is Impractical
Sure, the Gantt chart is pretty. It’s clear. It’s easy to follow. But it’s also bullshit. Any project plan that pretends to be anything more than a snapshot of what you know right now and what the current plan is, subject to potentially massive, disruptive change at a moments notice is nothing more than a security blanket. It comforts you, it covers you, it makes you think that the world is all right, and that there’s no way the monsters can get to you. But it’s all a lie — it’s a GLADOS-level lie, right up there with the cake.
But the real problem with the Gantt chart is the cognitive dissonance that it creates. Ask anyone what they think of them, and they’ll tell you, with a straight face, that they view them as estimates, and that the target date at the end rarely is going to be the “real” end date. But get those same people in a meeting where you’re telling them, three months out from that “fake” date that things are going to slip, and they. Will. Flip. Their. Shit.
Why? Because they’ve made marketing plans, and they’ve made customer promises, and the training materials are ready to go, and the interns are leaving, and the British are coming, and a thousand other excuses to blame the developers and the product managers for giving everyone that project plan that they asked for.
Let’s be honest — nobody hears “this date is flexible.” Nobody hears “there are still some unknowns that might bite us.” Nobody hears “this is our best guess at a delivery date given what we know.” They see the Gantt chart, and the Gantt chart is God to them — it may as well be written on a stone tablet. The minute those bars and arrows and dates appear in front of those business stakeholders and the management team, they’re transfixed and all logic, reason, and understanding of the realities of building products goes out the window.
But There is Hope!
So, what the hell can we do? The business wants a project plan, but we all agree that Gantt charts are the Devil…right? Well, what we have to do is a little song and a little dance, and present them with something that cannot be viewed as a hard-target deadline. Start by easing back on the dates — turn them into “Sprints” without any relationship to months and years — “Sprint 1”, “Sprint 2”, “Sprint 3”, ad nauseum. This very small change actually alters the discussion at a fundamental level — we’ve managed to abstract away the dates, and are not talking in the language of iteration.
Another thing you can do is to remove all those dependencies and connections — flatten out the plan as much as you can, and transform all those small, individual deliverables into some container object — I like to call them “themes” and “epics” to stick with the Scrum terminology that I learned many years ago. The point is to focus on the goals, and not the path to get there. This allows the path to change, so long as the goal remains the same.
Finally, don’t be afraid to punt completely when asked for a project plan — position it carefully and clearly, so as not to make your management team and stakeholders think that you don’t have a plan, but refocus on the work that’s being done now and how it’s valuable, rather than what’s going to be done in the future. Use your Top Ten Priorities list to show that you do have a list of things to do, and that you all agree that the next thing up is flexible and decided at the time you’re ready to execute. Use the project plan discussion as a training and education opportunity on the values and benefits of being agile.
Iteration and agile sounds good, after further inquiries. The term “revisiting” lured me. But still, also, I strongly believe in 95% thinking, 5%. Keyboard. 95 % thinking will help define drastically all the agile params , starting with the definition of the iterations and the controls.
My point was that there is no way to be agile during the conception phase without issues coming down the line. Agile is obviously unavoidable and a great security for any project. as of the project,the question is: when does it need to get clear for everyone?
The article isn’t without context – in many companies that I’ve worked with, agile was not “unavoidable” and traditional “waterfall” methods of design, development, and release provided a high level of comfort with an illusion of predictability and stability. The best agile practices involve “just in time” ideation, definition, and execution — you do the amount of work necessary to move whatever it is into its next phase or iteration, execute, test, and learn — then iterate and repeat.
does this mean that each iteration is a final product,? even if it features almost nothing? anyway, Scrum is a brigt language, evolved, clever. in my ignorançe of it, I was substituting the general notion of “sprint” with “testings”, in a waterfall context. Testing was the “separator” thing. This from the fact that I have seen too often performances issues unfolding too late. Meaning conception errors. Still I have some effort to do, in a general way, to understand “what is said and why” versus “what I understand of it”. thank you
The goal of an iteration in Scrum is to deliver a “potentially shippable” result — generally speaking, this is some amount of functionality that is built, tested, validated, and that meets at least one customer need. The reality is that it’s often a subset of a bigger story, but the goal remains that it should be fully developed, tested, and validated in order to call it “done” and credit the team for their work. The basic ideal of nearly all agile development processes (of which Scrum is only one) is to ensure that you find issues as soon as possible, and resolve them as quickly as possible — in addition to being focused on end-user value whenever and wherever possible.
it makes sense , testing only a subset of the required features at once is way more productive than “testing the software as is, as of today”. more focused with a deeper examination on all accounts.
Keep in mind, though, that iteration and iterative development doesn’t mean that you don’t have to do regression and other forms of testing; the idea is to know that what you’re working on is working as it’s intended while you’re working on it — once you’re ready to “put it out there” you may have additional testing burdens to ensure there aren’t unforeseen impacts to the system as a whole. Of course, the other goal is that all of this testing should be as automated as possible, so that it’s a “push go” and see the results situation, not weeks of manual, black-box testing.