The Reasons Not to Use Scrum

I don't really see what's hateable in scrum, when done sensibly. Like what do you have?

1. Daily short, standup meetings just to make sure everyone is on the same page, nobody is terminally stuck, and everything is moving forward. Most of the time these are done in a few minutes and go by completely uneventfully.

2. Weekly plannings where the team figures out what to do next. That allows replying to real-world changes, or to adapt to team composition. Eg, if Bob, who knows everything there is about Postgres is on vacation, maybe we'll delay database related work until he returns.

3. Retrospective to see if everything is on track or things are getting badly bogged down somewhere. This is a good time to think about whether some feature will not make it at this rate, or such.

I don't think there's anything wrong with the core idea, and there's a lot you can adjust to your needs. If doing two week sprints is too much planning for you because all the tickets are long running, do it once a month instead.

Scrum is the duplo block of agile. That said, it doesn't have to be that heavy. A retrospective every other week, A sprint review every other week, a sprint planning every other week, and 15 minutes a day for standup.

So that's a half day block every other week and 15 minutes a day otherwise. It doesn't even need to be a half day block - our sprint plannings usually end up being 15 minutes because we work on refining tickets through the week.

My teams have 3-4 hours of standing meetings a week. We try to group them as much as possible to avoid dumb blocks of time. The vast majority of that time is going through the work together.

The vast majority of our meetings are making sure we are building the right thing. Reviewing the specification for gaps happens with development. You could say that that could be done asynchronously, and it does. But I think so much of the issue here is that people add more.

My current company's SREs switched from Kanban to Scrum shortly before I was hired, allegedly because they were working on things that were fun instead of things that were necessary.

Conversely, at my first SRE job, we did Kanban and it worked great. We met once a week, where my manager would discuss in broad strokes what needed to get done. Sometimes our Principal Eng would write a ticket to explicitly do something, but mostly we'd just figure it out on our own. Never once did anyone accuse us of being slow, missing work, etc.

I love Kanban. It's the only tracking system where you get treated like an adult.

It's a position very similar to "engineering architect" where you're given a huge amount of leeway to impose rules and process, but you have almost zero accountability.

The absolute worst are the "certified scrum masters" who are utterly bought in on whatever bogus "one true scrum process!" bullshit they've paid money to be certified in from a scummy for-profit company. I avoid these people like the plague - they kill companies.

In general - you can do quite a bit of "scrum" without any scrum master at all. Share early and often, adjust based on what else you're seeing shared and customer feedback, treat the people around you with respect, be accountable for the respect others are giving you. No scrum master needed.

Regardless I do agree with the author. In fact, in my opinion, the fact that scrum is not an engineering process is its largest shortcoming.

My opinion is that the difference between engineering and programming is that engineers support non-functional requirements. In other words they are responsible for satisfying technical constraints on a system. These are things like can my system fit within a certain size, weight, can it run at a certain speed, etc. This means that many people who are doing programming are actually doing engineering. Anyone who has tried to optimize a program is trying to meet a non-functional requirement on speed or memory usage.

Scrum does well if you want to bolt things onto your system. As a user I want to do x. Do you want to add a button? Make a user story, estimate it. Do you want to add a payment system? Make a user story, estimate it. It's simple and that makes it seductive. This sometimes works for non-functional requirements. System running too slow? Do a spike story. It was because we're using bubble sort under the hood. Make a story to swap it out with quick sort. But what if I want to change my response time of my system from 2s to 1s? Well we need to re-architect our system and launch a new satellite into orbit. Alright, so you can do that in a sprint, right?

For me, Scrum is a toy process of what business people think engineering is. It fails as a process because it doesn't account for non-functional requirements and it doesn't admit its shortcomings.

In other words, these things are very valuable: Individuals and interactions, Working software, collaboration, Responding to change.

https://agilemanifesto.org/

If you split up a task and assign parts to team members, you are only 30% done when all members have completed their part of the task. 70% of the work is in combining the parts back into a coherent whole.

So the teams that fail horribly are the ones that work in isolation and believe that combining the output of that work is easy.

The teams that actually get a product out the door focus on the majority of the work (making a coherent whole out of disparate parts) as SOON as possible.

That means sharing back with the group at the earliest possible moment, and then as often as possible as you update and change your part.

Now... scrum is hardly the only way to make that happen, but I think the processes it encourages follow the same trend: Work alone for very short periods, share often, adapt as needed in response to what else is shared.

The problem with scrum is just all the rest of it (especially scrum masters... those certifications are a black mark on your resume in my opinion).

Instead, build a steel thread. Make the simplest thing that can go through every team first. Every team working on the project goes to build that initial slice of functionality. When done, you have the infrastructure and tests necessary to make sure each next slice is functioning. It means that you have a low level friction through the project, but it is much smaller than the overall friction at an integration phase.

Then, use meetings to discuss the clarification of the specification and the technical design. Any status meetings can be at the EM/PM/Lead level as necessary but you will have the feedback to know how things are progressing quickly.

The whole dynamic of fixed-length iterations and "commitment ceremonies" puts heavy social pressure on developers to hit lots of tiny deadlines. And when minor estimation errors occur, there's a risk of developers shipping code that technically meets requirements, but which subtly compromises quality or maintainability. But hey, they kept their promises!

And then you hold retrospectives where you try to find out why production is a dumpster fire and the clients are unhappy.

Even skilled software estimators may be off by 50% on individual features. Over time, this mostly averages out. But chopping time up too finely and applying social pressure to consistently hit lots of micro-deadlines has to be paid for somewhere.

I am personally a fan of Kanban: Keep a priority queue of features. Estimate them as best you can. Allow decision makers to reorder the queue as they learn about customers. This still gives you rough estimates, and the ability to track estimation accuracy. But it doesn't back team members into a corner where they feel pressured to ship two days to soon just because it's the end of the iteration.

Organizations obsess over details. They want detailed plans and cost estimates months ahead. They have a low or zero tolerance for failure. They think in hard promises/contracts and punishment for those that don't deliver. All of this is entirely opposite to the core of agile, which "discovers" reality as it progresses.

Because people lack discipline, will powder Scrum meetings on top of existing meetings, create more meetings from stand-ups because Scrum doesn't teach individuals to be disciplined, drag out the meetings, etc. Scrum's entire premise of "get everyone together and talk" is the very thing which encourages people to talk. A lot. Without providing any suggestions to counteract it beyond "draw the head of the owl, now draw the rest"-type of advice.

>And how is having meetings a negative thing for remote work?

Meetings imply synchronous communication. Author is conflating remote with asynchronous, but nothing about the story implies collaboration needs to be synchronous / meeting-heavy either.

Standup/scrum meetings should be about identifying the work that has stopped moving forward or is progressing slower than we’d like it to. The team might find a solution on the spot or a new ticket is created and assigned to someone to dig deeper for a solution. Probably that ticket is assigned to the Product Owner.

Most standups/scrum meetings are not about unsticking work. What they are about will vary depending on the particular dysfunction of the company, e.g. managers trying to make sure everyone is working.

One place I worked at had two week sprints. The entirety of one day every sprint was spent on demo, retro, planning, commitment. But because the scrum master had to "build" a sprint and couldn't do that without knowing the size of tickets, there were two morning meetings every week to "analyse" tickets.

So you had: Week 1, 1 full day Scrum day, 2 half days. Week 2: 2 half days. So 3 days out of the 10 day sprint, so 30% time spent on Scrum.

Plus standups, so the hour before the standup nobody did anything (as judged by the number of PRs and comments and Slack activity) so that's an hour plus the time for standup every single day.

Maybe that's insanity, I mean I certainly thought so, but these things do happen.

But is it more valuable than the work that would have been produced by the e.g. 10 people, working for that hour in the flow every single day, if they hadn't been interrupted by that meeting? (Before/after the 15 minute meeting people are going to go for coffee, read emails, read the news etc., so you're probably losing about an hour of "flow" work by having the meeting.)

That's what we do at my company and it works pretty well. No process is perfect, but we really try to keep meetings to a minimum for devs. Daily standup is literally 5 minutes.

Scrum is just that plus these things:

- showing the client or their in-house rep what you've done and getting their input on it

- checking in with yourself + your team that the systems are working or working out how to improve them

- some recommendations for how often to do those, and for how long

- definitions of two other roles: one to own shaping the backlog and one to work as "manager" - does soft-skills people stuff, liases around the company to solve blockages, trains the developers who need it how to do this last bit themselves.

Scrum is informal, and the only strict parts are designed to monkey about with traditional business structures (business analysts, project management, line managers). When I say "monkey about with" I mean this: change the roles and lines of communication to reduce silo-ing.