
Scrum is the new waterfall - snow_mac
http://www.adambourg.com/2015/11/10/scrum-is-the-new-waterfall/
======
badloginagain
I've been at a few studios, all expounding how they're "Agile! Scrum! Fast-
Moving!" And I've seen true "agile" horror shows.

Stand-ups consisting of everyone either A) trying to prove they actually did
work yesterday in as many words as possible or B) taking this as a chance to
have a nice chat with everyone. Hour-long daily stand-ups are not agile.

The worst though was the planning meeting for next sprint, where no one had a
#$%^ing clue what they needed to do, what the priority was, where the
dependencies lay. A day every two weeks you dread.

I think the big take-away is not to do Agile for Agile's sake. Do it to solve
a problem- if developers don't know what each-other is doing, there's
solutions. Working on a product with changing requirements? Work in sprints to
be able to respond to that. But don't do it because it's what all the cool
kids are doing.

EDIT: The inverse is also true, people. It's not supposed to be a religion,
you can pick and choose practices and processes to fit your requirements. Do
what you need to do to achieve the goals you want to achieve.

~~~
kuschku
At the university where I am, we were discussing today in one compsci class
how agile is something that only works if you don’t care about consistent
quality and only care about always having the newest, shiniest, greatest.

And how, if you are working on software for ESA, or working for one of the
largest internet retailers, or if you’re writing a control software for
railway switches, waterfall is the only possible option.

Even if the target is moving, agile is never able to provide quality.

Some of my professors were hired before by large internet retailers to spend
weeks trying to understand even their business processes, as the retailer had
built their infrastructure without oversight and every employee was working on
whatever they wanted.

Just this "trying to understand what even is going on" helped them improve
their processes and greatly increase their profit margin, as they were able to
make many things more efficient with rethinking and rewriting.

 _EDIT: I’ll add my definition of quality here: Your software is able to
interact with third parties without them ever having to rewrite their
software, your software can run for decades without or with little
maintenance, and your software is well documented. In my opinion, Agile is
very ill suited for these requirements. One example is the Internet of Things,
where you can be sure no one is ever going to update their smart washing
machine_

~~~
jdbernard
That's not true. Quality and agile process are almost orthogonal. It is
entirely possible to develop extremely high quality software within an agile
environment and very possible to develop extremely poor software using
waterfall.

Agile doesn't mean "every engineer working on whatever they wanted."

Ultimately quality software results when developers place a priority on
writing correct software and when management is truly committed to creating
high quality software and all of the expense that includes.

~~~
kuschku
> Working software over comprehensive documentation

> Responding to change over following a plan

These statements from the agile manifesto are directly opposite to any kind of
quality software. Documentation and Code Quality are some of the most
important features. Your software is not working if it doesn’t exactly match
its documentation.

You can live with that in web software, but you’d end in jail if you tried to
write security critical systems like that.

~~~
braythwayt
Whenever the manifesto says “X over Y,” it does not suggest this is a strict
dichotomy. I have worked in an agile manner on software that had extremely
well-documented behaviour and all sorts of documented, objective requirements.

The expression "Working software over comprehensive documentation” simply
emphasizes what matters at the end of the day: Working software. If you need a
certain amount of comprehensive documentation to prove that the software
works, you incorporate that documentation into your process.

It’s the same as emphasizing collaboration over contracts. I worked for a
decade in consulting, I assure you there are contracts with clients even when
you use Scrum. You don’t refuse to have any hard, contracted, binding
commitments. It’s just that you prioritize collaborating with people over
setting up solitudes that communicate by throwing contracts over a wall.

As for responding to change over following a plan, if you can set up an
environment where there are no changes allowed to interfere with the plan, by
all means ignore change and follow the plan.

But if you actually have changes that matter, you need to deal with them too.
But that doesn’t mean don’t plan, or never follow any plan. It just means,
respond to changes that matter.

For example... What if you discover that the security for a piece of software
need to be updated. You’d respond to that, wouldn’t you? You wouldn’t push on
to finish what was originally planned with your fingers in your ears?

These are guidelines. They’re motivating forces. You are supposed to do it in
harmony with the hard requirements of your business and domain.

~~~
kuschku
Documentation can also be useful without working software.

For example, when you have to interface with others. They can work on the
software that depends on yours before you have even written a single line of
code, and it will work.

Software without documentation also can lead to serious issues – as in the
"does the train continue running when the signal is broken" question I
mentioned a dozen times now.

In actual critical projects, Documentation over software. The best software is
nothing without documentation.

That’s the first point where I have to disagree with it.

In many other points, agile leads to teams just carrying the technical debt
with them.

~~~
braythwayt
> The best software is nothing without documentation

You know, it’s not enough to restate your own points, you have to read and
absorb the things other people are saying.

Once again, “Working software over documentation” does not mean “Working
software instead of documentation.”

It means that working software is more important than documentation, but both
can be important. And it can be that documentation exists to make the software
work.

If I said “Working software over software patterns,” that wouldn’t mean
“Never, ever, ever use the Command Pattern, or Adaptors, or a Facade.” It just
means that you use those things to make the software work. And if they are
essential to making the software work, they are essential.

So you tell me that software is nothing without documentation, and I happen to
agree. But software is also nothing without binaries. But that doesn’t mean
“binaries over working software.” It just means, “build binaries as part of
working software."

------
andy_ppp
The best project manager I ever worked with just wrote everyone's names on the
board, asked what they were working on today, writing it on the board next to
their name. You can imagine how the next day went; "So Andrew, how did X go
yesterday, any blockers? Is it done? What are the issues, can we break this
down further?"

It's all you need.

------
cechner
I don't really agree with this - Scrum isn't really easy to do but in many
situations it is the simplest approach to take.

If you need to monitor your progress in 'real' terms (i.e., whats actually
completed) Scrum is pretty much the minimum ceremony you can get away with in
my experience.

If you don't need to do that, say if you don't have a deadline that you need
to know you wont hit ASAP, then Scrum is likely not a good fit.

> It’s boring, its old, it leads to pointless meetings run by people who don’t
> write software, who don’t understand the technical process behind writing
> software and don’t always care

I dont think these people are meant to be running scrums.

> Adhere to the sprint commitment, even if you have to work over time.

Yeah, and you will be if you dont adjust your commitments as soon as you
realise youre not going to meet them.

> Agile is about moving fast, building working software today and delivering
> with changing requirements

Yes it is. And scrum adds time tracking on top of that.

It sounds like you dont really know what the purpose of scrum is. And this is
fair enough, because I dont think they had a very good explanatory service -
it was pushed as the 'next big thing' like XML and SOAP was in the 90s.

~~~
ubernostrum
_It sounds like you dont really know what the purpose of scrum is._

Unfortunately, every response to "we tried process/technique X and it failed"
in this space is ultimately "you didn't understand it" or "you did it wrong".

So no _true_ scrum would have...

No _true_ Agile shop would have...

And where does that get us? It appears that the success rate of people
understanding and implementing these things is very close to 0%. Maybe the
problem is with the processes/techniques after all.

~~~
matthewmacleod
_It appears that the success rate of people understanding and implementing
these things is very close to 0%_

I don't think this is the case. You're likely only hearing about the failures.

Here's a counterpoint – we implemented Scrum. It didn't cause any real issues,
increased the speed with which we delivered features to customers, and
increased the visibility of everything that was happening both within the
development team and within the wider business.

Part of that was having a dedicated individual responsible for managing and
implementing that process who made sure that it was actually achieving things
we wanted to, rather than being a tick-box exercise, and who isn't afraid to
make modifications such that the process better reflects the needs of the
team.

In fact, I'd argue that the problem is completely the opposite to what you
imply – it's not that people don't implement 'true' agile or 'true' scrum, but
that they try to do so, rather than using these systems as a basis for
building a development process that works for their team. No _true_ agile team
is slavishly adherent to rules that don't work.

------
PythonicAlpha
As I experienced Scrum in practice, it is said that people should be
"empowered". In reality, something totally different is happening: People are
not empowered, but the management just delegates the responsibilities for the
project to the developers and lays back, assured that they just have to wait
for the "agile fruits" to be reaped. They have done everything, they could do,
now the "empowered" employees have to see ...

Those poor employees might feel "empowered", but in reality, they are
"impoverished". They are now responsible for the project, but often without
amble resources needed. For example, when they need additional hardware or
rooms or .... they are not empowered to get it. They are still beggars.
Instead, they are empowered to work longer hours to reach the project goals
they have set themselves. Why did they such a stupid thing? Because they
wanted to look bright or because of group pressure or because they want a
raise ...

And after they set their goals themselves, they are on their own.

This is not "empowerment", it is not about people -- it is just a good excuse
for the management to get rid of the responsibilities and to "motivate" people
to work longer hours. It is the newest "silver bullet" process of a project
management that already lost control.

~~~
yexponential
This. 1000x. This is definitely one of the pitfalls of poorly implemented
scrum. For bigger companies, scrum tends to be a decision by the higher ups
and implemented by the lower ranks keeping middle management is disarray over
their role in the change. Moreover as the author mentions agile is about
people first, but followed by processes. If scrum teams don't have the power,
or empowerment, to change the processes, to become more agile, to remove
blockers/impediments, the team burns out / self destructs for the precise
reason you mention about spending longer hours achieve the committed (not to
mention the committed is affected by the deadlines which are manipulated by
management/or worse, external stakeholders) in order to uphold their
word/project. To me there is a flaw here.

I do believe scrum can be an effective tool for a few use cases, but people
often underestimate the warning signs. "Scrum is easy to learn, but difficult
to master." \-
[https://www.scrumalliance.org/community/articles/2011/may/sc...](https://www.scrumalliance.org/community/articles/2011/may/scrum-
from-student-to-master)

~~~
snow_mac
This is really the heart of it, I've really only worked in environments that
have been top down as their implementation of scrum. When the engineer team
got to decide, we picked Kanban. The lightest process for us.

Scrum top down. I buy that. Bottom up? I'd give it a try, but the team needs
the ability to say "no".

------
mmanfrin
Scrum works fine when it's just programmers. Scrum and Agile become shackles
when management gets involved and sees it as a status-checkup for their top-
down view. The latter scenario seems to be 90% of situations, unfortunately.

------
bkjelden
The fatal flaw of any process - scrum, kanban, waterfall, etc, is when
engineering teams try to use them as a replacement for communication rather
than as a communication aide.

~~~
Laaw
Yep. Process is compensation for lack of talent, which may sound cruel or
arrogant but it's not. If you're great, you can self direct, design, and
implement what needs to happen in your project with no help or management at
all.

It's totally okay not to be great, but when you're not great you need help,
and help comes in the form of management, and management needs a way to set
and manage expectations. Agile is one way, waterfall is another.

------
kaspm
I don't understand why this is on the top of Hacker News. It seems to be one
person's opinions and experiences about complex issues that face hundreds of
thousands of engineers in thousands of companies across the world.

Nothing in the article makes me trust this persons perspective over any other.
It's not thoroughly investigated with metrics over many case studies. There's
no empirical evidence to back up his assertions. He doesn't have a reputation
for other work that would make me trust his informed opinion over any others.

There seems to be hundreds of articles touting every possible side of this
issue, why did this one strike a chord?

~~~
snow_mac
Your right, I presented no evidence. Honestly it was a rhetorical post that I
did not expect to strike the cord that it did.

------
plet
Whats wrong with waterfall? Surely mis-using waterfall was the culprit. I'm
guessing same goes for Scrum. I've never followed true scrum so my opinion
might be jaded however the devil generally lies in the implementation of the
process.

You cannot fit the same tire on a truck and a kid's tricycle, same way you
cannot fit the same process for all development cycle. If you team needs clear
direction and everything well defined (written in stone), follow waterfall. If
your team needs formal process but can do some things on their own (say a team
filled with new hires and one lone experienced dev), scrum might not be so
bad. Kanbaan is good when everyone knows what they're doing and you really
just want to know which stages do you need to focus more on.

You're best bet is probably to try all three and whatever else exists, mix and
match until you can successfully deliver your products without a whole lotta
overhead and then keep tweaking the process when conditions change (new hires,
folks leaving, change in goals/features).

~~~
anon4
Waterfall is literally a strawman methodology made up to illustrate the worst
possible way to build software (short of having a million monkeys trying
random programs), in order to serve as contrast to a way that actually works.

~~~
plet
I wasn't really going towards defending waterfall[1] but lemme give it a try.

Waterfall might be not bad when you cannot have feedback mechanisms, you
cannot roll out changes in phases, where requirements/scopes are fixed, tech
stack is well defined and products have matured enough.

[1] : wanted to more say, use the right tool for the right thing in the right
way. I don't think its easy but its doable.

------
carsongross
It's amazing to me the lengths organizations will go to avoid the one thing
that actually works: hiring a small team of really good developers, paying
them a lot of money and giving them hard ship date.

~~~
rev_bird
That seems like laissez-faire waterfall to me. The problem with the "hard ship
date" is that it usually comes with a set of expectations for what is ready on
that date: If you need software X on July 1, what happens when software Y
becomes more necessary on April 15?

~~~
carsongross
A hard ship date and flexible requirements is the way to do it: you force the
issue and require your (great) developers to immanentize the software. It
clarifies the mind and, assuming you didn't start off with absurd goals
anyway, you get most of what you want.

Most importantly, it gets you to ship.

------
lordlarm
But then you're working in a bigger business where you do actually need to
interact with managers and internal/external stakeholders. And they're all
asking you: «When can you deliver?».

Yes, estimating is hard. It's impossible really, but everyone knows this and
accept the consequences of delayed deliveries and blocking events. But they
want status updates and delivery schedules all the same.

Pointless exercise maybe? But in real life and in business actually having
someone thinking longer than three days ahead is usually a necessity, in my
experience.

I agree though that you should minimize the amount of pointless meetings and
solve blocking issues as they come - this is more a sign of a good tech lead
and healthy work environment rather than weaknesses in the Scrum methodology.

------
antiffan
Scrum at its core is about setting your team up to LEARN and improve by
introducing feedback cycles.

That's it.

If your team learns after one cycle that they are more effective without one
of the common ceremonies, then your team should drop it.

The problem that Adam is observing is not with Scrum itself - it's that too
many miseducated managers lose sight of the point and are obsessing over the
wrong details.

Source: I have been on extremely successful Scrum teams, I have seen Scrum
done properly dramatically transform "stale" teams, and I have trained with
Jeff Sutherland, one of Scrum's founders.

------
calinet6
Any system implemented without an understanding of how systems work, and how
humans interact with them, will be painful.

We need systems thinking, not any one prescribed process.

~~~
dragonwriter
> We need systems thinking, not any one prescribed process.

Problem is, its hard to get people doing systems thinking, _especially_ about
systems they are part of.

~~~
calinet6
It's hard, but it's the only problem remaining.

------
FatalBaboon
Straying away from any consideration of "how well agile was implemented", I've
never been at a shop that seemed to get any real advantage by saying they are
"agile". Although my experience is only 4 shops on that matter.

I would argue that since the method is deliberately left unclear, in reality
it mostly profits to whoever wants to game it to his/her advantage. And if
everybody wants the project to succeed as their respective primary goal, then
you do not need such methodology anyway.

Do whatever seems to work best for the team, and don't name it. Don't waste
time writing blog posts about how you found a new groundbreaking way to work,
as these matters are subjective.

For example, now I work by asking whatever needs most attention right now,
getting it done, and then asking again. No backlog, no notes anywhere,
nothing. If we forget about something and it is important, it will come back
up. It has no name and it works perfectly for us!

------
matdrewin
Similar to choosing a web framework, most often the issue is with the people,
not the methodology/framework.

------
a3n
I'm at a small BigCo. We have a few pilot agile projects. Based on what I see
them doing, and what I read in the article, it looks like scrums are two week
death marches.

------
dbg31415
This is so negative.

Look... the process can't be, "Hey you get all the time in the world to build
undefined requirements with out providing any sort of insight." The reason you
let people who don't code in to the meetings is because they pay your salary
-- right? So translate. Give them something that makes them feel you are
spending their money correctly.

It's not all that hard to just define requirements, put a line in the sand for
what you think you can get done in a two week block, and show your progress on
a board -- is it? This article seems to take the stance, "Devs are the only
ones who matter and everyone else is someone who is going to make me sit in a
meeting I don't want to be in." It's really immature to think this way, and
short sighted.

You need some sort of process, some sort of roadmap, so your sales and
marketing team can drum up interest for the product and the team can be
successful growing the business. This isn't an academic exercise, it's a job,
and you work on a team that requires communication to operate.

~~~
6d0debc071
If the primary way information flows between teams in your organisation is by
throwing everyone in a room on a bi-weekly basis, you don't have much of an
organisation. That's not professionalism, it's bad management under the
heading, 'better than nothing.'

------
je42
If you got a bad development process it doesn't matter how you label it SCRUM,
Waterfall or Kanban.

The main is issue is to implement SCRUM properly. If I have seen it both ways.
The difference is like night and day.

------
parasubvert
The problem is that Scrum is rather lukewarm agile. It's mostly about toe-
dipping, not making big changes in how you think about how you work. It _can_
lead to this, but it just really often doesn't.

Firstly, Scrum too often becomes the waterSCRUMfall - you don't deal with the
problem end-to-end, you insert a version of Scrum in the middle of a broken
organizational context.

Secondly, Scrum also mostly has a lot to say about team organizational
structure, reporting, and process (which managers like) but not so much about
software development practices (which help you do your job). This can lead to
busy work and misinterpretation from those who "manage" software rather than
those who "do" software.

Thirdly, I have a theory that a lot of the fallout from Scrum and agile not
working is due to people trying to find something easier to digest than
Extreme Programming, which includes nearly all the development practices that
scrum teams pick and choose. Once you look for something easier to adapt to,
meaning you don't have to change everything, it becomes easier for agile
consultants to keep modifying the already lukewarm process to be a 10%
improvement of the mess you already have rather than a leapfrog replacement.

And the few times a leapfrog is OK, it requires a lot of organizational air
cover and buy-in, top to bottom, because you can't "force" people to work in a
very different way without it being rejected.

My view is - if your approach to building software is broken, and you want to
do something different, you have two choices:

a) build a process organically from the top down and bottom up simultaneously
- perhaps a mix of Kanban for change management, and individual development
practices that the software teams & senior developers want to do.

b) if you have the willpower and lack the knowledge or patience, adopt a "more
extreme" agile method like Extreme Programming, and complement it with
organizational change management techniques like Kanban. And ensure you have
people or partners that can really help you with it (at all levels - not just
as "coaches").

Finally, Kanban is not a software development process. It's a change
management process. You an evolve a software development process out of Kanban
and picking/choosing from other ideas from XP or others. Kanban is good in
that it allows you to tailor an approach that deals with "big picture"
organizational change issues first -- trying to do too much and piling up
requirements inventory or work-in-progress. But it doesn't say anything about
how to build software.

------
j_mcnally
Where do I send my money! Scrum is the worst! Kill Scrum

~~~
snow_mac
This made me laugh. Send money to adam dot bourg at gmail

