Is Scrum obsolete?

The blog title may be mischievous, but that thought did run through my mind when I last interviewed for a job. I had spoken to 4 companies at the time, and 3 out of those 4 places deployed to production at least daily. If Scrum is a series of time-boxed sprints or iterations what meaning does it have when you ship stuff daily? I'm not saying Scrum should die, but I do wonder whether it deserves to be the default choice at so many software development organizations these days. It certainly did not seem to be a good fit for those doing daily deploys. Should we assume it's a good fit for most places?

I don't pretend to be an expert on development methodologies. What I am wondering is whether a lot of Scrum shops might not need its strengths and consequently suffer its downsides needlessly. Scrum is not the only "Agile" methodology, but it seems to be among the most rigid and ceremony-heavy. There's some pain involved. Is it worth it?

Gain

Let's consider what you gain with Scrum.

Scrum is great in a low trust environment, such as if you are a consultant doing work for another party. The artifacts that Scrum generates -- such as stories/tasks and estimates -- are great for billable work and accounting. The customer is always right, but changes will cost you, and I can document every cent. Why do I need so much money and time for this work? What have I been up to? I can show you. Scrum artifacts provide an excruciatingly detailed accounting and micromanaging of work that allows stakeholders to negotiate, commit and monitor. In fact, some Scrum terminology like committing to stories sounds like you're negotiating a contract every sprint. But what if you're not in a low-trust environment? Like many developers, I work full time at a company that sells software, not services. We work for ourselves. Do we really need all that cruft?

Scrum is great if your team needs protection. Its rigid time boxing prevents the chaos and churn when your team constantly gets hit by shifting external demands, whether they be from your client or from your own company. For the duration of a sprint, your team is allowed to do what it planned for that sprint. But what if your team needs no protection? If your team is simply given a broad mission and autonomy to pursue that mission, then it can drive itself rather than be driven in turn by external forces.

Scrum is great if you have rigid deadlines. If something absolutely must ship by date X, then you'd want something shippable by date X. Breaking down epics into stories into tasks allows you to adapt your priorities over time to fit a rigid deadline. What if you have no deadlines? SaaS companies don't even need to ship anything these days. We can deploy software any time, everywhere, whenever we feel like it.

In other words, it seems that Scrum is useful for compensating for organizational limitations. Where these organizational limitations do not exist, the pain associated with Scrum may not be worth it.

Pain

There's no free lunch. Along with Scrum's advantages, there are a few things it brings that bug me.

Scrum is very needy. This should be obvious. There's the all-day sprint planning meeting. There's the daily namesake meeting. There's the retrospective. For some of us, there's also the backlog grooming. Epics. Stories. Plan. Estimate. Task. Estimate more. There's a lot of busy work here that has nothing to do with delivering value.

Artificial deadlines teach us to do less. We are asked to estimate effort and time, and are bound by our estimates. We are honor-bound to complete a story within a sprint, so we learn that aggressive or even good-faith estimates are never rewarded. Consequently, we learn to pad our estimates. Success is predictability. Success is non-deviation. As a result, we learn to promise less and do less, because that is how success is measured.

Scrum doesn't let us do work in a straightforward, obvious way. I don't like the way Scrum distorts the way we work. Scrum requires that each user story deliver value and fit within a sprint time box. That often has little correlation with how we would naturally do the work. We have to distort work to fit an arbitrary time box, or write a little fiction. These 2 stories can actually be implemented with the same development task? Let's do the real work in the first story and fill the second with padded QA tasks. This story cannot be done in a single sprint? Instead of just doing the work in 1.5 sprints, let's artificially break down the work into separate stories that must be implemented separately.

In all places I've seen it, Scrum was imposed by management rather than requested by the staff. In many ways, it's easy to just go for Scrum. It's well-known, well-documented, and there's a big industry of Agile coaches, consultants and instructors ready to onboard your organization. In other words, it's the Standard. Developers like standards, don't we? But unlike our technical standards, this is a standard for driving human behavior. Humans are not machines. The need for coaching is a clue: Scrum is not easy. It's not something that comes naturally to humans, not how we naturally work. It's not humane.

I will probably write another blog post some day about how my current Scrum-free environment works. In the meantime, I offer a little food for thought: Scrum is primarily a planning tool. You spend so much time building intricate epic/story/task artifacts, arguing about whether to split a story or how much time a task needs. But it's only planning. What if we spent less effort on the planning, and more on the doing?

Related links

Christopher O'Donnell's tweet storm on Agile