Why Does Scrum Make Programmers HATE Coding?

preview_player
Показать описание
Every programmer seems to want to vomit the second the hear the word scrum. What is it about scrum that's made programmers hate coding so much, and how can you prevent this on your software development team?

In this episode, I share 7 reasons why programmers hate scrum, and how it makes our jobs nearly impossible on software projects where the scrum master, product owner (or product manager), and the rest of the software company use it to abuse programmers. These mostly get down to not understanding the scrum guide, and human nature!

In this first section of the video, I explain how management on scrum projects usually focus on speed and visible features to the point that it puts the quality of the product at risk. They treat story points like time. They resist investment in things like improved architecture, testing, deployment, and the other things needed to keep developers from quitting unless kept in check. And they fail to accept reality when bad user stories, missing acceptance criteria, and abuse of the burn down chart (and velocity metrics) turns scrum into a numbers game instead of about delivering a quality software product.

In the second section of the video, I share 7 practical tips for changes you can make on your software team to start loving scrum again! If programmers on your team hate scrum, drawing clear lines between what software developers and project managers, product managers, product owners, or scrum masters can and can't make decisions about is essential. But as programmers, we also need to be more diligent with how we follow scrum processes. We need to closely inspect the work and only move forward with 100% acceptance criteria. We can't make commitments to vague user stories. And we have to stop estimating just for programming and include time for all the things we know we need - QA, automated testing, automated deployment, infrastructure as code, software architecture - basically all the goodies that keep a project on track as it grows in complexity. This is how modern teams do continuous delivery and devops.

I hope this video gives you some good things to think about. Scrum is a complicated topic, but following everything exactly by the scrum guide is a slippery slope. To love scrum again, programmers need to work with management and the rest of the company to adapt processes to meet the way everyone needs to work together to deliver software. And that's different for every team!

#scrum #programming #coding

RELATED CONTENT

Daily Scrum Meeting: A Status Meeting in Disguise?

How Senior Programmers ACTUALLY Write Code

Spot a Fake Agile Team in Under 7 Minutes!

Can User Stories Make Software Projects Late?

Continuous Delivery: Are You Missing The Big Picture?

Need help with your career? Book a free career consultation:

CHAPTER MARKERS

0:00 Introduction
0:36 7 Reasons Why Programmers Hate Scrum
0:58 #1 PO in Daily Stand-Up
1:36 #2 Overstepping Scrum Master
2:15 #3 Obsession With Features
3:38 #4 Story Points Treated As Time
4:42 #5 Refusal To Cancel Sprint
5:58 #6 No Acceptance Criteria
7:19 #7 Burn-Down Chart Used To Blame
7:54 7 Ways To Love Scrum Again
8:16 #1 Remove PO From Daily Stand-Up
9:00 #2 Put Scrum Master In Their Place
9:49 #3 Buffer Estimates For Code Quality
11:03 #4 Don't Commit To Multiple Sprints
12:04 #5 Keep The Burn-Down Chart With Developers
13:00 #6 100% Acceptance Criteria
13:52 #7 Deliver Features That Delight
15:16 Episode Groove

Download a free software development career guide from my home page:

Рекомендации по теме
Комментарии
Автор

Does scrum feel like it hurts more than helps on your project? What are you doing to rescue scrum from the grip of overreaching micromanagers and keep the product moving forward?

HealthyDev
Автор

In my nearly 40 years as a software developer, I worked in pretty much every development process known to man, from total seat-of-the-pants with no rules or documentation to the most rigid waterfall possible. I never cared, I could just make it work. Scrum defeated me, I never felt so utterly disempowered. Nothing but meetings and micro planning. It got to the stage that I was standing outside the office for 15 minutes every morning getting my head together before going in. Eventually, I just retired.

andrewdale
Автор

If the management is incompetent, the methodology will always suck, no matter which one you use.

ruynobrega
Автор

I just finished 18 years of hell as a coder. Scrum was never used right. Story point always converted to time. I was given harder projects with similar points, with almost no acceptance criteria. I’ve always felt like the problem. Now I’m 48 with a family, and am starting over in another career. I’d rather die than go back into one more scrum meeting on one more team at one more company. I’m not the smartest, but I know when I’ve been screwed over . Thanks for sharing.

robertbeckman
Автор

I had a boss that thought that agile working meant they could dump extra work on their employees at any time and employees should be "agile" enough to deal with it.

boldvankaalen
Автор

Lately, when a job description talks about being an agile, fast-paced environment with rapidly changing requirements... that tells me they have bad management and I definitely don't want to work there. Instead, I look for places which say they need someone self-directed who can figure out what needs to be done and do it, without having to be micromanaged. At my last job, I talked to my manager like once a month, along with casual chatter with the team over IRC, and it was great for everyone involved. When upper management inflicted scrum on everyone though, everything fell apart -- people left, projects failed, and eventually they cancelled almost everything and laid off a third of the company.

ToyKeeper
Автор

As a doctor, I send my condolences to you and other developers. Medicine has the same problem with middle management started to "manage", "improve efficiency" at the cost of patient care. Your subtitle for the episode can be "When Managements move in."

Pongo
Автор

I'm laughing out loud watching this. Everything you mentioned is so spot on, it's amazing how consistent it is across nearly every company. I think the biggest problem is that you have non-technical people in positions over power where they tell the developers what to do. We have always been at the bottom of the totem pole and until that paradigm shifts, we are screwed.

trckster
Автор

The funny thing is, every time I had SCRUM training, I always felt like, yeah, this process is great! But then the day to day, I had so much stress and anxiety or loneliness, and I couldn't figure out why. Now I get it

natalieeuley
Автор

software is R&D, and there are very few managers properly trained to manage R&D projects, they try to transform it into a proper manufacturing process where everything can and should be known from the start

software is R&D: you formulate a hypothesis about what the users need, you write the code, then you test it on your users as soon as possible ;-) and get feedback

EmilNicolaiePerhinschi
Автор

I've been a software engineer for over 40 years. When I started older sages advised me that "you can have it fast, or good or cheap" pick two. Perhaps I wasn't as good as the old guys because I have found you can have only one. Faddish methodologies like scrum do not change this.

brucerosner
Автор

I was a dev, and became a scrum master (and now agile coach) because of bad scrum masters and bad management. I've helped a few teams, but some organisations insist on this stuff we all know is bad and it is hard to tell your boss no. I've been fired because I'm standing up for the team, and that's a big sacrifice to make for one's colleagues.

lappynet
Автор

One thing that I found quite laughable that I heard in a sprint meeting was that being "agile" and making specs on the road means for the developer to foresee any possibility and be adaptive beforehand!
I knew we are seen as magicians but that takes it to a whole different level.

kassios
Автор

I have one more point i hate scrum for, the endless amounts off meetings. Stand ups, refinements, demo’s, retro’s, all kinds of in between meetings and all that on top of the normal questions you get from coleagues. … it hampers your day so terrible . Neve just 1 day uninterupted working…

duckeydutch
Автор

Management always has a choice: they can get the work done most effectively, or they can reinforce their own sense of control. Almost always they pick the latter. That's the motivation behind almost all of the issues you mention here.

markw.schumann
Автор

As somebody who’s worked in organizations large and small, though not in a programming role, it’s so easy to see how basic human nature starts to warp these processes. If I had to boil it all down I’d say when everyone is 100% loyal to the success of the project, it’s easy. As more layers of management come in, and people start to care as much or more about looking good to their boss, or maxing out their KPIs in their local fiefdom than the success of the project, you start to see scope creep. One very common thing I’ve observed is “looking busy”, which can manifest in not pulling the plug on a meeting or skipping some documentation, even though it would be more efficient, because you don’t want to look like you’re not working hard (because your performance is no longer tied to product success but to KPIs, etc)

drummer
Автор

Love how you randomly started plying the guitar hahaha - I was starting to feel angry thinking about my experiences exactly how you described. Then the guitar tune just instantly made me feel calm. Very nice and thoughtful touch there

_tnk_
Автор

1. Scrum master was never supposed to be a position or a title. It was supposed to be a role that was rotated within the team each sprint of 6 weeks.
2. Most scrum implementations ignores the technical practices that are required to make it work in the first place.
3. Installing Jira, sprinkling a bunch of burnups, burndowns, story points, sprints, stand ups does not make anyone agile.
4. Stand-ups is not meant to be a reporting function, it's a sync meeting around "what is the most important things to focus on/resolve today?".
5. Story points are BS by and for people not doing the job.
6. And then programmers end up hating agile because they've been told that their dysfunctional scrum is "agile".
7. And no one read extreme programming explained or the agile manifesto, and the second page is totally unheard of.

As Ron Jeffries said "I like to say that I may have invented story points, and if I did, I'm sorry now."

PS. Don't mention SAFe - the devil's spawn by the old waterfall and RUP people. Pyramid scheme.

ddanielsandberg
Автор

In the "Refusal to cancel sprint" they also would try to make devs work extra hours to achieve the goal.

maykolpurica
Автор

Better name for this video: "Why do programmers hate working in a poorly run team?" Working with the incompetent leaders you mentioned would be a nightmare in any software development lifecycle

wiebewiersema