00:00:00
some of the most dysfunctional teams
00:00:01
i've been on have been when management
00:00:03
just wants to plot ahead and the
00:00:05
developers are like we don't have enough
00:00:06
information they're like well tough just
00:00:08
get started no not tough
00:00:12
[Music]
00:00:21
if you're like most programmers you
00:00:23
probably want to
00:00:24
vomit the second you hear the word scrum
00:00:27
corruption greed and power have taken a
00:00:30
term that should have meant freedom to
00:00:31
programmers and turned it into something
00:00:33
that's one of the most hated terms on
00:00:35
the internet in this episode i'll share
00:00:37
some of the reasons most programmers
00:00:39
hate scrum and why a lot of the
00:00:41
practices that teams follow are actually
00:00:44
against the scrum guide and then at the
00:00:46
end of the video i want to share some
00:00:47
really practical tips with you that'll
00:00:49
actually help you get back to loving
00:00:51
scrum again if that sounds like
00:00:53
something impossible at this point you
00:00:55
probably need this video more than you
00:00:56
realize so the first reason programmers
00:00:59
hate scrum is when the product owner
00:01:02
attends the daily stand up you might not
00:01:04
know this but if you read the scrum
00:01:06
guide it actually says write in it that
00:01:08
the product owner shouldn't even be in
00:01:10
the daily stand-up unless they're a
00:01:12
developer they're actually working on
00:01:14
the project i talked about in one of my
00:01:16
other videos that's about how the daily
00:01:18
scrum is basically a glorified status
00:01:20
meeting in most companies how when you
00:01:22
have the product owner in your daily
00:01:24
stand-up people don't feel safe to be
00:01:26
honest about what's going on in the
00:01:28
project and so one of the biggest
00:01:29
reasons i see many developers hate scrum
00:01:32
is because they can't be transparent and
00:01:34
honest every time they get together the
00:01:36
second reason most programmers hate
00:01:39
scrum on their project is when the scrum
00:01:41
master tries to kind of suggest various
00:01:44
technical approaches as though they're a
00:01:46
programmer you've probably been on a
00:01:48
project before where you're in a daily
00:01:50
scrum meeting and people are discussing
00:01:52
some complexities and some complications
00:01:54
with getting the work done and the scrum
00:01:56
master will suddenly pipe in and start
00:01:58
to suggest ways to break the work up
00:02:00
differently ways to change maybe the
00:02:02
approach to the code and that's
00:02:04
completely not their business their
00:02:06
whole purpose is to help people do scrum
00:02:09
not to help people design and deliver
00:02:11
the software product that's the
00:02:13
programmer's job the third reason
00:02:15
programmers hate scrum is because often
00:02:18
the company will want the only things
00:02:20
that ever live in the backlog to be
00:02:22
feature work as most of us know as
00:02:24
programmers to deliver a good software
00:02:26
product we have to have qa we have to
00:02:29
have automated testing we have to have
00:02:31
automated deployment we have to have
00:02:33
architectural patterns in place and back
00:02:35
on waterfall projects prior to scrum
00:02:37
there was a whole phase called the
00:02:39
design phase of the software when before
00:02:41
any features were built the architecture
00:02:44
and the basic code base was set up for
00:02:46
the project and these days on a lot of
00:02:48
scrum projects you've heard of people
00:02:50
come up with sprint zero which is
00:02:51
basically supposed to be one sprint
00:02:53
where all the architecture decisions and
00:02:55
all the design decisions that need to be
00:02:57
in place up front are figured out and in
00:02:59
my experience that's just not enough
00:03:01
time one of the biggest reasons i see
00:03:03
programmers hate scrum is they're on a
00:03:05
project and they need to refactor or
00:03:06
something like that i talked about that
00:03:08
in my last video and now they have to
00:03:10
surface that or they feel like they have
00:03:12
to surface that to the management and
00:03:14
they get into this whole arguing match
00:03:16
because ultimately the scrum masters are
00:03:18
too focused on features and output and
00:03:20
i'm going to talk about that in a minute
00:03:22
and they're not letting us actually put
00:03:24
in place better testing procedures and
00:03:26
better architectural patterns and making
00:03:28
sure that we can deploy efficiently
00:03:31
[Music]
00:03:38
the fourth reason most programmers hate
00:03:41
scrum is when story points are treated
00:03:43
like ours you've probably been on a
00:03:46
project where some project manager hire
00:03:48
up the chain a scrum master or a product
00:03:51
owner takes the number of story points
00:03:52
that the team agreed on and multiplies
00:03:54
it times hours or days this is so common
00:03:58
and so dysfunctional it's incredible
00:04:02
story points are not ours
00:04:04
period if you're on a project and
00:04:06
there's any kind of trying to convert
00:04:08
story points into time it's not a scrum
00:04:12
project it's a waterfall project your
00:04:14
company is trying to commit you to
00:04:16
deadlines exactly how we used to do back
00:04:18
in the 90s in waterfall and you
00:04:20
absolutely cannot do that on a scrum
00:04:22
project because you don't have a
00:04:23
separate design phase in development
00:04:26
phase and testing and stabilization
00:04:28
phase and release phase that's rich
00:04:30
enough to really give you full time to
00:04:32
think it through so if you're on a team
00:04:34
and the management is converting story
00:04:37
points into hours that's probably one of
00:04:39
the biggest reasons that you hate scrum
00:04:42
the fifth reason many programmers hate
00:04:45
scrum is when the product owner won't
00:04:47
cancel the sprint you may not know this
00:04:49
but in the scrum guide there's actually
00:04:51
provisions in there that there's a goal
00:04:54
that we all set for a given sprint
00:04:56
meaning like at the end of the sprint we
00:04:57
want customers to be able to place
00:04:59
orders or at the end of the sprint we
00:05:00
want customers to be able to view search
00:05:02
results it could be anything but it's an
00:05:04
outcome for the customer now there might
00:05:06
be a whole bunch of different tasks we
00:05:08
as developers do to accomplish that but
00:05:10
ultimately it's very common on projects
00:05:12
that we get into a situation where
00:05:15
something unexpected comes up there's
00:05:17
extra complexity there's more needed in
00:05:19
the design the product owner didn't
00:05:20
answer the right questions it can really
00:05:22
be anything and that puts the sprint
00:05:25
goal at risk and what's supposed to
00:05:26
happen is the sprint's supposed to be
00:05:28
cancelled and new planning is supposed
00:05:30
to be started to get to a realistic
00:05:32
deadline for an achievable date for the
00:05:34
new goal instead what i see many
00:05:37
companies do is they try to play tetris
00:05:40
with the tasks and with the scope and
00:05:42
get to the end of the sprint so they can
00:05:43
say we still delivered stuff on time
00:05:45
that's the absolute opposite of agility
00:05:48
and what scrum was even supposed to do
00:05:53
[Music]
00:05:58
the sixth reason programmers often hate
00:06:00
scrum is when a sprint starts and
00:06:03
there's no acceptance criteria i talked
00:06:05
about this in my video on user stories
00:06:07
but if you're at a company where there's
00:06:09
a lot of emphasis on getting everything
00:06:10
done by the exact dates that people
00:06:13
predicted things the only way you can do
00:06:14
that and actually feel confident that
00:06:16
you can pull it off as a developer is
00:06:18
you have to have a contract between you
00:06:21
and your management that this is what it
00:06:23
exactly is going to do nothing more and
00:06:26
nothing less otherwise if you just say
00:06:28
as a user i need to be able to place
00:06:30
orders so that i can receive my order
00:06:32
there's so many different edge cases
00:06:34
validation rules different paths the
00:06:37
code could go down as you're building
00:06:38
that in the middle of the sprint if
00:06:40
you're talking to the product owner or
00:06:41
you need questions answered it's just
00:06:43
going to blow the scope up and you have
00:06:45
no chance of hitting the date that you
00:06:47
originally planned on so you got to
00:06:48
start with acceptance criteria it
00:06:50
literally says i'm going to go to this
00:06:52
page i'm going to enter in this name in
00:06:54
this quantity and i'm going to place an
00:06:56
order and this is the exact amount i
00:06:57
should get back and if they're like well
00:06:59
we also want to see it handle these
00:07:01
other 14 situations each of those is a
00:07:03
separate user story so if you're on a
00:07:05
project and you hate scrum and it feels
00:07:07
like it's impossible to hit the
00:07:09
deadlines it's probably because the
00:07:11
company's in such a hurry to say they're
00:07:13
starting the sprint that there isn't
00:07:15
enough clarity in what's even being
00:07:17
built and there's no contract and the
00:07:19
seventh reason i think as programmers we
00:07:21
often hate scrum is when the burn down
00:07:24
chart is used to punish people instead
00:07:27
of to learn remember if story points are
00:07:30
not ours the velocity on a burn down
00:07:33
chart has nothing to do with how well
00:07:35
people are performing it's just giving
00:07:37
you an idea of how many relative units
00:07:40
of functionality are being delivered
00:07:41
people's self-worth should never be tied
00:07:43
to this team members should never be
00:07:45
compared well john delivered five story
00:07:48
points and mary only delivered three i
00:07:50
mean that's literally treating software
00:07:52
development like manufacturing so with
00:07:54
all those dysfunctions is it even
00:07:56
possible to love scrum again i
00:07:59
absolutely think so and i think scrum is
00:08:01
actually not a bad process it's not for
00:08:04
everybody there are other processes that
00:08:06
work better in some situations but let
00:08:08
me give you seven really tangible things
00:08:10
you can do that'll actually help you get
00:08:11
back to looking at scrum as something
00:08:13
that helps you rather than hinders you
00:08:16
the first thing you could do to love
00:08:18
scrum again is keep the product owner
00:08:20
out of the daily stand up literally it's
00:08:23
in the scrum guide if they're in there
00:08:25
every day it's not a daily stand-up it's
00:08:27
a daily status meeting period so
00:08:30
whatever you can do to educate the
00:08:31
product manager and help them understand
00:08:33
you're actually creating mental anxiety
00:08:36
for the development team by being there
00:08:38
you're not helping us at the sprint
00:08:40
review meeting we'll show you what's
00:08:42
delivered but until then we don't need
00:08:44
you now as a developer it's totally fine
00:08:46
to approach the product owner outside of
00:08:49
the daily stand-up meetings and have
00:08:50
questions and discussions in fact that's
00:08:52
exactly how it's supposed to work but
00:08:54
having them be present when people are
00:08:56
talking about what they worked on it
00:08:57
immediately devolves into a status
00:08:59
meeting the second thing you can do that
00:09:01
will get you back to loving scrum again
00:09:04
is never negotiate technical tasks with
00:09:07
your scrum master if you find your scrum
00:09:09
master starts saying things like well
00:09:11
maybe if you put off refactoring for
00:09:13
this sprint and did a little bit more of
00:09:15
it next sprint we could still hit the
00:09:16
sprint goal those are not the types of
00:09:19
calls that a scrum master who is often
00:09:21
someone with a certification they know
00:09:23
project management sure they may have
00:09:25
managed software products but they don't
00:09:26
even write code they're completely
00:09:28
unqualified to do that so i would
00:09:30
encourage you to just politely remind
00:09:32
the person hey i really appreciate
00:09:34
everything you're doing to help keep us
00:09:35
on track but we're the development team
00:09:37
and this is a necessary task and we are
00:09:39
going to do it this sprint
00:09:42
[Music]
00:09:49
the third thing you can do to get back
00:09:51
to loving scrum again and this really
00:09:53
gets into following continuous delivery
00:09:55
which i'm going to talk a lot more about
00:09:56
as the channel goes on is you have to as
00:09:59
a developer include extra time in
00:10:02
anything you estimate to include time
00:10:04
for new infrastructure that you might
00:10:06
need new tests that you might need to
00:10:08
write i talked about including extra
00:10:10
time for documentation in the last video
00:10:12
but basically if you want to keep not
00:10:14
only the code quality high but you want
00:10:16
to keep releases at a regular cadence
00:10:18
and make sure that as the features
00:10:20
increase you're still able to push
00:10:21
changes out quickly you have to protect
00:10:24
your commitments with a little bit of
00:10:25
extra time whatever you think it takes
00:10:27
to have a little bit of a buffer there
00:10:29
for uncertainty if your company is not
00:10:31
willing to invest in qa architecture
00:10:34
automated testing automated deployment
00:10:36
infrastructure is code they're basically
00:10:38
looking at the project like a we build
00:10:40
it once and then never touch it again
00:10:42
type of a situation and remember that's
00:10:44
not software software we can change at
00:10:47
any time that's one of the reasons why
00:10:48
we don't build software like cars we
00:10:50
don't build a physical product that the
00:10:52
only way it can be changed is we have to
00:10:54
bring it back to the dealer and make
00:10:56
physical changes to it right we can roll
00:10:58
software changes out anytime so let's
00:11:00
embrace that in the way that we do scrum
00:11:02
the fourth thing you can do to get you
00:11:04
back to really loving scrum again if
00:11:06
that sounds impossible is don't ever
00:11:08
commit to multiple sprints i see this
00:11:11
all the time and it's a company that
00:11:14
wants the same lie of predictability
00:11:16
that they thought they had with
00:11:17
waterfall but with scrum basically hey
00:11:20
let's estimate six months worth of work
00:11:22
let's put user story estimates on
00:11:24
everything let's look at the velocity of
00:11:26
the team and let's project based on how
00:11:28
many points you know we're delivering
00:11:30
each sprint that this is when we'll be
00:11:31
done with stuff that's six months in the
00:11:33
future that's a really nice thought
00:11:36
but it's completely ridiculous in the
00:11:38
face of the story points are not
00:11:41
ours one of the first things you can do
00:11:43
is really get your management to commit
00:11:45
to only expecting each sprint's
00:11:47
commitment to be something that the team
00:11:49
shoots for delivering and i'm going to
00:11:50
talk a little bit about how you can
00:11:52
basically increase the confidence in
00:11:53
your management so they'll actually
00:11:55
support you with this in a second
00:11:57
[Music]
00:12:04
the fifth thing you can do that'll get
00:12:06
you back to loving scrum again is don't
00:12:08
ever share the burn down chart outside
00:12:10
of the dev team if you share the burn
00:12:12
down chart with upper management they're
00:12:14
going to look at it like something to
00:12:16
measure performance by it is not for
00:12:19
measuring performance it's to help the
00:12:20
development team look at okay have we
00:12:23
picked up maybe a new member of the team
00:12:25
and we're actually seeing a little bit
00:12:26
less number of points delivered because
00:12:28
we're training someone if you share that
00:12:30
with your management team and they
00:12:32
aren't in all the daily standups and
00:12:34
they aren't in the code they don't have
00:12:35
enough information to interpret the burn
00:12:37
down chart accurately so what are they
00:12:39
going to do they're going to use it as a
00:12:41
kpi they're going to use it to measure
00:12:43
people so if you hate scrum one of the
00:12:45
first things you can do to get back to
00:12:47
actually liking scrum again and thinking
00:12:49
it's of any value is you've got to keep
00:12:52
anything that's part of the scrum
00:12:53
process that could be misinterpreted as
00:12:55
productivity metrics away from
00:12:58
management that doesn't understand them
00:13:00
the sixth thing you can do that'll get
00:13:02
you back to loving scrum again is don't
00:13:04
ever start work on a sprint without a
00:13:06
hundred percent acceptance criteria for
00:13:09
your user stories if you start working
00:13:11
on a sprint and all everybody has is
00:13:13
user stories and there's no acceptance
00:13:15
criteria you're basically guaranteeing
00:13:17
that you're not going to be able to hit
00:13:18
the sprint goal so one of the easiest
00:13:20
things you can do is make a commitment
00:13:22
to quality across the company and across
00:13:25
your team and say if we spend time in
00:13:27
sprint planning and we get to the end
00:13:29
and the developers are uncomfortable at
00:13:31
all with the level of detail in there
00:13:33
we're not starting the sprint period
00:13:36
some of the most dysfunctional teams
00:13:37
i've been on have been when management
00:13:39
just wants to plot ahead and the
00:13:41
developers are like we don't have enough
00:13:43
information they're like well tough just
00:13:44
get started no not tough there has to be
00:13:47
a shared agreement that work will not
00:13:49
start without enough information and the
00:13:52
seventh thing you can do to really get
00:13:54
you back to loving scrum again is
00:13:56
actually a super positive thing and
00:13:58
that's have something cool to show at
00:14:02
the end of every sprint i think one of
00:14:04
the most frustrating reasons why we
00:14:06
don't like scrum is we feel under more
00:14:08
pressure to hit our projected
00:14:10
commitments than to actually deliver
00:14:12
something cool as developers we're
00:14:14
supposed to be in control of the sprint
00:14:16
backlog that may surprise you the
00:14:19
product owner is in control of the
00:14:20
product backlog the developers according
00:14:22
to the scrum guide again are supposed to
00:14:24
be in charge of the sprint backlog well
00:14:26
if that's true as developers try to pick
00:14:29
things to work on that when you get to
00:14:31
the end of the two weeks or the week or
00:14:32
the four hours of the month or whatever
00:14:34
the length of your sprint is you've got
00:14:36
something you can show to the business
00:14:37
that's just going to excite them it's
00:14:39
going to build confidence in them and if
00:14:41
you're doing that on a consistent basis
00:14:43
then all this other process drama about
00:14:46
burn down charts and user stories and
00:14:49
story points and velocity all goes away
00:14:52
because it's really all about confidence
00:14:54
it's not about predicting the future
00:14:57
when you do scrum so i hope that helps a
00:14:59
little bit today scrum's a super
00:15:01
complicated topic i've got i don't even
00:15:02
know how many videos in a playlist about
00:15:04
it on the channel you can go back and
00:15:06
watch but what are some of the reasons
00:15:08
you hate scrum and what are some of the
00:15:10
things you've done to love it again
00:15:12
leave me some comments on the youtube
00:15:14
channel until next time thanks
00:15:18
[Music]
00:15:37
do
00:15:41
[Music]
00:15:59
do
00:16:01
[Music]
00:16:13
you
