
Scrum seems to be mostly about having better alibis - RalfR
http://agileoverflow.com/t/scrum-seems-to-be-mostly-about-having-better-alibis/47
======
derefr
> Engaged as a service provider or consultant by a larger corporate customer
> and not authorized to make product decisions yourself?

Then you won't _be able to_ do scrum. You have a waterfall built into your
development process: requirements and designs are generated and committed to
on the customer side, then "fall down to" the consulting development team.

Scrum (or, really, any methodology that attempts to keep time constant by
managing scope) is an iterated conversation between the people who want
things, and the people who make things. If the people who want things aren't
at the table, you can't have that conversation, and so you can't control
scope. Period.

------
DanielBMarkham
I love collecting these rants. For a long time, I've been convinced that
various techniques may be fine and dandy, but _the way we implement change in
organizations sucks_.

Fair disclosure: 1) I teach/coach Agile/Lean/Kanban/Scrum, and 2) I couldn't
care less about brand names and religious dogma. I'm a developer first. If it
works, do it.

Having said that, this author does not know what he is talking about.
Apologies for being so blunt, but there it is. And he probably doesn't know
what he's talking about because his organization has failed at making changes.

Really there's just a couple of questions to ask yourself. Can you get
everybody important to the project into the room working together? Can you
guess what you might do over the next week or two?

If you can do those things, hell if I care what you call it. If, however, you
believe that complex systems must always consist of dozens of people with
various deep-dive specialties? Then we've got a problem.

The problem isn't that some things in life are tough. Technology development
is certainly tough. It's that you need to realize that the enemy of
productivity has been siloing people and specialists that want to hand-off
their work to others.

In some cases, the business environment means you can't have everybody in the
same room. Fine, there are strategies for that (too much to go into here). In
some cases, people just want to keep working the way they've always worked.
Most of the time it's the latter case, not the former.

It's a shame that this person's environment has failed them in this way. No,
Scrum is not made for a lot of things, but you are not a special snowflake. I
can freaking guarantee you that no matter what technology problem you're
solving, all that Scrum/Lean/Kanban/yadda yadda stuff has been used to help
folks run fast. I would suggest trying to find other teams doing the same
thing you are, only much faster, and watching what they do. That's how all
these buzzwords came about, anyway. If you don't want to believe the books and
trainers, and I'm fine with that, go watch it work. Then write another
article. :)

~~~
edwinnathaniel
This is an interesting remark:

"Technology development is certainly tough. It's that you need to realize that
the enemy of productivity has been siloing people and specialists that want to
hand-off their work to others."

What if the type of challenges that need to be solved involves: embedded
device all the way up to cloud, big data, and devops automation where some of
these things require specialties?

Some sprints might be heavy duty on a specific area of specialties, how can
Scrum balance the productivity within a team?

~~~
quanticle
>What if the type of challenges that need to be solved involves: embedded
device all the way up to cloud, big data, and devops automation where some of
these things require specialties?

Then maybe Scrum isn't the best approach. Scrum (and agile methodologies more
generally) are not designed to solve cutting-edge problems where it isn't even
clear whether the product is possible, much less feasible, to build. Scrum is
designed for software teams working in a well-known problem space (e.g. line-
of-business web applications) where the challenges are organizational (getting
a clear set of requirements and managing requirements churn) rather than
technical.

I certainly wouldn't expect a scrum team to deliver software for a brand new
problem domain. For something like that, I'd expect better results from
something like spiral, which explicitly includes room for research,
experimentation and prototyping at each stage.

~~~
asgard1024
> Scrum is designed for software teams working in a well-known problem space

I always have to wonder, if your problem was already solved, why don't you
just buy off-the-shelf solution? If you aren't doing anything new, what is the
point? It seems like you cannot organize the work correctly already! Frankly,
if you have failed to use what was already done, no amount of management
methods will help cover _that_ productivity screw up. :-)

~~~
cmdkeen
Well known != well solved. It's the difference between "we need to build a web
application to do X" and "we're going to redefine how people do X".

Secondly have you seen Salesforce? The COTS solution isn't zero configuration
in many cases. Plus many businesses decide their unique selling point can be
having bespoke software that has a feature that the COTS version can't do, or
do as well.

I've just spent 3 years using SCRUM to build a CRM system after my employer
decided not to go with Salesforce because they wanted everything to match up
to how we do things. Plenty of other firms in our industry are extremely
jealous of what we've produced because it is domain specific rather than over
generalised.

------
Hominem
I am not a coach or trainer. I am just a developer trying to remain sane. I
tend to believe that any thoughtful process can work as long as you stick to
it. It just so happens I do agile/scrum.

I believe that at its core, agile is about two things. Planning on a shorter
time frame so you can react quickly as unknowns surface, and continuously
improving your process. The ceremony is meant to achieve those two things. If
you are are doing the rituals, and fail to achieve those two things, I can see
how it would seem worse than useless.

Here is what they don't tell you, it doesn't make software development easier.
In fact, it can make it harder. What it does for me is make it sustainable and
sane.

~~~
lambeosaurus
Thank you. I think you're correct. It's not about making our jobs easier -
it's about making a better product.

------
fit2rule
I've noticed, in 30 years of software development experience, that a lot of
new-fangled psychological/management "innovations" exist primarily to provide
justifications for bad behaviour.

Scrum being perceived this way is hardly surprising - its hard to develop a
methodology for anything where responsibility and control are arbitrated in a
fashion that gives the user (of the methodology) more of each component.
Taking full responsibility for things is not the same thing as having alibis
for when things "inevitably" go wrong .. if the methodology is a defense
mechanism from the damage that occurs when projects overrun, its not going to
be as effective at actually pushing projects through as it were if it were an
attack mechanism for how to make things go right, no matter what happens.
Alas, being effective versus being effected, is whats at play here. Few of us
actually want to face the fact of our own failing, unless of course we
'predict it' in some fashion, first of all - and therefore create the
conditions for failure to occur, 'comfortably'.

But like all tooling and methodology, it is a matter of the original intention
of the user that counts. If you're adopting Scrum to save your ass 'in case
things go wrong', you're doing it wrong already. If you're adopting it 'to
make things go right, and do things properly', then you're doing it right. The
only difference is the intention of those adopting the methodology.

------
quanticle
_Like committing to a sprint target. And literally doing everything to fulfill
it. Like not waiting for a manager to step in and ask for overtime and weekend
shifts. Remember? Scrum teams take all the necessary steps themselves.
Always!_

Isn't the entire point of scrum to enforce a _sustainable_ pace of
development? One that doesn't require heroics like having programmers come in
on nights and weekends to finish? The entire point of tracking time and making
burndown charts is so that you can avoid taking on too much work. If your team
doesn't have the ability to push back on the requirements and say, "Hey, this
is too much, we need to push features X, Y, and Z into the next sprint,"
you're not really doing scrum. You're doing kabuki-scrum, which is usually
just waterfall with all the meetings relabeled.

~~~
RalfR
Well, as far as I understood, Scrum's fundamental principle dictates that the
team delivers working software at the end of every Sprint.

This has partially to do with not over committing at the beginning, but if the
team fails to judge correctly, it has to do what needs to be done to fulfil
its promises.

Unfortunately, this clear obligation gets forgotten to often – as I pointed
out in the original post.

You seem to second my point.

~~~
marcus_holmes
I don't care what methodology you're using, if it includes crunch then it's
broken.

Proper, grown-up coding on a business application is incredibly wearying on
the mind, and results have shown time and time again through research studies
and professional management that past 8 hours coding in a day the average
programmer's code quality starts to deteriorate. Past 10 hours it goes
negative - at this point the code base is actually being damaged.

"doing what needs to be done to fulfil the promise" is actually alerting the
team that you've made a poor estimate of the effort required for this feature
and need to recalibrate. It is absolutely _not_ sticking with your poor
estimate and delivering shoddy code to the project.

~~~
pacala
The next time I hear "crunch" from a PM type, I'll publicly invite him/her to
lead by example and deliver a bunch of features over his weekend.

~~~
GFischer
Be careful what you wish for... I know several PM types that can match you
insane hour per insane hour - some had skin in the game (part ownership),
others were just overzealous and I know at least one burned out.

------
matthewmacleod
I actually started writing a point-by-point response to this, but it mutated
into a thousand words and will be better suited to a blog post at some point
in the future.

In the meantime, I think these are generally the same shallow straw-man
arguments against Scrum that we all see pretty frequently. I guess the key
points to bear in mind will be:

\- Scrum is not a be-all and end-all solution to all product development. If
you are developing a product for a slow-moving third-party (a case which is
described as one of Scrum's downfalls) then you are correct – it's probably a
bad choice. So is any agile approach. That is totally fine, and I'm not sure
why it's seen as a bad thing.

\- Scrum is not a fully-described, cast-iron set of rules that have to be
followed. It's a framework which can (and must!) be changed to suit the team,
and the product that's being developed. Concerns like wider-scale management
and integration of multiple projects are so dependent on the functioning of an
individual organisation that it would be ineffective to have a prescriptive
set of rules. Your 'Agile Coach', product owners and management team generally
have to deal with these issues in other ways.

\- Scrum is (apparently, based on the objections in this article) implemented
poorly in many places. For example, the 'seemingly endless series of
meetings'? That's _explicitly_ one of the things that Scrum does not
encourage! Micromanagement is the same. Scope change during a sprint as well.
That Scrum is poorly implemented is not a reasonable criticism of it, for me.

\- It's okay to fail to meet targets when delivering software, and inevitable
that it will happen. Scrum provides the tools to manage and recover from those
failures, and to help ensure they are limited in scope. Those retrospectives,
for example – it's totally valid to say 'We committed to feature <x>, and
failed to deliver it because <unforeseen dependency y> prevented us from doing
so'. The important thing is to understand what caused that failure, and how
similar failures can be prevented in the future. That's a fantastically
powerful tool to have.

Perhaps I'm just biased, because I've been working in excellently-managed
agile teams that have been delivering software very effectively, and have seen
how useful Scrum has been as a framework to manage the complexity of planning
it.

~~~
RalfR
I value your opinion, even if I do not agree with it. The argument of "Scrum
being poorly implemented" is brought again and again.

It's just another one of these go-to killer arguments.

If Scrum is so mega simple, why do we see endless cases of it failing to being
implemented correctly?

Maybe we should start thinking of a framework, that people can actually
implement and make successful, without requiring an entire army of coaches and
consultants, who make a ton of money from it.

I'd love if you'd continue the discussion over at Agile Overflow.

~~~
einrealist
We fail because it is about people interacting with each other. We fail,
because we were trained to work on our own and competitively. We fail, because
we have trouble to change our mindset and have even more trouble to change the
minds of others. This is why we will fail at alternatives to Scrum, too.

Scrum requires a different mindset. It requires us to work in a team with
honesty and jointly in order to be successful.

Teams fail at Scrum because they are dysfunctional from the start, don't share
the same mindset about their work and processes or don't embrace the ideas
Scrum provides.

~~~
RalfR
In other words: Scrum would work in Utopia?

~~~
einrealist
Do you live in Utopia? How do you get around in your environment?

Scrum is not a solution that you buy off the shelf and just run in your
company. It is a framework to manage work and scope in a team. And it
acknowledges that we are individuals who have to interact with each other in
order to achieve success. Both aspects are equally important and have to be
addressed. Scrum will not make problems disappear. But it helps you to manage
them in a transparent and controlled fashion.

Don't you live in an environment with rules (law) and frameworks (social
culture)? Is that environment perfect? I guess not. That's why we deal with
imperfections on a daily basis. Like we have to do when living Scrum.

------
drisco
My experience with scrum is that it is degrading to developers - it tries to
turn developers into interchangeable cogs in the machine, filled with
micromanagement (aka 'daily standups') and puts to much decision making power
into the hands of the 'Product Owners'.

I'm a grown up, i can make my own decisions, i can talk to clients (in fact, i
want to - no that, is not a distraction), and I don't need anyone looking over
my shoulder all the time.

~~~
codeshaman
Exactly my experience. Scrum is, above all, a system of controlling people.

Although it's defined as 'an iterative and incremental software development
methodology for managing product development', in reality it's a system for
managing power distribution within an organisation and managing dissent.

That is both a good and bad thing, depending on which perspective you want to
take. Some people love the structure and team consensus that scrum produces,
others are choked by the religious/dogmatic nature of the system.

I guess the more creative types are struggling most with scrum, because they
feel like they are not working at their full potential and hence feel like
'cogs' in the system.

~~~
killface
yes, of course it's always the "creative types" \-- they can't work in a team,
they can't work anywhere except their own sound isolation booth, and they
demand 22 continuous hours for 1 hour of flow, but they're somehow more
productive...

I'm so sick of everybody trying to cater to these crybabies. They can go work
for the government or something.

~~~
asgard1024
Ah, dammit, those creative types! Why can't they just follow orders like
everybody else? :-) (I haven't downvoted you, I am just explaining it.)

------
cc2
If you have no control over requirements and a bunch of people who can't work
together towards a common goal, I'm not sure what, if any, methodology will
work.

The main complaints against Agile by developers are: 1) I want to hide in my
technology rathole and never come out. 2) I'm allergic to accountability and
can't take people asking me once per day what I'm up to. 3) I don't want to
have to talk to other people.

So, if any of those apply to someone you're going to implement Agile with,
they're not going to be happy.

Agile is as much a cultural agreement as a methodological agreement.

~~~
asgard1024
None of these complaints is in the original post, which I agree with - the
things he talks about _are_ problems of SCRUM. Also, AFAIK the standup is not
about accountability, it's about communication.

------
RalfR
Just wanted to jump in and let you know that I do read your feedback and *
very much * appreciate it. I'm quite busy with responding over at Agile
Overflow but will eventually comment back here, too.

------
EdwardDiego
Scrum works well for my organisation.

> While they just try to focus on building software, Scrum dragged them into
> seemingly endless series of meetings called Reviews, Retrospectives,
> Plannings and Dailies.

This just caught my eye. The Scrum process as originally described had three
meetings - one planning meeting per sprint, one retrospective per sprint, and
one daily stand-up. It's a stand-up, as opposed to a sit-down, to try to
enforce brevity. It's also typically recommended to spend 5% of your sprint in
backlog grooming/refinement whatever we're calling it.

You should, of course, iterate on your process to make it suit yourself. My
team, for example, decided that we'd spread that backlog refinement over
multiple days to keep it short, sweet, and relevant. We probably spend more
time on it than 5%, but that's purely self-interest, as it keeps our plannings
short (we are usually coding by the afternoon of the first day of sprint), and
our stories well-estimated and deliverable.

But then it's hardly reasonable to complain that your modified process means
that the underlying principles are bad.

~~~
paulhauggis
I worked a remote job last year which used Scrum. We typically would have 2
hour stand-up meetings per day, A 3 hour retrospective meeting every week
(usually Friday) and 4-5 hour meetings at the end of each sprint for figuring
out what we were going to be doing for the next sprint (every 2 weeks). The
business owner would many times be figuring things out as we went along during
these 5 hour meetings..sometimes painfully slow.

This was all for a 5 person dev team. I was consistently billing more hours
for meetings than actual coding work. At one point, the owner decided to have
a meeting every Friday to just "hangout" where we would either tell a joke or
a story..to "get to know each other" (this was another hour). I was the only
American working for the company. The rest of the team was from India, Mexico,
and Egypt.

To give you an idea of the work environment, one of the other remote employees
kept overwriting all of our git checkins. They never figured out who it was
(I'm not sure why), but I had to re-do all of my checkins for 3 weeks. It was
complete chaos.

I finally quit when my business started making enough for me to survive
without it.

The icing on the cake was when the owner changed the name of the LLC a few
months ago, so all of my shares became worthless.

~~~
EdwardDiego
Yep, that sounds pretty terrible. To give you a contrast, our stand-ups take
10 minutes at worst, and our retrospectives take 3 hours every third Friday,
and plannings are about 3 hours also, again once per three week sprint.

------
mml
Agile/xp is not a set of practices. It's a set of principles.

Trainers might tell you otherwise.

------
zo1
Slightly off-topic. Does anyone know the origin of this (frankly weird)
terminology of scrum "master and "coach"?

Merits of the actual methodology aside, I just have to admit that it rubs me
the wrong way. Is it really _that_ necessary to indicate that most places
don't have scrum-like qualities in their processes, and require someone
certified to "teach" or "coach" it to them?

~~~
jordanb
I think they were trying to come up with new words for the role of "Project
Manager" and "Process Consultant" that didn't sound so waterfall-y.

------
ramses0
Scrum / Agile can have failure points both technically (code/development) as
well as socially (requirements/planning). It sounds like you've seen a lot of
social failure points in your experience.

I would hate to address all your complaints point-by-point, but I'll address
the first which leaps out to me: that of a requirements phase prior to sprint
start.

In the training I've gotten for scrum, there's an overriding principle that
you don't (nay, _can 't_) commit to work when you don't have all the
dependencies. I can't commit to building a brick wall when the bricks haven't
arrived yet.

If you have a hard requirement where you need/want to have an architecture
phase prior to sprint start then you should be staggering your architectural
planning phases with your development phases. In the current sprint you can be
working the architecture requirements for the upcoming sprint, and developing
off the requirements/design that was worked out in the previous sprint.

Overall, I think you've got some valid complaints but many that are misguided.
I worked with someone who "just wanted to code" and didn't work to grasp the
big picture. Much of what he did had to be re-done because it didn't meet the
actual customer needs.

You would likely look at that and scream: "See, scrum doesn't work! We should
have had a requirements document written 18 months ago that this code monkey
could have worked from!"

I looked at it and said: "Wow, I can't afford to babysit this guy who has all
the tools, information, and access necessary to correctly meet the customer
requirements, but consistently doesn't manage to do so."

In the first case, you have more clarity up front but less flexibility while
the work is in progress (front-loading work).

In the second case, we would have had to have two people doing the job that
one person should have been able to do (incorrect delivery was a persistent
problem with him which we worked over a year mentoring him on).

You are absolutely correct that scrum is a terrible methodology for building a
bridge. And waterfall is a terrible methodology for building a startup.

[https://crossbolt.files.wordpress.com/2013/11/when-to-use-
sc...](https://crossbolt.files.wordpress.com/2013/11/when-to-use-scrum1.jpg)

Scrum/Agile (when properly used) has two main purposes... to better predict
delivery of a particular technical capability (ie: when can I ship feature
"foo" to customer "xyz"), and focus on keeping the product under development
in a shippable state throughout the development process (ie: even though
feature "foo" isn't done, I can still ship A, B, and C with minimal
incremental work).

Waterfall is pretty much the opposite of incremental delivery, and in my
experience does a poor job of predicting delivery dates.

If you are in a problem domain where you have hard requirements up front, a
hard deadline, extremely well known technologies, then you are effectively
building a bridge.

Break out the gantt charts, put a flag in the ground that says: "We're doing
Waterfall" and be proud of it. But please try to avoid muddying the waters of
scrum when you're using a tool for something it wasn't designed for and
getting poor results.

~~~
freebish
My experience with agile/scrum is that it puts a more important bounding
function on the product/biz side, where they place demands. The most effective
scrum meetings I've seen have been where the biz side presents its desires,
then the engineers give them actual level of effort, then the biz side decides
_right then_ that they didn't care as much about this feature or that. That's
an incredible improvement over documents whizzing this way and that, meetings,
spreadsheets with LoE. Instead, just a quick meeting of minds.

"I want the blue button very, very badly." "no problem. it will take three of
us the entire scrum" "my goodness, I didn't want it that much. Ok, punted."

------
br3w5
I think the OP's mindset is flawed and perhaps had some bad
experiences/coaches with Scrum and possibly only one go at it?

I'm not sure why anyone would say "Scrum doesn't want to solve this". When
I've worked with teams new to Scrum and the question "how does this fit into
Scrum?" comes up, I'll discuss with the team and we come to a pragmatic
agreement that is right for the situation and context. Similar to TDD, I think
it's great but it's not always the right approach in 100% of situations; adapt
it to your needs.

All methodologies have their flaws and Scrum can sometimes frustrate me (I'm
not a purist) but I definitely prefer it to waterfall. Mature teams take the
bits that work for them and improve on the ones that don't. It seems the OP is
taking the methodology too literally which implies a lack of experience in
trying to apply it.

I've tried (and failed) to get a team to work on a feature as a team,
refactoring as they go. This didn't work, not because of the methodology, but
because the team just couldn't get their heads round it. We decided this was
fine and worked on UX a sprint ahead (and built this into the definition of
ready). A methodology should not have to cater for every personality and set
of skills - that's down to you as a team to figure that out.

Teams at first won't organise themselves but once they start taking true
accountability for their work (and not keep looking to a project manager for
direction) I've seen teams start to get more efficient and more motivated
because they get to take control of their work and define the process.

~~~
jghn
"but I definitely prefer it to waterfall"

I pretty sure you're not doing this here, but there's a lot of options outside
of the set of Waterfall & Scrum. All too often when scrum is debated it's
often set up in the "well, at least it's better than waterfall!" argument.
Great, that might be the case - I'd rather a kick in the ass than the nuts but
really I'd prefer neither :)

"the methodology too literally"

As the saying goes, "how big is your but" \- because everyone does scrum-but.
I'm not a fan of scrum in general, but once the but becomes large enough
"scrum" and i can be friends again. The purists drive me bonkers though.

~~~
derefr
I think when most people talk about agile, or any specific instantiation of
it, all they _mean_ is "we're going to not-do-waterfall, and then intuit the
rest, while attaching names from some methodology book to whatever results."

~~~
jghn
True, and admittedly "scrum" has become the "kleenex" and "xerox" of the agile
world. Fair point.

------
exelib
Just my point of view:

I disagree with Ralf.

Scrum is here NOT to solving ANY of YOURS problems. It's like a car - it's
give you ability to drive, but how you drive is up to you. If you can't drive
- you drive nowhere. If the street is broken - you can't drive, too.

What Scrum do, based on it's pillars (Scrum Theory,
[http://www.scrumguides.org/scrum-
guide.html](http://www.scrumguides.org/scrum-guide.html)), is ability (and
force you) to solve your own problems. Not more. OK, there are some preventive
things and some sort of problems just don't happen with Scrum (if you can
drive, of course), but it's not goal of Scrum.

And because, I think, there is no alibis at all. It's just disability to
drive.

/Scrum Master && Developer, who fight against large organization every f* day
for ability to drive/

------
qooleot
"Your Product Owner is more like a Shadow Product Onwer"

Typo with 'Onwer'?

~~~
qooleot
Hey curious about downvote (honestly, want to know why). I didn't see anything
saying that was a bad idea in the HN guidelines:

[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)

I felt the typo was one where I had to do a double-take and make sure it
wasn't some purposeful acronym. So, I posted a quick note since it looked like
the HN poster also was the article writer, and my comment would drift to the
bottom quickly and wouldn't get too far in the way of a larger discussion.

I could see maybe I should have made my comment more verbose so someone
wouldn't interpret it as being short or something? Or is there an unwritten
rule about not making quick editorial comments?

~~~
frostmatthew
> Hey curious about downvote (honestly, want to know why). I didn't see
> anything saying that was a bad idea in the HN guidelines

I didn't downvote the typo comment but I find it odd you would read through
the guidelines to see if commenting about typos is taboo but failed to notice
it says _Resist commenting about being downvoted. It never does any good, and
it makes boring reading._

------
scrumfailz
There is a reason scrum sounds so close to bum, because they are both full of
shit.

Whilst the mediocre teams in the crap organisations lurch from methodology to
methodology, paying consultants to lie to them in the vain hope of
improvement, the rest of us quietly and quickly deliver software of value to
our clients.

The only good to come from scrum is more fucked projects for professionals to
clean up later at decent profit.

~~~
rrrx3
I love that you weren't brave enough to make this comment on a legit account
and take the downvotes there. Bravo (brava?) to you.

I agree that there are teams that struggle with Agile/scrum, but those
struggles and failures generally have more to do with overall company culture
than they do with the teams themselves.

Get a good Scrum master, with appropriate chops, a spine, and good people
management skills, and you will have yourself a good scrum team. Full stop.
Halfway embrace the process by letting your dev manager run scrum, or let your
POs bully the team into things that aren't realistic, and you will have
failure. It's as simple as that. Whatever project management methodology you
choose has to be committed to fully for it to succeed. There's a reason why
Project Management exists as a job outside of software development.

And you're fooling yourself if you really think that that superheroic "more
fucked projects for professionals to clean up" line is buying you any
credibility. I've seen more fucked projects and mountains of technical debt
come out of "professional" clowns that swoop in to "fix" shit than I care to
relate.

------
oconnore
I love these threads, because you get to see a bunch of "* coaches" with a
financial stake in these ideas scramble to justify their existence in the
comments.

Popcorn time.

