Why Does Scrum Make Programmers HATE Coding?

some of the most dysfunctional teams i've been on have been when management just wants to plot ahead and the developers are like we don't have enough information they're like well tough just get started no not tough [Music] if you're like most programmers you probably want to vomit the second you hear the word scrum corruption greed and power have taken a term that should have meant freedom to programmers and turned it into something that's one of the most hated terms on the internet in this episode i'll share some of the reasons most programmers hate scrum and

why a lot of the practices that teams follow are actually against the scrum guide and then at the end of the video i want to share some really practical tips with you that'll actually help you get back to loving scrum again if that sounds like something impossible at this point you probably need this video more than you realize so the first reason programmers hate scrum is when the product owner attends the daily stand up you might not know this but if you read the scrum guide it actually says write in it that the product owner

shouldn't even be in the daily stand-up unless they're a developer they're actually working on the project i talked about in one of my other videos that's about how the daily scrum is basically a glorified status meeting in most companies how when you have the product owner in your daily stand-up people don't feel safe to be honest about what's going on in the project and so one of the biggest reasons i see many developers hate scrum is because they can't be transparent and honest every time they get together the second reason most programmers hate scrum on

their project is when the scrum master tries to kind of suggest various technical approaches as though they're a programmer you've probably been on a project before where you're in a daily scrum meeting and people are discussing some complexities and some complications with getting the work done and the scrum master will suddenly pipe in and start to suggest ways to break the work up differently ways to change maybe the approach to the code and that's completely not their business their whole purpose is to help people do scrum not to help people design and deliver the software

product that's the programmer's job the third reason programmers hate scrum is because often the company will want the only things that ever live in the backlog to be feature work as most of us know as programmers to deliver a good software product we have to have qa we have to have automated testing we have to have automated deployment we have to have architectural patterns in place and back on waterfall projects prior to scrum there was a whole phase called the design phase of the software when before any features were built the architecture and the basic

code base was set up for the project and these days on a lot of scrum projects you've heard of people come up with sprint zero which is basically supposed to be one sprint where all the architecture decisions and all the design decisions that need to be in place up front are figured out and in my experience that's just not enough time one of the biggest reasons i see programmers hate scrum is they're on a project and they need to refactor or something like that i talked about that in my last video and now they have

to surface that or they feel like they have to surface that to the management and they get into this whole arguing match because ultimately the scrum masters are too focused on features and output and i'm going to talk about that in a minute and they're not letting us actually put in place better testing procedures and better architectural patterns and making sure that we can deploy efficiently [Music] the fourth reason most programmers hate scrum is when story points are treated like ours you've probably been on a project where some project manager hire up the chain a

scrum master or a product owner takes the number of story points that the team agreed on and multiplies it times hours or days this is so common and so dysfunctional it's incredible story points are not ours period if you're on a project and there's any kind of trying to convert story points into time it's not a scrum project it's a waterfall project your company is trying to commit you to deadlines exactly how we used to do back in the 90s in waterfall and you absolutely cannot do that on a scrum project because you don't have

a separate design phase in development phase and testing and stabilization phase and release phase that's rich enough to really give you full time to think it through so if you're on a team and the management is converting story points into hours that's probably one of the biggest reasons that you hate scrum the fifth reason many programmers hate scrum is when the product owner won't cancel the sprint you may not know this but in the scrum guide there's actually provisions in there that there's a goal that we all set for a given sprint meaning like at

the end of the sprint we want customers to be able to place orders or at the end of the sprint we want customers to be able to view search results it could be anything but it's an outcome for the customer now there might be a whole bunch of different tasks we as developers do to accomplish that but ultimately it's very common on projects that we get into a situation where something unexpected comes up there's extra complexity there's more needed in the design the product owner didn't answer the right questions it can really be anything and

that puts the sprint goal at risk and what's supposed to happen is the sprint's supposed to be cancelled and new planning is supposed to be started to get to a realistic deadline for an achievable date for the new goal instead what i see many companies do is they try to play tetris with the tasks and with the scope and get to the end of the sprint so they can say we still delivered stuff on time that's the absolute opposite of agility and what scrum was even supposed to do [Music] the sixth reason programmers often hate

scrum is when a sprint starts and there's no acceptance criteria i talked about this in my video on user stories but if you're at a company where there's a lot of emphasis on getting everything done by the exact dates that people predicted things the only way you can do that and actually feel confident that you can pull it off as a developer is you have to have a contract between you and your management that this is what it exactly is going to do nothing more and nothing less otherwise if you just say as a user

i need to be able to place orders so that i can receive my order there's so many different edge cases validation rules different paths the code could go down as you're building that in the middle of the sprint if you're talking to the product owner or you need questions answered it's just going to blow the scope up and you have no chance of hitting the date that you originally planned on so you got to start with acceptance criteria it literally says i'm going to go to this page i'm going to enter in this name in

this quantity and i'm going to place an order and this is the exact amount i should get back and if they're like well we also want to see it handle these other 14 situations each of those is a separate user story so if you're on a project and you hate scrum and it feels like it's impossible to hit the deadlines it's probably because the company's in such a hurry to say they're starting the sprint that there isn't enough clarity in what's even being built and there's no contract and the seventh reason i think as programmers

we often hate scrum is when the burn down chart is used to punish people instead of to learn remember if story points are not ours the velocity on a burn down chart has nothing to do with how well people are performing it's just giving you an idea of how many relative units of functionality are being delivered people's self-worth should never be tied to this team members should never be compared well john delivered five story points and mary only delivered three i mean that's literally treating software development like manufacturing so with all those dysfunctions is it

even possible to love scrum again i absolutely think so and i think scrum is actually not a bad process it's not for everybody there are other processes that work better in some situations but let me give you seven really tangible things you can do that'll actually help you get back to looking at scrum as something that helps you rather than hinders you the first thing you could do to love scrum again is keep the product owner out of the daily stand up literally it's in the scrum guide if they're in there every day it's not

a daily stand-up it's a daily status meeting period so whatever you can do to educate the product manager and help them understand you're actually creating mental anxiety for the development team by being there you're not helping us at the sprint review meeting we'll show you what's delivered but until then we don't need you now as a developer it's totally fine to approach the product owner outside of the daily stand-up meetings and have questions and discussions in fact that's exactly how it's supposed to work but having them be present when people are talking about what they

worked on it immediately devolves into a status meeting the second thing you can do that will get you back to loving scrum again is never negotiate technical tasks with your scrum master if you find your scrum master starts saying things like well maybe if you put off refactoring for this sprint and did a little bit more of it next sprint we could still hit the sprint goal those are not the types of calls that a scrum master who is often someone with a certification they know project management sure they may have managed software products but

they don't even write code they're completely unqualified to do that so i would encourage you to just politely remind the person hey i really appreciate everything you're doing to help keep us on track but we're the development team and this is a necessary task and we are going to do it this sprint [Music] the third thing you can do to get back to loving scrum again and this really gets into following continuous delivery which i'm going to talk a lot more about as the channel goes on is you have to as a developer include extra

time in anything you estimate to include time for new infrastructure that you might need new tests that you might need to write i talked about including extra time for documentation in the last video but basically if you want to keep not only the code quality high but you want to keep releases at a regular cadence and make sure that as the features increase you're still able to push changes out quickly you have to protect your commitments with a little bit of extra time whatever you think it takes to have a little bit of a buffer

there for uncertainty if your company is not willing to invest in qa architecture automated testing automated deployment infrastructure is code they're basically looking at the project like a we build it once and then never touch it again type of a situation and remember that's not software software we can change at any time that's one of the reasons why we don't build software like cars we don't build a physical product that the only way it can be changed is we have to bring it back to the dealer and make physical changes to it right we can

roll software changes out anytime so let's embrace that in the way that we do scrum the fourth thing you can do to get you back to really loving scrum again if that sounds impossible is don't ever commit to multiple sprints i see this all the time and it's a company that wants the same lie of predictability that they thought they had with waterfall but with scrum basically hey let's estimate six months worth of work let's put user story estimates on everything let's look at the velocity of the team and let's project based on how many

points you know we're delivering each sprint that this is when we'll be done with stuff that's six months in the future that's a really nice thought but it's completely ridiculous in the face of the story points are not ours one of the first things you can do is really get your management to commit to only expecting each sprint's commitment to be something that the team shoots for delivering and i'm going to talk a little bit about how you can basically increase the confidence in your management so they'll actually support you with this in a second

[Music] the fifth thing you can do that'll get you back to loving scrum again is don't ever share the burn down chart outside of the dev team if you share the burn down chart with upper management they're going to look at it like something to measure performance by it is not for measuring performance it's to help the development team look at okay have we picked up maybe a new member of the team and we're actually seeing a little bit less number of points delivered because we're training someone if you share that with your management team

and they aren't in all the daily standups and they aren't in the code they don't have enough information to interpret the burn down chart accurately so what are they going to do they're going to use it as a kpi they're going to use it to measure people so if you hate scrum one of the first things you can do to get back to actually liking scrum again and thinking it's of any value is you've got to keep anything that's part of the scrum process that could be misinterpreted as productivity metrics away from management that doesn't

understand them the sixth thing you can do that'll get you back to loving scrum again is don't ever start work on a sprint without a hundred percent acceptance criteria for your user stories if you start working on a sprint and all everybody has is user stories and there's no acceptance criteria you're basically guaranteeing that you're not going to be able to hit the sprint goal so one of the easiest things you can do is make a commitment to quality across the company and across your team and say if we spend time in sprint planning and

we get to the end and the developers are uncomfortable at all with the level of detail in there we're not starting the sprint period some of the most dysfunctional teams i've been on have been when management just wants to plot ahead and the developers are like we don't have enough information they're like well tough just get started no not tough there has to be a shared agreement that work will not start without enough information and the seventh thing you can do to really get you back to loving scrum again is actually a super positive thing

and that's have something cool to show at the end of every sprint i think one of the most frustrating reasons why we don't like scrum is we feel under more pressure to hit our projected commitments than to actually deliver something cool as developers we're supposed to be in control of the sprint backlog that may surprise you the product owner is in control of the product backlog the developers according to the scrum guide again are supposed to be in charge of the sprint backlog well if that's true as developers try to pick things to work on

that when you get to the end of the two weeks or the week or the four hours of the month or whatever the length of your sprint is you've got something you can show to the business that's just going to excite them it's going to build confidence in them and if you're doing that on a consistent basis then all this other process drama about burn down charts and user stories and story points and velocity all goes away because it's really all about confidence it's not about predicting the future when you do scrum so i hope

that helps a little bit today scrum's a super complicated topic i've got i don't even know how many videos in a playlist about it on the channel you can go back and watch but what are some of the reasons you hate scrum and what are some of the things you've done to love it again leave me some comments on the youtube channel until next time thanks [Music] do [Music] do [Music] you