business – Arabela Navarro

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:

What it’s made of
What structure it has
What created it
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:

Cause	PM Translation	Type of Problem	Examples	Typical Wrong Fix
Material Cause	Resources	Capacity / Constraints	• Not enough QA • Budget limitations • Tooling gaps • Unrealistic timelines	Pushing the team to “work faster” instead of adjusting capacity or scope
Formal Cause	System Design	Structure	• Poor backlog definition • Unclear processes • Weak architecture decisions • Misaligned workflows	Adding more meetings or micromanagement instead of fixing the system
Efficient Cause	Execution	Delivery	• Low productivity • Communication breakdowns • Lack of accountability • Ineffective ceremonies	Redesigning the process instead of coaching or improving execution
Final Cause	Purpose	Direction	• 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:

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

Why Productivity Advice Doesn’t Always Apply to People in Consulting (And That’s Okay)

Every time I watch a productivity video on YouTube, I notice a pattern: most creators showcase beautifully minimalist calendars with one or two meetings per day. They have spacious blocks for deep work, creative thinking, gym sessions, or even long walks to “reset the mind.”

I admire their discipline. But I also can’t help but think, What world are they living in?

Because in mine—the world of IT consulting—it’s not uncommon to have 5, 7, or even 10 meetings in a single day.

So… am I doing something wrong?

The Consulting Reality

In consulting, especially in tech, the environment moves fast. We work across multiple teams, clients, time zones, and technologies. Communication is part of the product we deliver.

Many of us work in complex implementations. That alone involves developers, architects, QA, UX designers, clients, and internal stakeholders—each with their own expectations and timelines.

And so, the calendar fills up. Quickly.

The Myth of “One-Meeting-a-Day” Productivity

A lot of productivity advice is based on individual contributor roles or solopreneur lifestyles. These creators often have full control over their schedules. They can say “no” freely. They can disappear for hours to do deep work.

That’s not always the case in consulting. We work in environments where alignment and collaboration are essential—and that often translates into meetings.

But Does That Mean We’re Doomed?

Not at all. But it does mean we have to define productivity differently.

For us, being productive might look like:

Facilitating clarity across stakeholders
Making a key decision during a call that unblocks an entire team
Managing to create 30 minutes of quiet focus amidst the chaos
Ending the day knowing your clients, teams, and timelines are aligned

And yes, some days will still feel overwhelming. But that doesn’t mean you failed—it just means the nature of your role requires flexibility and resilience.

What Helps Me

I try to limit myself to three meaningful meetings per day. I don’t always succeed, but this goal helps me stay aware of my energy.
I time-block focus time the night before—just like I would a client call.
I promote async updates when possible. Not everything needs a meeting.

Final Thought

If you’re in consulting and feel guilty for not living up to the productivity standards you see online—please stop. You’re not doing it wrong. You’re just playing a different game.

The key is to find your own definition of productivity, based on the realities of your work, your energy, and your goals.

Because in the end, productivity isn’t about copying someone else’s routine—

it’s about creating a rhythm that works in your world.