
Ask HN: Have you ever seen Scrum work well? - NickM
I&#x27;ve been at several different companies in my career that have tried to use Scrum, and it never seems to work well. The funny thing is, in every case I hear managers saying the same thing: &quot;tons of other companies use Scrum and it works great, if it&#x27;s not working for us we must just not be doing Scrum right.&quot;<p>We end up spending years tweaking rules and processes trying to &quot;do Scrum right&quot; and get things to actually neatly fit into predictable sprints, and it never seems to happen, and nobody ever seems to be happy, yet the people in charge seem unwilling to try anything else.<p>I can&#x27;t help but suspect that this is all just a silly fad, and everyone is just stubbornly sticking to it because &quot;it&#x27;s what everyone else uses&quot; and therefore feels politically safe. But, I&#x27;m trying to keep an open mind, and of course it&#x27;s possible I&#x27;ve just had a string of bad luck. Has anyone actually seen Scrum work well? Is there some make-or-break factor that everyone is missing here?
======
president
My observation is that Scrum/Agile/<your favorite SDLC methodology here> is
just a proxy for team competency. If you have a team that is technically
proficient at what they do, have reasonable time management skills, and are
motivated and incentivized properly, it doesn't matter what SDLC they use and
they'll figure out an efficient way to succeed. At the same time, if you have
a rag-tag team of developers who don't know what they're doing all the time,
it doesn't matter what SDLC they are using, they are going to fail. SDLC might
give some guidelines for managers to feel safe but it all comes down to
understanding the economics of the team and figuring out what works best for
them.

------
bitfhacker
I have a diferent perspective.

I work in a portuguese bank at almost 2 decades and now we use Scrum and
Kanban.

For the sake of clarity when I talk about Scrum in "my bank" I use two epochs:
\- b.s. (before Scrum) \- a.s. (after Scrum)

Before Scrum we work hard and we dos many things, but we didn't measure
nothing so we didn't learn.

After Scrum, we work hard, we build, measure and learn.

We have performance indicators, we know where the botlenecks are, we know a
team velocity and how many Functionalities IT deliver in racha month/year. We
can compare the performance with other years. We can learn with our mistakes
because we have data to prove it.

Scrum have disavantages, but in my humble opinion working without Scrum is a
lot worse.

------
jayturley
Yes, I have seen Scrum work well. The key is to recognize it is a tool for
increasing team performance, team member autonomy, and increasing
organizational transparency.

It is not a product management framework that should be used to manage
inch/milestones and the like.

As soon as some sort of top-down control is (almost invariably) applied, it
breaks Scrum. And most organizations want top-down oversight and control, not
a high-performing team that may be resistant to organizational processes that
negatively impact product development while satisfying other organizational
needs (like LOC metrics or something else equally pointless).

Scrum is just empirical process control and improvement. The iterations aren't
just to do the next thing on the backlog, but to improve the team's ability
(and speed) to create working software that satisfies business needs.

The main reasons I have seen scrum fail are:

1) The organization implements a layer of management on top of Scrum that
"won't effect it", but it does, because if you don't understand Scrum/agile,
modifying it usually won't have the desired outcome.

2) Inexperienced Scrum Masters who act as a team leader, when their actual
defined role is that servant coaches whose goals are to protect the process
from interference and the team from organizational intrusion during sprints.

3) The transparency required for Scrum to operate reveals inefficiencies or
actual malpractice at higher levels, and those levels are protected by
management, creating a roadblock that cannot be passed.*

As you can tell, yes I have drunk the Kool-Aid, but I have seen Scrum (and
other agile implementations) drastically improve performance and software
quality, but you have to have buy-in and support from the highest levels to
make it a success. When the process meets a roadblock that cannot be removed,
it kind of kills the whole thing.

* Personally, I have seen it reveal:

\- VPs who are actively preventing projects from succeeding (but who are
protected by their level), \- Rockstar (cowboy) coders whose poor development
practices (no source control, no testing, code in production) negatively
impact the rest of the software teams, but as they are the CEO's buddy,
nothing can be done to address the behavior, \- Database teams who
successfully blame their errors on software development teams, because the
Director of DB is a buddy of the President, so his word is taken over actual
evidence

------
JohnFen
I've worked at three places that used Scrum (and am a certified Scrum master),
and while it was pretty much a nightmare all around, I did actually see it
work once, on a different team in a company I worked at.

I tried hard to find out why it worked for them and not for the other teams,
but was never really able to figure it out.

~~~
rightbyte
Sad story. I belive that you need to be working side by side in a team to
understand the dynamics in it. It's probably really hard to spot who or why a
team works from the outside. All the right micro-optimizations decisions taken
...

------
theworld572
No, I have not ever seen it work well. I was so frustrated by its prevalence
in the industry that it was one of the main reasons why I decided to leave
software development and work in cyber security / penetration testing instead.

I have since returned to software dev because the fact is I love coding and
development but I try to minimise the time I spend working for companies by
only working short term contracts while working on side projects inbetween
jobs. If one of my side projects becomes successful and I end up hiring
developers then there is no way in hell I will be forcing the horrorshow that
is Scrum on them. Yes, yes I know "thats not real Scrum", but that doesn't
change the day to day reality of working in teams that follow Scrum, or
"Scrum".

------
foopod
I think this often comes down to why a team uses Scrum. Does the team actually
see value in it and want to use it? Or are they told they have to use Scrum?

~~~
NickM
Generally it's the latter, and people are just forced to use it. However, I
have made an honest effort to try and see the value in it, but the whole
concept of trying to squeeze everything into artificial scheduling boundaries
via sprints just feels very weird to me. Invariably projects just end up
spilling over from sprint to sprint, because even if you manage to break
things up into small enough chunks to do a meaningful piece of a project
inside of a sprint, then you still end up with leftover time at the end...and
then of course you're not going to sit around doing nothing, but rather you'll
go ahead and get started on the next sprint's work in advance.

So the ultimate outcome is that you have to follow a certain specific set of
prescribed meetings and rituals every X weeks when the current sprint ends or
the next sprint is starting, but the actual work that's happening rarely seems
to follow a schedule that has anything to do with the sprint cadence.

------
quintes
Is everyone onboard the train or are there people who are not going to support
it?

Was what you did before working better?

What comes out of your retros?

