Why Does Scrum Make Programmers HATE Coding?
What is it about scrum that's made programmers hate coding so much, and how can you prevent this on your software development team?
Watch or listen to this episode
YOUTUBE
SPOTIFY
APPLE
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!
What Specific Things Make Programmers Hate Scrum?
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.
Practical Things To Change That May Help You Love Scrum Again
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!
Skip To Points In The Video
- 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
Resources
- 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?
About the THRIVING TECHNOLOGIST show
On YouTube and all major podcast networks, Jayme shares teamwork and leadership strategies, guidelines for healthy company culture, and stories about real projects so you can have a sustainable career in the software industry.
Jayme Edwards
A family man and veteran of nearly 40 software projects, Jayme experienced many wins and losses over his career as an architect and consultant.
Now he's coaching software developers, managers, and business owners to overcome challenges in the IT industry - so they keep growing.