Seneca on Speed: The Shortness of Sprints

There is a ritual that happens every two weeks in engineering teams around the world.

It is Friday morning. The Sprint ends at 5:00 PM. The kanban is still full of tickets in the "In Progress" column.

The panic sets in. Engineers start cutting corners, skipping tests, and merging code just to meet the arbitrary deadline of the "Sprint Velocity."

The complaint is always the same: "We don't have enough time. The sprint is too short."

Two thousand years ago, the Stoic philosopher Seneca heard similar complaints from the busy Roman elite. In his essay De Brevitate Vitae ("On the Shortness of Life"), he offered a rebuttal that destroys the modern excuse of "not enough time."

"It is not that we have a short time to live, but that we waste a lot of it. Life is long enough, and a sufficiently generous amount has been given to us for the highest achievements, if it were all well invested."

If Seneca were a CTO today, he would say: The Sprint is not too short. You are just wasting it.

1. The Cult of "Busyness" vs. Velocity

Seneca mocked the Romans who were "breathless with no purpose"—running from the barber to the banquet, always busy but achieving nothing.

Today, we call this Agile Theater.

We fill the sprint with ceremonies:

• Daily Standups (15 mins that turn into 45).
• Backlog Grooming (2 hours of debating features that might never be built).
• Sprint Planning.
• Sprint Retro.
• Demo Day.

By the time the Engineer actually sits down to write code (the "highest achievement"), 40% of the sprint is gone.

We are not working; we are talking about working.

The Stoic Audit:

Seneca advises us to audit our time as strictly as our money.

Look at your calendar. How many hours this week were spent in "Deep Work" (coding), and how many were spent in "shallow busyness" (Slack, meetings, status updates)?

True Velocity comes from Focus, not motion.

2. The Cost of Context Switching (The Fragmented Mind)

Seneca wrote:

"The mind that is distracted is capable of nothing... The man who is everywhere is nowhere."

This is the neurological reality of Context Switching.

A developer needs roughly 20 minutes to "load" the mental model of a complex codebase into their brain.

• If a Product Manager taps them on the shoulder (or Slack) every 30 minutes to ask "ETA?", the developer never enters the "Flow State."
• They are "everywhere" (Slack, Jira, Email), so they are "nowhere" (in the code).

The Solution:

You must guard the time of your team.

• No-Meeting Wednesdays: A modern application of Stoic solitude.
• Async Updates: Kill the Daily Standup. Write it down. Let people read it when they are ready.

3. "Premeditatio Malorum" (Pre-Mortems)

Why do sprints fail at the end? Because of Optimism Bias.

We assume the API will work. We assume the database migration will be instant. When reality hits (Heraclitus’ River), we panic.

The Stoics practiced Premeditatio Malorum ("The Premeditation of Evils"). Before starting a journey, they visualized everything that could go wrong—storms, bandits, illness.

The Agile Application:

Before the Sprint starts (during Planning), do a Pre-Mortem.

Ask: "It is two weeks from now, and we failed to deliver this feature. What went wrong?"

• "The third-party API didn't have a sandbox."
• "The design specs were missing a mobile view."

By visualizing the failure before it happens, you solve the problem while you are still calm, not when you are panicked on Friday afternoon.

4. Speed is a Byproduct of Tranquility

The fastest Formula 1 drivers say that when they are driving their best, it feels "slow." They are so focused, so calm, that the chaos slows down.

The frantic driver—sawing at the wheel, braking late—is usually slow.

The same is true for Engineering.

• Haste: Rushing to merge code without tests. (Result: Bugs, Rollbacks, Negative Velocity).
• Speed: Writing clean, tested code once. (Result: It works. You move to the next ticket).

Seneca warns us: "Nothing is less characteristic of a busy man than living."

In our context: Nothing is less characteristic of a productive engineer than rushing.

Summary

The next time your team complains that the deadline is too tight, do not just extend the deadline.

Audit the waste.

1. Cut the ceremonies. (Stop the Agile Theater).
2. Block the interruptions. (Protect Deep Work).
3. Plan for the worst. (Pre-Mortems).

You have enough time. You just need to stop throwing it away.