
Scrum disempowers developers - Robin_Message
https://www.lambdacambridge.com/blog/how-scrum-disempowers-developers-and-destroys-agile
======
nickelcitymario
Like any and every business theory, Scrum has one or two core ideas that are
awesome, but could be explained adequately in a paragraph or two. This does
not sell books and consulting, so it evolved into a field of its own.

The fact that there is so much B.S. in Scrum doesn't mean that it has nothing
of value to offer, though.

Here's what I get out of it:

1\. Sprints are a better way to organize than Waterfalls. I've experienced
this over and over again personally, so I'm sold on this.

2\. It's important to stop what you're doing on a regular basis to evaluate
progress and problems. This always seems like a waste in the moment, but
failure to do so leads to regret down the line.

3\. Ship functional products as frequently as possible. This is better than
waiting until everything is done, because you can get feedback early and often
from the end user.

Okay, so that's 3 ideas. It's better than most.

~~~
mmusson
My experience is that a good team does a good job. A bad team doesn’t.

I think the focus on methodologies is to get a good result from an uneven
team. Companies desperately want to treat programmers like standardized
workers that can be mixed and matched as needed. The siren song of the
methodology is that maybe it can achieve that goal. I have never seen this
work in practice.

There are no quick fixes. People can improve but it takes time, dedication,
and support.

~~~
some_account
I really dislike agile. A product owner asked me once if I get some benefit
from them...and no, I don't. Thry get a lot of benefit from me sharing what
I'm doing because they can then keep track of it and communicate it to other
people, but I don't get any benefit personally.

I want to be the guy who talks to the rest of the employees, implements things
and get direct feedback from them. I dont want anyone in the middle of that.
It just complicates everything and makes me less connected and known in the
company.

~~~
vannevar
_I want to be the guy who talks to the rest of the employees, implements
things and get direct feedback from them._

How exactly does agile prevent you from talking to your teammates and getting
feedback from them?

~~~
some_account
Team mates are the ones I'm working with all the time. I don't need scrum
processes to talk to my team. A good team knows how and when to share
information.

~~~
geezerjay
> Team mates are the ones I'm working with all the time. I don't need scrum
> processes to talk to my team. A good team knows how and when to share
> information.

Scrum processes are just a way to ensure that no stakeholder, including team
members, is left out of those talks, left in the dark, or left unheard. Having
a clique single-handedly and unilaterally dictating changes without
communicating them or listening to any stakeholder doesn't serve anyone's
interests. That's how projects fail.

------
matthewmacleod
I find this article lacking, because it makes all of the same mistakes typical
of these bandwagon anti-Scrum articles.

Despite working in a a Scrum team, I recognise _literally nothing_ of the
problems that are described. Our product owner works closely with both
commercial and development groups to build the backlog. Pressure to build good
technical solutions is reasonably balanced with commercial requirements. The
development team is empowered to step in and request product changes when they
think it's necessary. This happens because we are a team of skilled
professionals who want to deliver working things at reasonable pace, and this
applies to both commercial and development groups.

There is a weird underlying assumption in these kinds of articles that
implicitly seems to assume that Scrum will somehow turn a bad team into a good
one. I have no idea where that comes from. A team using Scrum still needs
skilled people who know how to do their jobs effectively – and that includes
the scrum master and product owner roles. Introducing it into a good team can
then help to reduce the impact of common software development issues. It
doesn't work for every company, team, or product – but that doesn't mean its
without value.

I'd be more interested in articles that talked a little about better processes
that we can use. I'm absolutely open-minded about the idea that there are
other legitimate and effective ways to deliver software other than Scrum,
because it's obviously the case. "These are the problems with Scrum and this
is why they aren't a problem in <other process>" is more valuable than "If you
have a bad team then Scrum is bad".

~~~
barrkel
I recognize the disfunction. What happens is that the owner of the backlog
becomes the controller of how much time gets spent on what. With feature
pressure, it's all new features all the time, with no scope to address debt.

~~~
alistairSH
IMO, this is where a good leader (SM, tech lead, whoever - I don't mean a
literal manager) advocates for sanity on behalf of the rest of the team.
Mostly, this just requires somebody to say "No." every so often in the face of
ridiculous demands.

As SM, it's my job to ensure that not only will the PO listen to concerns from
the team, but the team feels empowered to provide that criticism. If neither
of those happens, I've failed.

A bad PO will RUIN a team. I've seen them do just what the blog entry claims.
I've also worked with POs who don't do any of the bad things claimed.

~~~
Cthulhu_
This is correct. The article (and grandparent) seems to quickly jump to the
assumption that the members of a scrum team are mindless drones - and don't
get me wrong, some scrum teams are - but they are empowered by scrum itself to
have a say or two itself in what to deliver when. The PO only decides
priorities, and is not (officially) allowed to pressure for time and
deadlines. In return, the scrum team gives feedback in the sprint ritual about
how fast they're going, relatively, in story points delivered. This is only
relative to that team's own (previous) sprints.

I think the main issue is that people are doing scrum wrong, applying
traditional management to an agile process.

~~~
dgreensp
Does Scrum itself empower individual members of the development team? Saying
it’s on the developers not to be “mindless drones” and the managers to not be
“bad managers” may be true but doesn’t really refute the article’s point.
Maybe you have Scrum disempowering developers and (at the best companies)
other forces, including other practices and processes, empowering them.

For example, Scrum says responsibility for operations and testing are to be
shared responsibilities; you don’t have an ops team or a testing team, or
titles, or recognized responsibility. You might have a de facto ops team, but
those are just some individuals who have chosen to carry pagers right now.
I’ve seen things like this play out and been puzzled by it. I didn’t actually
realize until reading this article that people have been giving talks and
writing books saying that “subteams” are bad, but it makes sense now.

The point being, not having officially recognized responsibilities is a form
of disempowerment.

~~~
alistairSH
_not having officially recognized responsibilities_

I feel like that's a bit of an overstatement. While scrum advocates for shared
responsibility, it doesn't demand no-titles, no-roles, or no-passions.

It's all about ensuring the entire team possesses 'T' shaped skills. Depth and
expertise in some areas, but still generally knowledgable across all areas. My
test engineer doesn't write much code, but in a pinch, she can. My PO is fully
capable of "running" the team in my absence, as is the test engineer. All my
developers know the full DevOps pipeline and can contribute to it, though none
of them are DevOps engineers by title or primary responsibility. And I'm an
ex-developer-now-manager who can do a bit of everything, though these days I'd
rather go to meetings and play office politics so my developers can do their
thing.

~~~
dgreensp
_Scrum recognizes no titles for Development Team members, regardless of the
work being performed by the person;_

 _Scrum recognizes no sub-teams in the Development Team, regardless of domains
that need to be addressed like testing, architecture, operations, or business
analysis_

Maybe T-shaped people are required to make Scrum work, or vice versa? Like if
you are running a restaurant and your company process says “there is no
distinction between waiters and chefs,” then your waiters need to be decent
cooks, and your chefs need to be personable and presentable. “Passion” can be
a liability in this environment, for example being passionate about great food
or great service. The lack of specialization doesn’t seem directly related to
how to do great work, or be really happy at work.

------
js8
My biggest beef with Scrum (and why I think it's a scam) is that they renamed
everything, all the processes.

Historically, there are three important sides, and roles, for each project.
Product management - takes care what the customer wants to have build. Project
management - takes care of what is delivered is on schedule and that there is
enough material/personnel to build it. Architect/engineering lead - takes care
of whether the thing is technically feasible, what technologies are used and
what technical trade-offs are made.

And there was a vast literature and discussion about how these three sides
affect the result of the project, and how to solve these problems.

Unfortunately, Scrum, renaming everything, acts as if the history of project
management doesn't exist. And if you forget history, how are you supposed to
learn from it? That makes it easy to sell snake-oil. I frequently hear, for
instance, that scrum master is not a project manager, despite him having some
responsibilities in this area.

And as the blog post also expounds, there is no recognition for these three
different sides of each project in Scrum (ironically, there is some
recognition of that in Scrum derivatives such as Scaled Agile Framework, for
instance, modulo nonsensical renaming of the roles).

~~~
lmm
I don't think there was anything like the kind of consensus you're portraying
about what these things were called. Different shops used their own terms for
things; "architect" meant radically different things from one pre-scrum shop
to another, "engineer" even more so. "PM" would be used interchangeably;
different people from the same company would tell you it was "product" or
"project".

I don't like renaming things for no reason, but if you want a term to have a
precise meaning and not carry any baggage from previous similar-but-subtly-
different usages, it's probably best to coin a novel term.

~~~
js8
There might not be a clear consensus what a given person does but there are
three types of tasks or concerns on the project, as I outlined them. Do you
disagree with that?

So if Scrum (or any other methodology, for that matter) wants to define a new
role (to what end?), they should explain, how they are related to these
concerns? What tasks that were traditionally done by the triad are supposed to
be done by the new role, and why? And moreover, how are the concerns from the
triad dealt with in Scrum?

That's what I miss from Scrum. There is no connection to what was before,
aside from using waterfall as a straw man (it's not a methodology to begin
with). It's an ideology, its own world.

The result of Scrum being an ideology is, somebody who becomes scrum master in
Scrum, and effectively doing project management work (in the better case), by
default, has no idea that there is a field called "project management", and
that he should study that field. So they don't know, for instance, the classic
like Fred Brooks.

~~~
lmm
> There might not be a clear consensus what a given person does but there are
> three types of tasks or concerns on the project, as I outlined them. Do you
> disagree with that?

That's one way to break down the set of tasks/concerns you've identified, sure
- but only one. I don't think that the industry as a whole accepts your
categorisation into three, or even your paradigm for which tasks do and don't
need addressing in this way.

You're coming across as far more ideological than the thing you're attacking,
assuming that your particular breakdown must be the canonical one when it
simply doesn't have a level of industry acceptance that would justify that.

~~~
js8
No, you misunderstand. I don't care about the breakdown, but I do care about
these tasks and concerns (and you seem to agree that they exist). How to deal
with them needs to be explained in the context of the new methodology, and how
it relates to the old ones. That's what I have not seen with Scrum, it pretty
much ignores all the history of project management as a discipline.

And actually, when I started programming professionally, I didn't think that
management was necessary, and that we could self-organize and all that. But as
I changed projects and bosses, it turned out, I just had a good manager (and
it was a waterfall-like method, by the way).

So I think the idea of self-organization is intuitively appealing to many
people (especially young without any experience), and if you have a person in
the team who can naturally take each of these roles, then I think it can work
(that is - sometimes). But today, I don't think it will work in general, and
for that reason.

Now I recognize that, for instance, you need somebody well-organized on the
team who can make sure things do not fall under the table. Or you need
somebody who is process-oriented, interested in improving process. Then self-
organization can work.

If you don't have people with specific traits like that, or they don't emerge
as natural leaders (gain respect) in their specific areas of interest, then
you need to appoint somebody to have that role. Then it makes sense to have
explicit project manager, or product manager, or architect, who focus on
certain tasks and concerns.

I suspect the fact that sometimes you can do without having these people
designated as such can account for some anecdotal success of Scrum (or any
other method - I personally had the best experience with waterfall-like
approach).

~~~
lmm
> I do care about these tasks and concerns (and you seem to agree that they
> exist).

Not really, and I don't think the industry as a whole does either. Everyone
has their own set of tasks and concerns; I don't think there's any consensus
that says that all the important ones are on your list, or that everything on
your list is important.

------
jrochkind1
> the product owner often works alone and the development team simply receives
> a stream of backlog items that need to somehow be brought into a cohesive
> whole

This is the root of the problem in my opinion.

I am not interested in defending "Scrum", I don't like what I know about it,
in the few experiments I've been involved in with it (not by choice), I agree
it was disempowering to developers, trying to treat developers like
commodities.

However, I am a fan of trying to do things agilely (iteratively, figuring out
what to do next in relatively short chunks without trying to plan out the next
year+).

In the experiences I've had where this _worked_ the product owner was
_intimately_ involved with the development team, with lots of communication in
both directions, with the development team's info and feedback effecting how
the product owner prioritized and determined (and changed, agilely) acceptance
criteria.

The product owner had to embrace/accept that this would be a significant time
and energy commitment to them, they could not be looking to minimize their
time here, and had to accept that "with great power comes great
responsibility" \-- that they needed feedback from developers to make these
decisions properly.

On the flip side, through these good experiences, I also learned that a good
product owner is _so important_ -- as a technical decision-maker I don't
_want_ to be responsible for determining product priorities or acceptance
criteria. I want my feedback to be taken into account, but having someone else
(who is good at it) be _responsible_ for it let's me focus on applying
technical excellence to achieve the goals set by the PO, and takes _so_ much
pressure and anxiety off of me. Especially when I can trust them to know what
they are doing it and do it well (just like they can trust me to execute
well).

I _do_ think the development team needs a "technical lead" in addition to
product owner, not just an amorphous bunch of people "self-organizing".

~~~
dnomad
A "one way" product owner is useless.

Backlog grooming is a thing [1]. In fact, I'd say after the Increment, it
might be the most important thing. If developers and _all_ the owners are not
continually reviewing the items in the backlog together, clarifying them and
making sure everybody understands what is being asked for and what the
priorities are, breaking down stories that are too big, making sure that, yes,
some tech debt gets in there, then all you've accomplished is a kind of mini-
waterfall where stories get shoved to the top of the backlog by whoever comes
last and then developers hammer away at them frantically at the beginning of
each sprint.

> I _do_ think the development team needs a "technical lead" in addition to
> product owner, not just an amorphous bunch of people "self-organizing".

Scrum consistently fails because everybody thinks in terms of the "who" and
the "how." Scrum books are all about the process, the daily meetings, the
roles and the responsibility. This a symptom of a much larger issue here, the
"technological paradigm" that pervades nearly all corporations. There's an
unfailing obsession on organization charts, department boundaries, and
processes.

It's all kinda silly.

As somebody who's managed too many scrum teams to remember here's the secret:
don't focus on the "who" or the "how", focus on the "what." The what is all
that matters. In Scrum there are certain key artifacts: stories, the backlog,
the increment, blockers, and retrospectives. Relentless focus on the quality
of these artifacts as _documents_ and you will excel at Scrum. But you have to
really care about the quality of these documents. Everybody, not just the
scrum master, has to keep iterating over these document/artifacts until they
are awesome. This means continually refining stories until people know them
inside and out. Continually polishing the backlog until it shines. Making sure
everybody understands exactly what will be delivered at the end of a sprint,
the increment, and when it's delivered having people write feedback and rate
the increment. It means investigating and documenting every single time a
developer is blocked for more than 15 minutes and then making sure it never
happens again.

I've worked with remote/distributed scrum teams and what I've found is that
you can even throw out all the ceremony -- the daily stand-ups, the endless
sprint review meetings, the endless retrospectives. When the team is
distributed between London, Shanghai and Sydney and most of the developers
work from home at oddish hours such meetings are impossible. But by focusing
on the documents even such a distributed team can fly. So, yeah, at the end of
the day this all boils down to effective communication and writing things
down. Most knowledge games do.

[1] [https://www.agilealliance.org/glossary/backlog-
grooming/](https://www.agilealliance.org/glossary/backlog-grooming/)

~~~
jrochkind1
I'm not sure if you are arguing against what you quoted from me (that I think
a technical lead is neccesary, cause it is a "who"), but the reason I come to
this conclusion from my experience is because technical decisions on the macro
or medium level need to be decided on a fairly regular basis, and I do _not_
want continual endless consensus committee meetings hashing them over. Or a
free-for-all with no coordination.

It is not only more efficient, but better for morale to have an agreed upon
person upon whom the buck will stop. Sometimes when things are "everyones"
responsibility they end up actually having nobody take responsibility for
them. Such a person with ultimate responsibility and authority for technical
decisions should be both competent and not an asshole, they should be in
constant dialog and taking feedback from everyone else, and paying real
attention to their concerns about technical matters.

But for the same reason you need a Product Owner (instead of just the
amorphous group of all stakeholders) to ultimately take responsibility for
decisions about priorities and acceptance criteria, you need a technical lead
to ultimately take responsibility for technical decisions.

I think that "Scrum" doesn't have this is just part of it's attempt to
commoditize developers (something I think is characteristic of "scrum" but not
part "agile" generally or at it's best). "Scrum" sometimes seems as if it's
designers thought there _are_ no technical decisions to be made, just a bunch
of widget-ized, swappable developers churning out code to meet the
requirements set by the PO. But, in fact, there are technical decisions to be
made, that will effect other people's work and the product as a whole, in the
short- and long-terms. Regularly.

------
jillesvangurp
Pretending to do agile seems to be widespread thing in our industry. There are
literally no companies out there not claiming to be agile. So, the word has
become meaningless. Scrum is the lowest common denominator in our industry
when it comes to that.

Agile implies getting things done and getting things to market. If scrum helps
you do that great. If not, ditch it. In my experience, Kanban is a step up on
the evolutionary ladder. Both have issues with not prioritizing essential
activities related to research, refactoring, etc. that you need to guard
against. There's a difference between agile and firefighting.

One worry with scrum is the roles of product manager and scrum master. In my
experience these things end up being formal job titles in bigger
organizations. This is bad because they are typically on the very low end of
the scale. That means you end up with the least experienced people filling
these roles and a lot of corporate politics. I've seen more than a few
organizations that were hiring accordingly.

~~~
christophilus
My company doesn't claim to be agile, I don't think. We just allow devs to
work on whatever they find interesting. If something really urgent comes up,
its urgency is made known to the dev team at large, and someone always steps
up to the plate. Works fine for us! Also, we don't have deadlines. Things ship
when they are "good enough".

Granted, we're very selective in our hiring process, but it means things just
work without much need for fancy management practices.

If any dev managers are reading this, I can say, this approach works, and you
should give it a try.

~~~
knoq
A previous company I was at worked this way and it was a dream. That said, it
does require very selective screening processes and maturity from those you do
hire.

However, it was the most happy / least stressed I've ever been in my life. I
still get beers almost weekly with over half that team. This "strategy" really
built comradery because we were always talking and discussing rather than
leaving comments on some Jira ticket (which we did for async or when
necessary).

Seriously.... give it a shot if you can

------
tootie
Our weekly "why scrum sucks" post that's really a "why my company does scrum
wrong and I don't know how to fix it".

Product owners push customer value. Of course. You should too. Code quality
and refactors have business value. Reduced maintenance cost, fewer bugs,
faster future dev. If you can't explain that to your product owner then maybe
it's not worth doing. I think your big missing piece is the collective
ownership aspect. Product owner gets to set priorities, but it should be a
collective discussion. Every dev should be allowed to express their opinion
and it's the job of the product manager to referee.

~~~
addicted
Who is the “you” here? Who is supposed to explain to the product owner that
code quality and refractors are worth doing?

The real issue the article brings up is that Scrum has an individual who takes
ownership and responsibility for the product backlog, it has an individual who
takes ownership and responsibility for the project management, but it has no
individual who takes ownership and responsibility for the non visible
technical aspects of the product.

In an ideal world, this responsibility would be taken up by the scrum master,
who would have technical expertise, but as the article points out, (a) scrum
never states this, and in fact, hints in the opposite direction, and (b) this
is rarely the case in the real world. The scrum masters are usually as non-
technical as you can get.

~~~
jameshart
This is utterly backwards.

The team owns it all - the process, the product, the technical artifacts, the
code quality. If the team is looking to the PO or the Scrum Master to take
responsibility for things, then they are going to fail.

The product owner is there to help the team understand what value they can
deliver. The scrum master is there to help the team optimize the process. The
team hopefully has developers on it who are there to help the team make well
engineered pieces of code Maybe there are designers to to help the team make
great user experiences. The team has specialists, but the team works
collectively to deliver results.

If your scrum team has a bunch of engineers on it wondering how to get their
voice heard over the product owner, you don’t have a scrum team building your
software, you have a PO acting as a tech lead running a waterfall project.

------
struppi
If you do Scrum like that, you're doing it wrong (I know, no true Sctosman
[1], and I know, there are actually dark patterns [2]).

I wrote a whole book about "Agile Anti-Patterns" [3]. Most of the book's
content is about things that many companies get wrong when they start with
agile or lean software development. Because it is very easy to get those
things wrong.

Yes, those problems are extremely common. Not only with Scrum - Organizations
also face those problems when they try Kanban or SAFe or whatever. Because,
change in a traditional organization is hard. And to _really_ implement Scrum,
you'd probably need to change more about the organization than the org was
willing to change.

But those problems are not Scrum's fault. If the team has no power, it is also
not truly self-organized. And the Scrum Master is not doing their job.

You could start to improve by creating awareness about the problems. Blaming
Scrum may or may not be a good idea to do that - Because, some people in your
org may be invested in Scrum. Some mentoring or coaching for your Scrum
Masters, Product Owners and developers and managers might be a better start.

[1]
[https://www.davidtanzer.net/david%27s%20blog/2014/03/26/no-t...](https://www.davidtanzer.net/david%27s%20blog/2014/03/26/no-
true-scotsman-in-agile.html)

[2] [https://ronjeffries.com/articles/018-01ff/hills-to-die-
on/](https://ronjeffries.com/articles/018-01ff/hills-to-die-on/)

[3]
[https://www.quickglance.at/agile_antipatterns.html](https://www.quickglance.at/agile_antipatterns.html)

~~~
tannhaeuser
That sounds ridiculously similar to people hanging on to communism/socialism:
"the principles are sound, it just hasn't been implemented as intended".
Except, just like communism, Scrum has never and will never be implemented "as
intended" because that's contrary to our collective evolutionary gifts, and
against a developer's desire to find satisfaction in good craftsmanship. A
project management methodology building on utopian altruistic ideals and
delusions wrt people's motives is just propaganda.

~~~
Cakez0r
I've seen it work to the benefit of everyone before (I'm a developer). It's
not a pipe dream.

~~~
tannhaeuser
Yes I've also been in SCRUM projects that worked well; however, these projects
would have worked well under any organization, because of the particular
people on the project.

~~~
Cakez0r
Yes, when it's worked for me, the team has also been great. What I mean,
though, is that scrum was an active benefit to us. The project would've gone
well with or without scrum because the team was good, but scrum was helping us
achieve our potential over using other approaches (that I know of).

------
mwilliamson
I think the value I get out of Scrum, or XP, or any other methodology, is two-
fold.

Firstly, it gives you a set of tools to use -- sprints, TDD, product owners,
and so on -- that should work well together. To use them well, I think you
both need an understanding of how each of those tools supports some idea or
principle that the methodology promotes, and whether or not you think that
principle is important for your team.

Secondly, a methodology gives you a starting point of how to run a development
team. It's easier, although not necessarily better, to start from a pre-
existing cohesive set of practices than to build a process from scratch.
Especially if a team isn't experienced with many of the ideas, this is not an
unreasonable place to start.

I think the key is:

1) knowing what principles your team thinks is important (low defect rate?
frequency of releases? developer happiness? empowerment?). This is often hard
to articulate. As time goes by, you might discover principles that were
previously implicit, or you might find that the principles that are important
to you change.

2) knowing how each part of your process maps back to one or more of those
principles

3) having a mechanism that allows you to tweak your process over time (for
instance, retrospectives), whether that's adding, changing or removing parts
of your process

Scrum can be a sensible starting point so long as you're willing to introspect
and consider which bits are and aren't working for you, and you're empowered
to do something about it.

~~~
knoq
Not disagreeing (though not a fan of Scrum or Kanban), but can you elaborate
why TDD is part of the "agile toolset"?

I've seen this claim multiple times and it's never made sense to me. I do TDD
on side projects where there's not even a hint of "agile."

~~~
mwilliamson
Rapid feedback and short iteration cycles are often considered to be an
important part of agile development. TDD suggests that you write a test first,
and try to make that test the smallest increment that moves you forward. It
feels to me that TDD is an application of the principles of rapid feedback and
short iteration cycles on the level of code.

If you think using TDD improves the quality of your code, then it's also
important for maintaining high code quality, since that enables some of the
other agile practices, such as frequent releases.

I don't worry too much about whether a particular practice is agile or not. If
you find TDD useful, then great! It's often included in conversations about
agile development, but that doesn't mean you have to be doing agile
development in order to use it.

~~~
knoq
Makes sense. I just see them grouped a lot as if they are a "required
dependency" for lack of a better phrase. Thanks

------
noarchy
One would expect Scrum to disempower developers. After all, it is a management
methodology (yes, I know some will protest at this label), and it emphasizes
those things as a result. Any resemblance to software development methodology
has long been lost, if it was ever there at all.

That said, an entire industry has emerged to sell this methodology, and it is
supporting a vast array of jobs: everything from those selling the
certifications, to the software used to track developers. There are too many
vested interests now, and no company wants to admit that it burned through
thousands of dollars, with dubious results, to "train" managers and subscribe
to the usual software bundles.

I expect the comments here will also have the usual comments about how Scrum
is great, and everyone who is critical of it is just doing it wrong.

~~~
kaustyap
On contrary I found scrum to be empowering for developers at least in my
organization. Earlier, we used to have Technical Manager who provided estimate
for a feature/project just based on his gut feeling which often was
challenging and not feasible. But then developers needed to burn midnight oil
to achieve the targeted release date. It often put enormous pressure on highly
talented and competitive developers who had to cover up for less skilled
developers. Now the development team is empowered to give its own estimation
considering all factors. Mind you, in can lead to overestimation, but then we
have experienced Technical Lead working also as a scrum master and individual
contributor who is there to correct the course.

In general scrum will work best when 1\. The product owner is from technical
background with enormous experience under his belt in product
development/architecture. The Product owner does not work alone in silos to
create backlog but interacts with development team regularly to refine the
backlog. In our case, the product owner is someone with 20+ years of
experience who has worked in roles like developer/architect.

2\. The scrum master is also highly technical person who has been working on
the product for several years. In our team, the same person wears different
hats as per the need like scrum master/technical leader/individual
contributor.

It may not be exactly as per scrum guidelines but worked fine so far for us.
Ultimately we need to look for good practices in each methodology and bend it
as per our needs.

------
matt_s
The teams I've been on that just 'jive' usually start with some process
framework but then evolve to just work well together.

There are strong philosophies in Scrum and Agile that should be kept as
guidelines. The key is being agile (lower case 'a') so you can adapt to
changing priorities. Continuous Integration/Continuous Delivery go a long way
towards empowering developers.

Two ways to tackle technical debt in projects:

1\. Tech debt sprint. If scrum master and product owner can't get onboard then
they need to realize somewhere in the near future, a feature they want will
either break things or take forever.

2\. Break up tech debt into small efforts someone can do in short time boxes.
Even do feature flags or something to make slower progress towards a goal
rather than tech debt sitting in a backlog for months.

An example of a guideline is estimation with planning poker. We completely
ditched estimation activities. The estimates were usually off and not good
predictors of completion. The team has a cadence of ticket completion and the
'sizes' of the tickets vary some but you don't need to waste time estimating.
Developers (humans) are horrible at estimating. Having a good PM/PO set
expectations with the business helps.

~~~
matthewmacleod
I would say that estimation isn't so much about predicting completion as
understanding hidden assumptions in the team.

We sometimes find that engineers have entirely different concepts of how a
particular feature or change needs to be implemented. Estimation – planning
poker in particular – is a great way to reveal that and start exploring what
the reasons are.

~~~
matt_s
It is a good facilitator of that conversation but you don't need to do
estimating to have that conversation about implementation details. Once a team
arrives at common patterns of implementing things then those conversations
really only need to happen for new implementations or integrations with other
systems.

------
JepZ
> Scrum has become the de facto definition of Agile

That is a part of the problem. Scrum is very far from Agile. Scrum introduces
processes and tools while the Agile Manifesto [1] clearly states:

> Individuals and interactions over processes and tools

That said, Scrum isn't entirely bad. Its just not what many people think it
is. As a tool to change the culture of a company that has been shaped by
classical project management methods for decades it is very valuable. But the
process shouldn't stop there as Scrum isn't the end, its the start.

So companies which managed to implement Scrum should try to move on to more
Agile practices to transform their culture over time.

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

~~~
srtjstjsj
The Scrum process is a set of tools to push individuals into interaction
instead of hiding from each other.

~~~
Clubber
Yes, and sets aside a lot of time for them to interact (read not get things
done) for no good reason.

I need interaction maybe 5% in my week. Anything outside of that is just
goofing off. Oh and email works great for that sort of thing (interaction, not
goofing off).

------
heartteams
I've had a lot of success working with teams that use scrum practices and
agile values. Many team members (like several developers and testers) have
actually gone on to become scrum masters themselves at different companies.
The feedback I've gotten is that it's an empowering way to work - you choose
your commitments, team aligns around a goal, priorities stop constantly
changing, teams make time to improve the things that slow them down, etc.

It's hard for people to go back once they've seen it work. The people that
I've worked with have said that when they do move on to other companies they
didn't realize how helpful it was until it was gone. It can seem like some
bullshit, I get it. It's change. It's not a perfect model. Also, when leaders
or teammates behave in a command-and-control and uncollaborative way, it's a
lot less fun.

Biggest personal challenges: connecting team members to real clients,
integrating UX (need more people and up-leveling of team members), too-stable
of teams (I like forming around new ideas and the excitement of that), being
distributed, the language (Scrum Master - really?!!?), perscriptive agile
peers

------
ordinaryperson
What’s that quote from Elon Musk - process is an excuse for large companies to
keep mediocre talent?

Put enough smart people in a room and they’ll figure it out. Scrum isn’t any
worse than Kanban or ‘pure’ Agile or Waterfall or Lean — every system has
tradeoffs and smart people learn to adjust.

No company is perfect. Tell management how the process can be improved. If
they ignore you, consider moving on.

~~~
acdha
> What’s that quote from Elon Musk - process is an excuse for large companies
> to keep mediocre talent?

Isn’t he the same guy who’s been learning that more process is necessary to
make cars safely and on-schedule? I’d be reluctant to draw any broad
conclusion from one optimistic aphorism.

~~~
smackay
But the essential difference is that process applied to manufacturing is about
repeatability, quality, reliability etc. where process in software is more
about communication.

Eventually, maybe, a software process will be more like a manufacturing one
but the variation in technologies, techniques and general fashion make that
hard - even in limited areas such as CRUD web apps. I think you'd get the same
outcomes with a manufacturing process as we currently get with software if
every year you changed the engines, materials, electronics and transmissions.

~~~
watwut
Awesome software development process that is not about communication: testing
by testers. Also code and documentation review. Also, keeping tasks in tracker
and having version controll. Etc.

~~~
jrs95
Code review definitely is about communication. That’s arguably it’s biggest
benefit. The author could test something himself, but code review facilitates
a conversation and keeps people on the same page.

~~~
tonyarkles
My experience is that people often _can 't_ test what they've been doing by
themselves. They've got blind spots and assumptions that they can't see. They
have a mental model for how a feature is supposed to work, and they test that
mental model, but they don't test outside of that model.

~~~
watwut
Yes, this. Programmers are supposed to test their own code. And write tests.
You are not supposed to have bugs for what you thought to test.

Tester is for independent check you forgot about or did not knew about. Tester
is so that you don't stop testing your code due to too much confidence.

Without testing, programmers tend to not have feedback on bugs, tend to think
they don't have them and then tend to produce more bugs in the long term. Not
because they are lazy or bad, but because they are normal humans.

------
Robin_Message
OP here: lots of people have written about problems with Scrum (e.g.
[https://news.ycombinator.com/item?id=16892307](https://news.ycombinator.com/item?id=16892307)
). I'm trying to take a bit more of a systematic, longer, researched and
justified view of things, so any feedback is very welcome!

~~~
jacques_chester
What I've mostly noticed is that when people show up with cynicism or actual
anger towards Agile-with-an-A, perhaps nine times in ten, Scrum was involved
(edit: though this might be sample bias, as Scrum is by far the most popular
methodology).

I'm sure it's working really well for some folks. A large fraction of the
magic of any agile system is the folks involved and their familiarity and
experience with it. I work for Pivotal, our wheelbarrow is XP with Lean
trimmings. I've seen it up close for 4 years in both consulting and large
product development and -- summarising -- it works.

But no small part of it working is the context. Our context is that we hire
carefully and that the entire organisation is interested in, and supportive
of, the way we work. It is fantastically easier to do agile well in an
environment where it is already done well (which is why we ask our clients to
come work in _our_ office).

If I had to pick the most destructive part of Scrum, it's the sprint
commitment. Yes, it's called forecasts now, but folks are held to it anyhow.
All it does is create a dynamic which generates either waste or burnout.
Software should be releasable at _all_ times, not once every two weeks. New
features should be presented to a Product Manager as they are _done_ done, not
according to what is an essentially coincidental cadence chosen because two
weeks is easy to mark on a calendar.

At Pivotal the closest we came to sprints was setting up a quarterly release
cycle for our flagship product, PCF. The first few were a _mess_ and we
massively overshot our planned dates several times. We switched to something
much closer to our normal way of working: release trains. Every quarter we
make a release. If a component product has a feature ready at that time, the
feature gets shipped. If it doesn't, it doesn't. And that's that.

We already have a lot of our customers who've adopted automation to update
their PCF platforms for patches on a rolling basis. My fond secret hope is
that one day, we'll be able to drop the quarterly release cycle as well and
just ship things when they're ready to ship.

~~~
mikekchar
> If I had to pick the most destructive part of Scrum, it's the sprint
> commitment.

I've organised many XP teams that regularly hit our sprint commitments
virtually every time. The times when I've found it problematic to hit sprint
commitments were due to the following:

\- Sprint was too small. 1 week sprints are awesome, but they are extremely
difficult to hit. I run 2 week sprints if I can manage to get people to agree.
It can also significantly reduce planning overhead.

\- Stories were too big. Stories should have a median delivery time of about
1-2 days for a 2 week sprint. The occurrence of 5+ day stories should be in
the 1:100 range. High risk stories should always be arranged first in the
sprint so that even a 5 day story doesn't blow the sprint out of the water.

-Stories were ill-defined. Goes together with the previous point. If you have a really high variance on your stories, it's probably because of this. You should have a "backlog grooming" session once every 2 weeks. At that meeting, you go over any new stories in the backlog and any stories that might make it into the sprint commitment. All developers should attend the meeting. At the meeting you decide: Do you understand what the story means? Could you start coding the story today? Should the story be broken up? It helps if project managers are _not_ in this meeting -- they just respond to the feedback after the fact. Only stories that get the thumbs up, make it into the sprint commitment.

\- Stories did not have acceptance criteria. Similar to the above, but more
specific. Everybody might feel they understand what to do, but if you can't
answer the question "How do I know when it is done?" then it isn't a story.

In the above cases, you can fairly easily fix the problems and still have
sprint commitments. I have also been in some situations where I think sprint
commitments didn't match the team. For a variety of reasons, I really like
sprint commitments, but it is a bad idea to stick to it if it's not going to
work. Here are some situations where I've had problems:

\- Developers had many disagreements about how/when to merge code. They would
take unpredictable amounts of time to merge code. If pressured to merge in
order to hit targets, conflict would eventually erupt in the team.

-There was a young team that did not know how to relax when there is a deadline. Sometimes they merged inappropriate code just because they are afraid to be the one on the critical path. Sometimes the cut corners for the same reason. If you can pair program, it can really help with this.

In these cases, it's a matter of training the team. It helps if you can keep
the team together for a long time and if you have a manager who isolates the
team from a certain amount of surrounding politics. But sometimes, for a
variety of different reasons, it isn't going to work. It's not bad to reach
for something else at that point.

Sprint commitments can be really beneficial in my experience, but it's one of
those things that is the result of having a high functioning team. It's not
necessarily the way to _make_ a high functioning team.

~~~
vinceguidry
How do you organize acceptance criteria? Is it language that has to be added
to every story?

~~~
nradov
Every user story should have acceptance criteria (confirmation). Otherwise how
will you know when you're done? One common technique for organizing acceptance
criteria is to write them in user voice form: "As a <user role>, I want to
<activity>, so that <business value>."

[https://www.scaledagileframework.com/story/](https://www.scaledagileframework.com/story/)

~~~
vinceguidry
Every once in awhile we'll get someone to actually do that. But most of the
time the verbiage in the story summary is the acceptance criteria and if
there's a problem understanding what is expected, the team lead is the go to
person.

I was wondering if there's a lighter-weight way of specifying acceptance
criteria, or a framework for deciding which stories need additional criteria
specification.

~~~
nradov
The Product Owner is accountable for distilling user requirements into proper
user stories, including acceptance criteria. (Other team members can help with
that but the PO is _accountable_.) POs who don't do that consistently need to
be retrained or replaced.

And the Scrum Master has to be a gatekeeper. During sprint planning if a user
story lacks proper acceptance criteria then it stays in the backlog for
further refinement.

~~~
mikekchar
Yes, I think this is exactly right (not just in what Scrum/XP says, but also
in how it has to be). Separating that role is super important and is
potentially one of the friction points in transitioning from a more
traditional setup (as evidenced by TFA). In my experience, it is also very,
very important that the Scrum Master is _not_ the manager of the team. It has
to be someone whose accountability is to the technical success of the team as
distinct from the delivery of high level objectives for the team. In a more
traditional setup that would be someone like a team lead, senior dev or even a
system analyst. XP doesn't define this role specifically and it is probably a
weakness -- I've done it as a coach, but usually I appoint someone on the team
to do it.

Also, interestingly, I've often had project managers who refuse to do the PO
role (I usually call it the "Customer Proxy", but it's the same role). In
those cases I try to appoint someone who is accountable for writing stories.
They consult with the project manager for the higher level "vision" (but in
practice the project manager does virtually nothing -- a state of affairs
which they are usually quite familiar and comfortable with, unfortunately).
Prioritisation of stories is done by the development manager, PO and project
manager (if they are different from the PO). In this case, the Scrum
Master/Coach is not invited to that meeting.

To answer the original question: How do you represent the acceptance criteria?
Personally, I do not like code based representations of acceptance criteria.
Having said that, my entire exposure to them is working on legacy projects
where they have gone badly wrong.

The main problem is the same problem with trying to maintain prose
documentation of the requirements of a large system -- those requirements are
at least as long as the implementation of the system. They are also at least
as complicated. We've slowly created ways of organising production code to
make it easier to manage. The same is not true for BDD style acceptance
criteria, or even prose requirements documents.

At the beginning of my career I spent a lot of my time writing requirements
documents in prose. Every 6 month release would include something like 1300
pages of requirement documents. Maintaining these requirement documents was
impossible. Very quickly they get out of date and so you no longer have any
description of the working code other that the implementation itself.

Based on these experiences, my attitude is that requirements (including
acceptance criteria) are ephemeral. They exist for the life of the story and
then you abandon them (note: I'm still massively in favour of acceptance tests
and unit tests, but implemented as code that is written in a similar way to
the production code -- because we have techniques for managing that
complexity).

Long story short: I write them in prose on the story and appoint someone to
making the determination whether or not the acceptance criteria is sufficient
to add the story to the sprint commitment (as nradov explained in much fewer
words than I did :-) ).

------
starbugs
I think the article confuses what Scrum is and what some (probably most)
companies make out of it. I agree that there are scary things happening in
practice and I've seen a lot of scrumBut and scrumAnd that really endangers a
lot of projects.

My experience is that this is often caused by a lack of understanding of the
methodology and how it can be applied and integrated into existing structures.

Also existing structures need to be integrated with Scrum to make it work.
That is, they need to be transformed to match agile workflows.

The latter is not easy. Especially not in larger companies. I am not surprised
that most do not even try to tackle this.

~~~
Robin_Message
I'm not confused :-) Maybe I don't set it out clearly enough, but I'm
criticising Scrum as it is widely practiced, rather than how it ought to be
done.

And yes, integrating it with the rest of the company is the biggest question,
e.g. if you really are agile, what does your sales team tell customers about
future upgrades?

------
robin_reala
For me Scrum is like training wheels for agile. It’s restrictive and hinders
progress at any real speed, but gives you the framework to start producing
stuff in an agile way. Once you out grow it there are plenty of better
methodologies, include the proper agile way which is that the structure of
your product management is also a component to be iterated. It’s difficult to
jump straight in at that point though.

Just a shame that most teams’ processes crystallise around Scrum. Working with
self described Scrum masters is painful as they’ve built themselves into a box
they can’t see out of.

------
wpietri
This is a good article, but I disagree that Scrum's major flaw is a lack of
hierarchy on the development teams. I've worked on some great self-organizing
teams, and they're more than equal to the product manager. They outnumber the
PM, after all.

The problem only comes in an organizational culture of "whatever the boss
says". In that context, teams rarely learn to self-organize. Instead, the
previously existing control hierarchy stays in place. Before, developers built
whatever spec landed on their desk. Now they build whatever is in JIRA.
Developers in that world can't even conceive of pushing back.

It's my belief that if Scrum had had some strong counter-balance to that, like
an Engineering Master, then it just wouldn't have been adopted. Scrum won out
over the other Agile processes (of which there were several) not because it
produced better results, but because it was the one most comfortable for
medium- and large-company managers. It provided the feeling of transformation
without actually changing anything important. They were doing waterfall
before, which became untenable with the rise of the Internet. Now they do
mini-waterfall, call it Agile, and imagine themselves kings of the world.

~~~
fwip
About a year ago, we went from no-process to "agile?? I guess?"

And let me tell you, a badly implemented process is a great way to turn self-
driven developers into cogs that just do what's in Jira. Getting your tech
decisions questioned by non-tech scrum masters during standup, requirements
that don't arrive till midsprint, inability to deploy anything that hasn't
been specifically inspected by the sole overworked product owner, etc.

It's not intellectual laziness, it's a defense mechanism. You can't be
emotionally invested in your work if the process makes things worse for
everyone, at least not without a good therapist.

~~~
srtjstjsj
> questioned by non-tech scrum masters during standup,

Standup is for raising issues, not answering questions. Standup rules says to
defer discussions to a separate meeting.

> requirements that don't arrive till midsprint,

Not scrum-specific, and scrum requires either (a) not doing that, or (b)
negotiating a trade to remove another requirement.

> inability to deploy anything that hasn't been specifically inspected by the
> sole overworked product owner

Not scrum at all. Scrum deploys every month, as clockwork, with whatever is
built so far.

~~~
fwip
Yes, these are all examples of process done badly.

------
bartmcpherson
Why would you let yourself get so stuck in the minutia of SCRUM? Use the parts
you need and not the parts that work against you.

The value usually listed first in the agile manifesto is "Individuals and
interactions over processes and tools".

~~~
Robin_Message
To quote one last bit of minutiae: "Scrum’s roles, events, artifacts, and
rules are immutable and although implementing only parts of Scrum is possible,
the result is not Scrum."

I agree with what you're saying, but Scrum says not to modify it. That's one
of my problems with it.

~~~
srtjstjsj
> implementing only parts of Scrum is possible

------
MichaelMoser123
[https://age-of-product.com/agile-micromanagement/](https://age-of-
product.com/agile-micromanagement/) another interesting observation along this
line; when the scrum master is a middle manager then he will micro manage the
show - because that's the way he is supposed to function.

Empowering the workers is a good idea, but it is not how most organizations
work.

~~~
dasmoth
A slightly different take on why scrum becomes micromanagement, which has
always seemed revealing to me:
[https://www.mountaingoatsoftware.com/blog/ssssh....agile-
is-...](https://www.mountaingoatsoftware.com/blog/ssssh....agile-is-all-about-
micromanaging)

~~~
MichaelMoser123
I don't know about continuous integration; version control + automatic builds
really helps to prevent the mess that you have without it. I still remember
the nightmare of copying sources from and to a central directory.

~~~
dasmoth
That’s something I’d probably put on the “good servant but bad master”
category. Agree with what you’ve said, but have also seen it start to get
oppressive.

(One pain point is when it is used to hide build/deployment complexity to the
point when it’s no longer practical to build the thing on your own
workstation...)

------
captainbland
I agree with the criticisms of Scrum on the whole. However I find it bizarre
that this article and the other one it links to (which quotes Milton Friedman,
which ought to be enough to raise eyebrows by itself) crticises organisations
which market themselves as non-hierarchical (or in the marketing lingo
'holacracies') when they clearly adhere to hierarchy if you think about it in
any depth, just a badly organised one.

Edit: And I guess my real point here is that Scrum doesn't usually work
because the development team as a whole has no way of pushing back on
decisions made by the overall business hierarchy unless they just go tools-
down.

Then it goes on to crticise Valve for not delivering HL3, despite that clearly
being a successful business (and one where Gabe has over 50% of the $2.5
billion equity valuation... non-hierarchical, sure, whatever you say) -
perhaps all of this emphasis on shipping products as fast as possible and no
emphasis on the service and the interests of staff is the real problem here.

~~~
0xfeba
Yes I thought the jab at Valve was a cheap shot; very poorly supported.

------
mlthoughts2018
It’s often impossible to talk productively about this because of all the No
True Scotsman fallacies uses to defend Scrum, e.g.:

“No _true_ Scrum master would do X.”

“A product owner who doesn’t Z is just a bad product owner. Not Scrum’s
fault.”

“If X is disempowering people then X is not Scrum.”

These are not valid defenses, and they just distract us from the elephant in
the room, which is Scrum’s constant presence everywhere these problems occur.

At some point if the tool cannot do its basic job without requiring perfectly
scrupulous product managers and “real” Scrum masters, etc., then it’s Scrum’s
fault, and we need to think of less prescriptive, less inflexible models that
cannot be so easily subverted politically to merely pay lip service to
technical quality, while bastardizing reasonable principles to serve quarterly
JIRA datamining expeditions and Dilbert-style management practices.

~~~
mindcrime
Oxygen is also present everywhere these problems occur, so clearly oxygen is
at fault...

~~~
mlthoughts2018
Someone proposes a mechanism by which Scrum is problematic.

“In Scrum, product owners ought to empower the team to advocate for technical
quality, but in many Scrums, this does not happen, and short-term, quality-
ignorant changes to the timeline rule instead.”

This is a claim about the _mechanism_ of Scrum’s failure. And in response
someone offers a non-falsifiable defense, like, “whenever that occurs, it’s
always the company’s pre-existing badness to blame. Never Scrum.”

Can you _really_ not see how this is completely different from an unqualified
claim that correlation implies causation?

Your comment comes off like you think it has some rhetorical punch, but I
invite you to reconsider that you migh have completely missed the entire
point.

------
xivzgrev
I LOL'd at this

"Valve is the other famous poster-child of radical freedom. And just as soon
as they release Half Life Episode 3, I'll be happy to take lessons from them
on getting software delivered."

------
pigleg
I wouldn't fault it for lack of technical craft, that's not a specific
statement in the original manifesto, except loosely maybe "working software".
Largely forgotten now since more than a decade has passed, but even the poor
implementation of Scrum has helped shut down the RUP hyper-documentation
madness, massive unshippable releases with hundreds of bugs, etc.

When trying to explain "Why agile?" to new devs out of school, I struggle
"Well... it helps to have been through a soul crushing waterfall deathmarch.
If you read the manifesto after that, you will start to weep for joy." But
they don't really get it.

So i could argue that even when badly done Scrum has improved the success rate
and business satisfaction across the industry. Every couple of weeks the
business gets some new functionality and the devs get feedback. Great! But I
would agree, it's been long enough with Scrum, I'm ready for the next
evolution in this story.

Much of it does also depend on the type of team, product, environment so that
scrumbut customization seems nearly inevitable in my view.

Agree we need a way around the short-sighted prioritization, we've overlain
some classical PM roadmap concepts to make sure we also chip away at longer
term initiatives and debt.

~~~
Robin_Message
In part one of this series ([https://www.lambdacambridge.com/blog/2018-05-how-
scrum-destr...](https://www.lambdacambridge.com/blog/2018-05-how-scrum-
destroyed-agile)) I explain how technical craft was key in all the agile
methodologies, _except_ Scrum. So I think that was part of the thinking in the
original manifesto, but not expressed at the time (fish don't perceive water?)

I suppose you're right that Scrum is better than waterfall deathmarches, but I
hope we can do even better.

~~~
pigleg
You assert that technical craft was key I think by inferring the bent of the
associated methodology of each the people involved?

I don't agree, I think the main aim of agile was to solve the extreme
dysfunction with the business-side and non-technical people, and there it has
succeeded. (This is perhaps also reflected in your observation that XP
interest has ebbed while scrum continues to climb in popularity.)

Have you had a look at the context inthe history statement in the manifesto:
[http://agilemanifesto.org/history.html](http://agilemanifesto.org/history.html)

Quotes from that: "At the core, I believe Agile Methodologists are really
about "mushy" stuff—about delivering good products to customers by operating
in an environment that does more than talk about "people as our most important
asset" but actually "acts" as if people were the most important, and lose the
word "asset". So in the final analysis, the meteoric rise of interest in—and
sometimes tremendous criticism of—Agile Methodologies is about the mushy stuff
of values and culture."

"For example, I think that ultimately, Extreme Programming has mushroomed in
use and interest, not because of pair-programming or refactoring, but because,
taken as a whole, the practices define a developer community freed from the
baggage of Dilbertesque corporations."

~~~
Robin_Message
Fair enough, I agree that avoiding the baggage of Dilbertesque (great word!)
corporations was key.

My point was just that all the methods except agile had explicit technical
requirements. XP required TDD and pair programming which was incredibly
extreme at the time (and still is fairly out there).

These were people meeting up at OOPSLA. They were programmers' programmers. I
absolutely think craft and technical quality was important to them. I think it
was so intrinsically important that they didn't express it clearly in the
manifesto.

But I could be wrong; I wasn't there!

------
agentultra
What are these technical priorities that are being ignored by your team?

I know some examples of cases where the development team was performing poorly
which led to a bad experience with scrum. The symptom is when the development
team asks for stories to refactor some code. They don't want to add any new
value to the system or enable work in a different area: they've just made a
rats nest out of the code or it doesn't live up to their expectations or
guidelines. The cure for that? Set coding guidelines (and not just the syntax
formatting variety: be hard and opinionated on initialization, patterns, and
language features), mentor your team to refactor code after they've got it
working and made their tests pass, and encourage developers to leave code in a
better state than they found it. Also ensure that the business stakeholders
and product managers are not setting unrealistic timelines and expectations.
In time you'll find fewer requests to create backlog items to refactor code.

What else is there though? If your product and team leads are not concerned
with security, performance, or other important factors you need to make them
aware... that has less to do with scrum and more to do with good
communication.

------
ericjwhuang
Robin, most of what you mentioned in your article are true and I agree with
them. I had very similar situations (conversatons may end up with "alright,
this is Product Owner’s call") and I understand most of developers get
frustrated about this. I had been there and I was the developer who got
frustrated, but I managed to change it (yep I also agree Scrum does not teach
us how and we had to figure it out ourselves) by understanding PO, influencing
them about what we proposed by describing value and making a plan for win-win.
It is not a fun journey to be honest, but once you are there (we are not
completely there yet) your team will trust each other and work more
collaboratively. I am really happy to know I am not alone and I have so much
to say and share, if you are interested in it, saw my experience at
[https://medium.com/@ericjwhuang/how-scrum-fails-and-what-
you...](https://medium.com/@ericjwhuang/how-scrum-fails-and-what-you-can-
help-b3073f587537)

------
jarl-ragnar
Scrum is just a simplified process for applying some of the principles behind
lean manufacturing to software engineering. One of the core principles of lean
is - minimize work in progress (WIP). Sprint's are just a way of minimizing
WIP.

Why minimize WIP? Because WIP holds the risk that you're building the wrong
thing. In manufacturing this might be using flawed parts that won't get tested
until later in the process or it might be building inventory that you
ultimately can't sell because the market demand has changed. In software WIP
risk could be a misaligned understanding of the requirements; a flawed view of
what minimum viable product looks like to the target market or a technology
stack decision that represents a performance dead-end. In all of these
examples you want to find out if you've made an error as soon as possible
because if you're wrong then all of the WIP may need to be discarded.

A smart team holding to the core lean principles should feel empowered.
Arguably Scrum, in it's dis-empowering form, is just another process to help
manage mediocre teams.

~~~
specialist
Agile workflow is based on the notion that software can be created thru
progressive revelation. Like Moses wandering in the desert.

But, as you suggest, per the original writings, the real goal was to better
manage upward, and has nothing to do with creating projects.

The alternative is what we gray beards call "have a plan". Well, as much as
any one can plan for the unknown.

------
emilesilvis
Let's do a little thought experiment where we try to stay within the scrum
universe, but try to solve the main problem (developers being disempowered by
scrum) by modifying the scrum framework. As the author states, "So Scrum has a
master, product has an owner, but no-one is empowered to advocate for
development priorities." Let's add another role to scrum called the craft
master. This individual has excellent technical leadership skills and deep
technical knowledge. The craft master's goal is to defend what the team is
doing as a _craft_ (much as the scrum master would defend the process of scrum
itself), making sure that the craft's level of quality is manifested through a
Definition of Done that takes way more of a center stage than it currently
does. Would this be empowering developers?

IMHO, the answer to this question is "yes".

~~~
steveropa
I am on the fence. A master craftsman is awesome to have on a team, but I
worry that, just as understanding of Scrum gets pushed off as the Scrum
Master's problem, craftsmanship would become the craft master's problem.
That's how we get "team leads" and "architects"

------
pjbster
Sometimes - heck, perhaps most times - when Scrum is involved, some
organisations are just too fscked to save. Over time, the "leadership" have
reacted to market forces by imposing variations on processes, cuts, reorgs and
redundancies. The result is a workforce who, even if they were given total
autonomy and unlimited resources, would be unable to turn things around.

Not that these execs would see it like that. Instead, they hear this Scrum
thing has worked wonders elsewhere so they wheel it in and, if it fails this
time, it's clearly the crappy workers who are to blame. "Management was right
about that all along."

I take other commenters' point about strong leadership making a difference.
Fully agree with that. But some situations are simply unrecoverable no matter
how great the team.

------
majewsky
I encourage the author to load this post over a spotty 2G connection. I have
the feeling that some paragraphs (mainly quotes) were just missing for me,
maybe because of failed XHRs. Also, it takes much longer to load despite being
plain text.

------
lispm
> Finally we have this self-organised, cross-functional, non-hierarchical,
> essentially amorphous development team. They are meant to be self
> organising, with no one telling them how to build the product backlog.
> However, they have limited or no say over what is top of the product
> backlog, pressure to deliver something sprint-after-sprint, and no-one with
> the authority to balance the product owner and advocate for developing with
> higher quality. In fact, the whole way Scrum views the development team is
> completely flawed given how real organisations operate.

Setting up the scene to fail, and then, surprise, it fails. Blame it on scrum.

~~~
conatus
"no-one with the authority to balance the product owner and advocate for
developing with higher quality"

In a functional scrum team everyone on the team should be empowered to
advocate this. In turn the product owner should be receptive to technical
improvement because it is in the interest ultimately of the overall project
success.

~~~
mlthoughts2018
These types of replies always strike me as No True Scotsman fallacies, which
are rife in Agile & Scrum.

“No _true_ Scrum team would do X.”

“No _functional_ team would disempower people...”

At some point though, Agile & Scrum cannot be propped up like that.

When the same failures happen again and again all across the industry, it’s
time to admit that _the tool facilitates that failure._

The tool (Agile & Scrum) is the correlate here. Somehow it’s always showing up
co-located with these problems, but we’re never honest enough to step back and
admit maybe, sometimes, with enough evidence, correlation can be related to
causation in this case.

~~~
lispm
A poor organization will find out how to fail in many processes. The problems
are much deeper than at the scrum level.

~~~
mlthoughts2018
This just trades one non-falsifiable defense for another.

First it’s “no _true_ Scrum implementation would have property X.”

Now it’s “any observable badness of Scrum was just ambient badness of an
already bad company bleeding into Scrum.”

~~~
lispm
> no true Scrum implementation would have property X.

That's not the point. Scrum does not say anything how good your organization
is. Scrum won't fix these problems.

Thus you can have a great Scrum setup and still fail.

Of course you can have bad management and a 'true scrum implementation'.

Your mistake is to assume that Scrum fixes all kinds of management practices
or that 'true scrum' also means all kinds of other things, which it does not.

It's also unlikely that specifically bad management practices are especially
caused by Scrum - it might have some negative effects in some organizations -
it might have positive effects in some other organizations.

Scrum is simply not sufficient to be successful - if we want to be successful
Scrum might be a good tool in a certain domain, but we also need to address
the other issues/topics/practices/processes. Most of that stuff is very
independent from using Scrum or not.

~~~
mlthoughts2018
What? I don't assume Scrum should or can fix bad management practices.

I'm saying adding Scrum to already-bad management practices is like throwing
gas on the fire. Scrum doesn't help.

Also, if Scrum is only some kind of special snowflake process that only works
when applied in sociologically perfect companies, well then it's useless.

I'd rather use custom, ad hoc, duct-taped together management practices that
get the job done even in the midst of bad corporate sociology.

~~~
lispm
> What? I don't assume Scrum should or can fix bad management practices.

What? Scrum fixes all bad management practices?

> I'm saying adding Scrum to already-bad management practices is like throwing
> gas on the fire.

There we need evidence that it is actually so. Haven't seen any convincing
data for that.

> Scrum doesn't help.

The sentence before claimed something else: Scrum makes it worse, quickly.

> Also, if Scrum is only some kind of special snowflake process that only
> works when applied in sociologically perfect companies, well then it's
> useless.

True, but that's not the case. Scrum can be used with advantage in average to
good companies - but the reality is that good software product development is
not that easy and has many ways to fail - for example the software could have
a huge security problem, it could have architectural problems, it might not
earn enough money, etc. - nothing which the scrum process will fix. There are
many areas on the management and other levels, which scrum does not address:
payment, office, product, market, hiring, ethics, ...

Scrum is really on a tiny framework addressing a few basic things in small
team organization.

> I'd rather use custom, ad hoc, duct-taped together management practices that
> get the job done even in the midst of bad corporate sociology.

Personally I'd rather work in a company willing to learn how to successfully
develop software in some reproduceable way.

~~~
mlthoughts2018
> What? Scrum fixes all bad management practices?

What are you saying here? I was questioning your original statement that I
mistakenly thought Scrum should fix bad management practices. I do not think
that, and no part of that is a criticism of Scrum. The criticisms are other
things. Your follow-up just seems confused about your own parent comment.

> "There we need evidence that it is actually so. Haven't seen any convincing
> data for that."

I've seen a lot of that evidence, in threads like this, in the original post,
and also empirical evidence in my own work experience with Scrum as both a
developer and a manager across several organizations of various ages and
sizes. I'm not asking anyone to take my word for it though. I'm happy to look
into randomized controlled studies about effectiveness of engineering teams
with or without Scrum. Much like with open-plan offices, I'm confident the
evidence shows zero efficacy (despite huge planning overhead costs and time
wasters) for using Scrum even after controlling for whatever confounders you
think are the scapegoats for Scrum's badness.

It's a good thing we don't have to worry about _what you 've seen_ as our
standard of evidence for discussing this topic, and we're free to make useful
written arguments and discussions, like the linked post in the OP, that also
appeal to important qualitative aspects of the problem, like how developers
are disempowered, or how management always misuses Scrum-related progress
tracking data.

> "The sentence before claimed something else: Scrum makes it worse, quickly."

This is pedantic to the point of making me suspect you're just trolling to
argue with anyone who doesn't like Scrum. Yes, indeed, two different sentences
claimed two separate but compatible and related things. Shocking!

> "True, but that's not the case. Scrum can be used with advantage in average
> to good companies"

You're demanding evidence but then just making equally unsubstantiated claims
in the opposite direction. What's to say that instances of well-delivered
software you've seen weren't done _in spite of Scrum_ rather than _because of_
it. That would need evidence too. And particularly because Scrum requires a
far-reaching and globally prescriptive implementation (e.g. do team planning
_exactly_ this way and _exactly_ on this timeline, estimate your workload
_exactly_ like this, use _exactly these_ meetings, etc.) it strongly suggests
the burden of proof is on Scrum proponents to explain why this is better than
customized, individually and organically developed workflows that teams use
because they are demonstrably working for them.

> "Scrum is really on a tiny framework addressing a few basic things in small
> team organization."

This is abject nonsense. Even a framework that did nothing but prescribe _that
teams must do some form of estimation every X weeks_ would be hugely
overbearing bloatware. Scrum goes so much further, prescribing a huge overhead
of different meetings, a bunch of specific named positions that have to have
specific responsibilities in teams, and overbearing principles that
superficially look small in writing but really are huge bureaucratic
nightmares, like mandating that all teams should be cross-functional, which is
totally disconnected from business realities in many cases, especially for
teams whose sole business value is highly specialized domain area.

> "Personally I'd rather work in a company willing to learn how to
> successfully develop software in some reproduceable way."

This presumes that there always exists some "reproducible way", and that it is
one-size-fits-all for the a whole company. You're just denying the premise
that customized, situation-specific or team-specific workflows could be the
right way.

It's fine if you want to deny that claim as a personal preference or opinion,
but you're just taking that as your own assumption, and then tacitly basing
various claims about the superiority of Scrum on this built-in, hidden
assumption.

~~~
lispm
> I've seen a lot of that evidence, in threads like this, in the original
> post, and also empirical evidence in my own work experience with Scrum as
> both a developer and a manager across several organizations of various ages
> and sizes.

'evidence' found in Hackernews posts?

> I'm confident the evidence shows zero efficacy

this will surely help with selecting evidence, given that you know already the
findings.

> This is pedantic to the point of making me suspect you're just trolling to
> argue with anyone who doesn't like Scrum. Yes, indeed, two different
> sentences claimed two separate but compatible and related things. Shocking!

How about deciding what you want to say: a) scrum makes it worse or b) scrum
does not help?

> This is abject nonsense.

Really? Before we have worked with RUP and Agile RUP. Compared to that Scrum
is tiny.

> like mandating that all teams should be cross-functional, which is totally
> disconnected from business realities in many cases, especially for teams
> whose sole business value is highly specialized domain area.

The team should be cross-functional based on the product the team develops.

> This presumes that there always exists some "reproducible way"

This actually presumes that I identify successful practices which can be
applied in many projects. We did.

> You're just denying the premise that customized, situation-specific or team-
> specific workflows could be the right way.

No, I'm not denying it, but when my team had success with Continuous
Integration, I probably would use that in the next project - when applicable.
It would also be a surprise if in a new project I would need to start from
scratch to completely redesign workflows and team communication, without any
prior knowledge/practices applicable.

I've worked for a few decades in software projects and in software consulting
- often I was responsible for project and team setups. Often developing new
stuff. I can easily imagine that other domains work differently.

~~~
mlthoughts2018
> "How about deciding what you want to say: a) scrum makes it worse or b)
> scrum does not help?"

Both!

> "Really? Before we have worked with RUP and Agile RUP. Compared to that
> Scrum is tiny."

Nuclear submarines are tiny because aircraft carriers are large. And this
means submarines are a good investment.

> "The team should be cross-functional based on the product the team
> develops."

This is ignoring reality in many cases. A team might develop something domain-
specific, like a natural language processing algorithm, but then later the
product requires a web service and a front-end. As a result, management
requires specialist machine learning researchers to spend their time writing
front-end widgets, because "Scrum says to be cross-functional" (and don't even
think of saying the no-true-Scotsman reply, "but that means they're doing
Scrum wrong!" _Scrum_ leads them to that type of thinking).

In many cases, the different functionalities for a single product should
absolutely not be embedded in the same team. Rather, much like in software
design, it's important to separate concerns, and have teams with modular and
clearly defined boundaries between their different and complementary skills.
Then for a single product, parts of it will be worked on by different teams
that each have specialized skill in one area, and can operate independently of
each other because it's not muddied by an artificial requirement for "cross-
functional" skills.

Some other times, Scrum-like cross-functionality is good. That's why Scrum is
wrong to unilaterally prescribe it for every product and every situation.
Sometimes it's good, sometimes it's bad, and teams need to be empowered to
customize according to whatever the case at hand needs, not the unilateral
model that Scrum tries to impose.

> "This actually presumes that I identify successful practices which can be
> applied in many projects. We did."

But then what do you say to people who have identified successful practices
over decades that conflict with Scrum and are mutually exclusive with Scrum's
approach. Scrum worked for you. Great. It didn't work for me.

What's your reaction to that fact? If your reaction is to say, "well then you
did Scrum wrong, because it _always works_ " then you _are_ just denying the
premise that any other solution could be possible, and it absolutely is a No
True Scotsman fallacy.

Can you at least admit that some people have earnestly tried Scrum in a
situation when Scrum is advertised to work, like iterative software
development, and they did not "do it wrong" yet still found that it didn't
work for their team?

~~~
lispm
> Both!

Strange,

>Nuclear submarines are tiny because aircraft carriers are large. And this
means submarines are a good investment.

Not sure what this has to do with Scrum or the low complexity of Scrum, which
fully can be explained in a small book or a week of training.

> This is ignoring reality in many cases. A team might develop something
> domain-specific, like a natural language processing algorithm, but then
> later the product requires a web service and a front-end. As a result,
> management requires specialist machine learning researchers to spend their
> time writing front-end widgets, because "Scrum says to be cross-functional"

Management actually meant: we don't want to spend more money. They fooled you.

Basic knowledge: a NLP developer is not a front end developer. Yes, you can
add and remove people from teams during the runtime of a project.

If your management is too dumb or you are too easily fooled by management,
don't blame Scrum.

> In many cases, the different functionalities for a single product should
> absolutely not be embedded in the same team.

True. But that has nothing to do with Scrum.

> Rather, much like in software design, it's important to separate concerns,
> and have teams with modular and clearly defined boundaries between their
> different and complementary skills. Then for a single product, parts of it
> will be worked on by different teams that each have specialized skill in one
> area, and can operate independently

Sure, this is how silos in big companies try to work. For small teams this is
overkill.

> of each other because it's not muddied by an artificial requirement for
> "cross-functional" skills.

This is not an artificial requirement. Small teams with cross-functional
skills make communication more effective. If you have large problems, then you
need to scale that. But that is all basic knowledge.

> Some other times, Scrum-like cross-functionality is good. That's why Scrum
> is wrong to unilaterally prescribe it for every product and every situation.

Again, basic knowledge.

> Sometimes it's good, sometimes it's bad, and teams need to be empowered to
> customize according to whatever the case at hand needs, not the unilateral
> model that Scrum tries to impose.

Scrum does not impose an unilateral model for all projects. You can develop in
all kinds of ways and Scrum might not be applicable to your domain/setup. You
can even take elements of Scrum - just don't call it Scrum - a daily standup
meeting can be useful in many projects.

> But then what do you say to people who have identified successful practices
> over decades that conflict with Scrum and are mutually exclusive with
> Scrum's approach. Scrum worked for you. Great. It didn't work for me.

Then don't use it. Simple as that.

> Can you at least admit that some people have earnestly tried Scrum in a
> situation when Scrum is advertised to work, like iterative software
> development, and they did not "do it wrong" yet still found that it didn't
> work for their team?

I already said that you can do perfect Scrum and still fail. You can also
succeed without Scrum. It's just more likely to succeed with Scrum in
situations like small team (10 people), product development, changing
requirements, responsive customer, etc. etc.

Also if your team does not like banana, don't feed them banana.

~~~
mlthoughts2018
> "Not sure what this has to do with Scrum or the low complexity of Scrum,
> which fully can be explained in a small book or a week of training."

Earlier you made a disingenuous comparison of the relative bloat of RUP and
Agile RUP in comparison to Scrum. The relative overhead costs of Scrum
compared to those other methods don't matter. Only the overhead of Scrum
compared to low-overhead and low-formalism methods that deliver the same
business outcomes.

> "Basic knowledge: a NLP developer is not a front end developer. Yes, you can
> add and remove people from teams during the runtime of a project."

Scrum, despite not explicitly saying it in any formal documents, facilitates
managers in avoiding adding or removing of the right specialized people, by
creating an expectation that every engineer ought to be trained as a full-
stack engineer, and using language that makes it sound like every team ought
to cover every possible domain.

> "If your management is too dumb or you are too easily fooled by management,
> don't blame Scrum."

How is this relevant? No one mentioned dumb management nor workers who are
fooled by management. We are talking about how Scrum _encourages_ and
_facilitates_ this kind of behavior, even among earnest management and fully-
aware teams. It seems like more of the same No True Scotsman fallacy for you
to presume it can only be caused by "too dumb" management or teams being
"fooled". Yet again, in your description, the bad stuff cannot happen in a
"real" Scrum setup, only in a "bad" one where people are either dumb or
foolish. Defining away your problem.

> "True. But that has nothing to do with Scrum."

False, Scrum explicitly holds it as a principle that teams should always be
cross-functional. Scrum doesn't allow the possibility that e.g. front-end work
for a wide variety of products should be separated into a single front-end
team, and corresponding backend work separated into different backend-specific
teams. It advocates that all teams working on projects with front-end and
backend needs should be both front-end and backend teams. This is very much a
direct problem with Scrum itself.

> "Scrum does not impose an unilateral model for all projects."

This is one of the defining properties of Scrum. A unilateral choice for
sprint length, format and frequency of planning meeting, details of required
story point estimation, daily stand ups, required retrospective, etc. Scrum
doesn't allow omitting these things when they are not useful. There is a
_tiny_ amount of customization allowed (e.g. t-shirt sizes instead of story
points, or 3-week sprints instead of 2-week), but it's meaningless in terms of
what a team actually needs to customize (which is stuff like dropping
estimation all together, and e.g. only hold occasional retro meetings
scheduled in an ad hoc way at the team's convenience, not enforced every X
weeks as part of a sprint).

> "It's just more likely to succeed with Scrum in situations like small team
> (10 people), product development, changing requirements, responsive
> customer, etc. etc."

My experience is the opposite... that adding Scrum in exactly those situations
just means we have to do extra boilerplate work to get the same end product
finished on time, and that Scrum is not more likely to succeed than other
methods.

~~~
lispm
> by creating an expectation that every engineer ought to be trained as a
> full-stack engineer,

This is false. Scrum requires the TEAM to be cross functional for the product
it develops. It does not require each TEAM MEMBER to be cross-functional. Even
'full stack' (a concept not from Scrum) does not mean 'expert on everything'.
Full stack means able to work with front- and backend frameworks for websites.
A 'full stack' developer for example will not be expected to be a NLP or a ML
expert. The full-stack-developer might have no idea about automated
performance tests and he/she usually will not have deep UX skills.

I usually use 'T-shaped' or π-shaped as a requirement for team members.
Horizontal skills enable the person to work in a Scrum team with all the added
stuff (like automated testing, software repositories, task system, continuous
integration, ...). Vertical skills add depths in one or two fields: backend
development with Java, frontend development with JavaScript, agile testing,
business analysis, database admin/programming, cloud infrastructure, etc.

Looks like you are setting up strawmans - another fallacy.

~~~
mlthoughts2018
> “Scrum requires the TEAM to be cross functional for the product it develops.
> It does not require each TEAM MEMBER to be cross-functional.”

It’s naive to approach this in some letter-of-the-law way. Whatever you want
to argue that “Scrum says” the reality of what it facilitates & encourages
(which is the attenpt to push everyone towards full-stack responsibilities) is
different.

> “A 'full stack' developer for example will not be expected to be a NLP or a
> ML expert.“

This is just not how it plays out in big corporate Agile. They _absolutely_
try to combine specialized skills with front end skills. I work in ML & I
can’t tell you how many times I see job ads for “machine learning engineer”
requiring experience in React, devops tools, highly specialized database
internals, etc., with job descriptions listing all manner of wishlist full
stack competencies _in addition to_ PhD-level skill in some machine learning
domain. How these places keep thinking the drives and interests required for
this can coexist in a single person, I don’t know, but they keep it up. Always
in a “fast-paced Agile environment” too.

~~~
lispm
> It’s naive to approach this in some letter-of-the-law way

The principle of a cross-functional team is widely explained and described.
Basically everyone will tell you the same story. Even Wikipedia:

[https://en.wikipedia.org/wiki/Cross-
functional_team](https://en.wikipedia.org/wiki/Cross-functional_team)

> A cross-functional team is a group of people with different functional
> expertise working toward a common goal. It may include people from finance,
> marketing, operations, and human resources departments.

The companies I work for are able to understand that.

> I can’t tell you how many times I see job ads for “machine learning
> engineer” requiring experience in React, devops tools, highly specialized
> database internals

Zero?

I've just searched on monster.com for "machine learning engineer". Hits: 300+
Then I searched for "machine learning engineer" and "react". Hits: zero.

Combinations "machine learning engineer" and "scrum": 8 hits.

I fear your 'many times' is not backed up by reality.

~~~
mlthoughts2018
> "The principle of a cross-functional team is widely explained and
> described."

You are completely side-stepping the entire point and it's extremely
disingenuous. You're acting like because the specific words in a Scrum
principle says "cross-functional team" that it must mean everyone who uses
scrum practices it in the most charitable, idealized way.

Instead, in real companies, terms like cross-functional team, regardless of
any dictionary definition or intention in theoretical Scrum, are completely
subverted for convenience of managers and business people. In particular, it's
taken to mean that if a team needs more expertise in a skill area, it's fine
to require training or expect self-learning in that area from existing staff,
regardless of how wildly inappropriate it would be given their skill set. And
because Scrum doesn't do anything about this, other than to vaguely encourage
"cross-functionality", the problem shows up all the time in companies that use
Scrum and is often amplified by it, with middle managers pushing back that
e.g. my ML team ought to be trained in Javascript so we are "cross-functional"
to write frontend GUI stuff.

When it comes to people with marketing skills, finance skills, etc., then of
course they see them as separate domain specializations worthy of new
headcount to grow the team's skills. But they lump all of software and
information technology into a single huge bucket.

> "The companies I work for are able to understand that."

Your experience has been fleetingly uncommon then, to such a degree that it
does not generalize to common or average situations, and therefore we ought to
discount your experience as too much of an outlier from most of the industry.

Since you boasted about looking on job search engines for these crazy pan-
everything job ads, yet you clearly did not actually look for them, let me do
it for you and definitively prove you very, very wrong on it.

I searched for results containing both 'TensorFlow' and 'Scrum' on Indeed,
sorted by newest, and just walked down the list of results.

<
[https://www.indeed.com/jobs?as_and=tensorflow%20scrum&as_phr...](https://www.indeed.com/jobs?as_and=tensorflow%20scrum&as_phr&as_any&as_not&as_ttl&as_cmp&jt=fulltime&st&salary&radius=0&l&fromage=any&limit=50&sort=date&psf=advsrch)
>

Here are some specific ads:

\- < [https://www.indeed.com/cmp/Thor-Incorporated/jobs/Big-
Data-2...](https://www.indeed.com/cmp/Thor-Incorporated/jobs/Big-
Data-2fcaf5b19857b6c0?sjdu=Zzi_VW2ygsY1fzh3Ma9ZsE4zIT1NTXCwgFBhdjeTC3OPWAcJw9OUC6SQ9eq71cxvHm2XOPIuNx8cplkDcUf5qg&vjs=3)
> This one contains desired skills directly managing scrum teams, IoT
expertise, tons of BI database systems, tons of machine learning frameworks,
among much else.

\- <
[https://www.indeed.com/viewjob?jk=a6693cf7a3422b247&from=ser...](https://www.indeed.com/viewjob?jk=a6693cf7a3422b247&from=serp&vjs=3)
> (This one is for a full-stack web developer that also needs experience in
machine learning frameworks, cloud-based devops tools, "LEAN and Agile/Scrum",
and about a dozen specific frameworks.

\- <
[https://www.indeed.com/viewjob?jk=abe4938edc06babe&from=serp...](https://www.indeed.com/viewjob?jk=abe4938edc06babe&from=serp&vjs=3)
> (This one specifically names Agile, Scrum, JIRA, and Trello, amongst also
listing specific deep learning frameworks, Node.js, Flask, and .NET,
familiarity with healthcare data, 5+ years of ETL experience, and demonstrated
front-end experience.)

\- <
[https://www.indeed.com/viewjob?jk=c231123cf951f128&from=serp...](https://www.indeed.com/viewjob?jk=c231123cf951f128&from=serp&vjs=3)
> (This one lists half a dozen databases, half a dozen cloud frameworks,
Spark, Storm, BigQuery, Theanos, Tensorflow, Keras, Python, R, Scala, C++,
Java, Ruby, Angular, React and then finally lists as the final item, "Drive
agile software development practices (Scrum, Kanban, XP, test-driven
development, DevOps)")

\- <
[https://www.indeed.com/viewjob?jk=4f7f9564892a1c9a&from=serp...](https://www.indeed.com/viewjob?jk=4f7f9564892a1c9a&from=serp&vjs=3)
> (This one lists front-end, Javascript, and Angular experience for a front-
end role, specifically says, "Experience with an Agile development / SCRUM
approach", and then also says "Experience working in a cloud based
environment, such as the Google Cloud Platform (GCP), or the Amazon Cloud and
using languages such as Jupyter and TensorFlow", which indicates a bad mistake
(calling Jupyter and TensorFlow 'languages'), despite the fact that Deloitte
is a huge company that could easily invest more into better effort on
recruiting ads.

There are so many more, 80 results I found on Indeed just with 'tensorflow'
and 'scrum', without even trying more generic search terms or looking on other
sites.

Most likely you did not even search for this, or else just engaged with
confirmation bias when one or two job ads didn't match the pattern.

But regardless, as anyone with experience in machine learning will tell you,
it is extremely common for companies to try to require you to have front-end
skills or train you to have them and then give you crap projects that are only
aspirationally focused on machine learning, or just use machine learning as
crappy hype signalling.

> "I fear your 'many times' is not backed up by reality."

No, you're just in a rush to use confirmation bias to defend scrum without
deeply looking into the points that Scrum critics make. This claim is
trivially disproved, even just from the links above.

~~~
lispm
> are completely subverted for convenience of managers and business people.

That's again is fully independent of Scrum.

> we ought to discount your experience as too much of an outlier from most of
> the industry.

He, now you are 'we' and suddenly I'm alone. Nice trick.

> I searched for results containing both 'TensorFlow' and 'Scrum' on Indeed

You are shifting topics, that's extremely disingenuous. Your argument was
about a 'Machine Learning Engineer' and 'react' knowledge.

Let's look at the job ads:

'Solution architect' \- not a 'Machine Learning Engineer'

'job not found'

'Data Engineer' \- again not a 'Machine Learning Engineer'. no 'react'.

'CTO - again not a 'Machine Learning Engineer'.

'Frontend Developer' \- again not a 'Machine Learning Engineer'.

You also generally seem not to understand job ads. If they list as desired
skills a, b, c, d, e, f, g, h, ... then usually an interesting SUBSET is
required. These skills are often mentioned so that they appear in searches and
to signal people a range of interesting technology.

> I found on Indeed just with 'tensorflow' and 'scrum',

What does that show, again? Nothing. Your argument was about 'machine learning
engineers' doing front end development with react. Stick with your original
argument.

> extremely common for companies to try to require you to have front-end
> skills or train you to have them and then give you crap projects that are
> only aspirationally focused on machine learning, or just use machine
> learning as crappy hype signalling.

Now we are back to front end development. If your 'machine learning engineers'
have to do 'frontend development', they should look elsewhere. The topic is in
high demand and there are lots of better employers which have actual 'machine
learning' projects for engineers.

~~~
mlthoughts2018
> “What does that show, again? Nothing. Your argument was about 'machine
> learning engineers'”

Yes, the linked roles required experience with TensorFlow and other machine
learning frameworks for specific job functionality focused on machine learning
engineering.

Please re-read my comment above because it refutes your earlier comment, in
which you claimed that jobs ads requiring combining inappropriate cross-
functional skill groups while specifically also mentioning Scrum don’t exist,
and offered disingenuous claims about trying to look it up, when just a
cursory search already showed your claim to be wrong.

Here you are again disingenuously acting like the specific job title words are
the only part that matters — that’s ridiculous. It’s obvious from the linked
job ads (which were just the first ads in the list, selected just by clicking
links 1, 2, etc. from the results, i.e. there are _many more_ ) are intended
to function as machine learning engineers in various ways if you read the job
descriptions.

In fact it seems you are _again_ trying to dodge the problem with another No
True Scotsman fallacy. Now you’re saying “no _real_ machine learning engineer
role can have a title such as xyz..”

This seems to be your go-to defense for everything. Just look at examples that
clearly and unequivocally refute what you are saying, then turn around and try
to claim that no “real” example would be like that. Just trying to define the
outcome you want (“Scrum isn’t disempowering” or “machine learning job ads
don’t require front-end skills”) by defining the premise to already have that
outcome baked in (“Scrum is by definition empowering, so disempowerment only
happens when not correctly doing Scrum” or “real machine learning engineer job
ads don’t have other titles or list front-end technologies, so any examples
which do must not be “real” examples.”)

> “If your 'machine learning engineers' have to do 'frontend development',
> they should look elsewhere. The topic is in high demand and there are lots
> of better employers which have actual 'machine learning' projects for
> engineers”

This just speaks to your lack of knowledge of this part of the job market, and
how tons of large companies staff up on machine learning staff without
anything more than a hype-driven, aspirational understanding of machine
learning, and no actual statistics projects to offer the people hired. Often a
hugely credentialed machine learning engineer is tasked to babysit Tableau
dashboards or get added to PagerDuty for answering 2 am alerts for failed
Spark jobs.

Only in very few companies and very few teams do these workers actually get
approval from pointy headed managers to spend time on research or modeling at
all.

Again, I’m glad for you that your experience with ML has been an incredibly
unlikely, pleasant outlier with a company that magically always does Scrum
“the right way” (and where Scrum is never to blame when they don’t), and
where, despite all industry trends, they give good statistics and modeling
projects to machine learning engineers (whose specialties are perfectly
respected).

This is such a fairy tale scenario though that your experience is inapplicable
to reasoning about the more general case of how Scrum itself begets and
amplifies and tacitly permits all sorts of bad practices that it ought to be
expected to reduce. And your experience is inapplicable to reasoning about how
Scrum’s endorsement of cross-functionality is inextricably linked to the way
managers assume any engineer, of any specialty, should take on cross-
functional software responsibilities.

At this point I do not have confidence that you are participating in the
comment thread sincerely, and you are merely attempting to shallowly gainsay
whatever I say without actually looking into it.

Maybe you can’t stand not having the last word or can’t deal with it when
someone refuses to not call you out on your shallow arguments, I’m not sure
what the motivation is. But either way, at this point you’re cherry-picking
isolated comments and then rephrasing them as repeated No True Scotsman
fallacies in which no “real” example of what I describe is allowed, by
definition for you, to contain the bad characteristics you seek to deny, like
Scrum’s inherent flaws or the way engineers functioning in a directly machine
learning capacity are often forced to also have cross-functional skills in
front-end frameworks, devops, etc.

You’re welcome to have the last word if you want it in some follow up to this
comment with the same cherry-picking and gainsaying.

But since I have lost confidence that you’re discussing this in good faith,
and you are without sincere willingness to look into my points, I’m not going
to reply again, and you’re welcome to criticize that choice of mine as well.
If I thought you were being sincere instead of yet another No True Scotsman
attempt to define away the problem, I would continue. I don’t believe that, so
I am disengaging.

~~~
lispm
> Please re-read my comment above because it refutes your earlier comment, in
> which you claimed that jobs ads requiring combining inappropriate cross-
> functional skill groups

Your example was explicitly about 'Machine Learning Engineers' with 'React'
skills. For that you have presented zero evidence so far.

> I’m not going to reply again

I think that's fine, since your last posts were not able to back up your
claims around Scrum leading to making 'Machine Learning Engineers' to work as
'React' programmers. None of the positions you presented were actually for
'Machine Learning Engineers'. Instead you presented job offers for CTOs and
Solution Architects - two very different positions. Since you could not
provide evidence for your original claim, you came up with a different
selection of positions and skill requirements.

For some reason you project all kinds of project failings from staffing to
task selection to the Scrum methodology, instead of looking to yourself, your
team and your management.

------
brlewis
I disagree that the scrum master needs to be a technical leader. Technical
leadership needs to come from the development team. The scrum master mainly
needs to be a good communicator, communicating the value of feature priorities
to the dev team, and the value of tech priorities to the product team.

EDIT: If your scrum master isn't a good communicator, here are some tips for
doing the communication yourself: [https://medium.com/@brlewis/fighting-
technical-debt-in-an-ag...](https://medium.com/@brlewis/fighting-technical-
debt-in-an-agile-team-c48662abf76e)

~~~
maxxxxx
And the scrum master needs to be empowered to do things. In my company the
scrum master has pretty much no authority because the line managers are still
pulling the strings.

------
axilmar
The problem with Scrum is that it tries to solve one problem (the problem
being that business processes are dynamic in nature) with a set of tools that
is not meant for this kind of development (namely, static processes, static
development procedures, static tools).

The actual solution to business needs is to able to create software like a
clay sculpture. I.e. build the software in front of the client, using dynamic
tools, satisfying their immediate needs. There is no need for sprints,
retrospectives, and all the jazz, if we could actually create our software as
dynamically as business processes are.

------
gerbilly
From what I could tell, most workplaces use scrums to enforce a minimum
starting time for all their developers.

They would typically schedule an early in person scrum meeting to defeat all
the devs that like to work late or remotely.

~~~
walshemj
From my experience though using DSDM end of day standups are better.

It also helps where team members have different commutes and stops wasting the
time of early arrivers. I regularly used to be first in the office even though
I had a 70 mile commute to London when compared to my co workers who lived in
London.

------
rhacker
We got rid of most processes. I "think" what we do now is Kanban - I say
"think" because I haven't looked at Kanban closely really. But we look at our
board, and everyone just works on things, and when they are done, we help
assign a new task. When code is done, we roll to QA, when that is done we
merge, and release to production. Issues that get worked on are usually in
production in a couple days. This excludes major refactoring work or risky
items. Those are handled in special unique ways.

------
tuke
This is fine as an opinion piece and a close reading of parts of the scrum
guide, but some kind of evidence (even reports via surveys) would help.

------
_pmf_
Here's a nice situation where the scrum team decided to become self-organizing
and fired the manager who forced scrum onto them:
[https://workplace.stackexchange.com/questions/112596/how-
do-...](https://workplace.stackexchange.com/questions/112596/how-do-i-regain-
managerial-control-of-my-self-organizing-team)

------
parvenu74
The four points of the Agile Manifesto follow the pattern of “valuing the
preferred over the less critical.” Seems to me that a valid — if not
infallible — corollary is that if you practice the preferred TO THE EXCLUSION
of the less critical you’re guaranteed to accumulate technical debt. The more
fastidiously the less critical is ignored the more catastrophic the reckoning
will be.

------
FrankyHollywood
Dave has an interesting talk about it.

[https://m.youtube.com/watch?v=a-BOSpxYJ9M](https://m.youtube.com/watch?v=a-BOSpxYJ9M)

My personal experience is any project where scrum actually works is a boring
project, no interesting problem is predictable.

Fortunately I see mostly frustrated scrum masters, not understanding why
planning fails :)

------
matt_f
Hey folks. Short question: What's better?

I read through a lot of detailed analysis of Scrum's shortcomings in the
comments here, but little in the way of "Instead".

If anyone cares to share his/her vision: based on your experience, what would
be a (nutshell) model for a better system?

Thanks <3

------
himynameisdom
Most of these problems, such as refactoring, lightweight documentation, and
tech debt can be mitigated with a good definition of done and a strong
understanding of the sprint goal, whatever it may be.

This is a classic "Scrum" v.s. "How We Interpret Scrum" hit piece.

------
MrBuddyCasino
Are you working in feature factory? Chances are you're doing Scrum:

[https://hackernoon.com/12-signs-youre-working-in-a-
feature-f...](https://hackernoon.com/12-signs-youre-working-in-a-feature-
factory-44a5b938d6a2)

~~~
sprky
Great article, but but none of it has anything to do with scrum.

~~~
MrBuddyCasino
True, but they're synergistic - Scrum is the natural choice for a Feature
Factory and reinforces all the bad aspects of it, Kanban much less so.

------
roma1n
Is there a prescribed SW development methodology at large technology
companies? (e.g. Google). Google in particular seems to be heavy on tooling
but, perhaps intentionally discards SCRUM et al from the outset.

------
languagehacker
This sounds not so much like a valid argument and more a thinly veiled tirade
against one bad project manager this person has had during their career. Yes,
most by-the-book approaches to agile project management are bad because they
are by their very nature not pragmatic towards the reality of a given
engineering team or product organization. No, that doesn't give you an excuse
to claim that the tens of thousands of individuals (more?) who have made a
successful career out of project management are all incompetent snake oil
salesmen because there happens to be a certification with a low barrier to
entry.

Grow up.

~~~
Robin_Message
I can see why you'd think that. I just want to put on the record that all of
the project managers I've worked with have been extremely competent and a joy
to work with.

The problem is not the people, it's the methodology that gets in the way of
people doing their jobs. The poor implementations of agile that Scrum
encourages are what is devaluing project management, not my post.

------
pbadenski
Milton Friedman famously said that “one of the great mistakes is to judge
policies and programs by their intentions rather than their results.”

------
Graham24
There is no silver bullet. Never was, never will be.

------
ChicagoDave
As long as tech debt stories are created and prioritized and poc’s are enabled
through stories, Scrum works just fine.

------
pbadenski
for your daily dose of reflection replace "Scrum" with communism (or
capitalism if you like) and developers with citizens

------
it
If there's a Scrum Master, what does that make everyone else involved?

