Again, thanks Joaquin for sharing these.
This (insanely long) email is in response to article:
https://michaelochurch.wordpress.com/2015/06/06/why-agile-and-especially-scrum-are-terrible/
Here's my tl;dr of the article: He associates agile with aggressive
management, hyper-focus on individual productivity, stifling developer
creativity, poor code quality, and a lack of professional development.
Here's my tl;dr of my response: Agile encourages humane management,
de-emphasizes individual performance, enhances developer creativity,
can/should improve code quality, and is neutral to positive regarding
professional development.
And with that, I invite you to marvel at my massive wall o' text
Disclaimer/context: I was a professional programmer for a decade before
agile was invented. I have been a strong advocate for agile software
development since 2001, but I remain agnostic about the specific
implementation called Scrum.
I disagree with much of what is in this article. I can see that the author
has been in some highly dysfunctional environments, and he has my sympathy
for that. He pins the blame on agile and scrum, where I see other causes.
I’m afraid that much of my response is the dreaded “that’s not agile!”[1].
But I will try to focus on my own experiences, and will try to comment on
his statements which seem more refutable.
Speaking as a developer, switching to “stories” and “iterations” greatly
improved my sense of accomplishment, rather than stripping it away. Stories
are written loosely enough that I would have to work closely with the
customer (or proxy) to figure out what was really needed (and technically
possible). Iterations allowed me to celebrate every couple weeks that we
had made tangible progress. The typical pre-agile alternative was to futz
around aimlessly for a few months, and then have a few months of all-out
death march, before releasing something that was both late and unfinished
at the same time.
I tend to agree about the pitfalls of open-plan offices. But I was
complaining about those in the 80’s, so I don’t see those as an agile
problem. And if I have experienced “humiliating visibility” into my work,
it was in non-agile environments.
In agile, programmers should never be “jerked around or punished when
things take longer than they ‘seem’ they should take.” If that’s happening,
it’s not agile. Period.
The distinction between business-driven and engineering-driven is a real
thing, although there are some subtleties that I think the author
overlooks. I have seen a lot of engineering-driven organizations make
really bad choices: They can produce things nobody wanted; they can
overproduce things to the point of bankruptcy; they can bounce from cool
idea to cool idea without finishing anything. Basically, either approach
can be done well or poorly. At least in theory, I believe that the business
people (or more accurately the “product” people) can and should understand
the customer, and from that they should be able to guide the team to
satisfy those needs. If the business people ignore technical concerns
raised by developers (including tech debt), then they’re not doing it
right. This idea that code quality suffers under agile/scrum seems to be a
recurring theme.
The author claims that “Architecture and R and product development aren’t
part of the programmer’s job, because those things don’t fit into atomized
‘user stories’ or two-week sprints.” Wow, I disagree so strongly with that.
Especially with Test-Driven Development (of which I’m a huge fan),
architecture is *always* a part of the programmer’s job. Architecture and
code design are ongoing, and require constant attention. The developer is
always expected to find (research?) the optimal design. And I’m not sure
how “product development” could not be a part of software development.
I agree that estimates are often misused/abused. But I disagree that they
are useless or harmful. I wrote a lengthy email in an earlier thread on
that topic.
The author feels that agile methods put programmers in the role of
children. Personally, I have experienced two kinds of non-agile
environments: Those that are more structured (waterfall-ish), and those
that are less structured (chaos/cowboy-ish). In the former, I have felt
like a powerless child. In the latter, I have felt like an out-of-control
teen. In agile environments, I have felt like a responsible adult.
This might be a good place to mention that I strongly believe that
programming is a craft. The output has to be functional, so it’s not an
art. We’re generally not inventing entire new paradigms and ideas, so it’s
not science. We’re usually not applying universal laws and heuristics, so
it’s not engineering. As a craft, those who have the skills and knowledge
should be respected, appreciated, and rewarded.
I dispute the claim that “Agile is designed for and by consulting firms
that are marginal”. Some of the biggest early proponents of agile were
developing in-house
