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 of progress appearance Pay for 2x the number of people you need Gather fine-grained data based on meaningless metrics Then Scrum is what you are looking for! exactly , who is not a true Scotsman "Oh you had problems with Scrum at your last employer? Well, that's not real Scrum." - your scrum master Needless to say, we don't use scrum at . Which brings us to our first problem... Qvault 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 we find Scrum's definition: Scrum Guide 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 . It makes them feel in control and informed. They know exactly what was done and when it was completed. the management team 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 will now take almost because I've wasted time putting in along the way. My imposter syndrome starts to set in, but at least management will have pretty burndown charts. 2 months 4 months artificial stopping points 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 my assignments. understand Even if the scrum master is a lovable person who grasps the technical issues from a high-level, 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. Scrum Master isn't a full-time job. 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 system. actual 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 . Why do we need to add an extra step of ? A simple estimate of "how many days?" would have been easier to think and reason about, while also providing more granularity. workload -> time workload -> story points -> time 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 to the estimator. no detriment Final Note: Agile != Scrum I'm a fan of agile methodologies and the . 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. Agile Manifesto fin. Thanks For Reading Follow us on Twitter if you have any questions or comments @q_vault Take game-like coding courses on Qvault Classroom to our Newsletter for more educational articles Subscribe

Super

Twitter

2022 - HackerNoon Contributor of the Year - Algorithms

2022 - HackerNoon Contributor of the Year - Cryptography

2022 - HackerNoon Contributor of the Year - Github

2022 - HackerNoon Contributor of the Year - Job Hunting

2022 - HackerNoon Contributor of the Year - Mathematics

2022 - HackerNoon Contributor of the Year - Online Education

Coding Guru of 2022

Super Career Strategist of 2022

Learn to code on Boot.dev

Nominated for 2022 - HackerNoon Contributor of the Year - Algorithms

Nominated for 2022 - HackerNoon Contributor of the Year - Mathematics

Nominated for 2022 - HackerNoon Contributor of the Year - Cryptography

Nominated for Coding Guru of 2022

Nominated for 2022 - HackerNoon Contributor of the Year - Github

Nominated for 2022 - HackerNoon Contributor of the Year - Online Education

Nominated for 2022 - HackerNoon Contributor of the Year - Job Hunting

Nominated for Super Career Strategist of 2022

Too Long; Didn't Read

Developers: Build Less. Deliver More. [Learn how]	

Leave Scrum To Rugby - 4 Major Issues With Using Scrum 

Leave Scrum To Rugby - 4 Major Issues With Using Scrum

Too Long; Didn't Read

Companies Mentioned

Lane Wagner

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

Leave Scrum To Rugby - 4 Major Issues With Using Scrum

Too Long; Didn't Read

Companies Mentioned

Lane Wagner

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES