Agile became adopted because waterfall is suited for construction projects or factory floors not software development. It accounts for the fact that software developers are very poor estimators (even the best software devs) determining how long things take to build or implement.
Waterfall as it was done in early 2000s was mostly a high level plan and smaller unofficial iterations on the ground. We knew we need to test, and sometimes partially release stuff in advance to have an idea of what's actually working and what's half baked.
The same way successful agile projects are almost always done with unofficial rough planning and dependency graphing checked ahead, and smaller iterarion following the big picture from there.
On both methodologies, religiously adhering to the mantra is suicidal, and I don't see agile being significantly better except if all you care about it getting paid iteratively -- which is a noble goal for a consultant.
Perhaps the point that bears reiterating is very few shops actually followed hard line waterfall planning (nor agile, for that matter).
Waterfall is suited for projects where the outcome is known (e.g., guidance software for fancy new jet, embedded software, etc.) where establishing a deadline is necessary and possible because the desired feature set is fixed (at least in theory) and changes are locked behind a (likely multi-year) requirements and design process with contacts and lawyers.
Agile is better suited for exploration of a product space or implementation of projects where agility (surprise, surprise) to changing/unknown client needs is paramount. Clients don't know what they want till they see what they don't want, so agile is great for that type of build. The web-facing world loves agile, because the "end" goal is usually, "make money so we can hire more developers to build more website [whatever that means] to make more money to hire more developers...".
There are means of mitigating bad estimation (e.g., Spolsky's "Painless Software Schedules" and particularly "Evidence-Based Scheduling".), but you can't account for a 50 hour feature added 19 weeks into a project. Agile (acknowledging the broadness of that category) alone doesn't do anything to mitigate either bad estimation or surprise features, it simply trades "known deadline, fixed features" for "unknown deadline, flexible features".
I'm unconvinced. If new features of unknown complexity are getting added to your product backlog with the expectation that estimations are done against them and not that exploratory work is planned and undertaken instead, that's a problem with the culture and not with the process.
Scrum in particular (according to Coplien et al. at least) is meant to handle prioritization of work as a conversation between the people who want stuff built and the people actually doing the work to get stuff built. The only thing it recommends—not even prescribes—as it relates to estimation uncertainty is embracing the framework to chart a new course more easily when the facts change.
A big pattern that is prescribed (though perhaps only implicitly via reiterating that the product backlog is strictly in delivery order when work starts) is that the product backlog is append-only when you don't want to trigger more planning and, as a direct consequence, draw up a new refined product backlog for everyone to work from. If you need to reorder your product backlog items to add something in the middle, that's a signal that the facts have changed, and the plan needs to be redone. That isn't prima facie all that different from a more traditional project management method.
Agile only aims to make planning suck a little less to change by baking certain touch-points into the process so that someone can pull the proverbial andon cord unceremoniously.
> Agile is better suited for exploration of a product space
More apropos this, if you've ever heard of a spike solution, that's agile's attempt at controlling for uncertainty when it isn't exactly clear how to do something or how long something will take. It necessarily triggers additional planning, and the product backlog item for it is a clear display of the uncertainty inherent in delivering that helps determine where in the ordering that work should fall.
Likewise, if you generally know what the roadmap looks like and have confidence that it won't change, the uncertainty is still in the humans doing the work. I've always put vacations and bereavements and on call shifts and other kinds of fixed-date "generally not available for product work" things into the product backlog, and having that visible to everyone with stake in the work is always valuable.
You could say "requirements are satisfied", is the threshold but those always change on a project. You need to predict what you need in the future. No one is good at that, but the fact that some may be lucky does not imply that it's possible. Doing it right in a schedule based environment means contract renegotiation. This could be expensive and many times its easier for the customer to bypass management and convince the engineers to take on more scope for free. This happens all the time, project managers need to be vigilant! But vigilance does not build value, it just creates avenues for conflict.
Regardless of what your methodology is, every successful project will become a "unknown deadline, flexible features" product at some point in its life-cycle. Why are we bifurcating that stage at an arbitrary point based on faulty assumptions made months and years in the past? What agile does is it moves the arbitrary bifurcation point to t=0 and avoids classes of zero-sum customer-management-worker conflicts.
If Agile didn't exist I think we would have just invented it.
My point is that the uncertainty in a project is a constant and every methodology which tries to change it can only hinder the work of a team.
The best we can hope is that we know what we don't know and have enough robustness to handle what we don't expect.
They can be used with any methodology - waterfall, Spiral, etc.
Most of the “modern” methodologies like scrum are too short cycled to handle complexity well. It seems that the classic techniques like PERT have been forgotten since my PM days. Very useful for something like building a house.
Part of the problem: I haven’t been able to find a decent FOSS replacement for MS Project, which is pretty expensive and not open source. Any ideas?
Then I start adding links to task predecessors. If that starts getting messy on the Gantt, I print out a PERT network, tape it together, hang it on the wall and start brainstorming with a felt tip. Enter any added links into the project.
At this point, run a Critical Path calculation (longest path through network from start to finish), which gives you the slack on the CP relative to your must finish date. Hopefully, there is some. If not, look for parallelism opportunities.
Once that's all planned out, some PMs check to see if they have enough human resources to accomplish the tasks, especially the ones running in parallel. Enter the resources, and the software will commit them as early as possible. If there aren't enough, it will push out the critical path.
Issue tracking is pretty orthogonal to project management, unless it identifies unplanned tasks out of the expected workflow. Issue tracking is usually much finer grained than project tasks.
For software, consider this: you want to do an initial system integration acceptance test with the customer next week. You just started the project. What needs to be done to pass that acceptance test? That's your first Gantt/PERT/CPM. You revise it for every integration test as the project develops, sometimes totally. In the old days, we'd call that a Spiral methodology. Top down, but keep re-visiting the top level on a scheduled basis at formal Project Reviews with the customer and negotiating any changes.
For a house, you are just starting. You want a certificate of occupancy in two months. Do you have drawings and a building permit? What needs to be done? Is it even possible? (Changes and delays will kill you, but it's always wise to move as quickly as possible!)
> Issue tracking is pretty orthogonal to project management, unless it identifies unplanned tasks out of the expected workflow. Issue tracking is usually much finer grained than project tasks.
FWIW, I tend to punt on even having an issue tracker at all. I find that it winds up being a depository for people to dump things that seldom get looked at, and absent tools to trim and prune the issues for me, it turns out that bubbling these things up as failing integration or acceptance tests is often a better use of time.
It's also possible, and sane people do this, to use ranges instead of fixed times for your durations. This helps to discover risk (particularly of exceeding a deadline).
Discovering all interdependencies and details takes much more time than completing a significant amount of the tasks. So again, the diminishing returns of project planning/guessing/tracking vs completing the work.
Also task discovery amidst execution.
The problem with some (many?) project managers is that they don't make that distinction. They just try to apply the same tools to every situation. Gannt charts for example are relatively useless to model processes that involve a lot of unknowns or branching paths. And of in such a project they are relied uppon they can become actively harmful.
But this can be the case for literally every other PM tool.
The Gantt chart is from Gantt’s method that I think were pretty much all waterfall projects as he practiced 100 years ago making factories or whatever.
But the chart is used everywhere and is super common in agile tools just to sequence stuff and demonstrate your start to start and start to finish, etc dependencies. It’s a common test to see if things targeted will fit in a sprint.
It’s funny when an article’s author doesn’t even read the Wikipedia article on things which makes you wonder what his method is for writing these. Is he randomly inserting terms?
That's a strange claim. Gantt charts are not a method, so claiming that they're "[a]lso called the “waterfall” method" is bizarre on its face. Gantt charts are a tool. They're a visualization of a schedule: the items, their expected start time, duration, their relation to each other. It's useful for any project management team. You have N issues you need to resolve (Waterfall or not) and some can be done in parallel but others have dependencies? A Gantt chart can help you visualize how the work will play out.