Scrum makes you dumb
Delivery of the "Anthropic Sympathy" keynote that this post is taken from

Scrum makes you dumb

Scrum is a suboptimal development methodology that will make developers less intelligent, less disciplined, and more forgetful. Scrum is the least-worst methodology you can adopt in a dysfunctional enterprise. This does not mean that it is something we should encourage.

Continuously delivering the most important thing in the simplest way is a much better solution.

Sprints are the problem

A central tenet of Scrum is the commitment to a set of deliverables by the end of a sprint. Deadlines help to focus the team. They also, however, give a false sense of certainty to stakeholders, and more importantly make developers:

  • less able to solve abstract problems (y'know, that thing you pay them handsomely to do)
  • exhibit reduced self-control, increasing the likelihood to incur technical debt (done to hit your arbitrary end-of-sprint deadline)
  • less able to remember to do things in the future (like patch the corners they were tempted into cutting in order to hit your arbitrary end-of-sprint deadline)

What is the basis for these outlandish claims? The wealth of research detailed in the book Scarcity.

The false certainty of deadlines

Before we get to scarcity, let me substantiate "false sense of certainty". Committing to deadlines gives stakeholders a warm fuzzy feeling that something will definitely happen.

No-one can accurately predict the future all of the time. If you think you can, I suggest you read Black Swan or go and buy me a lottery ticket. Estimates are more likely to be accurate for things that have been repeated many times, such as the billionth Lego brick to come off the production line.

If your software developers are able to accurately estimate how long something will take, you should fire them. If they've done something so many times before that they know exactly how long it'll take them to do it again, then they should have made a reusable solution by now.

The scarcity effect

Being reminded that you don't have enough of a thing that is important to you, even in a hypothetical situation, is enough to cause the previously-listed effects. In short one can imagine the subconscious diverting resources to worrying about not having enough of said resource.

I summarise this and more in my Anthropic Sympathy blog post and keynote.

In the context of Scrum the (artificially) scarce resource is time.

Scrum teams are in a perpetual state of scarcity - fretting endlessly about whether things will make this sprint of the next, and whether they'll feature in the end-of-sprint demo. Sadly I've witnessed all too often the pointless flapping over whether a feature will be done by Friday (hooray, we make the sprint!) or Monday (boo, you're late and we have to re-plan the next sprint, you awful lazy developers).

Why do we have these deadlines? Why did we make these commitments? There are two reasons for this, both of which are antiquated practices which have been usurped.

Functional teams optimise for the wrong sort of cost-saving

Dysfunctional enterprises will have one semi-valid reason. Your organisation is likely made of functional silo teams, and the next team in the value chain needs to know when you'll be done by. If you're late, then there'll be knock-on effects.

What do you mean, "dysfunctional enterprise", you know-it-all hipster?

Enterprises with functionally-aligned silos are optimising for the wrong kind of cost saving. This could be a blog post all in itself, but in today's world you should not be worried about driving down the overheads of running IT. You should be worried by the cost of not being able to deliver quickly enough.

Single-function teams are an artefact of minimising overheads, and if these teams are on the critical path to value delivery, then your organisation really needs a self-service platform and to transition to product teams.

Trust and motivation (or a lack there-of)

An insidiously pervasive reason for the prevalence of deadline-driven practices is an absence of trust and motivation. Management do not trust that a development team will be working hard; they use the looming threat of chastisement for missing a deadline as the stick of motivation.

The fear-based motivation of hitting deadlines is often accompanied in an enterprise with incentivisation schemes that are tied to the consistently counter-productive notion of SMART targets. Again a whole topic in itself, it's been demonstrated time and again that extrinsic rewards (such as money) actually decrease the likelihood of someone enjoying the incentivised behaviour, and also reduce the likelihood of the behaviour being repeated once the reward is removed.

Ordered backlog

Without continuous delivery, there is no way to demonstrate the progress a team has made. Conversely when every feature hits production upon completion, then business value is realised immediately and progress can be measured by the number of features delivered in the last two weeks.

Trust can be further built via the use of an ordered backlog. The Product Owner prioritises the backlog, and the developers only ever pick tasks from the top, thus ensuring that they're always working on the most important thing.

The backlog should be visible at all times to stakeholders, so that they can see exactly what is being worked on.

The developers implement every story in the simplest way possible, ensuring that they are not over-engineering solutions that aren't needed.

If developers are always doing the most important thing, they're never goofing off. If they're doing it in the simplest way, then they're already taking the shortest route to business value. Sticking a date in a calendar isn't going to make any difference to when the work gets done by.

Conclusion? Please stop practicing Scrum

It's hard to imagine a situation where Scrum is more productive than continuous delivery, and where its use is not a symptom of larger dysfunction in the value stream.

The one exception I can think of is the video games industry, where teams need to be single function (ie a musician isn't a gameplay programmer) and so need to coordinate around agreed objectives. As games increasingly become provided as services, I can see even this use case changing.

I'm dismayed at the wasted time and money caused by Scrum, and its negative effect on the reputation of agile practices. I urge anyone practicing Scrum to think long and hard about the above, and ask "is Scrum our ideal methodology, or is it the least-worst option of a business unwilling to modernise?"

I'd also urge you to go and read the write-up of the speech that this post is taken from. Self-service platforms, continuous delivery and productivity are all entwined topics.

Srilu Balla

SPS | PSM | PSPO | MS Information Management | Speaker | Blogger | Agilist | Software Explorer | Software Builder

3y

OMG!! This is so true. Scrum is DO IT before you Know it methodology. Lazy managers make Scrum work and yell at members who ask questions. When Agile is supposed to be about talking and conversations. Whatever. You nailed it. Ty

Like
Reply

Couldnt agree more. All that oppose mostly make a living out of it. :).

Fredrik Wendt

Growing Agility (consultant, ProAgile)

5y

When people bash things on faulty assumptions, they may appear populistic and ignorant. Happy to schedule face to face time to update your Scrum from before when the Iphone was around. (CD and Scrum works just fine together, and Scrum is no silver bullet with all the answers, that'd make it a methodology, which it ain't.)

Thank you for sharing your point of vue and your article is great by the way ; in fact I fully agree with you 😊 Howerver, what do you think to combine Scrum with Grantt diagram's ?

Like
Reply

To view or add a comment, sign in

Insights from the community

Others also viewed

Explore topics