I’ve been reading quite a bit of material produced by the agile community of late. I’ve looked into engineering practices and culture. I’ve observed agile metrics and product identification. I’ve even stumbled into the realm of marketing and team building. In all of this, I’ve seen the same old trope wheeled out — “Scrum isn’t appropriate for the modern age”. Then, what follows is what I can only describe as the ultimate straw man convention. Arguments so fragile, I could write an application in VB.net and brute force them into submission. With that in mind, I thought I’d address some of the common critiques that I bump into regularly.
Scrum is old now
I’m endlessly confused by people who equate an idea being old with it being ineffective. People just say “Scrum isn’t relevant any more” and leave it at that, as if that’s an argument on its own. New things are awful. I’ve recently found out that dabbing (which was bad enough) has got a freakish, mutated cousin named flossing. Back in my day, the cha-cha slide kept us true and I don’t see any reason to change now. Scrum is the cha-cha slide. Useful, concise and timeless.
One release a sprint is too slow
This is what you look like when you tell me that scrum mandates one release per sprint
Let’s have a quick look at the scrum guide.
At the end of a Sprint, the new Increment must be “Done,” which means it must be in useable condition and meet the Scrum Team’s definition of “Done”
Funny that, it almost sounds like the minimum you should be doing is once a sprint. Does it tell you a maximum? No! That would be insanity. Go and cowboy things into production to your hearts content.
The daily stand up lasts too long
Imagine Elon Musk looking at you like this and asking “You can spend 8 hours reading Centos documentation in your basement, but you can’t talk to other humans for 15 minutes?”
If you can’t stand in the same spot for 15 minutes, see a doctor. If you’re standing in the same spot for longer than that, you’re not doing scrum you silly goose!
The Daily Scrum is a 15-minute time-boxed event for the Development Team.
This also covers variations on this theme — “The stand up has nothing to do with the engineers”, “The stand up is so boring”, “No one is listening at stand up”. Adjust your glasses and read the freaking scrum guide. Stand ups should be short, to the point and developer lead.
Engineers don’t get a say (The product owner has too much power)
The role of the product owner is to optimise the team’s ability to deliver value. Here are a list of things that doesn’t mean.
- They don’t get to aggressively shut down any dissenting opinion.
- They don’t have to get a say in your salary bump.
- They don’t need to sign off on your lads holiday to Ibiza (you degenerate).
What they get to do is know intimately what is good for the product. They should then seed that knowledge into the team with evidence based reasoning. A good product owner will discuss with the team, engaging the experts that Scrum has surrounded them with and form a considered, measured, informed opinion. In fact, that’s not even limited to good product owners — that’s the default position of a rational human being. Scrum doesn’t tell your product owner to be irrational. Your problem isn’t with the notion of a product owner. It’s that one of your colleagues is a dick.
We should be able to talk whenever we want, not just in the ceremonies
Wow, you’re right. I’ve been living a lie. I must have missed the bit in the scrum guide that stated:
Thou shalt not communicate except within the pre-approved ceremonies. All else is silence. Headphones are to be worn at all times. Long live anime and misanthropy.
These ceremonies are the absolute bare minimum you need to collaborate effectively — they are there to ensure you’ve got the opportunity to talk. If you wanna talk outside of them, go right ahead! Scrum doesn’t give a s**t.
Our industry moves too fast for Scrum
Did you know that Netflix can stick to a plan for a couple of weeks? Your company that customises wardrobes is probably going to be okay. Unless you’re in an actual war zone, writing code that will fix turrets to defend you from the rifle wielding marathon sprinters that have you surrounded, I’ll be willing to bet you can stick to a sprint. All that aside, even if you genuinely work in an absolute mad house, let’s look at what scrum says.
During the Sprint:
No changes are made that would endanger the Sprint Goal
Let’s say you’re managing production infrastructure. Estimate it! Measure your defect rates and your mean time to fix. Understand how you’re working as a team and budget for it in your estimations. If your users are completely inept (they are), estimate for it! Add some contingency. It doesn’t need to be exact but put some padding in. You’re responsible for telling the wider team what is possible, given the constraints you’re in.
But what if the sprint is completely pointless now? The scrum guide has a section all about cancelling a sprint. You know what it advises? Cancel the sprint, meet up, discuss what you did in the last sprint and what you need to do in the next sprint — then do it. Wow, so much process and ceremony. Talking a bit, then doing things. Intolerable.
Scrum vs Kanban
That’s a bit like saying Alan Partridge vs Hulk Hogan — they do different things. Kanban is a collection of processes for improving the flow of work through a system. Scrum just cares that you’re meeting regularly and reviewing yourself and your plans. The scrum guide, when describing the development team, states this:
They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;
So if you want to apply Kanban principles to your ways of working, go ahead and do it. Scrum, again, doesn’t give a s**t. You’re the engineer and it’s on you to decide how to do your job.
Isn’t a sprint goal like, a deadline?
No. It’s a goal. That’s why it’s called the “Sprint goal” and not the “Sprint deadline”. Let’s look at the definition of a deadline:
the latest time or date by which something should be completed.
And a goal.
the object of a person’s ambition or effort; an aim or desired result.
Funny that, the latter sounds way more like a sprint goal. Let me ask you, what happens if you miss a sprint goal? How often do you simply carry over to the next sprint with the same ambition? If the answer is “all the time!” then it’s not a deadline. You’ve passed it and it’s still just as valuable, ergo it’s a goal. Your court date for indecent exposure is a deadline. Changing your website colour scheme from mauve to lime green is not.
So why put a date on it at all? Remember, scrum is the minimum set of meetings necessary to collaborate. Essential to agility is regularly analysing your goals. If you miss a sprint goal, sprint planning and sprint review will let you know if it’s worth pursuing while sprint retrospective will allow you to highlight what went wrong before you carry it over and have another whack at it (or not, if you decide). That meeting might be as simple as “Keep doing what you’re doing, it’s cool” or it might be as complex as rethinking it entirely. You don’t know until you talk.
So why does my product owner treat it like a deadline? Because your product owner hasn’t read the f***ing scrum guide. Print it off and staple it to their chair or, better yet, send them a link to this article with some 🔥emojis.
I understand the product already, I don’t need a product owner.
Your soul is the marshmallow, being toasted on the fires of burnout.
So in between researching new technology, plugging holes in your infrastructure (which you now run thanks to that pesky Devops culture), managing your technical debt, mentoring junior engineers or being mentored by seniors, giving lightning talks and brown bag sessions, performing ritual sacrifices to the ghost of Alan Turing, arguing with your support team and supporting the existing production software yourself because your support team keep forwarding you emails… you’re also happy to go to the stakeholders and debate costing, time scales, road maps and feature prioritisation and everything else that goes with growing a product? You’re going to do the analysis to find out which feature fits next? Maybe read some books on marketing and product development while you’re at it! Hell, after all that you can write a blog post about how ProductDevSecHROps has changed your life and the grey hairs are unrelated, really.
Maybe in Silicon Valley. Not in Stockport.
The truth is this. There is a lot of due diligence and work that needs to go into, not only building a product, but creating an office culture whereby good software can continue to be made and engineers are encouraged to be the best versions of themselves. You’re just as responsible for the latter as well as the former. Don’t let your ego turn you into a zombie and don’t let your product turn you into a customer service representative. Scrum is dead right on this one. Product is an entire domain in its own right and putting that onto people who are already slammed is, not only hilariously impractical, but also unbelievably unfair.
Man, all these meetings are so unnecessary
Let’s just have a quick look at what scrum advocates.
- Sprint planning — Work out what you want to do in the sprint.
- Daily scrum — Work out how you’re gonna tackle the next day.
- Sprint Review — Work out what you did in the sprint.
- Sprint Retrospective — Assess out how you worked in the sprint.
What the hell were you doing before? Did no one know what they were doing? Did you not talk? Maybe no one ever came and looked at your work. Maybe you never once looked at how you’re working and thought about how it might be better. What do you think life is like without Scrum? Do you think all of these things will just go away and you will be all the better for it?
Without these ceremonies, it all falls down to you. These conversations would still need to happen. All Scrum is doing is being realistic and upfront about their existence. Scrum or no scrum, someone is gonna need to sit down with you and help you plan, make sure you’re on the right track, make sure your product works as desired and someone is going to need to take responsibility for your working practices. Missing out any of these is asking for trouble and without something encouraging you to put time aside for them, the probability of their slipping through the net goes up.
Estimating is fundamentally flawed. We can never get it right.
Scrum isn’t based on the premise that we can perfectly predict how the next few weeks are going to pan out. Scrum doesn’t really care how you estimate or how much stock you put into those estimates — it simply asks that you give it a go. The act of estimating isn’t necessarily about getting it right. Allow me to explain. Let’s imagine a conversation between Jim and Jenny, two engineers, and Emma the product owner.
Jim: “I reckon that’s not too big you know”
Jenny: “Yeah agreed. Shouldn’t be too bad”.
Emma: “So should be dead easy then right!?”
You know what the problem is here? No one else has a clue what the other are on about. Jenny doesn’t know what “not too big” means. Emma thinks it’s all gravy. Jim might be drunk, who knows. Far too vague.
Jim: “Looks like a 3 point task to me?”
Jenny: “I was thinking 8 but only because of the additional config change”
Jim: “Damn, I forgot about that. Does that really make it an 8?”
Jenny: “I’ll settle for a 5?”
Jim: “Beautiful.”
Jenny: “Wanna go for a drink later?”
Emma: “Can I join?”
Jim and Jenny: “No. You’re weird.”
The act of estimation creates positive, healthy conflict. Positive conflict creates a mix of ideas and that creates the best possible insight. Remember, Scrum doesn’t care what you do with the estimates or how you do the estimations — so long as you give them a go.
I hate Story points. They’re just references to time.
Read. The. Scrum. Guide. Scrum doesn’t care how you estimate. Use farmyard animals if you want. Use the top 10 worst moments of your life as a measurement if it means that much to you. Scrum, and I for that matter, don’t give a s**t.
I just want to write code!
Scrum has you writing code for the vast majority of your time. If your organisation decides to throw in a few other meetings into the mix for a laugh, don’t come to me and whinge about how scrum has drained all your day. Scrum cares that you’re building the right thing and that means, gasp, talking to people a bit. Scrums got you writing code for 80–90% of your time. It’s your friend in all of this.
And I know, I know; you’re far too intelligent to possibly converse with the other hairless apes that you are stuck with. As a service, call it charity if you want, descend from the mountain to the level of us mere mortals and explain your profound ideas. Thus spake developer.
Well, there you have it
Scrum isn’t saying an awful lot. Have an idea where you’re going, revisit that vision regularly and let the experts have the strongest influence in their expertise. I don’t know anyone who would disagree with that while sober. Hell, I’ve seen people on bath salts doing a little introspection from time to time.
Many of the “criticisms” laid at the feet of scrum are usually down to a few more fundamental issues. Issues like “I don’t trust anyone since my cat ran away from me”. Wait no, that’s me. Best we cut this off now.
For me Scrumbants, feel free to follow me on twitter!