When Scrum Mattered

Scrum was once an important part of my public identity.

I read it, practiced it, blogged about it, and eventually wrote a book about it. This was not a passing interest in a fashionable methodology. Scrum changed how I understood work.

Before that change, project management was already an important professional skill for me. I wrote about it often between 2008 and 2013. I considered myself good at it. I could structure work, coordinate people, manage dependencies, and move a project toward delivery.

Scrum disturbed one part of that competence in a useful way.

It replaced push with pull.

The difference pull made

Traditional project management could easily place the manager at the center of movement. The manager divided the work, assigned it, followed up, escalated, and pushed the system toward the plan.

Scrum asked a different question: what happens when capable people pull work they understand and can own?

That change looked procedural, but it was deeper than procedure. Pull required clarity, competence, trust, and visible commitments. It asked the person doing the work to become an active participant in deciding how the work would move. It reduced the distance between responsibility and action.

That is what drew me in.

I became an avid reader and practitioner. I started ScrumZen and wrote about the problems we encountered while using Scrum. I wrote for Scrum Alliance. My 2012 article, Seven Things I Wish I'd Known When I Started Out as a ScrumMaster, received attention, comments, and criticism. That response mattered because Scrum was not merely a subject I was studying. I was testing my understanding in public.

The surviving files show that I was working on #SCRUM tweet in April 2012. The book was designed as 140 short thought-lenses about building better software through Scrum. I wanted the ideas to be brief enough to remember and useful enough to change behavior.

Then I had to write the book again.

The manuscript I lost

On November 1, 2013, on Dhan Teras, someone broke the glass of my Honda City and stole a Mac, a BlackBerry, and a hard disk from the car.

The manuscript went with them.

I remember the event through those physical objects: the broken glass, the missing devices, and the absence of work I believed I had already done. Losing equipment was one thing. Losing the manuscript was different. A device can be replaced. Reconstructing thought is harder.

I recreated the book. #SCRUM tweet was eventually published in 2016.

The reconstruction now feels consistent with the subject of the book. I had lost a plan and an artifact. I still had the thinking that produced them. The work could be rebuilt because the ideas had already entered my practice.

A note of gratitude

I did not arrive at the book alone.

I first met Rajesh Setty online while studying “distinguishing the distinction” after Landmark Forum. He became my mentor. His guidance and encouragement helped me find my way to the book. Rajesh created the ThinkTweet form that grew into the ThinkAha series and served as its executive editor. He guided me as I wrote #SCRUMtweet.

My friend Tanmay Vora had already written #QUALITYtweet. I reviewed its manuscript, and his example showed me what this unusual form could hold. Mitchell Levy, Rajesh's publishing partner, took on my first book as its publisher.

I remain grateful to all three. Rajesh's influence, however, went beyond the making of this book. I learned from his ideas, but even more from the generosity with which he helped other people bring their ideas to life.

What the old writing already knew

Reading the work now, I can see both conviction and warning.

The conviction is obvious. I believed Scrum could help teams build better software, deliver value sooner, make impediments visible, and replace command with self-organization.

The warning was already there too.

One book lens says methodologies are only a means to deliver. Another says working software matters, not the processes. My Scrum blog then said, “Scrum is a vehicle, not the destination.” It also said Scrum does not solve problems. It exposes them, and people still have to solve them.

Those were not side comments. They were the beginning of the position I hold now.

Any process is not a solution. A solution is a solution.

A framework may help people see reality. It may create a cadence for making decisions. It may limit work in progress, shorten feedback loops, or clarify who owns what. Those are meaningful contributions. They still do not solve the customer's problem, make a weak product valuable, repair poor judgment, or create responsibility where incentives punish it.

The process must remain subordinate to the problem and the solution.

When Scrum becomes the work

Scrum is most useful when it creates evidence and adaptation. It becomes harmful when performing Scrum replaces doing the work.

A backlog can grow while understanding shrinks. A daily meeting can become a status ritual. Velocity can rise while value remains uncertain. A retrospective can name the same problem repeatedly without changing the system that produces it.

None of this proves that Scrum failed. It shows that a framework can be followed without its purpose being served.

The official Scrum Guide has become less prescriptive since my early writing. It no longer mandates the familiar three Daily Scrum questions. It describes teams as self-managing, not merely self-organizing. It emphasizes goals, value, and adaptation, and it no longer assumes that Scrum belongs only to software.

The wider world of project work has moved in a similar direction. Predictive, agile, and hybrid methods can all work. Current project research increasingly points toward fit, value, adaptability, stakeholder alignment, and systems thinking rather than loyalty to one methodology.

That does not make method irrelevant. It puts method in its proper place.

What I would carry forward

I would still carry several disciplines from Scrum into serious work:

• establish a meaningful goal before organizing activity;
• let people pull bounded commitments they can own;
• make work, constraints, and uncertainty visible;
• produce evidence rather than polished status;
• inspect the evidence with the people affected by the outcome;
• adapt when reality contradicts the plan;
• agree on what acceptable completion means;
• improve the system, not only the task list.

These disciplines do not need Scrum terminology to remain useful. They belong to a broader capability.

I think of that capability as project leadership under uncertainty.

Project management coordinates work that is sufficiently understood. Project leadership under uncertainty keeps the mission coherent while the work, environment, and possible solution are still changing.

That leadership cannot live only in a designated project manager. A Forward Professional provides it wherever the mission needs clearer intent, better evidence, a decision, or responsible adaptation. The title matters less than the willingness and ability to pull the right problem.

This is also where the entrepreneurial spirit enters the work. Entrepreneurship is not confined to founding companies. It appears whenever someone accepts responsibility for movement without waiting to be pushed through every step.

Scrum helped me see that.

It was not the final answer. It was one of the systems that changed the questions I asked. It taught me to look for pull, evidence, ownership, and adaptation. Experience taught me to ask one question before defending any process:

What solution did it help us create?