The post Leave Scrum to Rugby, I Like Getting Stuff Done appeared first on Qvault.
Scrum is a buzzword, the virtue signal of choice for middle-management in software organizations.
If your goal as a manager is to implement a system by which you:
- Speed up the appearance of progress
- Pay for 2x the number of people you need
- Gather fine-grained data based on meaningless metrics
Then Scrum is exactly what you are looking for!
"Oh you had problems with Scrum at your last employer? Well, that's not real Scrum."- your scrum master, who is not a true Scotsman
Click To Tweet
Which brings us to our first problem…
Problem #1 – Scrum Is Vague
It’s hard to criticize Scrum. The idea of “Scrum” in my mind is likely very different from the one you are familiar with. This is by design, and by admission. In the official Scrum Guide we find Scrum’s definition:
A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.
I like to put it more tersely:
Scrum (noun) – 1. [software] Any good process that works good
Because the definition is so vague, the only thing I’ll be able to criticize throughout the rest of my tirade is the common practices of “Scrummers” that I’m familiar with. Hopefully, some of you lovely readers can relate.
Problem #2 – The “Sprint”
According to the official guide:
The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, useable, and potentially releasable product Increment is created
Sprints are useful like achievements in video games are useful; they make us feel warm and fuzzy inside. Motivation is a powerful tool, don’t misunderstand me. The problem is that those warm fuzzies are mostly for the sake of the management team. It makes them feel in control and informed. They know exactly what was done and when it was completed.
I’m not against management being informed… but at what cost?
Sprints require achievable short-term goals. Let’s pretend that I’m part of a team that does two-week sprints (because the duration must be consistent) and I’m assigned to build an API that isn’t useful until the whole thing is completed. Let’s also say that in my head I believe the whole task to take two months if I can work consistently.
I need to break the API into pieces that can be completed in 2-week increments. I might be able to get some of the endpoints done in as little as a day or two, but I don’t want to miss any of my goals, and I know some of the more difficult logic could take as long as an entire week per endpoint. There are 14 endpoints so I decide on a round figure of 2 endpoints per sprint.
An API that could have been completed in 2 months will now take almost 4 months because I’ve wasted time putting in artificial stopping points along the way. My imposter syndrome starts to set in, but at least management will have pretty burndown charts.
Problem #3 – The Scrum Master
The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t.
Depending on how the idea of the scrum master is implemented, it can be a bad idea or a worse one. Let’s just talk about what seems to me to be the most common scenario.
The scrum master is a non-technical, middle-management type that likes to be in charge of stuff.
In addition to all of their development work, the engineers are now interrupted frequently by the scrum master who is asking when the “Java code” for the React app will be done.
The very individual whose purpose it is to stop the outside world from bothering their developers is the single biggest bother. In my opinion, non-technical people should rarely, if ever, be managing technical people (except the CEO). I should be able to go to my boss for help and advice with my tasks, or at the very least I should expect them to understand my assignments.
Even if the scrum master is a lovable person who grasps the technical issues from a high-level, Scrum Master isn’t a full-time job. Too often scrum masters daily tasks involve a stand-up or two in the morning, a meeting with higher-ups in the afternoon, and not much else.
If you still feel the need for a “scrum master”, just let the lead developers handle the job. They are already at stand-up and likely have a better idea of what is going on. You aren’t putting more on their plates, you are likely taking something off.
Problem #4 – Estimates
Within Scrum, estimates have a primary purpose – to figure out how much work the team can accomplish in a given sprint. If I were to grant that Sprints were a good idea (which I obviously don’t believe) then the description of estimates in the official Scrum guide wouldn’t be a problem.
The problem is that estimates in practice are a bastardization of reality. The Scrum guide is vague on the topic so managers take matters into their own hands. With this in mind, I am again going to criticize some common practices that I have seen in regards to estimates.
Fibonacci and T-Shirt Sizes
Many super-hip organizations enjoy using the most confusing scales for estimates. They claim that this somehow makes estimating a faster and less stressful process. I remain woefully unconvinced.
My first day at a new company during our estimation meeting after hearing they used the dreaded “story points” system:
Me: “What is the scale used here for points?”
Scrum master: “Fibonacci, where 8 points is the max because we defined it as the amount of work a developer can handle during a two-week sprint”.
I eventually learned the actual system.
1 point: 0 – 8 hours
2 points: 8 hours – 2.4 days
3 points: 2.4 days – 1 week
5 points: 1 week – 1.5 weeks
8 points: 2 weeks
The end goal of an estimate is to convert workload -> time. Why do we need to add an extra step of workload -> story points -> time? A simple estimate of “how many days?” would have been easier to think and reason about, while also providing more granularity.
A common objection to using such a barbarically simple system is:
We use fibonacci because its hard to imagine the difference between 7 and 8 days. No one can estimate that closely. Fibonacci sequences go up by ~60% at each step so you aren’t forced to get very close to your estimate.
To that, I propose base-2 exponentiation based on the scale you care about in the first place, time.
1, 2, 4, 8. Hours, days or weeks.
It seems we have solved the problem! Until another good-intentioned scrum master pipes up:
If estimates are grounded in measurable time then engineers will feel like they’ve screwed up if they miss their estimate.
Good point, estimating is hard and we don’t want anyone to feel like they are a bad engineer just because they aren’t the perfect estiamtor. That said, maybe instead of starting a game of “Whose Line Is It Anyway?”
the reasonable expectation could be set that estimates are just that, estimates.
Estimate – roughly calculate or judge the value, number, quantity, or extent of.
If an estimate turns out to be bad it can be re-estimated at no detriment to the estimator.
Final Note: Agile != Scrum
I’m a fan of agile methodologies and the Agile Manifesto. I’m not a fan of Scrum. In a later article, I plan to go over my thoughts on what to do in lieu of Scrum while still running an “agile” organization.
fin.
Thanks For Reading
Hit me up on twitter @wagslane if you have any questions or comments.
Follow me on Dev.to: wagslane
The post Leave Scrum to Rugby, I Like Getting Stuff Done appeared first on Qvault.
Top comments (6)
I think you'll really enjoy these two talks by Allen Holub, which align very well with this article:
The death of Agile and #NoEstimates or skip to #NoEstimates End Summary
In summary, the death of Agile is that Scrum is basically the antithesis of remaining agile (lowercase on purpose). You can't respond quickly to customers and have locked sprints. You can't remain agile and have silo roles.
NoEstimates claims that you can't estimate and you shouldn't even try. You can project once you've started and you can prioritize so you know you're always working on the right thing. Beyond that, just work based on priority (and ruthlessly prioritize) and get stuff done.
Thanks for sharing Lane, very well written!
Have seen a lot of scrum hating recently, and I can understand all your points, the thing I'm missing in your post and in many others are alternatives!
Scrum was created as an alternative to the old waterfall way, and so far, haven't see anything that complete as alternative, a proper framework that can guide any development team.
Do you know about any proper documented frameworks that can help solving this problems?
Hi, I wrote some articles about agile not so long ago. You might want to check it out.
Also, I've found the process used at Basecamp is quite close to what we use at my work. And it works for us. Its called ShapeUP, check it out.
I don't think that's the right way to look at it. There are real problems with scrum and they show themselves in frustration of people involved with it. The are things that work in scrum and things that don't. Daily standup is excellent for instance. Pointing stinks. Scrum master should not even be a role, but a shared understanding of few principles.
Thanks for writing this up. I thought I was alone in feeling some of the pain points you have expressed. Scrum intentionally disengages the estimates from reality with the hopes that it would save developers from schedule pressure. The intent is good, but solution is wrong. It would be more helpful to agree on a system where estimates are updated regularly. It will improve the communication and make us better at estimating over time.
Another problem of estimating in points is that we don't know what a point represents. My current team has taken a decision that points are based on complexity, not time. So, we often get into discussions whether something is complex or time consuming.
Another reason I don't like points is that we often have to go back to review things we pointed before to anchor ourselves at the scale. We have to do that because each one of us has a different imaginary scale in our minds. If we used days estimate instead, we would have none of these issues.
I really think points are pointless. It helps nobody, but creates extra confusion. It makes it hard to communicate with the business, who won't care about your imaginary points but cares about when things will be available.
Nice article, thanks for sharing. I'm on the same boat. I worked in many Scrum projects and teams, thats why at my current job we are staying away from it.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.