
A brief list of what Scrum gets wrong - aard
https://medium.com/@ard_adam/why-scrum-is-the-wrong-way-to-build-software-99d8994409e5
======
gregdoesit
Scrum isn't good or bad, but the way the OP (or their company) uses it seems
to be a reflection of an inflexible culture.

For example, the OP argues how scrum strips engineers the autonomy they need
to get the job done and how it's super inflexible. When we did scrum with my
team, the scrum master role was rotated among engineers, growing each of us
significantly as professionals. We also made changes to the "core" of scrum
after our retrospectives when we decided it was stuff that did not work for
us. When management tried to use story points for tracking or forecasting we
told them to forget about the whole thing. We added bugfixing sprints after we
observed the bugs piling up.

I can go on - we made scrum work in an environment where we were empowered to
do what makes sense. The crux of the post seems to be that OP has some very
rigid management and devs cannot change the mindset.

Instead of complaining about scrum, I suggest the OP either try changing the
culture from the team level. Or if it won't work, just get out and work at a
place where there is sane management who does not drink the rigid scrum kool-
aid. Luckily, there are more and more places like that these days.

~~~
jstimpfle
> Scrum isn't good or bad

I must have heard this at least a dozen times in the last months. OOP isn't
good or bad, Exceptions aren't good or bad, Scrum isn't good or bad. It makes
me mad. Guys and girls! Software is not a contest in being liberal and
tolerant. There are methods and techniques that are objectively better than
others in reaching most of the goals that are important. You wouldn't contest
a F1 driver on a bicycle - not on a race track. And engineers who really know
their stuff usually agree on how to build software in a given domain. I do not
know of any success stories using Exceptions on Kernels or RDBMSs or even most
server software. But I know people have tried, and even they agree it was a
bad idea.

If you want to say Scrum isn't good or bad, depending on how you tweak it so
it sucks less, then I say it's definitely bad. It's not a solid method that
helps you reliably reach your goals.

If you want to say Scrum isn't good or bad unless metrics are defined (that
doesn't seem to be the case here), then you are right, but it's a meaningless
statement.

~~~
ploxiln
> OOP isn't good or bad, Exceptions aren't good or bad, Scrum isn't good or
> bad. It makes me mad.

It's all true though. Do whatever you want, all that matters is that you do it
_well_ \- you just can't simplify a good software engineer down to techniques
like these.

I recommend reading this piece from a guy who studied software development
methodology for over 20 years:
[http://alistair.cockburn.us/Characterizing+people+as+non-
lin...](http://alistair.cockburn.us/Characterizing+people+as+non-
linear,+first-order+components+in+software+development/v/slim)

~~~
spookthesunset
The thing is, what is the alternative to a scrum process? I see so many shops
with zero defined process constantly re-invent project management wheels that
were solved a long time ago. Start from a known place like scrum and then
adapt it to your team and organization.

We standardize around protocols, frameworks, programming languages, etc
because adding constraints and processes make a problem much easier to solve.

If not scrum, what? Where do you start?

~~~
user5994461
Kanban, gantt, unified process, extreme programming, trello, rfc.

There are plenty of methodologies and tools that can replace or complement
Scrum.

~~~
SAI_Peregrinus
Or even the engineering design process. Every ABET accredited engineering
program teaches it, and while there are minor variations in the specifics it's
always broadly the same. It's worked well in the engineering disciplines for
decades & produces reliable products. There's no reason it can't work well for
software, only an unfortunate case of "not invented here syndrome".

------
wilkosez
I agree 100%.

Thankfully I dont do agile any more, but I'm close to several teams that do.
My fondest memories are:

No over-arching design (Implement feature after feature however the hell
anyone likes) Once said features are implemented, taking the time to
"refactor" (read: completely rewrite because the code was so bad) becomes a
really hard sell.

Thus, new features get progressively harder to implement, as you touch a
deeper cross-section of the code to try and fix stuff semi-covertly, without a
formal refactor.

"Tech Debt" was done in sprint scheduled after phase of dev sprints. After,
say, a year of development, lets fix all the problems in 3 weeks... When
you're dealing with procedural php masquerading as OO, MVC with business logic
everywhere it shouldnt be, and abuse of inheritance such that you cant throw
an error in a command line because you're not a logged in browser user, who's
had their language queried from a database, and doesnt fall back to default
when the db isnt there... 3 weeks isnt gonna cut it!

Introducing peer review was supposed to sort that, but bad or inexperienced
devs didnt know they were doing shoddy work (it met the criteria after all..),
and good devs became impediments because so many stories needed redoing.
Demoralising.

We were probably "doing agile wrong". But it's like a religion: open to
interpretation. In my experience it's a tool used to extract maximum customer
benefit at the expense of the developer's soul, under the pretence of "self
managing team" \- ie. "You brought it on yourself".

~~~
spookthesunset
> Once said features are implemented, taking the time to "refactor" (read:
> completely rewrite because the code was so bad) becomes a really hard sell.

This should be a hard sell. The code in production works. Why does it in need
a rewrite? The fact it needed a rewrite in the first place doesn't really
reflect on scrum but on poor engineering and management practices.

~~~
wilkosez
"The code in production works"

This might be what I have the biggest problem with. To a customer, it works.
The customer is happy, they pay their money, which makes management happy, and
we all get paid. So the site takes 10 seconds to load on certain pages, who
cares! It works, right?

Behind the scenes, there's a fleet of web servers burning CPU so add some
more! A database that's overwhelmed, throw some more CPU/mem and faster disks
at it! Maybe optimise some queries if you can get it into sprint. But a
fundamental problem with the implementation itself cant be fixed, because "it
works". Want to leverage some slave dbs for reads? Sorry, no time for that
because unpicking the backend would take too long!

It's backwards. In my idealised view: Good design first = better code = less
resource hungry = less cost for servers = support more users = more revenue =
less time spent working around crap = more time to implement features! = more
revenue = better wages. Everyone wins.

Imho, agile doesn't help make this happen.

~~~
cbsmith
Again, there's a ton of wrong here...

If you really have a fleet of web servers burning CPU and you arne't tracking
the costs, then I guess "it works" until someone figures out there isn't any
money left in the coffer.

There is a lot of value in working software, and unless your engineering
infrastructure expenses seriously outweigh your engineering payroll costs
(which does happen, but is hardly commonplace), CPU efficiency isn't the be-
all to end-all and focusing on it may well prove to be counter productive. If
no one actually cares about your page load times, it may very well be that it
doesn't matter. You can spend a near infinite amount of time & resources
trying to get optimal performance (talk to someone who does high-frequency
trading to get a sense) well past the point where the costs pay off.

There is tremendous value in "it works" that engineers generally struggle to
fully factor into their thinking (I come by this wisdom honestly). People have
written about this extensively (e.g.
[https://www.joelonsoftware.com/2000/04/06/things-you-
should-...](https://www.joelonsoftware.com/2000/04/06/things-you-should-never-
do-part-i/)). That said... the notion that you can't fix actually serious and
counter-productive problems with the product because "it works" sounds not
only counter to Scrum, but really counter to any software development
methodology I've ever heard of.

~~~
wilkosez
> If you really have a fleet of web servers burning CPU and you aren't
> tracking the costs, then I guess "it works" until someone figures out there
> isn't any money left in the coffer.

What if the costs are fixed? (own servers, unmetered bandwidth) The problem
shifts down the line when you want to add a new product and the first product
is consuming all your resources. Refactoring then becomes a necessity, but
there's no capacity for it because the company is focused on shiny product #2,
while also adding shiny features to product #1. Now fire a few people to save
money, leaving the remainder short handed, who get stressed and demoralised.
But that's ok, because "it works!". Why cant we design first, lay down a good
foundation, _then_ add features. The business makes more money, people keep
their jobs, instead of spit-balling "user stories" at an application which
becomes a giant spit-ball.

> CPU efficiency isn't the be-all to end-all and focusing on it may well prove
> to be counter productive > You can spend a near infinite amount of time &
> resources trying to get optimal performance

I used CPU as a broad example. What happened in my case was there was _no_
performance. At release it was unusable. What stuck in my side was I knew it
was going to happen, and had been calling for refactors. But if you cant get
them prioritised because you cant justify the customer benefit (it's not
released yet, so nothing has fallen over yet) vs features! features! features!
it then becomes a bodge job /after/ release. eg. Instead of "refactor this
code to make it do fewer queries" it's "lets shove the results of these
queries into a memory cache." This satisfies agile, you've iterated and made
things "better" \- and it fit into a 2 week sprint! - but it feels backwards.

I was going to go on and talk about quantity vs quality, but a quick fact-
check google revealed the evangelists with their "Agile parables" (it even
sounds cultish), which are in no way perpetuating Agile to sell support tools,
say I'm wrong.

I need to thank you for making me realise it's time for a career change. After
all this time Agile has failed to convince me, I'm inclined to conclude it
never will. But should the next methodology of the moment come along that
emphasises quality over quantity, I reserve the right to shout "I told you
so!"

~~~
cbsmith
> But should the next methodology of the moment come along that emphasises
> quality over quantity, I reserve the right to shout "I told you so!"

Again, your problem isn't coming from the methodology. The priority on quality
comes from the context, not the methodology. I have a friend who does
presentations on agile all the time and his team prioritizes quality pretty
much over anything simply because it allows them to develop faster.

~~~
PaulRivers
The agile methodolgy claimed we needed to switch to it to increase quality.

Quality got worse.

In this scenario it's the fault of agile, as the reason for doing agile was to
increase quality.

~~~
cbsmith
"The agile methodology" doesn't really make claims about what a specific group
of people need to do.

It's a tool/methodology that can help you increase quality.

If quality isn't a priority, a methodology that helps to better align your
work with your priorities isn't going to improve quality.

------
lumost
Having been a manager, PM, and lead engineer this article really resonated
with me. Scrum has a brief window of utility if a team isn't delivering at
all, and has lost management trust. It also has a large window of dis-utility
where everyone haggles over points, shows velocity as results, and leaves
customers and businesses wondering what their engineers are doing. Trust your
engineers to do the right thing on their own and they might just surprise you.

~~~
ebbv
What does “trust your engineers to do the right thing on their own” look like
to you? And how is that stopped by SCRUM?

For the way we do it, when a stakeholder wants our team to do something, they
come to us with user stories and acceptance criteria that matter to them. Then
we hash out the rest of it. I don’t really see a useful way we could be
trusted more. The Marketing department knows best what feature it is they want
on the website, and why. So they specify that part. We estimate complexity and
the business weighs the priority of that feature against other stuff in our
backlog and it falls into an appropriate sprint based on that and other
motivating factors. Then we do the work.

I don’t see a lack of trust? So I’m curious where you see it and feel it
should be done better?

~~~
stctgion
Perhaps they meant when the engineers decide the the priority of the features
and maybe even define some features themselves

~~~
ebbv
If your company isn’t tiny your engineers generally shouldn’t be deciding
priority. Unless your company is small enough that the engineers have a clear
view of all the priorities of the business all we are capable of is saying
“This seems really important to us.” And then that has to be weighed by people
who have the bigger picture.

But outside of a very small company to me it’s a bigger crime to waste
engineer time with all the meetings necessary to give them that full
perspective. When I started at my current company I was the only developer and
I worked directly with the CEO and our single marketing person. Back then I
helped decide priority. Now the company is too big for that. I don’t have time
for all the manager and marketing and business planning meetings to be able to
decide priority.

As far as defining features, we can propose them like anybody else but I think
I already explained why usually it makes sense for them to come from whoever
owns that piece of what you’re doing. But this of course again depends on the
structure of your company.

------
evfanknitram
Meh... All of these items are more or less misinformed so I'm just going to
bring up one.

> Because all product decision authority rests with the “Product Owner”, Scrum
> disallows engineers from making any product decisions and reduces them to
> grovelling to product management for any level of inclusion in product
> direction.

The product owner is part of the scrum team. She or he is responsible for the
backlog but if she has trust in the engineers she can let the engineers add
their own things to it.

I think OP just works in a bad place.

~~~
kasey_junk
If OP worked in a “good” place where product managers & engineers trust each
other to do those tasks, what value does Scrum bring?

The process is there to account for the places where the people fail. If a
requirement of a process is unfailing people then it’s not a valuable process.

~~~
matthewmacleod
_The process is there to account for the places where the people fail_

That's just wrong. It's there for lots of reasons – to help avoid failures and
surprises, to deliver sustainable pace, to help make estimations, to ensure a
common understanding of problems and challenges… the list goes on.

Scrum doesn't require infallible people – it's just a tool to help avoid
failures, which happen regardless of the skill of your team.

~~~
kasey_junk
I’ve not found that to be the case. In fact on at least 2 occasions in my
career adding scrum practices to a product team essentially destroyed them.

I’ve seen instances of all of the items the article claims being problems in
practice. That was across a wide variety of teams & skill levels.

I’ve also seen no evidence in the literature or research that backs up your
assertions.

I’ll concede some teams have benefited from scrum practices, but in the face
of my anecdotal experience & the lack of data forgive me for being skeptical
of a practice that seems largely around to keep process consultants in
business.

I’m certainly not receptive to a defense that someone who criticizes it just
works at the wrong place or hasn’t seen “real” scrum.

~~~
matthewmacleod
_In fact on at least 2 occasions in my career adding scrum practices to a
product team essentially destroyed them._

Why was Scrum added to these teams if they were already working? It's a tool
to deal with problems. It's not something to use if another process is already
working.

 _I’ve seen instances of all of the items the article claims being problems in
practice.

I have found essentially the exact opposite of all the problems that are
claimed to exist, and I've equally seen no research to confirm that they
somehow destroy teams.

_my anecdotal experience & the lack of data forgive me for being skeptical of
a practice that seems largely around to keep process consultants in business

My experience directly contradicts that. Every Scrum-ish team I've worked with
has had a pretty steady pace of development and produced good software. Some
other processes have worked too; the worst I've seen are fake-agile-actually-
waterfall processes.

 _I’m certainly not receptive to a defense that someone who criticizes it just
works at the wrong place or hasn’t seen “real” scrum._

There's no such thing as 'real Scrum' so I won't use that defence. A good
process is one that works for the team and company. Scrum is not a universal
solution; for extremely high-performing teams it's probably overkill; for
bureaucratic teams it will crush everything. It's just another good tool to
use where appropriate.

~~~
kasey_junk
Usually scrum seems to be added for the sake of ‘predictability’

But nothing about the process fundamentally change the problems with software
estimation. So in cases where teams are delivering rapidly at high quality but
unpredictably, scrum acts as a place to hang paperwork & as a process to hide
bad project managers. All while lying to management with charts.

~~~
cbsmith
> But nothing about the process fundamentally change the problems with
> software estimation.

I'd argue quite the contrary.

> scrum acts as a place to hang paperwork & as a process to hide bad project
> managers. All while lying to management with charts.

So weird. The "paperwork" tends to make bad project managers all too
transparent.

~~~
kasey_junk
You'd be arguing against research in that case. Software estimation is a
widely studied subject and no estimation technique we've found has brought
projects into the 'predictable' mode.

There are a few different estimation techniques that are better than others
but scrum actively avoids those techniques (probably for the best as they are
expensive and don't show huge gains over other forms of estimation).

Instead scrum attempts to track a made up velocity number by using any number
of known to be inaccurate estimation techniques. It then gets hyper focused on
breaking down tasks into small enough tasks that the velocity number stays
constant, all while forgetting about the real desire, the quality software the
business desires, delivered to paying customers. At that task, scrum has
proven to be no more predictable than any other technique.

An enlightening exercise for any project manager is to go to a sales team and
explain what you are delivering in a given sprint. Almost always, they won't
care at all about that, and will instead ask for when some 'major epic' thing
will be done, at which point you won't be able to tell them with any more
certainty than if you'd just guessed.

Thats the best case. The worst case is that all that work you put into showing
transparency around velocity ends up being used against the teams working on
the hardest and most innovative projects in your organization. Their velocity
will be all over the map while the maintenance teams will look good. You'll
have convinced the leadership of the organization that velocity is a real
number to track (cause you spend so much resources tracking it) and the
incentive structures will reflect it. You just made it worse for good
engineers to join the teams solving your hard problems.

~~~
chris11
> There are a few different estimation techniques that are better than others
> but scrum actively avoids those techniques (probably for the best as they
> are expensive and don't show huge gains over other forms of estimation).

What methods would you suggest for software estimation then?

~~~
kasey_junk
I wouldn’t do it. Prioritize your backlog, work on the most important things,
reprioritize at your planning meetings.

Invest in going fast, reliability & figuring out priorities. There are lots of
agile methodologies that abandoned the estimation step for the reasons I
mention (fdd,rad,dsdm).

------
amarkov
Respectfully, I'm not sure the author understands what he's talking about.
He's arguing for the no-op process where engineers determine all their own
tasks and priorities - and I mean, I'd like that too. But there's a
fundamental difficulty in aligning each engineer's personal goals with those
of the company, and some amount of management or organizational design has to
go towards addressing it. Engineers won't just naturally align with the
organization if nobody rewards us for doing so.

> Do managers or Product Owners track and estimate every task they engage in
> with little or no say in what they work on?

> Are they required to present burn down charts that show that they are on
> target to finish?

> Are they required to do bi-weekly sell-off meeting to justify their
> activities?

These things are in fact the primary responsibilities of managers and product
owners.

~~~
bassman9000
_Engineers won 't just naturally align with the organization if nobody rewards
us for doing so._

Hoes does Scrum reward the engineer for such alignment?

edit: grammar

~~~
rossdavidh
Theoretically, Scrum is a way to say 'work on this, because it's what aligns
with the organization'. But, of course, whether it really does or not depends
on who is implementing it and how.

~~~
bassman9000
Scrum telling you how to align with the organization is not rewarding the
engineer in any way. Orthogonal concerns.

How does Scrum reward the engineer, in a way that it does it better, and more
profoundly, than other methodologies?

~~~
amarkov
When you let engineers run around doing our own thing, we never have to show
that the work we're doing _is_ the most productive use of company time. We
just have to show that it plausibly could be. Nobody will hesitate to reward
the well-liked engineer with a cool sounding project, even if other things
would really be more important.

As the author noted, Scrum solves this problem by making number of story
points completed the primary tool for a team to measure its productivity. If
the cool-sounding project isn't important enough to take other items out of
the sprint, there's no way to offer a post-hoc justification for doing it
anyway. It has no story points, so work on it is considered non-productive.

------
wnevets
I've found that "certificated scrum masters", "certificated project managers"
and their ilk are the problem. Anyone who says we must follow a specific
process because that is how agile development is done is missing the point.

The actual agile manifesto makes a lot of sense IMO.

[http://agilemanifesto.org/](http://agilemanifesto.org/)

~~~
bassman9000
Does it? E.g.

 _Welcome changing requirements, even late in development. Agile processes
harness change for the customer 's competitive advantage._

Everyone has deadlines. Either customer imposed ones, or the market running
against you. At some point, you'll have to meet them. When do you stop
accepting changes and deliver? Can you welcome last minute disruptive changes?
Sure. But the market won't wait for you to implement them.

 _Deliver working software frequently, from a couple of weeks to a couple of
months, with a preference to the shorter timescale._

Some tasks require longer attention spans. This is the classic technical debt
accumulation choke point. Now, iterations + deadlines make sense. But does it
have to be a fixed 2/3 week period, always? Where the flexibility in that?

 _Build projects around motivated individuals. Give them the environment and
support they need, and trust them to get the job done._

To be fair, I've only seen Scrum. But this point is in direct contradiction.
Scrum is about diluting the individual. Everyone is a replaceable resource.

 _Agile processes promote sustainable development. The sponsors, developers,
and users should be able to maintain a constant pace indefinitely._

This is just wishful-thinking, the Agile Point. The only remotely close way of
doing this is turning everyone into cogs in a machine. No, thanks. Weren't we
valuing the individual?

 _Continuous attention to technical excellence and good design enhances
agility._

And takes time. Ops, sprint's time is over. I guess that refactoring can wait.

 _The best architectures, requirements, and designs emerge from self-
organizing teams._

Some of the most successful products and projects (Linux, Python, Apple)
revolve around strong leadership.

There are definitely good ideas in this manifesto. Ideas that have been
applied for years, before even the manifesto came to be. Some others are just
wouldnt-it-be-nices.

~~~
matthewmacleod
Yes, it does.

 _Everyone has deadlines. Either customer imposed ones, or the market running
against you. At some point, you 'll have to meet them. When do you stop
accepting changes and deliver? Can you welcome last minute disruptive changes?
Sure. But the market won't wait for you to implement them._

There is no point in delivering software which doesn't meet customer
requirements. If changes to software are required because it doesn't meet
requirements, pretending otherwise solves nothing. Agile processes make it
easier to cope when these changes happen, and accept that if change is
required then other constraints have to move – such as deadlines.

 _Some tasks require longer attention spans. This is the classic technical
debt accumulation choke point. Now, iterations + deadlines make sense. But
does it have to be a fixed 2 /3 week period, always? Where the flexibility in
that?_

Most tasks do not require 'longer attention spans', whatever that means.
Almost literally every task can be broken into smaller parts with minimal
effort, helping to expose implementations to scrutiny at earlier stages.

And while Scrum traditionally has a fixed sprint length, there's no
requirement to follow that to the letter. If your constraints are such that it
doesn't work, then adjust the process to suit.

 _But this point is in direct contradiction. Scrum is about diluting the
individual. Everyone is a replaceable resource._

No – Scrum is about the _team_ of individuals. Depending on a single
individual is obviously stupid regardless of what process you use.

 _The only remotely close way of doing this is turning everyone into cogs in a
machine._

Not at all true. A nice sustainable pace is reasonable for any team of skilled
professionals. If you are not achieving it, your team is broken.

 _And takes time. Ops, sprint 's time is over. I guess that refactoring can
wait._

And pretending otherwise does nothing. Make refactoring a requirement for
completion, and you will avoid this problem.

------
nulagrithom
Don't tell me why Scrum sucks. That's really not useful to me.

Show me a better system instead.

~~~
user5994461
Call it Kanban, it's exactly the same thing but without all the certifications
and consulting services around it.

[https://thehftguy.com/2017/12/06/scrum-vs-kanban-arent-
they-...](https://thehftguy.com/2017/12/06/scrum-vs-kanban-arent-they-the-
same-thing/)

~~~
richliss
You're incorrect.

Scrum is a framework. Kanban is a method of implementing a system.

Here's Kanban creator David J. Andersen's own words:

[http://www.scrumcrazy.com/David+Andersen+-+There+is+no+kanba...](http://www.scrumcrazy.com/David+Andersen+-+There+is+no+kanban+process+for+software+development).

Also Kanban has certification:

[http://leankanban.com/team-kanban/](http://leankanban.com/team-kanban/)

And consulting services around it:

[http://leankanban.com/project/services/](http://leankanban.com/project/services/)

~~~
user5994461
They're both a basic TODO list with a fancy commercial name.

------
notacoward
One under-appreciated shortcoming of Scrum is that it doesn't deal well with
dependencies on other orgs that have their own schedules and probably don't
use Scrum themselves. We ran into this at Red Hat, where the other org is an
external open-source community. You do your work quickly like Scrum forces you
to, submit the work upstream, where people not operating under Scrum's
artificial time pressure ignore or reject it. Hardly surprising, since quick
often means dirty. In any case, you have no control over how long it takes
that process to complete, let alone when the new code gets into an upstream
release so you can pull it back in. What always ends up happening is that
developers have to take on more work in progress while code works its way
through someone else's process. If it's done officially it's no longer really
Scrum. If it's done unofficially it's still no longer really Scrum, and even
worse the time spent shepherding patches upstream is invisible to the Scrum
planning process.

Maybe Scrum works when you're a passive consumer of the frameworks, libraries,
etc. that you use, with no expectation that any significant time will be spent
contributing back. I don't know; I haven't worked in that kind of environment
for a very long time. That only seems like a tiny segment of how real
development gets done, though.

~~~
ebbv
I don’t see this as really an issue. When your work is done it’s done. If it’s
someone else’s work that needs to be done now before you can do something
else, those should be separate issues/stories/tickets that are blocked until
that external work happens.

In my mind it’s no different than waiting on a design or pricing sheet or API
key or any other dependency that holds up work. Yeah you might have to context
switch to something else for however long you are waiting but that’s what
happens.

Also why the “do your work fast like SCRUM forces you too”? SCRUM doesn’t mean
do your work shitty and fast. Maybe your organization wants it to but whether
you prioritize speed or doing it the best you can or whatever is up to you, I
don’t see that as part of SCRUM.

~~~
notacoward
> When your work is done it’s done

Have you ever worked on open source? Getting code accepted upstream is not
somebody else's work. It usually involves significant ongoing effort _by the
author_ on top of what they did to implement and test the code in the first
place. That work is usually very interrupt-driven too, responding to review
comments etc. whenever someone upstream happens to wake up, and that makes it
even worse. Your "separate issue" idea is exactly how Scrum fails to account
for real work in progress when open source is involved.

~~~
ebbv
If that work is non-development work like writing emails or getting in
hangouts or Slack conversations or whatever then you’re right it doesn’t get
tracked in SCRUM tickets/issues/stories (typically.) but that’s fine. Because
it should be reflected in your velocity automatically by the reduced
development work you can accomplish.

If it does result in development work; like your pull request results in
revisions. You have choices about how to account for that. If you feel you
have confidence about how much extra work that will add based on the issue
you’re working on, you can account for that when pointing it. (Much like you’d
account for writing tests or going through code review process within a team.)

If you have no handle on how much work it takes for whatever reason
(contributing to multiple projects with wildly different expectations) then
you can make new issues for each set of revisions. This will give you clear
history that you can reference afterwards and learn from.

In any case; it’s a poor craftsman who blames his tools. SCRUM can work for
all these situations if you want it to. If you have a defeatist attitude or if
you prefer to blame systems and tools for your problems instead of finding
solutions, you can do that too.

Let me be clear; I’m not saying SCRUM is for everyone or the best system or
any of that. I’m just saying these specific claimed problems don’t hold water
with me.

~~~
notacoward
> it’s a poor craftsman who blames his tools

It's an even worse craftsman who persists in using the wrong tool. If the tool
does a poor job or requires more maintenance than the work it saves - as would
be the case if your suggestions were followed - then it should be abandoned in
favor of another. Which is what we did. Solutions found, nothing defeatist
about it, and I notice you didn't answer the question about whether you've
actually tried to do this.

~~~
ebbv
I have contributed to open source occasionally. It’s not a part of my job most
of the time so it’s rare.

But it’s also not relevant at all. As I tried to spell out the situation you
describe is not unique at all. It’s the same thing every software dev
encounters.

I’m glad you found tools that work for you, but this exchange has been
unpleasant so I’m done with you.

~~~
notacoward
> It’s the same thing every software dev encounters

No, it really isn't. "Upstream first" development such as Red Hat does is
_fundamentally_ different than developing in private, even if that includes
throwing the occasional scrap back over the fence.

If you think this exchange has been unpleasant, consider that casually
dismissing others' experience rarely leads to any other outcome. Did you do
your part to make it pleasant for anyone else?

------
stefanve
Yeah this seems to be an excellent list on how not to Scrum. Or an what
happens when scrum is used by people that don't understand the spirit list. I
actually scrolled down to see if it was a joke list or had a deeper point.

Scrum is actually used to make sure the dev team is part of the decision
process and there is no reason not to be innovative But of course the
enterprise can kill all things good

------
agf
A lot of this article is a mix of a little bit of truth with a lot of what is
just bad management.

But the first few and final example are good warnings that can be applied
anywhere, Scrum or not. Paraphrasing / quoting the article:

"[If] all product decision authority rests with the “Product Owner” ...
engineers [are disallowed] from making any product decisions and reduces them
to grovelling to product management for any level of inclusion in product
direction."

"[If] all the engineer’s time [is accounted for] in a tightly managed fashion,
[that] discourages innovation — which typically occurs spontaneously and
outside of any schedule or system of good predictability."

"[You] encourage “least amount of work possible” solutions [when you expect
engineers] to conform to ... strict predictability requirements."

"[If you] divide every task into small items that can theoretically be
completed by anyone on the team .. [you] discourage engineers from taking
pride in and/or ownership of their work. This lack of ownership results in ...
Poor design [and] Lack of motivation ('It isn’t my thing', 'It was broken when
I start working on it')"

"[Don't] ignore the fact that any task that has been done before in software
does not need to be redone because it can be easily copied and reused. So, by
definition, new software tasks are truly new territory and therefore very hard
to estimate."

------
codingdave
> Because all product decision authority rests with the “Product Owner”, Scrum
> disallows engineers from making any product decisions and reduces them to
> groveling to product management for any level of inclusion in product
> direction.

Only if your Product Owner sucks. Their job is to communicate with all
stakeholders, which includes letting the engineering staff have their say. If
the engineers feel left out, the product owner isn't doing their job.

> Scrum, in accounting for all the engineer’s time in a tightly managed
> fashion, discourages innovation — which typically occurs spontaneously and
> outside of any schedule or system of good predictability.

It doesn't. That is why there is a 'focus factor' baked in, to allow for their
time to not be tightly managed.

> Scrum encourages “least amount of work possible” solutions — to conform to
> it’s strict predictability requirements.

No, it doesn't. The scope of a task becomes a negotiation point for assigning
stories into sprints. Sometimes you do something quicker to make the sprint
work. But that shouldn't be the default answer. It should just be a talking
point. Most of the time, the engineers dictate the effort required to complete
a feature, and if they always pick the quickest easier way.... well, then that
is a problem that needs to be resolved with the team.

I could go on for every point. But I'm not seeing a single shred of evidence
that this author actually understands Scrum. They seem to have been exposed to
poor scrum teams, focusing completely on processes and documents, not the
communications, negotiations, and discussions that are truly the heart of
scrum... admittedly put within a defined structure. I'm not saying Scrum is
perfect. It isn't, but you definitely are going to hate it if you have never
even seen it done well.

~~~
nadezhda18
> > Scrum, in accounting for all the engineer’s time in a tightly managed
> fashion, discourages innovation — which typically occurs spontaneously and
> outside of any schedule or system of good predictability.

> It doesn't. That is why there is a 'focus factor' baked in, to allow for
> their time to not be tightly managed.

Can tap into my experience and say that it does discourage innovation and has
nothing to do with focus.

While doing innovation and research, your path is fuzzy and unpredictable and
does not fit into a predefined scope that the team has to commit on at the
beginning of the sprint.

While doing research or innovating, you never know if you can deliver business
value - your research may succeed... or may fail, which is often the case.
Meanwhile, in the predefined sprint scope, everybody is clear what tangible
business value it will bring, everything is clear and no room for wiggling and
straying away.

Edit: I am not talking about occasional research tasks, which seem to fit well
into Scrum structure. I was talking about the innovation as a project that
requires a big chunk research to be done.

~~~
matthewmacleod
_While doing innovation and research, your path is fuzzy and unpredictable and
does not fit into a predefined scope that the team has to commit on at the
beginning of the sprint._

This is because _you are doing it wrong_.

Innovation and research is valuable. It has a business cost, and may not
result in business value in all cases. That's totally fine! But it's still
important to recognise that so that we can understand the costs and benefits
that are being realised.

I pretty frequently engage in long-running research tasks within a Scrum team.
The approach that works is to be clear about what the deliverable output is.
Perhaps this takes the form of a plan of action, or documentation of the
research. If the whole scope of that research project doesn't fit into a
sprint, then that's a red flag – break it up.

I've had literally no problems with this approach and it's made the process of
understanding the business costs of long-running, uncertain projects much
clearer.

------
empath75
We do scrum and this doesn’t describe how it works for us at all. Our scrum
master isn’t our manager and neither is our product owner, for example. And we
have gone some time with minimal direction from the product owner at all, when
things were going well.

My main complaint about scrum was how much of my time was spent in meetings vs
working.

------
tootie
I just put my teams on scrum and they love it. Immature scrum that focuses on
metrics and jira boards can be a very tough transition, but mature scrum that
focuses on collective ownership and continuous improvement is heavenly.

------
richliss
Another day and another post where someone who believes their companies
incorrect adoption of the Scrum framework is evidence that Scrum itself is at
fault and therefore creates a Strawman to attack.

Scrum is a victim of Semantic Diffusion.
[https://martinfowler.com/bliki/SemanticDiffusion.html](https://martinfowler.com/bliki/SemanticDiffusion.html)

You know all of those things that you're doing at work when someone says its
Scrum? Chances are they're not Scrum but practices that are additional to
Scrum:

User Stories? Not Scrum

Story Points? Not Scrum

YAGNI? Not Scrum

Pair Programming? Not Scrum

Planning Poker? Not Scrum

The list goes on.

I recommend that anyone who currently hates Scrum to spend 30 minutes one
lunch time and read the Scrum Guide: [http://www.scrumguides.org/scrum-
guide.html](http://www.scrumguides.org/scrum-guide.html)

You may then realise how that consultancy that your company hired butchered it
to sell their people to do transformation, or that old school Programme
Manager changed it because he wanted more control, or that Scrum Master who
joined a company who was already doing a butchered Scrum implementation and
did a 2 day course and learned nothing else then espoused what they knew as
Scrum when they joined a new company.

This article shows the author has strong opinions on something they don't
understand - That's not a good trait to have.

------
jonstaab
Having personally witnessed all of these symptoms of "agile" on teams I've
been on, I was pleasantly surprised to discover when I read Jeff Sutherland's
book that none of these problems have much to do with Scrum, which is more of
a way of thinking about building (and tearing down) processes to optimize for
the things only the team can identify, than a process itself.

I think the reason these sorts of bad practices crop up so often is because
internalizing and applying the sort of ego-free principles of Scrum is very
very hard, even for a small team (or individual).

Reading that book [0] (particularly the first half) was eye-opening for me,
and I recommend it to anyone who works in an "agile" environment.

[0] [https://www.amazon.com/Scrum-Doing-Twice-Work-
Half/dp/038534...](https://www.amazon.com/Scrum-Doing-Twice-Work-
Half/dp/038534645X)

Edit: I would add that the linked article is pretty typical of things I had
read online about Scrum before I read Jeff's book, and I believe are very
misleading and unhelpful, as they abuse one way to solve the problems they
complain about. Bad team dynamics didn't come from Scrum. Maybe Scrum failed,
but that's a whole different discussion.

------
lillesvin
> It assumes that engineers cannot conduct a meeting effectively without a
> facilitator (Scrum Master)

Scrum isn't perfect but this is certainly not true. If the team is well-
functioning there doesn't need to be a facilitator of any kind present. Sounds
like OP is either in a bad team or with a bad Scrum master—or both.

~~~
rhizome
_If the team is well-functioning there doesn 't need to be a facilitator of
any kind present._

This is a tautology.

~~~
lillesvin
Only if you misunderstand me. ;) What I meant was that Scrum doesn't dictate
that there _has_ to be a facilitator present but if your team isn't well-
functioning it's probably a good idea to have one. I.e. if the Scrum master
has done his job exceptionally well he's rarely needed.

------
hacknat
I think more people need to talk about best fit. People shoehorn scrum into
every situation, when it is perfectly valid to say that it won’t work
sometimes, and others when it would work well. You wouldn’t use JavaScript to
build an operating system, and you wouldn’t write your browser code in C. So
why assume that one SDLC regime is right for every situation.

Scrum seems to work well when estimation really is possible and there is true
ownership and flexibility on the team.

I have not seen Scrum work well with brand new products or situations where
practically every task is an unknown and the team is defining and prioritizing
features in the product as they move and discover. Which makes sense as Scrum
does assume a high degree of uniformity and definition. There are situations
where the product owner, temporarily, has to be the whole team.

------
raverbashing
Funny, while in agile teams I made several product decisions and did innovate
in some occasions.

You don't need everything to be "inside the project/inside the process" and
even then, more things fit there than people might think.

------
talltimtom
This is a list of things they are doing wrong not things wrong with Excel,
Visual Studio, JIRA, The Scrum Methodology or any other tool they have poorly
implemented.

They should seek external help in getting their usage of these simple tools
back on track.

I’ve seen people create horrible abominations using Excel, that doesn’t mean
that the tool itself is broken or that all the effective usages of Excel are
wrong. It’s the same with Scrum. If you use it right it’s awesome, if you use
it wrong it’s just a different name for the same old bad project management
you always had.

------
cbsmith
So much wrong here. I couldn't quite figure out the full nature of the problem
(aside from working in a terrible environment), but then I saw this the
author's most recent post: [https://medium.com/@ard_adam/the-fountainhead-and-
software-e...](https://medium.com/@ard_adam/the-fountainhead-and-software-
engineering-d991b269af2e)

Now it all makes sense.

------
hacknat
The biggest one for me is estimation. I grant that certain domains work on
very predictable tasks, but what if you are working on a new product that is
solving a lot of new problems? Practically everything should be a spike. I’m
working on a new product right now and our estimates are worse than garbage as
they end up just haunting us with management.

------
specialist
Pretty good list of symptoms, side effects, phenomenon.

My assessment is somewhat more simple:

Scrum is a strategy to reach an unspecified goal thru incremental revelation.
(1)

I'm old school. Raised on PMI and gantt charts. I prefer defined goals and
critical paths. (2)

(1) Drunken sailor's walk thru the problem space.

(2) What we grey beards called "a plan".

------
badprose
"Scrum is probably the worst way to build software, except for all the
others."

~~~
walshemj
Well having done RAD/DSDM (including projects presented at the IEE) some of
the bizarre rules based things scrum gets up to seem sub optimal (to be kind).

I have even done very successful hybrid projects that used Waterfall for
design and built the system using RAD in 12 weeks - including doing a physical
delivery.

------
nwhatt
A lot of these items are process points. The whole point of scrum is that the
team determines and refines the process over time. Scrum is not a process but
a process creation framework.

I agree with most of the comments so far this is bad management.

------
enesunal
This list shouldn't be named "what scrum does wrong", it should be named
"excuses made by engineers who don't want to take responsibility"

------
newscracker
> 7\. Scrum is very management heavy. Typical teams have Product Owners, Scrum
> Masters, and Team Leads. Innovative, motivated teams operate better with
> less management, not more.

> 8\. Scrum is typically implemented with HORRIBLE task management tools
> (Jira, tfs, etc…) that enforce very bureaucratic interpretations of Scrum
> that waste huge amounts of developer time. Additionally, they effectively
> lock you into one mode of operation, no matter how ineffective.

Scrum is not just management heavy. It's micromanagement heavy. If someone
asked me for an account of what I did for a whole six (assumed to be
productive) hours yesterday and how many story points have been burned, and
wanted this every single day, I can only imagine that the person has no
experience with software development whatsoever. There are productive days
when a lot of stuff gets done and there are unproductive days when almost
nothing gets done because it's hard to focus or because of distractions. But
the daily standup meeting that's enforced would make any unproductive days as
something to get publicly shamed about.

On the tools, yes, whatever I've seen in Scrum dictates a lot of time spent
updating the tools with estimated hours, hours spent, remaining hours,
everyday. That data is rarely useful for any further estimations or to figure
out what's going on.

Lastly, the "story points not related to effort but related to effort"
conundrum confuses developers (especially the ones who are considered to
follow instructions and code whatever the user story's tasks say). Add to this
a really weird concept called velocity, which is not just a measure of how
many story points are completed in a sprint, but is used as a range — too low
and you're not working hard enough; too high and your estimates are wrong. The
only way to satisfy the Scrum master in many cases is to lie and make the
velocity conform to expectations.

I have no idea who was tying to prove what to whom when they came up with
Scrum and Scrum certifications. The certified Scrum masters I've seen don't
even know how to write a good user story or to break it into tasks.

Give me low process overhead iterative waterfall any day over these schemes.
Repeatedly trying to turn software developers into predictable manufacturing
style widget makers is not a good idea.

~~~
matthewmacleod
You have given an example of a shitty company using a shitty process. It's
unfortunate that it's nominally 'Scrum', but that's kind of irrelevant.

 _If someone asked me for an account of what I did for a whole six (assumed to
be productive) hours yesterday and how many story points have been burned, and
wanted this every single day, I can only imagine that the person has no
experience with software development whatsoever._

This is wrong. If this is happening, you are following a broken process.

 _On the tools, yes, whatever I 've seen in Scrum dictates a lot of time spent
updating the tools with estimated hours, hours spent, remaining hours,
everyday._

No it doesn't. This is wrong and broken.

 _Lastly, the "story points not related to effort but related to effort"
conundrum confuses developers _

If a software engineer can't immediately grasp this abstraction then they are
not good software developers.

 _too low and you 're not working hard enough; too high and your estimates are
wrong_

Velocity should not be used as a stick. It's a measure of the amount of work
being done which can be used for planning. If it fluctuates, that can indicate
problems that need to be dealt with.

 _Give me low process overhead iterative waterfall any day over these schemes.
Repeatedly trying to turn software developers into predictable manufacturing
style widget makers is not a good idea._

"Low process iterative waterfall" is basically Scrum.

I work two-week sprints. There are a total of four hours of meetings for those
two weeks. 5% overhead seems pretty reasonable.

~~~
newscracker
The problem, as I see it, is having Scrum certifications and certified Scrum
Masters who follow a rigid process with many conditions (which is antithetical
to the agile mindset).

I know “low process overhead iterative waterfall” sounds agile, but somehow
the word “Scrum” seems to make people want a certified Scrum Master (these
people usually frown on waterfall-like processes even if those are better
suited for delivery).

------
matthewmacleod
This is a bad article. It conflates "bad management" with "bad process", and
unfortunately pays too much attention to an idealised "official" version of
Scrum. This is the first thing that anybody developing a Scrum process should
discard.

Let's deal with these points step-by-step.

 _Because all product decision authority rests with the “Product Owner”, Scrum
disallows engineers from making any product decisions and reduces them to
grovelling to product management for any level of inclusion in product
direction._

This is a sign of a bad team. The product owner in a functioning Scrum team
works with the engineers to establish the product direction, both at the micro
and macro levels. My current product owner will involve the engineers in
almost all product decisions; she is responsible for mediating between the
different priorities set by different parts of the business. All product
meetings are open to engineers who want to contribute. It works well, and
Scrum has no embargo on this.

 _Scrum, in accounting for all the engineer’s time in a tightly managed
fashion, discourages innovation — which typically occurs spontaneously and
outside of any schedule or system of good predictability._

Scrum should not involve 'accounting for time'. It's entirely possible to
include innovation and research within a sprint – sprints should always be a
little flexible and allow for some expansion or contraction of goals
specifically to support this. Longer-term innovative or research tasks should
be treated like any other work – and importantly, the process should be
flexible enough to accept that priorities sometimes change, and that failing
to meet a sprint target because the situation changed is okay.

 _3\. Scrum encourages “least amount of work possible” solutions — to conform
to it’s strict predictability requirements._

This is simply false. Uncertainty should be built into every prediction made.
The goal is to _assist_ with predictability, not to _require_ it.

 _By dividing every task into small items that can theoretically be completed
by anyone on the team, Scrum discourages engineers from taking pride in and
/or ownership of their work._

Only if you have a poorly-skilled or unprofessional development team. Scrum
isn't going to fix that problem.

 _5\. Scrum is highly intolerant to modification, and it’s proponents
typically espouse an all or nothing attitude in it’s implementation._

Finally, a possible reasonable objection! The first thing one should learn to
do when building a process is to ignore all dogma. Adapt Scrum for your
particular requirements; it's still Scrum, more of less. Nobody has ever
implemented Scrum precisely as described.

 _6\. Scrum’s attitude of intolerance to self-examination is present in all of
it’s practices. Only processes that operate internally to Scrum’s framework
are open for modification— as for Scrum itself, it is seen as sacrosanct._

See above.

 _7\. Scrum is very management heavy. Typical teams have Product Owners, Scrum
Masters, and Team Leads. Innovative, motivated teams operate better with less
management, not more._

Scrum involves three roles – a product owner, a scrum master, and a
development team. The product owner decides what to do; the scrum master looks
after the process and removes roadblocks for the others; the development team
do the work. These roles can be combined where required. Frankly I'm
struggling to imagine a _lighter_ form of management.

 _Scrum is typically implemented with HORRIBLE task management tools (Jira,
tfs, etc…) that enforce very bureaucratic interpretations of Scrum that waste
huge amounts of developer time. Additionally, they effectively lock you into
one mode of operation, no matter how ineffective._

You're entirely free to practice Scrum using whatever tools you want.
Personally I have no problem with a simple Jira implementation. If it's been
over-complicated, then you have implemented it badly. The whole point is to
provide tools that make it easier to manage work. I use Jira, spend
essentially no time using it beyond keeping track of what I'm doing and
sharing knowledge about particular work. If this tool doesn't work, use
something else.

 _9\. Scrum discourages bug fixing, reduction of technical debt, and risk
taking, all because of its narrow, exclusive focus on only doing items that
Product Owners would interpret as valuable._

The product owner must be a skilled professional who works with the
development team to decide what the priorities are. If the development team
believe that a particular bit of non-user-facing technical work needs to be
done, then that should be taken into account by the product owner—who as a
professional, will trust the development team's judgement—and appropriately
prioritised.

No process will fix an overworked team, or compensate for a lazy product
owner. Frankly, it's not Scrum's fault.

 _10\. Scrum is hypocritical. Do managers or Product Owners track and estimate
every task they engage in with little or no say in what they work on? Are they
required to present burn down charts that show that they are on target to
finish? Are they required to do bi-weekly sell-off meeting to justify their
activities?_

Product owners are accountable for their activities like anybody else. I think
they'd benefit from a bit of Scrum in that! In fact, we've found that our
process has worked well enough that other business units are beginning to roll
out Jira to help teams understand what work they're doing.

As for the other points, I've never had to present a 'burn down chart' or
otherwise justify my activities to anybody. Again, Scrum will not fix a
micromanagement culture.

 _It assumes that engineers do not have task tracking systems that they
already use to manage their time and therefore need time-management hand-
holding._

Scrum does not involve time-management. Let me say this again: "SCRUM DOES NOT
INVOLVE TIME-MANAGEMENT".

 _It assumes that engineers are not to be trusted with directing their own
work._

It does not do this. I am trusted to direct my own work. I agree what that
work is with other stakeholders. That's Scrum.

 _It assumes that engineers cannot align themselves with the best interest of
the organization, without tight supervision._

It does not do this. I am not supervised; I use Scrum to agree with the rest
of the organisation what is in its best interests.

 _It assumes that engineers cannot conduct a meeting effectively without a
facilitator_

It does not do this. My scrum master (actually the head of development, acting
in that role for multiple teams) takes care of the nitty-gritty of booking
meeting rooms, setting calendar dates, preparing documentation, taking notes,
finding availability, and that kind of thing. They are a helpful facilitator.
If you have an alternative, that's awesome. The scrum master doesn't ned to be
involved.

 _It assumes that you can plan every facet of a software task by merely
talking about it in sprint planning /backlog grooming_

It does not. No ticket describes every aspect of a feature. Ideally, you can
do this, but we all know that things can change. Roll with it and take the
obvious step of dealing with unexpected changes like an adult.

 _It assumes that all engineers work the same way._

That's just flat-out wrong.

 _Scrum story points are supposedly meaningless, yet they are tracked,
recorded and presented at many levels in an organization and often are the
only metric by which a team’s performance is represented (ie. Velocity)_

As far as I'm aware, nobody outside my team knows anything about our velocity.
It's purely a method used to help us understand how much work we can commit to
in a given period. If it is being reported, you are doing it wrong.

 _Scrum is designed to manage the weakest Engineers and consequently dis-
empowers the better ones._

No.

 _Scrum is the opposite of many of the points set forth in the original agile
manifesto:_

No justification is provided.

 _15\. Scrum ignores the fact that any task that has been done before in
software does not need to be redone because it can be easily copied and
reused. So, by definition, new software tasks are truly new territory and
therefore very hard to estimate._

This is laughably wrong.

Basically, I disagree emphatically with _every single point_ made in this
article. I have had an _excellent_ time as part of a Scrum team; I have a
clear idea of:

\- What I'm doing \- What others are doing \- How we can help each other \-
What the business priorities are \- When particular tasks take longer than
expected \- How we can avoid surprises and failures

I honestly can't imagine working any other way.

~~~
megaman22
Every criticism of Scrum or Agile evangelicism is met with these No True
Scotsman arguments that if you were simply better, or tried harder, the
process would save you.

I want a process that works for the messy, suboptimal world that is reality.

~~~
matthewmacleod
I'd argue that you can't 'solve' bad developers, bad managers, or bad culture
with _any_ process.

------
jack9
This seems like a coded endorsement of Agile processes.

------
vannevar
I'm disappointed that this throwaway list of unsubstantiated bullet points is
being treated seriously, but seeing as it is, here's "A brief list of what
this article gets wrong about Scrum":

1) The author makes the unfortunately all-too-common mistake of confusing
agile development with software design. Agile says very little about software
design, other than observing that it is incremental and iterative rather than
revelatory and monolithic. Scrum, as an example of agile practice, is
primarily concerned with implementation and delivery. The Product Owner can
consult anyone they want in the course of designing the software, and of
course that includes the engineering team. Scrum encourages the PO to seek the
participation of all stakeholders in sprint planning and review, but other
than that, design is left to the PO's discretion.

2\. Nothing in scrum discourages innovation, and agile certainly encourages
innovation to a much greater degree than the detailed spec-driven alternative.

3\. There is actually a grain of truth to this one, but it confuses what
happens within one sprint with the overall process of software evolution over
many sprints. What the author is complaining about here is basically Scrum's
version of YAGNI ("You Ain't Gonna Need It"). It's the principle of doing the
simplest thing that could work first, and then elaborating on it. My 35 years
of software development experience tell me that this is a sound approach.
Others may disagree.

4\. Scrum does not require the "dividing every task into small items that can
be completed by anyone on the team". It definitely encourages dividing work
into meaningful pieces with tangible, testable results. But nothing prevents a
team from matching work with the team members most suited to doing it. The
author seems to be complaining about working on a team in general, where the
credit for the product must be shared with others. Nothing about scrum
encourages 'lack of ownership' to any greater degree than any other team-based
development process.

5\. This is simply wrong. Scrum encourages modification and explicitly proves
the flexibility for it by ensuring that you're never more than a sprint away
from changing direction if it becomes clear that's necessary. And of course,
if the team is _really_ blindsided by new information, the PO can cancel the
current sprint and start a new one.

6\. Scrum explicitly encourages self-reflection through the retrospective that
occurs every sprint. The author here is apparently ignorant of this aspect, so
maybe it was not practiced in his company.

7\. Scrum requires minimal management. The Scrum Master is not intended as a
manager, they are intended as a way to short-circuit bureaucracy so that any
impediments to the team's progress can be removed. And I've never seen any
software development process of any scale that doesn't have a Product Owner or
a team lead, though the titles may change.

8\. There are lots of bad tools. Don't use them. Find good ones, if you need
them. Scrum _requires_ very little, a whiteboard and some sticky notes will
do.

9\. Scrum does not discourage (or encourage) bug fixes or refactoring. As the
author notes, that's at the discretion of the Product Owner. Again, that's
always true, whether you're using Scrum or some other software management
system.

10\. The Product Owner is responsible for delivering the product on time. Of
course they are accountable, and I guarantee that if they're at all competent,
they're doing far more reporting and documentation for their superiors than
the team is for them.

11\. Scrum assumes none of these things. Not a single one. Who has a Scrum
Master at every engineering meeting, for instance? Ridiculous. The Scrum
Master runs the daily scrum, which is a 15- or 20- minute daily sync up. They
don't attend any other technical meetings unless someone wants to invite them
for some reason.

12\. Of course scrum points aren't meaningless; why would anyone bother to
track them if they were? They tell the team what it's velocity is, which is
useful to the team for sprint planning, and useful to management for resource
planning.

13\. Scrum disempowers the best developers from...what, exactly? Scrum is
designed to allow devs to focus on delivering, so they don't have to guess at
what's being requested, and so they get quick feedback on what they've
implemented. At all times, they know how they're doing. There's nothing
disempowering about scrum.

14\. The Manifesto doesn't say "no processes or tools". The scrum process is
very light compared to the spec-driven process that it replaced. And as noted
above, it doesn't require many tools. The fact that people feel like they need
ten Atlassian services to do it isn't Scrum's fault, any more than the fact
that you bought a Total Gym and a ThighMaster means that fitness is bunk.

15\. Any developer who truly believes that "any task that has been done before
in software does not need to be redone because it can be easily copied and
reused," and that any new task cannot be estimated, should really find another
profession.

Honestly, I think the article is a troll. For the author's sake, I hope so. If
not...well, he says he's a Programmer and Dog Owner. I hope he's a really good
dog owner.

------
mmcnl
Wow, this article is blatantly wrong on almost every point the author makes.

------
amai
Only a brief list?

------
ebbv
My team does SCRUM at work and almost none of these apply to us. Sounds like
the author works in a bad company.

~~~
wolco
I work for a good company but the team I was on a few years ago was using
scrum. It really does promote pushing debt down the line because the product
owner only cares about what they can see or measure. The debt isn't part of
that set so the developer has to fight to address it. After the first battle
many will stop fighting because they are measured by how well the product
owner thinks that developer is implementing their roadmap and on track with
the schedule they got approved.

Products with heavy debt tend to get rewritten rather than fixed. So it makes
sense to keep the schedule through shortcuts and push as many features as
possible. Then throwaway the product and rewrite in something newer and more
modern.

For developers the benefit is your resume will have the latest tech and you
can write sloppy non-abstracted code and not worrying about having to support
the product later. Management gets increased visibility into each task with an
accurately followed schedule.

Not a surprise it has become so popular. If I could change one thing I would
make the scrum master in charge of technical documentation. That one change
would force the master into understanding the code at a lower level. That
would make them the most knowledgable person on the project thus it would
remove the need for daily standups because team members could go to the master
at any point in the day with questions or to coordinate effort.

~~~
ebbv
SCRUM does not push for bad, tech debt laden products any more than any other
development system. Managers who want you to push code out the door ASAP will
do it just as much no matter the system you’re using.

The solution is not to blame whatever particular form of agile you’re using;
the solution is to replace the bad managers if you can’t educate them on why
that’s short sighted.

------
rhapsodic
Mediocre developers will produce mediocre results. No methodology will pull
great results from mediocre developers.

------
jadedhacker
The engineer here is protesting being turned into a factory worker, becoming
alienated from his work, and being used towards the ends of management rather
than his own. It is an indictment of capitalism's effects on workers, even
highly skilled knowledge workers.

What he is expressing is the inkling of the desire for a better world; perhaps
one where there is democratic control of the production process by workers.

A spectre is haunting software development. Developers of the world unite! You
have nothing to lose but your chains.

------
sifoo
The Agile movement was all about dropping the process hoop jumping and
focusing on solving problems efficiently, that's why it was considered
extreme. Too extreme, as the one true implementation to rule them all is worse
than what the agile movement was revolting against. This is how the game is
played, over and over and over again; any movement that threatens the
narrative is embraced, corrupted and ultimately used as a weapon against its
core values.

------
firewalkwithme
I am getting real tired of methologies and agile movements all together

------
bumelant
This post confuses many things but firstly it doesn’t properly talk about
Product Management. PM is customer centric and marketing heavy discipline and
just knowing how to code and good intentions of devs may not work on
competitive market. Secondly Scrum is project management framework and says
nothing about software development practices and leaves them completely to the
judgment of the team (including developers and PO because they collaborate
heavily in Scrum).

