
Does scrum ruin great engineers or are you doing it wrong? - Lilian_Lee
https://stackoverflow.blog/2020/06/29/does-scrum-ruin-great-engineers-or-are-you-doing-it-wrong/
======
js8
We use Scrum at work and I have to say, I am pretty annoyed by it. I think it
is fundamentally rooted in the idea that ideal software development is just a
continuous production of small improvements to the code. And from this come
all its micromanagement failure modes (which there are plenty).

I think in reality, SW development done right is nothing like that. It is
highly discrete when it comes to output, because it takes time and
experimentation to come up with the correct way to approach a problem, but if
you do it right, you save yourself an incredible amount of time. It's more
like mathematics, where it takes time to discover that things are actually
rather easy (this quote comes to mind
[https://micromath.wordpress.com/2011/11/06/andrew-wiles-
on-d...](https://micromath.wordpress.com/2011/11/06/andrew-wiles-on-doing-
mathematics/)).

Of course, if you look at the project from the longer time perspective, it can
appear as continuous production of improvements. But it has a kind of quantum
nature, if you decrease the scale of time, you will see less continuity and
more discrete bursts of code production. There is something like uncertainty
principle that on certain scale, it's pointless to try to predict things,
because making the correct prediction (which is needed at least to define
thing DONE) will take as long as doing the thing in the first place.

I don't consider myself special, but it is possible that Scrum ruins great
minds because they seek conceptual clarity (we sometimes humbly call it "lack
of technical debt"). I am not sure how to make that work with Scrum. Perhaps
if everything was done three times, punctuated by a team discussion, each time
with shorter code.

Second thing that I dislike the most about Scrum is that it threw away (or at
least "conveniently" renamed) pretty much everything that was ever known about
project management. Of that, probably the formal estimation methods (replaced
in Scrum by intuition for some reason) are the biggest loss. (I think it comes
from the fact they actually realized the quantum nature of development is a
problem.) To me, that is a huge red flag that it is, in fact, a snake oil.

P.S. I am tired of the YADIW excuse. Let's have a nice honest discussion about
how it can be fixed.

~~~
MattGaiser
> Of that, probably the formal estimation methods (replaced in Scrum by
> intuition for some reason)

This has benefits and downsides. One of the one hand, the development team
getting to control the estimate helps to control the workload.

On the other, I agree. Why are we pulling estimates of effort out of thin air?
Why are we being asked how long it will take to do work in sections of code we
have never seen?

Planning could be far more accurate if we just got a proposed task list a day
before planning.

~~~
js8
> One of the one hand, the development team getting to control the estimate
> helps to control the workload.

I think that's a kind of waterfall strawman. In every other discipline, you
would ask engineers for an estimate. It's insanity to do otherwise.

~~~
MattGaiser
> In every other discipline, you would ask engineers for an estimate. It's
> insanity to do otherwise.

I studied engineering in university and profs had plenty of stories about
bosses sending business analysts to look at similar projects, generating a
time estimate from those projects, and then send that estimate to the
engineers as their deadline for completing the project.

It being insane doesn't stop people.

~~~
Scarblac
That's a pet peeve of mine. A perfect estimate is one without bias. It can't
be without variance because there is always uncertainty involved in what needs
to be done exactly.

So if you take an estimate and turn it into a deadline, in the _perfect_ case,
the deadlines can only be made 50% of the time.

Of course, in practice there is bias, there are things you forgot to include
in the estimate.

------
kevsim
I interviewed a long time ago at a med tech company in Boston where Jeff
Sutherland, one of the inventors of scrum, was the CTO (I believe). I had
recently been through scrum master training at my current job and was quite
keen to see how scrum was applied in the place where the guy who invented it
was working. I asked my first interviewer how they used scrum on their team
and his answer was that they didn't use scrum. I was pretty shocked. Then he
explained that scrum didn't fit well with their team and the way they worked
best together, whereas on some other teams they were really happy with scrum.
Made me realize that's there's no one size fits all process for software
teams. Some of these "pre-baked" processes can help teams depending on their
composition and maturity, but teams/companies really need to find the way of
working that works for them.

~~~
Areading314
If you read his book, you'll see that he repeatedly drives the point home,
that Scrum is not a set of pre-baked processes, but a philosophy around
measurement, prioritizing, and continuous improvement. The cargo cult meetings
and processes are more a product of the "Agile movement" that is championed by
mediocre middle managers.

~~~
danjac
That's the problem though: any philosophy that cannot be implemented by a
"mediocre middle manager" (i.e. most managers in most companies) is doomed to
fail. And if it requires an "amazing" manager to succeed, the question is
whether it's down to the philosophy or the manager.

~~~
sergeykish
But there are no managers in SCRUM. It is doomed to fail once methodology is
thrown out and replaced with manager. I've been on SCRUM presentation in 2007.
They explicitly stated - we help forming the team and go away.

~~~
danjac
> there are no managers in SCRUM

A philosophy that hinges around some ideal of how the world should be, rather
than dealing with the world as it really is, often ends up being implemented
as the exact opposite of that ideal. I can think of some historical
parallels...

~~~
sergeykish
Just don't call it SCRUM.

Call it "fraud SCRUM because it sells so well" or "lipstick SCRUM so we look
cool" or "didn't read SCRUM but we have meetings and sprints". SCRUM works,
maybe not for everyone but this denies us a chance.

~~~
danjac
No True Scrum again...

~~~
sergeykish
Look, I've had good experience with SCRUM team. Later I've been searching for
work, "SCRUM", interesting, interview, what? PM? Another place, PM? Yet
another... I have not found. They would not tell that it is not SCRUM before
interview. And oh, they failed so miserably, I knew how it works but couldn't
do anything. It is regress.

So often it is PM who destroys project. I've seen good PMs. Two. Great guys.
Great managers protects project from upper management and helps to resolve
teams disputes. Others... They are like third wheel - developers like to
build, business knows what to build, managers - exercise control.

~~~
danjac
That's just it though: the fact that Scrum only works given this perfect "no
management" ideal. It might work as a lightweight set of guide-rails in a
self-motivated, experienced team which has 100% hands-off trust from
management, but I'd argue that in that perfect-unicorn case Scrum is not the
key to success but rather the fact that you have a good team and good
management. In practice - as you are finding - this combination is very rare.
Furthermore I'd argue that in the typical company with typical management,
Scrum will lead to even greater micromanagement and overhead, and might
actually be worse than, say, some version of ad-hoc Kanban-lite.

~~~
sergeykish
Yes, but not _works_ but _is_. Scrum requires trust and autonomy. Otherwise it
is a set of non applicable tools, jumping with parachute under water. I argue
Scrum with PM is oxymoron, like round square. I know it is rare, earlier it
was easier to find.

Why discussion is about Scrum, not Scrum tools application and awful project
management? The language is subverted, why do you help it?

------
PaulKeeble
In the one place I saw Scrum work really well it wasn't because of scrum we
succeeded it was the amazingly talent team that groked their goals and
understand how to build software well. The complete lack of an enforcer
manager was a huge win, being connected directly into your customers and
letting them drive what they needed and balancing it with the engineering,
that worked really well. They executed well despite scrum and ultimately used
Kanban with on need for the biweekly meetings since they were releasing many
times a week.

Scrum was a small part of a package of process, the important bit that made
that possible was the engineering processes not the task management ones. The
business needed to work out what matter most to it and the developers
certainly helped more as their expertise in the subject matter grew but what
made it all slick was the automation and engineering. Engineering is where the
time goes on a software project and doing that well is what matters. As an
industry we focus so much on something that is a few hours of effort a week on
planning and tracking and yet the big time goes into the actual work. If you
spend a lot of time doing planning and tracking and not producing software you
are doing it wrong regardless of whatever process you say you are using. Scrum
is not remotely sufficient, it ignores all the important bits.

~~~
jariel
"being connected directly into your customers and letting them drive what they
needed and balancing it with the engineering,"

Lucky you however, letting 'raw' Engineers interface with customers is usually
a disaster. Engineers build tech, the company builds products, and they are
very, very different things. A lot of pieces in there - support, training,
docs, _price_ , risk, leverage, IP, know-how, relationship management,
legality, confidentiality.

Experienced Engineers who have a lot of exposure to Product, Sales etc. can do
this, there's usually a role there for a highly technical person to support
sales.

If it were only a matter of 'the customer saying we need XYZ and Engineers
doing that' then great, but it's almost never that.

~~~
PaulKeeble
You need the right customers. We were really lucky the lady in charge of the
business team learnt enough of how the development worked to sit in that
middle ground between her team of experts and ours to guide the direction
well. I would say she and our engineering principle were what made things work
well. If you are working with generic customers out there in the world then
its much harder to utilise customer focussed requirements.

------
jyriand
What i don’t like most about scrum is the sprints. Doesn’t matter if it’s one
or two weeks long, we never have a successful sprint, the velocity chart looks
like random numbers, and we spend hours on debating what the story points
really mean. Sprints are artificial deadlines that don’t really make any
sense, developers don’t care, business people don’t care. A project i could
complete in a month will take at least three months, because of the processes
we have to follow. Instead of refactoring and thinking about overall design i
have to worry about getting the task done by the end of the sprint.

~~~
woutr_be
The amount of hours our team has wasted on estimating, re-estimating,
splitting up stories, simply to make our burn down chart look great is
amazing. We would often be forced to split up stories the day before a sprint
review, just so that the chart would look like things have progressed, while
in reality nothing was completed.

Our sprint planning sessions were a FULL DAY, yes, an entire 8 hours of
planning. Because our scrum master wanted a detailed plan of what every
engineer would be working on, on every day of the week.

I still remember a certain even where we were forced to adjust our story
points, so that we could make a detail a month in the future. Yes, our “agile”
team, had a hard deadline that we had to try and make work. This was the
business decided that we’ll launch in a month, so now we’ll use our agile
methodology to somehow make it magically work. During a full day session to
plan for this, I suggested we should drop our scrum board and instead revert
to kanban. The scrum master threw me a dirty look and told the business about
this, pretty sure that’s why I was moved to another team.

~~~
xtracto
I have suffered through those sprint sessions of hell.

What has worked for me is the following:

\- let the most sr tech person ("the architect ") refine the stories maybe
with the PM. Then, the same person will point the stories. \- The sprint
planning is only for presenting the stories to devs and giving some minor
adjustments to the points if necessary \- The architect may deep dive with a
dev for a certain task while pointing it. \- That way we have a standard
complexity measure. We know different devs will perform different amount of
points per sprint . We dont lose time in pointless neverending discussions \-
it also works well in Mexico where people are not so vocal so the standard
poker planning doesn't go well

~~~
woutr_be
Sadly because of the way our organisation works, the scrum master pretty much
takes ownership of the whole process, he also sells agile to the business
side. So if you go against what he says, the business will know that you’re a
trouble maker, even if you had the best intentions.

Trust me, our team has tried, sadly the whole business wants to move to agile,
and it’s shoved down your throat, wether you like it or not, or even
regardless if it’s working for the team.

Eventually I gave up, the amount of energy wasted on these discussions is just
not worth it. After a while you learn to say the right things, while also
making sure you keep your technical freedom. Sometimes that meant not bringing
up certain technical tasks, and overestimating others so that you have time
for those other technical tasks.

------
donw
The problem with Scrum is that most practitioners have no idea why their tools
exist in the first place, under what conditions those tools apply, and what to
do when their tools fail.

Nearly every -- but not all! -- "Agile" environment I have worked in was pure
cargo cult, with none of the requisite cultural infrastructure required to
actually make any of it work, and often with a very strong centralization of
control that made local iteration... unpossible[1].

Or they do the opposite, and go full "Lord of the Flies", providing no
structure at all.

Both approaches yield poor results. You want to provide structure, but then
grant autonomy over that structure to those beholden to its results.

If you want to "be Agile", your organization needs to push a great deal of
control _and trust_ fairly far down in the corporate hierarchy. Doing this
successfully requires that organizations build the structures required for
both appropriate oversight and cultural promulgation, and few companies even
recognize the need for this, much less have the tools to do so.

[1] I am hereby defining this as "Possible on paper, but not in reality".

------
onion2k
_Very productive individuals that don’t work as a team_

I refuse to have those people on my team. One person who's twice as productive
as everyone else sounds great, but if that person's work doesn't fit well and
makes everyone else's work harder it always been a net loss in my experience.
I'd prefer my team works well together than have some "brilliant loner" join
it.

~~~
rawoke083600
Ja I've seen teams without them (10x, brilliant loner, call them what you
want). The times the teams are without that sort of talent(just talking pure
problem solving ability here)... was the times the teams, product and company
was also just that. mediocre/not-inspiring/meh. And they weren't solving a
hard problems !

If we were to take this to the extreme. Where do you slot in someone like Jeff
Dean ? Are you going to sit there and make someone like Jeff Dean, play poker-
scrum about how long the next "big research jump/product" will take ? Granted
not everyone will have a Jeff Dean. But I would never wan't to work in place
that is as boring as a place without someone like him.

Yea in my experience, scrum sucks for innovation !

~~~
mattmanser
What's with all the ellipses? Really makes it hard to understand what you're
saying.

Almost all of them should be replaced with simple commas or full stops.

~~~
rawoke083600
agreed... and fixed

------
waschl
I am in a big project which assembles 45 teams and all of them shall adopt
Scrum (for various reasons). My observation is that _all_ those teams which
have a sustainable pace with regards to architecture, technology, quality,
output, social behavior, etc have done so while adopting and embracing Scrum
in a clean way since the beginning of their existence as a team. _All_ teams
severely struggling with their content of work, output and collaboration have
also severe issues with regards to Scrum-adoption, and show anti-patterns
similar to the Stackoverflow thread creator‘s. However I would say the root
causes (which we discussed in maaaany meetings) are certainly neither caused
by Scrum nor increased by it, but individual mindset, dysfunctional team
dynamics, pressure, weird contracts, etc. and would be there under any other
or no process framework.

I am no Scrum fanboy (I think), but this experience and also from former
projects make me quite sure to not blame Scrum in the first place when I see
struggling teams, but trying to understand the underlying problems and solve
those.

~~~
waschl
One more thing: In answer to Scrum advocates claiming its about _doing it
right_ I would disagree and replace it with _understanding what is really
(really REALLY) the purpose and idea_ behind it. Don’t worship the cult and
don’t fight it because it’s the perfect target of rants, but see the
motivation behind it and acknowledge that there may be reasons why it makes
sense how it is to some degree. This doesn’t only apply to Scrum but to any
other interaction of humans.

~~~
dboat
Could you explain what you mean by the real purpose and idea behind scrum?

~~~
waschl
Let me try: I think it’s about reflection and continuous improvement and
providing a framework to enforce those. Scrum-haters in our group are also
notorious for an attitude of negativity and resignation in many matters, while
Scrum-friends want to improve all the time and find ways to do so, beyond what
is obvious.

~~~
watwut
I think that Scrum leads to resignation for many people, because it takes away
control out of individual and insists on everything being collective. So your
personal options to improve or make decision becomes severely limited.

Some people like it, because it allowed them to push themselves on the rest of
the team. But people who dont thrive in such constant dominance conflict end
up resentful and helpless.

~~~
jjav
That's an insightful concise description of "agile" experience.

As an anecdote, I have an acquaintance who is a psychologist in silicon valley
and he has mentioned he frequently works with patients suffering from mental
health issues related to being subject to "agile" at work. I wish someone
would do a proper study on this topic.

Personally, agile hasn't driven me to depression but it has made me target
roles that avoid it at all cost. Life is too short and precious to suffer
through a detailed status report meeting every.single.day.

~~~
watwut
I found that testers in particular find agile off putting and some avoid
working at such companies if they can. I am not sure why testers specifically
end up disliking that.

I think that agile ignores human psychology. First, in management theory,
intrising motivation happen when one has autonomy, mastery and purpose. Imo,
plus accountability. Agile removes that from individual, but has some rhetoric
that places it on the "team". But team is not person, it is set of people.

Second, it kind of assumes that people are socially perfect and everyone is
kinda the same and its answer to any social human problem is "that is team
dynamic or bad individual". It does not help to deal with _predictable_ human
imperfections, emotions and conflicts.

~~~
ohmyliver
possibly because usually they get a fraction of a sprint to do a whole sprints
worth of validation.

------
beaker52
The thing I personally see that corrupts Scrum the most are external
stakeholders. They're usually applying time pressures and defining work items
to be worked on. The team then has no ownership and no control, resulting in
an unhappy and unmotivated team that's constantly disappointed with itself for
not delivering and often isn't really invested in what's being asked of them.

If you want teams to care, they need to own it. When teams care, things happen
faster. The catch is that you can't make them care about what you want done.
You need to treat the team like the "10x rogue developer" giving them freedom
to pursue what they want to pursue, steered by the product owner, shielded
from external stakeholders. A product owner that mandates as _part_ of a team
"we need to do X by y because Bob from marketing wants it" has a losing battle
on their hands.

I really think the best person to be prioritising is the leader of the moment.
Sometimes it's the strongest Dev, sometimes it'll be the product owner,
sometimes it'll be the scrum master, sometimes it'll be a UX designer. It
could be anyone, that everyone believes in. The next week/month/quarter it'll
naturally be someone different, or maybe it's still that same person, if
everyone is on board then there's no issue, right? That's not to say there's
should be bitter infighting either, only that everyone should follow the herd.
This way, the majority of people believe they're working on the right thing,
and social pressures get others pushing in the same direction too.

------
fergie
(The linked article is a piece of content marketing and not the reflections of
an individual expert in the field.)

Typically for this type of article the merits of "Scrum" are debated without
Scrum first being defined, thereby making any reasonable appraisal impossible,
and inviting a "your doing it wrong" conclusion.

At this point I am genuinely unsure whether this is some sort of master-level
content-marketing trolling which is expertly crafted to goad engagement from
senior engineers, or whether it is just sloppy, misguided, business-school
nonsense.

~~~
jevgeni
It's a decent article.

Defining "scrum" in a debate-club fashion here is meaningless and is actually
a valid strategy to discredit any criticism of it.

1\. Scrum being a "philosophy" itself isn't clearly defined.

2\. Different orgs practice Scrum differently, hence the more specifically you
define Scrum, the less of the practice falls under that definition.

3\. Best definition in this context is "set of practices most orgs call
Scrum", which might as well be omitted.

And all of that has no bearing on the fact, that if team leadership busts out
Scrum boards and Jira tickets more often than discussing problems,
teaching/promoting knowledge and figuring out the best product design, then
it's probably a mediocre shitshow.

------
Animats
_Complicated tasks get deprioritized_

 _Features over robust code_

An effect is "birth defects are forever". An early design mistake is very
difficult to correct in a scrum-like "agile" process. The incremental nature
of the process favors patching around it.

This is OK for webcrap, but not OK for systems that have strong internal
consistency or time constraints.

~~~
xtracto
I disagree with this sentiment, well at least I disagree that it is SCRUM's
fault. I think this is a problem that resides higher up.

I have been in teams that to take the time to solve technical debt and even
generate technical wealth. The best approach that has worked for me is to
divide the development available time per sprint in: 33% new product features,
33% existing product maintenance, 30% Solve Technical debt (or 20% tech debt,
20% product debt with a 30-30-20-20 split).

With this I try to show that the problem of development teams NOT fixing their
crap i not an issue of the Agile/SCRUM process (or any other process), it is
an issue of management that prefers to ignore the mounting technical debt
(until it explodes and you have the Github downtime, or LinkedIn leaks or the
fact that changes become slower and slower due to codebase complexity).

~~~
JoeAltmaier
Hm. That sounds like a process issue. Which is what SCRUM etc are part of. So
its not process, but changing process will fix it? SCRUM + technical debt
management is the cure? Then SCRUM was missing something.

I put the blame squarely on the process, whether its SCRUM or whatever.

~~~
mindcrime
_Then SCRUM was missing something._

Scrum is missing a LOT of things, because it's very specifically intended to
_not_ be highly prescriptive. The whole idea is to iterate, use empirical
feedback, and evolve your process to match your context.

Right near the beginning of the Scrum Guide it reads

 _Scrum is not a process, technique, or definitive method. Rather, it is a
framework within which you can employ various processes and techniques. Scrum
makes clear the relative efficacy of your product management and work
techniques so that you can continuously improve the product, the team, and the
working environment._

------
fjfaase
Great article, but it does not mention management attitude. If upper
management does not have the right attitude towards Scrum, Scrum will fail. If
upper management does not guard the role of the Scrum masters, select capable
Scrum master and allow them to function correctly, Scrum will crumble into
another tool for micro-management which frustrates developers and destroys
productivity. I also have seen that often it are the more ambitions (and less
technically talented) developers that opt for role of Scrum master as a
stepping stone to a management role. These type of Scrum masters will starting
act like top-down managers, who no longer fulfill the role of a Scrum master,
namely provide a safe environment for the team to function optimally.

~~~
mindcrime
_Great article, but it does not mention management attitude. If upper
management does not have the right attitude towards Scrum, Scrum will fail. If
upper management does not guard the role of the Scrum masters, select capable
Scrum master and allow them to function correctly, Scrum will crumble into
another tool for micro-management which frustrates developers and destroys
productivity._

BINGO. The "problem with scrum" isn't usually scrum itself, but the management
and culture of the company. And bad management and toxic culture will, in my
experience, lead to the same results no matter what process / methodology you
nominally employ.

To me, most criticisms of scrum reduce to a (legitimate) claim that "scrum
isn't a magic bullet that will fix the fucked up management and toxic culture
at this shitty company."

~~~
AnimalMuppet
In fact, scrum is something the messed-up management has tried to use as a
magic bullet, rather than actually fixing themselves.

------
alexashka
The only right way to do 'great engineering' is by not having any middle
management.

The only right way to do great engineering, is by first asking _what_ we ought
to be engineering, not re-implementing the same shit over and over again, like
we do web frameworks in every new language.

Great engineering is completely unrelated to scrum. It is only in the
delusional mind of a middle manager that his existence and thoughts are at all
relevant to the success or failure of any project on this planet.

~~~
danjac
While "middle manager" is often nowadays a negative term, having a good
manager between yourself and the upper management/customer can be a godsend.
They can act as a bullshit filter, they can deal with bureaucratic busywork,
they can get you whatever resources you need, fight for more funding/people
for your team, help out with HR stuff and so on. You need these people so you
can get on with "great engineering".

~~~
amznthrowaway5
Those people should not be paid nearly as much as the actual value producers.

------
mharroun
Scrum, Kanban, scrumban, tickets with predefined checkins... all can work.

"Formal scrum" only exists to sell books, certs, classes; but more importantly
to give justification or a "fix" to failed project managers and leaders.

A process will not fix a team that has bad teamwork, is not productive, and/or
has bad communication/leadership/management.

------
gtirloni
I think it's similar to when someone switches jobs frequently and complains
about every company they've worked at. At some point, you have to realize it's
you not them.

To me it feels scrum is the person switching jobs constantly and saying people
don't get it.

~~~
baq
Yeah, no. Scrum is a tool. You can implement it wrong or be very strict with
it which kind of isn’t agile, but it’s always a people problem.

Scrum tells you 1) to analyze the way your team works, 2) make improvements,
3) talk to each other. If that sounds reasonable, it’s probably because it is.
The mythology of scrum being evil is misguided, I wonder how much of it is
caused by engineers forced to use JIRA configured by somebody who doesn’t work
with the team.

~~~
supercanuck
No true scrum.

------
moksly
I work in the public sector of Denmark, and I’m involved with both developing
and procuring solutions. We have quite a lot of them, around 300 for our
10.000 employees, and from a buyers perspective things like Scrum and agile
rarely makes a lot of sense. It’s down to the old triangle of time, features,
money, which agile and through it scrum mandates at least one has to be
flexible. Only that’s now how you buy software. No one is going to give you an
unlimited amount of money of time for an uncertain amount of features, and
almost nobody has the time to act into your Scrum schedule to prioritise
stuff. Because of this, it’s not really how you sell software either. As a
result Scrum often becomes a wrapped in a business side that’s very much
unified or waterfall process in companies pretending to be agile. I’m not
saying it happens everywhere, but I don’t think I’ve ever been involved with a
procurement or development process you could truly call agile.

That doesn’t mean you can use scrum, but it does mean that you should be
careful about how you do so. If you have a bunch of guys working on different
CRUD web-applications, does it really make sense to have them do a stand up
every morning? Probably not. But maybe the kanban board still works well.
Based on my own experiences you have to be careful and “agile” about how you
build your processes to suit your changing needs, but going full strict scrum,
is probably never going to work unless you’re a major tech company.

~~~
GordonS
> We have quite a lot of them, around 300 for our 10.000 employees, and from a
> buyers perspective things like Scrum and agile rarely makes a lot of sense

> No one is going to give you an unlimited amount of money of time for an
> uncertain amount of features

In a customer project I worked on recently, the consultancy I work at had a
contract based on the number of story points - something like, "we will
deliver 200 story points in phase 1". Now, because a story point is a
relatively nebulous thing, there is of course a lot of room on both sides to
fiddle things, but actually the customer was pretty happy with it.

The actual scrum teams were completely miserable, but that's a separate point
altogether :)

------
leto_ii
> Build a team to do scrum, don’t expect scrum to build your team.

This is a very important takeaway I think. A development methodology can work
to organize the processes of an already (relatively) well working group.
Expecting process standardization to fix dysfunctional human interaction is
just putting the cart before the horse. Scrum will not build trust between
coworkers or between workers and management. It will not allow non-technical
management to suddenly develop an understanding an appreciation for technical
difficulties.

------
samdwilson
I wish blog posts like this had examples of things they actually did. It would
make it a lot more informative to learn from an example.

------
doctor_eval
In my company we hired a CSM (certified scrum master) and we definitely did
Scrum by the book. But we didn’t do it right, in the sense that after 2 years
our productivity was worse than when we started.

In my experience, Scrum can easily become a series of little waterfalls,
rather than bring a flexible and needs based approach to building complex
products. This lead me to see that Scrum is not really Agile, where by “Agile”
I mean [0]. Scrum is a process and Agile is a mindset. Some teams are able to
hold both ideas in their head at the same time. But in my experience across
multiple large customers and projects, teams think that by doing Scrum they
are being Agile, and this is not the case at all.

Scrum is no more a solution to the social and political problems of a project
than is waterfall or the spiral model (which Scrum mimics IMO) or anything
else. A good team will succeed regardless of the project management
methodology and a bad team will most likely fail.

Scrum is not the problem nor the solution. It’s management’s job to ensure
that the teams are working well, that people have room to succeed and fail,
and that the project management methodology suits the needs of the project.
That’s certainly where I failed my business for a few years, until I worked it
out.

[0] [https://agilemanifesto.org/](https://agilemanifesto.org/)

------
29athrowaway
Very few people care to read the official Scrum documentation. It is not a
long read. Some posts on HN have more words than the Scrum Book.

As a result of not reading the documentation, not many understand what Scrum
is and what they're criticizing. I have been in that situation myself at some
point. One day, I found myself so frustrated that I read the Scrum book over
and over again until I could complete the certification assessment with
passing score, just to understand if Scrum was to blame for the problems I
perceived.

What I learned in the process was that scrum does not recognize the role of a
project manager and it does not make distinctions between development team
members. The development team is defined as self-organizing and empowered to
make decisions to a very reasonable extent.

The problems described here often start when some the self-organization and
autonomy of the development team is taken away. This can take many forms, like
adding roles like project managers or by redefining existing roles, such as
making the scrum master role absorb responsibilities from the development
team.

Those adjustments are suboptimal and almost inevitably result in an imbalance
of power between product and engineering, and that's a really bad idea that
will often result in engineering disasters.

Some companies create engineering holidays such as hackathons, where engineers
can take the time to work on neglected aspects of projects. But then, in many
companies, product people have started to intervene those events as well,
perpetuating engineering frustration.

------
danjac
While there may be success stories out there (and usual arguments apply for No
True Scotsman), a company that proudly states "we're a scrum shop" is at this
point most likely shorthand/signal for "we love meetings and micromanagement"
and is to be avoided if possible.

------
znpy
I work in systems engineering, automation, devops and that kind of stuff.

I've seen colleagues in development at other companies do this daily standups
and all this scrum thing.

From the outside it really looks like somebody constantly asking "are you done
yet?" And pressuring people into delivering. It really looks like something
invented to serve companies and management more than developers.

------
sunstone
Scrum is a process for large companies to force some group consistency across
their 1000's of developers. Think of it as the minimum viable group behaviour.
Naturally talented and effective team oriented developers know what to do
naturally and don't require the explicit framework.

------
richliss
99% of teams are doing Scrum wrong most likely.

Scrum has been ruined by many different groups (large consultancies,
certification bodies, the misinformed, bloggers etc.) and there is a movement
called the Scrum Pattens movement trying to fix the damage and to make it more
explicit. If you want to do Scrum properly read “A Scrum Book”.

Scrum is not a process it’s process design framework- you start with Scrum as
a framework to then, through inspecting and adapting, add what works for that
team (and no other team) and discard/replace what doesn’t through experiments
and retrospectives.

Does that sound like it’s liberating for engineers or something that ruins
them?

Note: Kanban is also not a process but a system for continuous improvement.
99% of teams doing that are doing it wrong too most likely.

~~~
dragonwriter
> Scrum is not a process it’s process design framework

Scrum as defined in _The Scrums Guide_ is a very specifically defined process
with a few degrees of freedom, not a process design framework.

Now, if your approach was actually Agile (unlike the many groups that do
Scrum, either as defined in the _Guide_ or some variation they've cobbled
together from other sources and still call “Scrum”, and think that by doing so
they are therefore Agile), any canned process will be at most a starting point
and input into what works for your team. But that is very much not Scrum as it
has been propounded from the beginning, including by it's creators.

> Kanban is also not a process but a system for continuous improvement

Kanban is a very specific process element related to flow visibility and
management.

~~~
mindcrime
_Scrum as defined in The Scrums Guide is a very specifically defined process
with a few degrees of freedom, not a process design framework._

Scrum as defined in the Scrum Guide prescribes very little. It's not much more
than "Have a development team, a scrum master, and a product owner, have a
product backlog, have developers plan their work, and work in time-boxed
increments." Nearly every other aspect of how work gets done is unspecified
and can (and should) be evolved by the team based on empirical observation.

My observation is that people have a tendency to adopt a version of scrum that
is based on certain "default settings" that everybody sort of assumes are
required, when they aren't actually. Two week increments, for example. I've
heard so many people complain about scrum mandating two week increments, when
it doesn't actually.

Or people complain about "velocity", and "story points" which are likewise not
part of scrum at all.

~~~
JoeAltmaier
They are certainly part of Scrum-master training. They're a widespread
practice. At this point, they can be grouped as 'part of Scrum' with fair
confidence, in any implementation you can point to.

Resorting to definitions is not helpful, when you work in a dysfunctional
organization, and instituting Scrum was the root of the disfunction.

~~~
mindcrime
_They are certainly part of Scrum-master training._

I am certified as a Professional Scrummaster, and none of those things were
taught as part of any training I went through, nor were they mentioned on the
certification test.

Referring to definitions _is_ useful, when many people are misunderstanding
the definition. If anything, we should be screaming from the hilltops "For the
love of FSM, go read the Scrum Guide, and the Agile Manifesto, and show your
managers and shitty Scrummasters what they're doing wrong." If we, as
developers, are not willing to draw a line in the sand and take a stand
sometimes, then what right do we have to complain? And if management won't
listen to us on this, they aren't going to listen to us on anything else and
we're back to "toxic management is the problem, not scrum."

~~~
JoeAltmaier
Or, not do Scrum. Do another process, like having an experienced team that
respects the other team members to plan their time and prioritize tasks, with
good communications between members of the team.

Looking at 'scrum master certification test questions' online I don't see
anything about technical debt, variable-length time boxes, re-prioritizing
work during a sprint etc.

A real and reasonable criticism of Scrum or Agile is, the structure is not
helpful to the actual work. Sure, making a list of tasks is quite useful. But
the time-boxing and task atomizing can dissect the work to the point of
dysfunction.

If nobody is doing Scrum right, we're right on the edge of a No True Scotsman
argument.

~~~
mindcrime
_Or, not do Scrum. Do another process, like having an experienced team that
respects the other team members to plan their time and prioritize tasks, with
good communications between members of the team._

That seems orthogonal to the question of how desirable (or not) scrum is. You
can have scrum (or not), and/or have "an experienced team that respects the
other team members to plan their time and prioritize tasks" and shitty
management is still going to wreck things.

 _A real and reasonable criticism of Scrum or Agile is, the structure is not
helpful to the actual work._

I 100% agree that there are times when the structure imposed on a team in the
name of Scrum (whether it's actually prescribed by Scrum or not) is harmful.
Don't mistake what I'm saying here as a massive endorsement of Scrum. It's not
actually my preferred methodology. But I do think Scrum can be useful to very
many teams in very many situations, and I feel like a lot of the criticisms
directed at scrum are somewhat misplaced.

 _If nobody is doing Scrum right, we 're right on the edge of a No True
Scotsman argument._

I think I get what you mean by that, and I probably agree to a point. But I
don't think it's quite "No True Scotsman", as Scrum has an actual definition,
to an extent that "true Scotsman" does not. But I'll buy the suggestion that
"if everybody is doing it wrong, then there's something fundamentally wrong
with the whole situation".

------
kevsim
This is something I think a lot about because I'm working for a small startup
[0] building an issue tracker and trying to take on the likes of Jira. We
discuss a lot about exactly how much scrum we should support "natively" in the
tool (sprints, story points, etc.) because we've seen scrum go wrong and turn
into a mess of micromanagement and misaligned incentives a number of times. At
the moment we've opted to make it very un-scrum and our early adopters aren't
complaining. Teams need to work hard to find a process that actually works for
them - tools and scrum master trainings can't dictate that for them.

0: [https://kitemaker.co](https://kitemaker.co)

------
sergeykish
Once there was great scrum master, no managers, felt like a team, no missed
sprints.

Once there were no managers, team crumbled in internal politics but was
bearable.

Once there was micromanagement, all fails to developers, all prizes for
management, each sprint failed, that was hell.

------
bJGVygG7MQVF8c
As a vendor of thought leadership, it's 100% in my interest to treat as
exogenous the likelihood that my framework / best practice / etc will be
implemented as I intend it to under ideal circumstances.

As a consumer of thought leadership — a sensible and responsible one, that is
— I'm compelled to treat such concerns as endogenous to the framework / best
practice / etc, and predict outcomes accordingly.

"You're doing it wrong" doesn't explain anything. At best it's the start of a
conversation, at worst it's intentionally used to elide the costs of whatever
it is you're selling.

------
mrich
As a manager you should think hard about what aspects of scrum are important
to you and where you can let loose. This will heavily depend on the makeup of
your team - how many experienced developers are there who don't need hand
holding? How many of them will still deliver without some oversight? How many
of them can mentor? How many inexperienced people do you have, how many will
be onboarded in the next year? Things like that determine and change your
development process.

~~~
MattGaiser
> what aspects of scrum are important to you and where you can let loose.

Scrum explicitly does not permit that. A criticism that didn't make it into
that answer.

[https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum...](https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-
Guide-US.pdf)

~~~
mindcrime
Two thoughts:

1\. There's a lot of stuff that is often thought of as "part of Scrum" that
really isn't. To the extent that the parent post you're replying to is
referring to these things, then he/she is spot on. Things like Jira tickets,
story points, planning poker, velocity, two week sprints, yadda yadda yadda.

2\. Scrum™ doesn't permit you to do certain things... while truly saying you
are doing Scrum™. But nobody has any real authority to mandate that you do
Scrum™ to the letter, as opposed to an in-house "little-s scrum" version. And
if that is what works better for you, you should do it. The goal is delivering
working software, not adherence to the Scrum Guide for its own sake.

------
Fire-Dragon-DoL
Scrum has its flaws, but even though is marked as a "process framework" and
the guide states you should evolve the process to fit your company (it is part
of the agile movement), it's considered a big red flag diverging from it even
a little, which completely invalidates the "people over processes" part of the
manifesto.

------
tomohawk
The main problem I've seen with scrum is that everything can get put into the
backlog, and the backlog becomes infinite.

Then, development becomes ticket driven instead of engineered.

I have seen scrum used successfully where an engineering process was placed in
front of the backlog ala Feature Driven Development.

There is a ticketing system, but it is kept separate from the work planning
system.

------
stx
In my experience it has been that people expect scrum to be a magic bullet.
Things are not going well... it will be better when we change to the new orgs
process. Only the real reason its not going well is because of lack of
planning and poorly written stories. The how you fix that is much more
complicated.

------
mem0r1
I almost can't believe that it's 2020 and people are still disscussing or even
worse "utilizing" Scrum. Pretty much all good and excellent Software engineers
I know who had to deal with it at various companies hated it.

------
loopz
Easy: Is the output great engineering because of scrum, or despite it?

------
Yhippa
How about letting developers pick or come up with their preferred way of
working instead of mandating Scrum?

~~~
kitotik
The only potential result of a competently run scrum process is exactly that -
a process that was designed by the team.

If you are stuck in some weird cargo cult that doesn’t allow the team to
iteratively change the process, you should call bullshit.

~~~
rightbyte
If scrum is any process designed by the team the term is worthless.

Sadly, scrum as I have seen it has been consultants preaching to the commoners
how their rigid process is going to make them agile.

Scrum is just flawed from the foundations for anything but very routine work
where you can somewhat estimate subtasks duration with any accuracy. But if
your job is that easy you hardly need any fancy process anyway.

~~~
kitotik
> If scrum is any process designed by the team the term is worthless.

SCRUM is a handful of tactics that a team can start off with to design and
implement the “right” process for a given team. For example, I’ve been on
several teams where through the use of retrospectives, daily stand ups were
abandoned and replaced with other means to keep the team in sync.

> Sadly, scrum as I have seen it has been consultants preaching to the
> commoners how their rigid process is going to make them agile.

That sucks, but sadly this is the most common case. Very few organizations
actually _want_ agility, as they are culturally and practically top-down
hierarchies that require command-and-control structures to function. These
consultants are generally brought in by middle-management who are grasping at
straws without any real buy in from the c-suite.

> Scrum is just flawed from the foundations for anything but very routine work
> where you can somewhat estimate subtasks duration with any accuracy. But if
> your job is that easy you hardly need any fancy process anyway.

I couldn’t disagree more. For “routine” work that is predictable, what value
does agility provide? It’s either done correctly or not. Agility is only
useful in dynamic environments when outcomes are hard to predict and there is
limited prior art to reference.

------
C1sc0cat
No and Yes

------
awinter-py
or both

