Tag: Project Management

Gantt Charts Are Not the Enemy of Agile

There’s a quiet assumption in many Agile teams that I’ve always found interesting: Gantt charts are for waterfall. Almost like they belong to a different world—a world we moved on from.

And yet, every time I hear someone say “Gantts are for waterfall”, I can’t help but wonder if we’re not actually avoiding Gantt charts… but avoiding time and visibility.

Because here’s the uncomfortable truth: Scrum helps us manage work, but it doesn’t always help us understand time. And time matters.

When I look at a backlog, I see priorities. When I look at a sprint board, I see execution. But when I look at a Gantt chart, I see something different. I see consequences. I see what happens if something slips. I see dependencies that weren’t obvious before. I see whether “we’ll probably make it” is actually true… or just optimism.

Some people resist Gantt charts because they associate them with rigidity—fixed timelines, fixed scope, heavy planning. But a Gantt chart is just a visualization. It doesn’t force you into waterfall. It simply answers a question Agile teams sometimes avoid: given what we know today, will we finish on time?

In complex environments, especially when multiple teams and dependencies are involved, that question is not optional. It’s leadership. Because without that visibility, dependencies become surprises, delays become explanations, and deadlines become negotiations.

A Gantt chart doesn’t replace Scrum. It complements it. Scrum operates in the present—what are we doing now? A Gantt chart connects the present to the future—where is this actually going?

And maybe that’s the real shift. Using a Gantt chart is not about controlling the team. It’s about respecting reality.

Lately, I’ve been thinking about this through a different lens. When I play chess, sometimes I get so focused on the piece in front of me that I completely miss what’s developing on the other side of the board. And then I lose a piece and think, “how did I not see that?”

Gantt charts feel like stepping back from the board. They don’t tell you what move to make, but they help you see what’s coming.

So no—Gantt charts are not anti-Agile. Used correctly, they are a tool for awareness. And in both chess and delivery, awareness changes everything.

The 4 Causes of Every Project Problem (What Aristotle Can Teach Modern Leaders)

Recently, I came across a video explaining the philosophy of Aristotle—specifically, his idea of the four causes.

It’s a 2,000-year-old framework meant to explain why things exist the way they do.

My immediate thought was: This applies to Project Management.

Not metaphorically—structurally.

Because one of the most common challenges in delivery is not execution itself, but misdiagnosing the type of problem we’re dealing with.

When something goes wrong in a project, the default response is:

  • Run a retrospective
  • Perform a root cause analysis
  • Use tools like the Five Whys

This approach is useful—but it assumes that every problem has a single causal chain. In practice, that’s rarely the case. They usually have multiple reasons.

Aristotle proposed that to truly understand anything, you need to look at it from four different perspectives:

  1. What it’s made of
  2. What structure it has
  3. What created it
  4. Why it exists

The Five Whys asks: “Why did this happen?”

Aristotle’s model asks: “What type of cause explains this?”

This is not a deeper question—it’s a different dimension of thinking.

Thinking with this framework can look like this:

CausePM TranslationType of ProblemExamplesTypical Wrong Fix
Material CauseResourcesCapacity / Constraints• Not enough QA
• Budget limitations
• Tooling gaps
• Unrealistic timelines		Pushing the team to “work faster” instead of adjusting capacity or scope
Formal CauseSystem DesignStructure• Poor backlog definition
• Unclear processes
• Weak architecture decisions
• Misaligned workflows		Adding more meetings or micromanagement instead of fixing the system
Efficient CauseExecutionDelivery• Low productivity
• Communication breakdowns
• Lack of accountability
• Ineffective ceremonies		Redesigning the process instead of coaching or improving execution
Final CausePurposeDirection• Misaligned priorities
• Unclear business goals
• Delivering output without value
• Teams optimizing for the wrong outcome		Optimizing delivery speed instead of realigning goals and value

Next time something goes wrong in your project, pause and ask:

  1. Material → Do we have the right resources?
  2. Formal → Is the system well designed?
  3. Efficient → Is execution effective?
  4. Final → Are we solving the right problem?