
Ask HN: Does Scrum work? - scrumskeptic
I’ve read the Michael O. Church article and quite a bit of other stuff about how bad Scrum and the like are, and I’m trying to find some counterpoint info. Unfortunately, most of what I find when searchig for information on the other side of the coin is from firms trying to sell scrum certifications and training. Are there any devs out there working in a scurm shop who think their team is actually successful because of scrum? Does this actually work from the Devs&#x2F;Engineer’s perspective or is it as much of a scam&#x2F;fad that it seems?
======
world32
No, compared to conventional project management, i.e. having a project manager
who understands the technical aspects but also meets with the stakeholders to
balance feature development with solving technical debt, it is much slower and
more frustrating to work in. Its really not that hard to manager a team of
developers - keep track of whos working on what and make decisions with the
team if something is blocking a piece of work being done. SCRUM tries to
formalise everything with explicit rules which in reality robs developers of
their ability to use common sense to get things done and results in hours and
hours of meetings to discuss, review and improve the various rules and
protocols.

I think it is a fad, most of the people I know who are big fans of it are also
fans of whatever other tech fad is going on at the moment i.e. blockchain,
nosql, the latest frontend framework etc. I find it extremely unfortunate that
SCRUM is so widely practiced in the software industry now, at one point it
actually caused me to quit my job to move to a different IT career, though in
the end I went back to development because I love coding and I've just had to
realise that SCRUM is something I'll have to live with.

There has been plenty written on this subject, here is some more reading:

[https://michaelochurch.wordpress.com/2015/06/06/why-agile-
an...](https://michaelochurch.wordpress.com/2015/06/06/why-agile-and-
especially-scrum-are-terrible/)

[http://okigiveup.net/not-big-fan-of-scrum/](http://okigiveup.net/not-big-fan-
of-scrum/)

Queue the "thats not scrum" responses..

~~~
ustamills
I find these comments fascinating. Scrum formalizes using rules? Compared to
what? Read the PMBOK and then say that. I do Scrum specifically because it
drops all the rules and leaves it to the right smart people to figure things
out. I can't even imagine how Scrum with lots of rules would work. I've done
Scrum since 2004 (got the SM cert too) and I truly don't understand what you
mean by that.

The idea that any project manager can be all that is so dangerously
optimistic. And yes, I realize there exists some PM somewhere who proves it is
possible to be a good project manager. But the existence of an outlier does
not move the bell curve, it's part of the bell curve. Most PMs need to be
taught to rely on their devs and product owners so they stop screwing up
projects themselves.

There is nothing so dangerous as a bad manager, especially a manager who
thinks, "I've got this....". And there are so many bad managers. Scrum helps
mitigate this by spreading the responsibility around to the people most likely
to get it, not by tossing rules at a team.

~~~
world32
Scrum rules: [https://www.scrumguides.org/scrum-
guide.html#definition](https://www.scrumguides.org/scrum-
guide.html#definition)

Perhaps you are right that good project managers are not too common, however,
I find it easier to reason with one single manager than to reason with an
entire team who has defined themselves as a "SCRUM team". In my experience the
dogmatic nature of SCRUM means that teams take on an almost religious attitude
towards it. A team like that is far more difficult to reason with than a
single bad manager and disagreemnts often end with the conclusion "Yes but we
do SCRUM and SCRUM says to do this.".

SCRUM contains some good princeples which I agree with like iterative releases
and attempting to break down stories into manageable chunks, but the reality
is that SCRUM is more than just a set of princeples to take on board,
otherwise it would not be a multi-million dollar industry for SCRUM
consultants and such.

You are right though, SCRUM has its use in preventing bad managers and bad
teams from doing bad things. However at the same time I think it hinders good
managers and good teams from doing good work.

~~~
ustamills
Thank you for a well written response.

I think maybe we agree on something. Religious fanaticism can break any good
process. I see Scrum as a place to practice flexibility. Example: I have a dev
team that is only two devs, a husband and wife team. We don't do standups
because they are together all the time and don't need that feedback and daily
planning.

I'll be adding someone to that team soon and will need to add some formality
so that feedback and daily planning are sufficient.

I have no room for fanaticism in my processes. It breaks stuff.

------
gvand
\- If you use Scrum[1] as a starting point to evaluate how your organization
is structured, to reason about your processes and as a starting point to setup
a process of continuous improvement (à la kaizen) that will turn your Scrum[1]
in something unique to your situation and likely very different from where you
started from: Yes.

\- If you use Scrum[1] to turn everyone into a cog of a cookie-cutter system
that you barely understand/control and that, for some form of deranged
reverential respect, you apply mindlessly without questioning anything: No,
may God have mercy on your soul.

In a more general sense, everything that is embraced aprioristically
(methodologies, frameworks, languages, etc...) has the same damaging effects
of a scam/fad.

The fact that most recent converts present Agile/Scrum as "the methodology
that saved us from Waterfall!!" like if no one before ever did short iterative
development cycles or tracked anything before, reminds me of those who drooled
over nodejs for its nonblocking magic and its thaumaturgical webscale
capabilities.

More reflecting, less bandwagoning.

[1] Replace with your favorite methodology.

~~~
emeraldd
Does anyone still use waterfall? I'd thought that had fallen by the wayside a
long time ago in favor of less rigid processes ...

~~~
Bumerang
Yeah, currently working on a project implementing new core banking system via
waterfall. You can still see it quite a lot in these extremely risk-averse
industries (pharma, finance, insurance).

~~~
closeparen
Usually we talk about waterfall being riskier, in that there is no validation
that your approach is leading to a working system, or that the working system
is meeting business needs, until the very end. The big bang integration step
might fail, the testing might reveal show-stopper bugs, or the customer might
go "oh, that's not what I meant," etc. but by the time you're learning any of
that, it's too late.

Why do you think it's preferred in risk averse industries? Is the agile-
partisan view of the relative risk incorrect? Missing something?

~~~
Bumerang
You don't do the whole implementation at once - you usually split it into
several chunks/releases and everything becomes more manageable. I am a fan of
agile where it makes sense - in projects/products where you have a strong
uncertainty about the actual outcome/desired product. Then agile gets you
there faster and cheaper.

But what people seem to forget about is that waterfall is actually cheaper in
those cases where you have a clear understanding of the needs, the end
product, and actions and tasks you need to do. This is usually the case in
banking - you usually have a box product you need to customize and integrate
(the toughest part, and processes are pretty much set (also strongly
determined by the regulatory requirements). Hence, most innovations are just
automation of specific process steps.

Another thing to consider is that the people in the bank are used to work in
this way, so it removes some traction and gets you up to speed faster.

~~~
closeparen
How is agile meaningfully different from small, iterative waterfalls?

Would you happen to have links to the text of regulation that specifies
software development process? The only ones I can think of specify properties
of the end result.

~~~
Bumerang
In agile (from my perspective) you rely on constant feedback from the
stakeholders (customers, Product Onwer, sponsors) and iterate on it - that's
why it's crucial to have short sprints so you can contain the uncertainty and
make sure you're heading in the right direction.

In the 'iterative waterfall' you usually split the work into several domains,
with each iteration taking months up to a year. E.g. when implementing new
core banking system, the first release could be 'move the customer masterhip
into the new system'.

Sorry for misunderstanding, I meant that business processes are usually
derived from the regulatory requirements, not IT processes. The following
implementation is then affected by those regulations - again, in a way that
limits potential differences between the desired outcome and implementation
choices.

------
cbanek
Any tech that claims to be a silver bullet never is. I consider scrum or other
project management technologies to fall into this bucket as well. Can it be a
useful framework? Sure. Can it be terrible? Sure.

What really makes a team successful is good people. Good people can make
anything work, even if it's a bad system. Bad people can take something
reasonable and turn it into a dumpsterfire.

About 10 years ago, when I did my first scrum training, I could practically
see the kool-aid being passed around. It is something that worked for someone,
so we just needed to do it, because it would make everything better. What
mattered more was the higher level managers always making arbitrary decisions
against what the line devs knew to be true. While scrum was supposed to
empower us, it really didn't, as we managed to have the managers always
defining the stories and sprints, and basically used it as a stick to beat us
with every 2 weeks. Organizations and people do as they want, and will do it
in any framework people propose. A framework like scrum, or a tool like JIRA
won't make a bad team a good team.

It seems like every consultant is trying to sell the story of how you can take
a non-functioning team and make it a bunch of rockstars with their class. But
it never works. You just need to be working with the best people, and that's
what gets results.

------
innocentoldguy
No, but then again I've never seen a company actually do Scrum. Typically,
they say they're doing Scrum, but instead, they've just renamed their project
managers Scrum Masters and have a daily status-report meeting where everyone
stands up.

------
d--b
Work methodologies should be taken for what they are: general advise on how to
do things.

Read it, see if that resonates with you and your team. If you think it does,
try it, tweak what you don't like. If it doesn't work, you'll know very
quickly.

Regardless of whether it works for you, methodologies are important because
they describe a mindset that you may need at some point, and that could help
you think outside the box you're in.

------
geoelectric
Nearly any coherent process an entire organization commits to will work. The
questions are more around whether they'll actually commit to a coherent
process.

Most orgs I've done "Scrum" in have done "Scrumbut" instead: "It's Scrum,
but..." and then screwed it all up.

Customization is part of the game for sure, but gutting the core principles to
reduce Scrum to a fancy status tracking mechanism doesn't preserve the
benefits very well. It's not the right kind of customization, it's neutering.
That seems to be such a common antipattern I have to assume it's a gross flaw
in the system itself:

 _The short term compromises are so startling to traditional management they
won 't wait to measure medium or long term gains, and instead tweak it to
death._

This isn't super surprising given that half the process in Scrum (product
owners, scrum masters, either finish as planned or scrap the sprint entirely,
etc) is to keep management concerns from whipping back and forth by limiting
the amount of influence management has mid-sprint. The other half is supposed
to make them comfortable with the first half (estimates, feedback, status,
burndowns), and predictably is the half most commonly preserved--as overhead
without a tradeoff.

So yeah, think it could definitely work in a group that understands it well,
and embraces both the flaws they were getting away from and the features they
were getting away to. Unfortunately, I rarely see that level of cooperation in
an org, so it usually doesn't work very well.

------
closeparen
Compared to what? I don't think opinions on Scrum can be meaningful in the
absence of a preferred alternative.

Having a continuously working artifact that changes incrementally according to
user feedback every couple weeks is probably a better idea than going from
months of documents to months of code to months of tests to your first demo
more than year later.

But within the basic paradigm, methodology is mostly a way of describing what
you were going to do anyway.

------
dawidw
I recommend to read Robert C. Martin's (Uncle Bob) view on that presented in
"The Tragedy of Craftsmanship":

[https://blog.cleancoder.com/uncle-
bob/2018/08/28/Craftsmansh...](https://blog.cleancoder.com/uncle-
bob/2018/08/28/CraftsmanshipMovement.html)

------
mempko
There are many successful examples. One famous example is the google AdWords
team ([https://www.alexanderjsingleton.com/google-adwords-the-
art-o...](https://www.alexanderjsingleton.com/google-adwords-the-art-of-scrum-
quintuple-constraint/)). Considering that AdWords became success after
implementing scrum, you can say "it works".

From my personal experience, Scrum does work but it requires a team that is
competent already. A team of incompetent people will perform poorly in any
scenario.

------
scollynz
Scrum is a great place to start but every team I've ever led using Scrum has
matured into using a KanBan like system.

------
UK-Al05
Scrum can get you to a basic level of working, but you have go beyond it to
get to advanced levels. Scrum was probably the state of the art back in 2005.

Things move faster now.

Every story is an iteration now.

------
roschdal
No.

------
vkaku
Only if your everything else is not process heavy.

------
wynch
define 'work'

~~~
wynch
work could mean :

\- 'having a broad vision of a project & being able to anticipate', well, this
seems unrelated to Scrum to me, Scrum might work, or not. The biggest error in
Development management being 'estimates', which was partly solved in scrum by
replacing hours/days/months with bananas/story points, but there is still some
equivalence in people head. And estimates are WRONG. I've never been good at
estimates, and I keep telling my employers that's not what they should be
paying me for...

\- cutting a project in small iterations so that budget can be adapted /
stopped at any time, and developers kept in check (because management don't
trust them) : this is maybe the most compelling use-case for scrum / Agile
methodologies.

\- having happy & productive developers: well this depends on what THEY like.
Some people need structure to feel good, and Scrum can provide that. Others
are more at ease with autonomy / being responsible for their work...

------
shmooth
yes, scrum works

and so does every other methodology

and yes, it's b/c of scrum.

and yes, it's in spite of scrum.

and yes, it's a full on scam/fad, just like every other methodology.

my best guess on where things currently stand is that: 1) most shops use it 2)
most shops use it very loosely, at best 3) most shops know to publicly despise
waterfall but know that scrum and the rest are just watered-down waterfall and
any shop doing near-actual scrum would kill to have a 'waterfall' dev model
again -- that is, a realistic dev plan without requirements that change on the
hour 4) until one of the new pseudo-methodologies (like design thinking)
replaces it, Scrum/Agile will continue to reign supreme (b/c it ultimately
exists b/c it is very management-friendly -- it's useful for controlling
employees -- not for any other reason like 'productivity', etc.)

------
tomerdi
worked for us - but you have to be committed to it and stick to it - just like
with any other tool you will choose ! very easy to start with Scrum

