SCRUM: The Revolutionary Art of Managing People Who Somehow Managed to Work Before You Arrived

How an entire generation reinvented the meeting, renamed the to-do list, and convinced corporate America that putting on socks requires a two-week sprint.

There was a time, not so very long ago, when companies employed people who possessed a remarkable and apparently extinct skill: the ability to do their jobs without assembling in a circle every morning to discuss the emotional journey of doing them.

These primitive workers operated in an astonishingly unsophisticated environment. They were assigned tasks. They completed those tasks. Occasionally, they encountered problems and, through some mysterious combination of professional experience, independent thought, and basic human communication, resolved them.

Then came Scrum.

And with it, an entire generation of aspiring managers who apparently looked at centuries of human productivity and concluded that the real problem was insufficient meetings.

The Great Sock Crisis of the 21st Century

Imagine waking up tomorrow morning and discovering that putting on your socks has become an Agile project.

First, you’ll need a Scrum Master. This is someone who doesn’t actually put on socks but facilitates the sock-wearing process by ensuring that everyone understands the importance of putting on socks.

Next, you’ll need a Product Owner, who will determine which socks deliver the greatest business value.

Then comes sprint planning.

The team gathers for 90 minutes to discuss whether the left sock should be prioritized over the right sock, whether both socks can reasonably be delivered within the current sprint, and whether putting on shoes represents an unacceptable expansion of scope.

Naturally, someone from management will interrupt to ask whether the socks can be delivered by Thursday.

A junior project manager will create a Jira ticket.

A senior project manager will create a dashboard.

And an executive will proudly announce that the organization has achieved a 17% increase in sock-related velocity.

Nobody has socks on.

But the dashboard is green.

Congratulations! You’re Now a Scrum Master!

One of the truly remarkable achievements of modern corporate culture is the creation of an entire management ecosystem around the revolutionary concept of asking people what they’re doing.

Consider the daily stand-up.

Every morning, highly trained professionals interrupt their actual work to gather around a conference table or stare into Microsoft Teams and answer three questions:

• What did you do yesterday?

• What are you doing today?

• What’s blocking you?

These are, coincidentally, the same questions a reasonably attentive manager could answer by occasionally speaking to the people they supervise.

But that would be management.

And management, apparently, doesn’t scale.

Instead, we have Scrum Masters, Agile Coaches, Release Train Engineers, Product Owners, Delivery Managers, and an ever-expanding collection of people whose primary responsibility is ensuring that the people doing the work spend a significant portion of their day explaining why they haven’t finished the work.

The irony is magnificent.

We’ve created a generation of professional productivity supervisors whose productivity is measured by how frequently they interrupt productivity.

The Two-Week Miracle

At some point, someone decided that the fundamental unit of human achievement should be approximately fourteen days.

Thus was born the sprint.

Apparently, the construction of complex software, the maintenance of enterprise infrastructure, and the resolution of unpredictable technical problems can all be neatly divided into two-week increments.

Never mind that a critical production outage doesn’t care about your sprint.

Never mind that a complicated engineering problem might take three hours or three months.

Never mind that your most experienced engineer may spend an entire afternoon preventing a catastrophic failure that never appears on anyone’s carefully groomed backlog.

No.

We must respect the sprint.

The sprint is sacred.

The sprint has velocity.

And velocity, as everyone knows, is what happens when you assign arbitrary numerical values to work you don’t understand and then congratulate yourself when those numbers increase.

An engineer might spend six hours resolving an obscure kernel issue affecting hundreds of production servers.

That’s three story points.

Meanwhile, someone else spends two days updating Jira tickets, reorganizing the backlog, and documenting the team’s commitment to continuous improvement.

That’s thirteen story points.

Guess who’s getting recognized at the next quarterly business review?

The Infantilization of the Experienced Professional

Perhaps the most insulting aspect of this magnificent corporate experiment is the assumption that highly experienced professionals require the same level of supervision as a kindergarten class preparing for recess.

Imagine an engineer with 25 years of experience.

This person has survived catastrophic production outages, midnight emergency maintenance, operating system migrations, security incidents, and enough executive-driven architectural disasters to develop a healthy distrust of PowerPoint.

They understand the systems.

They understand the customers.

They know what needs to be done.

Enter Tyler.

Tyler is 26 years old, recently completed a three-day Scrum certification, and has been appointed Agile Transformation Lead.

Tyler would like to know whether the engineer’s investigation into a production database failure can be broken into smaller user stories.

Tyler also wants to know why the engineer hasn’t updated the acceptance criteria.

The engineer explains that the database is currently on fire.

Tyler nods thoughtfully.

“That sounds like a blocker.”

Tyler schedules a meeting to discuss it.

The database continues burning.

We Don’t Have Managers Anymore. We Have Facilitators.

Somewhere along the way, actual leadership became unfashionable.

Leadership once meant understanding your team’s capabilities, establishing priorities, removing obstacles, making difficult decisions, and accepting responsibility when things went wrong.

Today, leadership increasingly appears to mean facilitating a collaborative discussion about which collaborative discussions should be facilitated next.

Nobody wants to make a decision.

Decisions create accountability.

Accountability creates risk.

And risk might negatively affect someone’s quarterly performance review.

Far safer to schedule a retrospective.

In the retrospective, everyone can discuss what went well, what didn’t go well, and what the team might do differently next time.

Naturally, the team will identify excessive meetings as a major impediment.

Management will acknowledge this valuable feedback.

Then management will schedule a follow-up meeting to develop an action plan for reducing meetings.

A new recurring meeting will be established to track progress.

The Corporate Theology of Agile

What makes this entire phenomenon particularly entertaining is that Scrum has acquired many of the characteristics of organized religion.

There are sacred texts.

There are certified practitioners.

There are rituals, ceremonies, and evangelists.

There are people who travel from company to company preaching transformation while demonstrating remarkably little interest in understanding what those companies actually do.

And whenever Scrum fails, the explanation is never that Scrum might be poorly suited to the work.

No.

The organization simply wasn’t Agile enough.

You didn’t embrace the framework.

You resisted the transformation.

Your team lacks Agile maturity.

It’s a beautifully constructed system in which the methodology is incapable of failure because every failure can be attributed to insufficient devotion to the methodology.

Meanwhile, somewhere in the building, an experienced engineer is quietly fixing a problem that six Agile Coaches have been discussing since Tuesday.

The Final Retrospective

To be fair, there’s nothing inherently wrong with organizing work into manageable pieces, communicating regularly, identifying obstacles, or reviewing what went wrong.

Competent teams have been doing these things since approximately the invention of civilization.

The absurdity begins when perfectly reasonable management practices are transformed into an elaborate administrative religion that consumes more resources than the problems it was supposedly created to solve.

When engineers spend more time updating tickets than solving problems, something has gone terribly wrong.

When managers require dashboards to understand what their own employees are doing, something has gone terribly wrong.

And when a company needs a Scrum Master, an Agile Coach, two Product Owners, and a Release Train Engineer to coordinate four people who already know how to do their jobs, perhaps the organization should reconsider exactly what it’s optimizing.

But don’t worry.

I’m sure someone is already working on that.

They’ve created an epic.

They’ve identified the stakeholders.

They’ve scheduled a backlog refinement session.

And they’re currently debating whether the initiative can be delivered within the next two sprints.

BREAKING: Engineering Team Completes Entire Project While Scrum Master Is on Vacation

Management launches immediate investigation into unauthorized productivity.

Initial findings suggest that employees communicated directly, made independent decisions, and completed assigned tasks without first obtaining consensus on their Fibonacci-based complexity estimates.

The organization has announced an emergency Agile maturity assessment to ensure this never happens again.

In the meantime, Tyler would like everyone to update their Jira tickets before tomorrow’s stand-up.

And for goodness’ sake, somebody help him find his socks.