Why Does Scrum Make Programmers HATE Coding?
Jayme Edwards
Tech Career Coach for Experienced Software Development, Management, and Consulting Professionals
Every programmer seems to want to vomit the second they 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 article, I share 7 reasons why scrum can make programmers' jobs nearly impossible on software projects where the scrum master, product owner, and the rest of the software company use it to abuse them. These mostly get down to not understanding the scrum guide - and human nature!
This article is a summary of?a video on my YouTube channel?about the same topic. In this episode, I share the most common dysfunctions with scrum I've run into, and ways to remedy them, while working on nearly 40 software projects.
7 Reasons Why Scrum Makes Programmers Hate Coding
Over the past 10 years, management on scrum projects have fallen back into the Taylorism approach to management where programmers are treated like cogs in a wheel, instead of empowering them to make impactful decisions.
When business leadership focuses on speed and visible features, or they step outside decisions they're qualified for to override professional software engineers, it puts the quality of the product at risk - and leads to a culture of fear instead of innovation.
#1 Product Owner In The Daily Stand-Up Meeting
You may not know this, but according to the scrum guide the Product Owner (or Product Manager - I'll use PO for short, in some companies) should not be in the daily stand-up meeting unless they are actively developing code on the project.
This is because the purpose of the daily stand-up is to ensure developers are communicating with each other. Developers should be regularly communicating with the PO, but not in a group daily meeting. This wastes everyone's time since product issues are discussed that don't directly impact every developer. And it devolves into a status meeting with the business' representatives present.
#2 Overstepping Scrum Master
The role of the scrum master is to teach team members how to do scrum. It is not to suggest to the development team the order they should do work, or how to approach the design of the software.
When a software development team has a scrum master that tries to make decisions they're unqualified for, they begin to resent scrum and look at it as hurting more than helping.
#3 Obsession With Features
To deliver and maintain successful software products, engineers need to implement:
When the scrum process focuses primarily on features, and software developers are prevented from working on these other required technical tasks, they grow to resent scrum. The code base often becomes a mess to work on, features take longer to build, and people quit the company.
#4 Story Points Treated As Time
In the late 90s and early 2000s, the software industry gathered enough data from projects to know that estimates in the complex problem domain that programming professional IT products is are unreliable.
We came up with story points as a way to break work up into smaller pieces. This lets the team select the smallest units of work possible so the impact of estimates being wrong is smaller.
On teams where story points are converted to time, programmers are put under unrealistic pressure to hit impossible deadlines. This is one of the biggest reasons people often quit the industry.
#5 Refusal to Cancel The Sprint
According to the scrum guide, the development team chooses user stories to work on each sprint. But those user stories are part of a larger purpose - the sprint goal. The sprint goal is an outcome for the customer that lets them do something that helps them with their job, or with solving the problem the software was designed to overcome.
When a team member is sick or undiscovered complexity rears its head, sometimes there won't be enough in the sprint to allow the goal to be reached. When this happens, the sprint should be canceled and new sprint planning should begin to come up with a realistic, achievable goal.
Instead, many companies begin to play Tetris with the tasks to try and get as much done as they can so they can show they completed what was planned at the beginning of the sprint. Step back and think about it - hitting the date isn't completing what was planned! There's no point in finishing the sprint if the goal won't be reached!
Marching along with tasks to try to hit a planned end date, when the date is not enabling the customer to do anything (but just an arbitrary commitment) is one of the things programmers hate the most about scrum.
#6 No Acceptance Criteria
As I talked about in another episode of the Healthy Software Developer show about user stories, on a team where the business itself is agile, work on a sprint may start with only simple user story sentences and no detailed requirements.
But many teams do not have an agile business (one that takes customer feedback from each release and changes the direction of the project). So they focus on the sprint end date like a deadline, and try to forecast the future through sprint planning.
In these situations, a programmer must have a contract between themselves and the business. This contract comes in the form of acceptance criteria. Acceptance criteria describes exactly what the software will do at the end of the sprint - nothing more, and nothing less!
When sprints start without acceptance criteria, and the business isn't willing to adjust sprint end dates and update the backlog based on user feedback, programmers don't have enough information to get their work done and chaos usually results.
#7 Burn-Down Chart Used To Blame
When scrum was created over 20 years ago, it didn't include story points, burn-down charts, and velocity. These were added later as a way to help the development team improve their ability to break work up into smaller pieces. Burn-down charts helped a team see if adding a new team member, or other changes outside the team's control were impacting their ability to get planned work done.
In some companies, the burn-down chart is treated like a performance KPI. It isn't! Story points should never be used to compare individuals, or compare one team to another. Remember story points are a relative unit of work to help with sizing - not an estimation tool or productivity metric!
Most of the recent videos on my channel end with an?#episodegroove?where I'm sharing little snippets of music I've written over the years.???
领英推荐
Practical Things To Change That May Help You Love Scrum Again
With all of those common dysfunctions, what can you do???
Here are 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.
#1 Get The Product Owner OUT Of The Daily Stand-Up
Without a place where developers can be free to discuss progress privately, politics are often introduced into a project with disastrous results. Patrick Lencioni's book The 5 Dysfunctions of a Team defines politics as "When people tell each other what they want to hear, and not the truth".
Developers should be meeting and discussing the project with the Product Owner whenever the need arises, but the daily stand-up meeting is not the place to do it. This is a place for developers to experience psychological safety and get into things that may raise more questions for the business, but that they can't take action on.
#2 Put The Scrum Master In Their Place
If a scrum master starts saying things like "maybe we should put off refactoring this sprint until next sprint, then we can get more features done this time", those are NOT the kinds of calls they're qualified for.
A scrum master often has experience teaching teams how to do scrum, and may be certified, but they do not possess the skills or experience in software engineering to decide when work should and should not be done.
The sprint backlog (the work the team will try to complete in one sprint) is created and owned by the developers.
#3 Buffer Estimates for Code Quality
If you're on a team with true business agility, from the leadership, through finance, and all the way down, you may not need to do this.
But for the rest of us - if your management is focused on treating projected sprint end dates like deadlines, we need to buffer our estimates.
Include time for things like:
Though software development is inherently unpredictable - if you estimate work assuming nothing will go wrong, YOU are to blame for unrealistic deadlines!
#4 Don't Commit To Multiple Sprints
One of the things management love to do is use the velocity of a team in a sprint (or two) to try and project the next 3-6 months worth of work, then create deadlines based on that.
Don't do it! This is treating software development like a manufacturing production schedule. The work we do on software projects is completely different than manufacturing. You can learn more about why in my episode about the uncertainty of estimates in software engineering.
The goal of a sprint is to try and enable an outcome for the customer. Then release it, measure the business impact, and adjust the backlog. If your company is trying to plan out 50+ features and deliver those with no feedback - do not use agile processes! Waterfall, with all its problems on their own, will be less dysfunctional than if you use scrum here.
#5 Keep The Burn-Down Chart With Developers
If management at your company is not in all the daily stand-ups (which they shouldn't be), and are not in the code every day, they will not have the information necessary to interpret the burn-down chart.
They will look at changes in velocity as problems with people's performance. The burn-down chart is a tool to help the development team learn. It is NOT an accountability or productivity tool!
You must keep anything that is part of the scrum process that could be misinterpreted as productivity metrics away from management that won't understand them.
#6 100% Acceptance Criteria
If a team starts a sprint without acceptance criteria, they're basically guaranteeing they won't hit the sprint end date with what they hoped to get done. While estimates in software are unrealistic, and it's perfectly normal for sprints to go long or have to be canceled, this will actually be true every single sprint without good acceptance criteria.
It doesn't matter if the acceptance criteria is written by the Product Owner, Customer, or Developers - but developers must accept it before the sprint starts. If the team gets to the end of sprint planning and developers are uncomfortable with the level of detail understood about the project in any way, the team isn't ready to start work! Period.
#7 Deliver Features That Delight
Since developers choose which items from the top of the product backlog they will try to implement in a sprint, they can influence the resulting sprint goal.
Scrum can make a team feel like the goal is to hit deadlines, predict the future, and meet commitments. But it's really about building confidence with the customer and the business - not predictability.
Since this is the case, why not choose things to work on that will show progress by exciting the customer and the business! Yes, not every sprint can be filled with visible work in the user interface. But articulating the value of the work we do, in terms of how it's helping our customers and the business reach their goals, is one of the best things you can do to stop scrum from being a drag, to being a delight.
After 25 years on nearly 40 software projects, I've recently met over 200 IT professionals online, helping them reach their career goals. Need help with your career? Book a?free software development career coaching consultation.
I hope this article (or the video on YouTube if you watch it) offers you some helpful things to think about. Scrum is a simple process at first glance, but complicated once you add humans to the mix. Following everything exactly by the scrum guide can help companies who don't have much business agility, but is also a slippery slope into becoming a process Nazi.
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!
Download a free software development career guide from my home page: https://jaymeedwards.com