
Why some software developers hate Agile - aard
https://www.objectstyle.com/agile/why-developers-hate-agile
======
mirkonasato
That's ironic since the Agile Manifesto was originally written by software
developers, in 2001. The problem is that since then - as Dave Thomas put it in
his "Agile is Dead (Long Live Agility)" post

"The word “agile” has been subverted to the point where it is effectively
meaningless, and what passes for an agile community seems to be largely an
arena for consultants and vendors to hawk services and products."

([https://pragdave.me/blog/2014/03/04/time-to-kill-
agile.html](https://pragdave.me/blog/2014/03/04/time-to-kill-agile.html))

~~~
morningseagulls
>what passes for an agile community seems to be largely an arena for
consultants and vendors to hawk services and products.

Worse. I once attended an agile community meetup, and felt like I had just
stumbled upon a weird cult. It's scary to think that there are so many
software developers out there who have to put up with these authoritarian
doctrinaires.

------
jamestimmins
As a developer who has been quite unhappy in Agile environments, I don't
actually think Agile is to blame, which the article alludes to.

I think the issue with Agile is that software is a field in which is difficult
to measure productivity easily. Then Agile comes along and offers the
appearance of making it easy to score and and measure team and individual
effectiveness. Sure it's "supposed" to be for the team to measure their own
effectiveness and empower people to work more productively, but for folks in
management roles, the opportunity to 'score' engineers based on Agile metrics
is too attractive.

Once it becomes just a way to figure out who's not moving fast enough, or
"failing to meet their commitments", of course people will hate it. It gets
changed from a tool into a stick.

~~~
ravenstine
It seems like the measurements used by teams shouldn't be available to
management because they will inevitably abuse that information.

~~~
cjblomqvist
I'll bite. Management always seem to get the crap. To summarize, if engineers
knew how to manage things better than management, why don't they? From my
experience, teams without management seem to complain about that and end up
with bad results. There are more factors at play, and honestly it's very rare
that the engineers sees that (or even acknowledge that they don't know all the
relevant factors, with all the implications that gives).

Of course, just as with engineers, there are good and bad managers. But it
seems pointless to always complain about management being the ones screwing it
up all the time.

~~~
jamestimmins
Yeah I don't mean to imply that it's _managers_ per se. Management seems
suuuuper hard and I wouldn't want the task of assessing engineering
productivity.

I just mean that the "metrics" put out by Agile give the illusion of something
useful to managers. It's totally understandable that folks in positions of
authority would attempt to make use of them. But I think the illusion of
objectivity is more damaging to teams than the acceptance of uncertainty.

~~~
shantly
I'd say that attempting to use the same tool to help a team communicate with
one another _and_ to communicate with management or stakeholders who aren't
very close to the project (involved daily near the ground level) is
essentially doomed. Management will either hate the answers they get or
they'll ruin the tool's utility to the team, resulting in worse communication
_at every level_ and slower work. Or both.

It's where I think Jira and other do-everything tools that try to be useful to
both ICs and management fall down hard, every time I've seen them used.
Management wants to see their burndown charts and such. They want projections
out months on minimal data. They want to see the performance of people, not
teams. Points become BS because everyone knows they're being watched. Totals
are missed the first few sprints (of course they are, you're still calibrating
WTF a point means for this team and this project!) and management gets pissy,
exerts more control, implies ICs are failing at their job, project goes
downhill from there. But look, we're Doing Agile! Such professionals we are.

~~~
ryandrake
As a project manager, I _hate_ taking a bug tracker and trying to beat it into
being a project management/communication/measurement tool. The only reason I
always end up doing so is that bug trackers are already in the engineers’
daily workflow so they are usually the source of truth about the project.

I’d love it if developers would be willing to collaborate using a dedicated
project management tool and leave the bug tracker for bugs, but the chances of
that happening voluntarily are nil. You gotta go where everyone else already
is.

~~~
shantly
> I’d love it if developers would be willing to collaborate using a dedicated
> project management tool and leave the bug tracker for bugs, but the chances
> of that happening voluntarily are nil. You gotta go where everyone else
> already is.

What'd that look like, that's different from what they do now? Trying to
imagine what developer input to that would look like. I think a lot of devs
already feel like existing PM tools they use for sprint tracking and such are
worse than if they pushed more planning into git or somewhere otherwise closer
to the code, so getting buy-in might not be _so_ hard if devs got to be a
little less heavy in a bunch of not-actually-that-useful-to-them tools on a
day to day basis.

~~~
ryandrake
Could be something as complex as MS Project or simple as a shared spreadsheet
with rows for each project and columns for each milestone or for things like
ETA, dependencies we’re blocked on, escalations needed, scope changes, etc.
Not sure how that could gel well with a source control tool but I’m all ears!

I think 1/4 of the challenge is what tool to use and 3/4 is convincing and
motivating people to be reliable and forthcoming with accurate information. A
good project manager demonstrates he or she can add value, unblock things,
escalate and communicate appropriately, and not just be the Project Police.

------
war1025
We moved to Kanban a few years ago and I think it's been much nicer than the
"sprints" we used to do.

There is a board. The board has a prioritized list of things to do. You work
on your thing until it is done. Then you pick your next task based on where
the priorities currently sit.

It's really not far off from the "sprint" idea. The main difference is it is a
constant re-balancing rather than an every X weeks affair.

~~~
wvenable
There is always a list of things to be done and it's usually prioritized and
often the highest priority item is what you do next. This isn't unique to
software. It isn't even unique to white-collar jobs. Why does that even need a
name?

~~~
haolez
Kanban goes a little further in my own experience. Here are some things I’ve
seen in the wild:

\- make sure that developers have some slack time, so that they can cater to
their tools and study new things

\- never move back an item to a previous column. If something more important
came up, you “cancel” the current task and start the new one. This helps to
identify bottlenecks

~~~
ChristianBundy
> never move back an item to a previous column. If something more important
> came up, you “cancel” the current task and start the new one. This helps to
> identify bottlenecks

Could you explain this a bit further? I'm imagining three columns, todo /
doing / done, and I'm working on a widget when I'm asked to put out a fire.
I'd imagine that the fire is moved from todo to doing and that the widget work
is moved from doing to todo, but it sounds like you're advocating for
something different.

Could you explain more about it or link to resources that might help me
understand? Thanks!

~~~
haolez
You need a mechanism to keep track of your unpredicted interruptions, so that
you can improve your process continuously (which is what Kanban is about).

Moving items back makes this harder (although possible). What I saw some teams
doing was to mark such items as cancelled, explaining in the tickets why they
got cancelled, so that a manager can then see which columns (i.e. steps of a
process) are interrupted more often. This could point to a bottleneck in this
process.

In the near future, the "rest" of the cancelled ticket would make it back into
the backlog as a new ticket entirely. This has the added benefit of keeping
your backlog cleaner.

~~~
nefitty
I will try this today with my own personal kanban board. I do find myself with
cards moving back and forth a lot. The way I've dealt with "Cancellations" is
I have a list called "Waiting" where I stick tasks that are blocked. Sort of
like pending review but it could also involve waiting for a resource, a
response, etc.

I think if I implement cancellations with details it could help me figure out
what processes are broken that caused fires(i.e. this report is suddenly due,
overriding everything else. Did I miss a memo? Do we have a solid process for
anticipating these sorts of reports in the future? etc.) I could then go back
during some planning time to view what needs some brain time.

Thanks for suggesting this!

~~~
haolez
There is another hidden benefit: sometimes a ticket that is moving forward and
backward is a fat ticket that should have been a few thinner ones.

When you recreate a ticket that was cancelled, you are compelled to review its
scope and adjust accordingly.

~~~
ChristianBundy
This makes a lot of sense, thanks for taking the time to explain.

------
mindcrime
Here's what's interesting... of all the people screaming about how much they
hate "Agile", pretty much none of them are proposing any alternative. And if
they _did_ propose an alternative, how much you do you want to bet that it
would look an awful lot like ... wait for it ... the Agile Manifesto?

It's been said before, even in this thread, but "Agile" as it's practiced
today is not the "agile" of the Agile Manifesto. The problem is ignorant
managers and consultants who don't actually know anything about how software
is developed, want a buzzword to slap on to what they're doing to CYA, and
will do stupid shit no matter what it winds up being called.

~~~
quanticle
The problem is that the "agile" of the Agile Manifesto is underspecified to
the point of uselessness. I'll quote the Manifesto in full:

    
    
        We are uncovering better ways of developing software by doing it
        and helping others do it. Through this work, we have come to value:
    
        Individuals and interactions over processes and tools
        Working software over comprehensive documentation
        Customer collaboration over contract negotiation
        Responding to change over following a plan
    
        That is, while there is value in the items on the right, we value
        the items on the left more.
    

That's it. That's all the manifesto gives us. In a real sense, _any
methodology at all_ is "not agile", since agile values individuals and
interactions over processes and tools. But while that _might_ work for a small
team, it's a recipe for disaster in any kind of larger organization.

~~~
mindcrime
Right. which is why I argue that it is important to quit referring to "Capital
'A' Agile" as though it's an actual methodology in and of itself. Agile really
just refers to a family of (loosely) related methodologies which purport to
adhere to those principles to varying degrees, and where different
methodologies make more sense in different settings. Collapsing all of this
discussion under the umbrella of "Agile" elides the point that there actually
are different approaches for different kinds of organizations, and different
projects.

------
all_usernames
Developers don't like:

* Committing to dates and then being accountable for the results

* Spending time planning, rather than "doing"

* Admitting to business leaders that much of their work time is not spent writing lines of code, but dallying in all the interesting byways of the field, favorite websites, pet projects, and random semi-related technology interests

* Sitting in meetings of any sort (sprint planner and retrospective)

* Having spoken, out-loud disagreements and negotiations in order to arrive at a consensus (sprint point estimations)

* Having their mistakes, miscalculations, lack of planning visible to everyone on a big monitor (sprint board / retro)

* Getting out of their chairs to go talk to someone else in order to remove a blocker or understand a dependency (task estimation and completion by end-of-sprint)

* Anyone involved in the process that isn't a coder (Scrum Master, Project Manager)

~~~
cloverich
Developers dislike:

\- Loosely estimating dates, then having management set them in stone

\- Spending more time talking about things than it would take to do them
("planning")

\- convincing business leaders that engineering is more than just writing code

\- sitting in meetings that add little value to the team

\- arguing over made up numbers for vague deliverables

\- having their mistakes, miscalculations, and other normal aspects of
software development enumerated and held against them, as though it was an
actual problem

\- having "scrum masters" come up with straw men to justify even more process

\- reporting to too many non-technical managers

The last point sums most of it up though. In many orgs, Agile is used as an
attempt to compensate for lack of technical leadership, as though process can
obviate the need. You need some, most, or all of your management and executive
team to have technical foundations, depending on how technical your product
is. You wouldn't put a football coach in charge of a coal mining operation
(forgive the hyperbole). The same principle applies to software.

------
GuB-42
Software developers, like everyone else, hate bad managers.

Good managers don't do "agile". They just manage. They may use techniques that
fall under the umbrella of "agile", but in reality, they just do what the
situation calls for.

Bad managers followed a course about the latest trendy methodology and pick
only the parts that that can be directly applied, ignoring the context
completely.

Books describing a process do it on an idealized case. It is like everything
is perfect except for the well defined problems that need solving. But "by the
book" situation is extremely rare. When it happens, it is the mythical
"$methodology done right". In practice managers have to mix and match
techniques for a real life situation, where nothing is perfect, but nothing is
hopelessly terrible either.

------
MikeTaylor
Developers love agile. The thing they hate is Agile. Which is completely
different. (Notably, it's not agile.)

~~~
quotemstr
Indeed, but this criticism suffers from the no-true-Scotsman fallacy. Better
to just eschew anyone who endorses "agile" no matter how persuasively he
claims to practice the one true actually-agile Agile methodology.

~~~
JimDabell
> this criticism suffers from the no-true-Scotsman fallacy

It really doesn't. Most of the things people hate about capital-A Agile are
things that specifically go against the agile manifesto.

Take a look at the Scaled Agile Framework (SAFe):

[https://156s6k36aesz1w6oyx474wo9-wpengine.netdna-
ssl.com/wp-...](https://156s6k36aesz1w6oyx474wo9-wpengine.netdna-ssl.com/wp-
content/uploads/2018/07/46BP-FULL.png)

It's an atrocity of an overbearing bureaucracy created by a committee of
consultants that obviously fetishise process.

Take a look at the agile manifesto:

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

Its very first principle is:

> Individuals and interactions over processes and tools

Take a look at the rest of the principles and compare them to that diagram.
SAFe is clearly the opposite of agile. It calls itself "Agile", but it's as
non-agile as is possible to get.

What we have here is not the no-true-Scotsman fallacy, it's somebody
rightfully pointing out that somebody born in Australia, who has never left
the country, with no heritage that comes anywhere near the northern
hemisphere, is not, in fact, Scottish.

~~~
quotemstr
Sure. Yet every single time an organization tries agile, the result is a
dysfunctional mess. After this history of pain, " _real_ agile isn't like
this!" has just as much legitimacy and persuasive power as the old " _real_
communism has never been tried" line.

~~~
JimDabell
> Yet every single time an organization tries agile, the result is a
> dysfunctional mess.

This isn't true though.

------
zippergz
I dislike Agile, but let's not operate under the assumption that removing or
changing the process is going to stop "the business" from wanting more
features, faster. There is no process that will make that go away.

~~~
arwhatever
[https://dilbert.com/strip/2005-11-16](https://dilbert.com/strip/2005-11-16)

------
digitbuster
Agile Fails for the following reasons. 1) In reality, most stories/tasks that
make it out of the backlog and into sprints are the ones that were inserted by
PM's, that support the short term goals placed on the PM. End result, massive
technical debt in short order. Even if developers express the 'need' for
refactoring, it gets delayed as the PM doesn't get fired for a messy code
base, but gets fired for a late deadline. 2) Companies 'turned' to "SCRUM" and
imagined/expected that by renaming meetings to "stand-ups" etc.. their
productivity would increase significantly. This usually resulted in management
blaming their engineering staff for their own follies. 3) Most Biz
environments don't lend to a 'perfect' scrum model, as such, many
organizations try to 'shoe-horn' practices in situations where it doesn't make
sense. For example, an organization may not have the ability to adjust
features or timelines, resulting in stories being a convenient way to blame
engineers for poor decisions outside of their control (Sales selling products
that don't exist and promising it yesterday, or Product demanding features
that are unrealistic, etc..). 4) Another buzz word that has little functional
value other than to help 'experts' get promotions, who in practice are nothing
but glorified PM's with a pinch of snake-oil salesmanship.

~~~
mindcrime
_Agile Fails for the following reasons. 1) In reality, most stories /tasks
that make it out of the backlog are executed on, ones that were inserted by
PM's, that support the short term goals presented to the PM._

This is a classic example of the problem we're fighting here. Agile is _not_ a
methodology and it does _not_ mandate use of stories, a backlog, scrums, etc.
Those things are artifacts of one particular methodology which purports to be
an exemplar of "Agile" \-- that being Scrum.

I really feel like most people saying "I hate Agile" really mean "I hate
Scrum".

------
tomnipotent
Agile is like HR - everyone thinks it's supposed to benefit the
developer/employee. It's not. It exists to benefit the company.

Agile was created so that consultants could provide better estimates to their
clients in a field that was incredibly new, at a time when methods of
evaluation were based on things like construction (think Gantt charts).

Its primary focus is on communication and setting expectations, which is
critical when dealing with non-technical stakeholders that think everything
should take a few hours. Everything beyond that is a bunch of bullshittery to
sell books, conferences, keynotes, courses and certificates.

Search for the word "consultant" or "client":

[https://agilemanifesto.org/authors.html](https://agilemanifesto.org/authors.html)

------
ngngngng
My favorite response when Product Managers bring up that business needs to
know when a feature will be done is "And I would like to know Apple's stock
price in 6 months."

I really believe this accurately communicates how difficult it is to estimate
software development timelines. You can't estimate unknown work, and unless
you're building wordpress blogs, your work in software is unknown.

------
DHPersonal
A lot of the conversation in the links shared in the article seem to be
repeating the lessons learned by an author of a different article recently
posted on Hacker News: [https://barryhawkins.com/blog/posts/the-myth-of-
commoditized...](https://barryhawkins.com/blog/posts/the-myth-of-commoditized-
excellence/)

------
all_usernames
The idea referenced in the blog post that sprints are "rushing" developers is
just nonsense. At least in every sprint process I've been a part of, the
developers are the ones assigning effort (points/hours) to each task. The dev
team is free to decide how much padding any task deserves to get the job done
right -- and some padding is totally legit and expected.

If you have a large task, one that's either too complex to estimate accurately
or with too many unknowns or outside dependencies, you should be breaking it
up into smaller tasks.

Developers decide how many points they can do in a sprint, AND they decide how
many points each task gets. There's no rushing involved here.

~~~
alexis2b
Except maybe for the point that humans are notoriously bad at estimating
creative work and biased in the shorter side... So taking estimations as
commitment is indeed a way to short-hand the one estimating. Thus the rush
when you realise your naturally optimistic estimate became a deadline.

------
ajnin
I've had one great experience working in an "Agile" team using the Extreme
Programming method. I have fond memories of pair programming, starting work by
writing tests with the business analysts, and focus on principles : DRY,
YAGNI, no hesitation to refactor what needs to be. The driving forces were
those principles. My other experiences with SCRUM, on the other hand have
either been deeply dysfunctional, or just plain devolving into churning
tickets. The driving force were metrics, velocity, charts.

I agree with one of the conclusions of that article (but not the title) :
Agile has been taken over by SCRUM, for most people now Agile = SCRUM. However
SCRUM is so successful precisely because it fits into the existing
hierarchical structures, it gives the impression of control to managers who
don't understand what software development is about, and it avoids having to
profundly question corporate organization. It's at its core a management
technique. If all implementations of SCRUM get it wrong, then SCRUM itself
must be wrong.

I think an alterative way of doing things would be to create small teams that
incorporate both programmers and business people, without product owner or
project managers or hierarchy. The work would be focused on one specific
project and driven by principles of craftsmanship. I've yet to try this idea
in the real world...

------
invalidOrTaken
The missing ingredient in 99.9999% of "Agile" shops is developers having
_hand_ in the relationship.

That's it. I realized a few weeks ago that I've been lucky to _almost always
work under other engineers_ , nearly my whole career. Magically I become a
thousand times more persuasive and articulate! (I didn't, I just have an
audience with better priors).

One developer-stakeholder relationship to keep in mind is Google-consumer.
When was the last time Google had to endure a call from you asking about
"velocity?" ...never. And this is because Google has a zillion dollars and
will continue on merrily if you die tomorrow. (Yes, Google has meme problems
like killing own products, releasing too many things, etc. The point is that
_you are not an active impediment to their development cycle_ )

The best way to Do Agile is to have engineers hold >50% voting stock in the
company, _and_ for the company to be in a position that it can say FU to any
particular client.

Actual agile is not rocket science, nor is it magic---you still have to make
tradeoffs, test with users, etc. It's just that you're doing those things from
an informed point of view, compared to the alternative where decisionmaking
power rests with those incompetent to wield it.

There is of course more to business than engineering. You _also_ want >50% of
the voting shares to be able to read an income statement, (and, in small-
enough businesses, to understand the value-add of accounting at all!) and
whatever metrics keep the lights on (CAC, etc). Yes, to effectively manage
complex businesses turns out to be complex!

------
rinchik
Devs LOVE Agile, the ideas behind Agile and the agility itself.

What devs hate is cargo cults. When management slaps "agile" sticker on your
team while having no clue what Agile is about, it's called deception,
misrepresentation, misinformation, and exactly what people usually "hate".

You direct your disappointment towards wrongly placed label, not Agile. Hate
your incompetent management instead.

~~~
crimsonalucard
I hate agile. And I'm a dev. This is not a matter of hating the wrong thing or
not knowing what agile is.

I literally hate agile, i think the definition of agile is loaded.

I propose a new form of project management called "Relativity." The definition
of relativity based project management is effectiveness. If something is not
effective don't do it, if something is effective do it. Wait aren't devs doing
this anyway? Is putting a fancy word on top of this obvious concept pure BS?
Is this what agile is doing? No it can't be BS. Not when people can take a
class for it. Once a class is made for "Relativity based project management"
you know it's no longer BS.

~~~
mindcrime
So which principles from the Agile Manifesto do you disagree with, exactly?

And what is the alternative that you would prefer?

~~~
alkonaut
One alternative I prefer: not specifying any deliverables or deadlines at all.
It’s just that mangers often have a hard time selling that to stakeholders.
But if you _can_ be in that process, it’s fantastic.

That is “our product is great, but it’s going to be outdated in 10 years, so
we’ll put you 5 devs in a room to try to build the Next Big Thing”.

I did that and it was great.

~~~
kthejoker2
Yeah, a process like this is applicable to maybe 5% of development projects
out there, and is definitely not ripe for abuse by all and sundry in the other
95%.

Demonstrate you're producing valuable work on a regular, fixed cadence. Use
whateve process you want to do so.

The hard part is defining value somewhere below "the whole project is done."
Harder than it sounds, people get it wrong all the time, astoundingly so,
almost to the point where I'm convinced it's some sort of evolutionary defect.

~~~
alkonaut
Completely agree. But here is the thing: as a developer I'm probably going to
dislike any process that management and stakeholders agree is viable. It's not
that I expect to find myself in any kind of non-viable process, but I also
don't expect to not dislike it.

------
kabdib
There was a big push for Agile in my old group at Microsoft (no names here).

It was basically micromanagement. I saw hours-long, daily meetings by PMs and
managers who were digging into the "velocity" of individual developers. They
would still add and remove work mid-sprint, and generally treated estimates
hard commitments rather than, well, _estimates_. You'd get a _talkin ' to_ if
they thought you were behind.

Mgt: "We need that Frobicle system done in a week."

Me: "What. This is mid-sprint. You're changing things up? And what the heck is
Frobicle?"

Mgt: "Don't care. Our estimate is a week, go do it."

Me: "Repeat: What is a Frobicle? Is there a spec? Someone I can talk to? What
color is it? Is it animal, vegetable or mineral?"

Mgt: "A week."

Our mandated daily stand-up was actually just a PM getting the team together
in a hallway while he polled us and wrote down our status, grist for those
aforesaid meetings. I got our PM to say, "Time for status" instead of "Time
for standup" because the meeting was useless to our team. Eventually I just
stopped going, and a few other developers did, too. We were doing our own
scrums, informally and as we needed them.

Naturally there was still crunch time. I'm actually okay with that, as long as
management doesn't try to deny that crunch time is happening, and limits the
damage to people and the organization, and doesn't do it continuously. A bit
of crunch every six months to a year is fine, while a crunch at the end of
every sprint is NOT, and that's where things were headed about the time I
left.

Agile brings out the worst in management.

~~~
yoz-y
Throwing this on agile seems like a stretch. Kind of reminds me of the recent
article about Commoditised Excellence. As soon as you slap a name on
something, people will use it willy-nilly everywhere and then blame you.

~~~
kabdib
The effort started out as "agile" and then turned evil six months to a year
later.

Scrum planning sessions, scrum masters, funny hats, we had it all. It's not a
stretch.

------
thrower123
Agile is fine if it is an organic, bottom-up process. And as any of the
founding Agile gurus like to profess, this was the original intention.

The problem is that it is usually implemented as a centralized, top-down
imposition by management. The net result is usually just a tax on productivity
to ever more process, paperwork, status updates, and meetings.

~~~
jvagner
I built a from-the-ground-up agile/scrum process workflow for a team shipping
a monolithic enterprise app that had a complex build process. Our productivity
sky-rocketed. We went from semi-annual production deliveries to monthly ones.

Management didn't skip a beat -- they pivoted to new and innovative ways to
push against the guardrails we built for requirements, approvals, agreements
and deadlines.

In this case, neither agile nor Agile were the issue.

------
SamuelAdams
> Some of the most frequently-mentioned problems with Agile are: Agile ignores
> technical debt;

This isn't a problem with Agile. This is a problem with the management in your
organization. I worked at an org that implemented Agile into 5 sprints.
Sprints 1-4 were focused on the business work - things that deliver value to
the organization. Sprint 5 was an "IT" sprint, where the developers owned the
priorities and had time to fix things like technical debt. This worked pretty
well.

> frameworks like Scrum are just “red tape,

Yes, companies need their people to operate in a predictable way. This isn't
the wild west - you need to be accountable to the people you report to. These
"red tape" processes are just regular checkpoints with various people in the
org to make sure everyone is on the same page.

Waterfall had this too, except the checkpoints were every 1 - 3 months.

I think the bigger problem is that some software developers don't want to be
accountable to people. They just want to do their own thing, like Joel Spolsky
recommends with his staff at StackOverflow. It can work great, in the right
environment. But the vast majority of companies do not operate this way.

> programmers are asked to commit to arbitrary estimates and deadlines

This has been as old as software itself. I've been on a waterfall project
which had "things that needed to be done" and those things had zero detail in
them. Yet I was asked to come up with a "ballpark estimate" by my PM. When I
had zero idea what it was about, who it would interact with, etc.

> never get the time to think thoroughly about the features they’re creating.

So add a Spike and give it a two week estimate so you have the time to do
whatever thinking / analysis you need to do to come up with a solid plan.
Spikes exist for a reason - not everything on the backlog needs to be a
feature.

------
jwildeboer
Devs are such a special kind of people that you should just leave them alone?
#sarcasm

I for one like where we are heading with things like Event Storming/Modeling.
I admit I care more about solutions than spending time on perfectly describing
a problem. Stop the navel gazing. IMHO. Agile tries to solve the Big Issue.
Communication.

------
disillusion
I've been a developer in both good and bad Scrums. Usually, the difference
boils down to one or more of these points:

\- Is the product owner any good? (physically present, has mandate, shields
the members from company politics, open to story input from the team; like
taking care of some tech debt or swapping stories around to fit developer
needs, setting requirements that are not too rigid)

\- Are the team members any good? (physically present, self-sufficient,
experienced enough or with a buddy, communicate open and clearly with the
product owner and other team members / disciplines, flexible enough to produce
a balanced result within the requirements)

\- Is the scrum master any good? (physically present, proactively alert for
difficulties in the process or team, encourages interdisciplinary pragmatic
solutions, expectation management product owner, balances the needs of the
team vs the needs of the product owner, enforces 5 minute standups in the
morning and a good but short retrospective after a demo)

\- Is the project any good? (realistic budget and MVP, enough room for
creativity in development and design, good reason for existence, stakeholders
that show up for demo's and stay for the drinks after)

\- Is the location any good? (a reasonably creative environment, preferably
where stakeholders cannot make surprise visits, with an open floorplan so
interdisciplinary communication is encouraged, with all needed materials and
enough room on the walls for a scrum board, a burndown chart and to drown them
in things like post-its, designs and technical schematics)

\- Is the timing any good? (one to two sprints minimum to get the team oiled,
not more then 3 days a week - so the other 2 can be spent at a lower tempo, no
team members with large attendance gaps or shuffling people in and out, not
more then 12-16 sprints because if the project needs more then clean it up,
have some downtime, and start a phase 2)

I probably forgot something, but I believe these are the main issues that can
really influence the success (and pleasure within) a scrum. One or two issues
can be worked around; any more and the project is a drag or even a bust.

------
hi41
Agile was misery for me. There were 5 managers on the call and just two
developers. The managers were taking status from the developers (me and
another guy). The deadlines were measured in hours and it was just horrible to
be on those calls.

------
ohduran
I've got mixed feelings about this article. Sure, I hate the idea to be force
to meet unrealistic deadlines, but that doesn't come from Agile. It is a
condition imposed by markets. Sure, in the long term, good quality code,
whatever that is, trumps anything else. But that analysis doesn't account for
the fact that those that don't fare well at the beginning...perish!

As in "we'll do it slower than the competition, but in two years they're going
to be in a spaghetti code nightmare". Possibly, but YOU WILL BE GONE.

------
fuzzy2
I'm currently part of a team implementing a "next-gen" HMI on an industrial
machine. There are too many new technologies, not enough experience and no
existing work.

Trying to squeeze this development effort into a Scrum workflow has produced
all the problems mentioned in this article. I feel that we're producing a huge
pile of crap that will come down on us sooner rather than later.

Our Certified Scrum Master is almost always absent.

It's just tiring.

------
Ididntdothis
Just read the Agile Manifesto. Most likely whatever your company does has no
semblance to what the manifesto says meaning it’s not agile other than the
name.

------
pdpi
I find that every single discussion I ever read about agile misses the point,
both on the side of its defenders _and_ its detractors. Agile is about one
thing, and one thing only: alignment between stakeholders.

Every single one of the twelve principles is either a truism that applies to
any and all situations ("Build projects around motivated individuals (...)",
"the team reflects on how to become more effective (...)"), or are
observations about where consulting-like relationships go wrong, and simple
strategies to mitigate those problems.

If you have an arm's length relationship between yourself and the business
stakeholders, where the business stakeholder (knowingly or unknowingly) has a
poor understanding of what the solution to their problem looks like, where
iteration is cheap, and where partial success is materially better than
nothing, then agile could work for you. This is common for consulting, but a
lot of product-like projects look like this as well, and agile might actually
be a good fit for product teams.

It doesn't work for a lot of environments, though.

In security/safety-sensitive environments, and many hardware-adjacent
environments, iteration isn't cheap. Infrastructure work often has long lead
times before the first milestone that can be meaningfully delivered to end-
users for feedback, and the engineering team is also the stakeholder with the
best understanding of the requirements. In cases where the business
stakeholders are internal to your company, and they have a really good
understanding of the work that needs to be done, the default agile posture is
to keep them at arm's length where a better strategy might actually be to fold
that business stakeholder into the development team.

------
yyyk
The Agile manifesto is fatally flawed, though for rather different reasons
than the ones typically given.

Agile was started by software developers, and everything in the manifesto is
very strongly tilted to how software developers do things and for bottom-to-
top (or at least shallow) organizations devs like. However, every existing
software company has much more of a top-to-bottom structure and is run by
managers. They even have people who are not managers or developers!

Every 'twisting' of Agile is a completely natural outgrowth of trying to fit
Agile to how organizations are actually ran and how people who are not
software devs need to do things. That exactly is 'true' Agile, because
business as structured today cannot support any other Agile you might conceive
of.

That's why Kanban is so much more appreciated - it wasn't conceived in denial
of how businesses are currently structured.

P.S. The other option would be to built the business to support Agile and not
the other way around. For better or worse, almost no existing company actually
works that way and that's not going to change.

~~~
yyyk
snarf21 posted elsewhere in this thread a perfect example. I'd like to refer
to his Agile list as some other roles in the organization might see it.

"Value individuals and interactions over processes and tools"

Management - _Processes and tools are exactly how we ran our business. It 's
the only way that scales (and is also lawsuit-proof!)_.

"Value working software over comprehensive documentation"

QA - _How am I going to test that software if I don 't have good documentation
of what it needs to do and how it works? Documentation is necessary for
working software, not something to be balance against working software_.

"Value customer collaboration over contract negotiation"

Management - _We do need to get paid you know. On that matter, our interests
are not exactly aligned with the customer 's. Furthermore, having clear
expectations and legal protections for both sides is a form of collaboration,
a necessary one in fact_.

"Value responding to change over following a plan"

Investors - _Ah, so you 're just following the market and have no intention of
initiating change on your own? How is your company going to be the next Apple
if you keep up like that?_

I'm not necessarily saying the other characters are right - but these
perspectives are a given in today's organization and are going to influence
the actual process. Indeed, given that managers have more power, these are
going to be the defining influences, way over some manifesto.

------
Communitivity
CPP, CORBA, XMPP, SOA, UML, Agile... Whenever I've seen the developer
community embrace a new set of tools (whether hw, sw, process, or a mix), I've
then then the marketing departments and consultants follow. After a period of
time the term for the new tools is muddied beyond recognition as people who
don't truly understand it try to use it in sales pitches and class materials.
In my experience the tool is rarely to blame (maybe I'll make an exception
with CORBA, ymmv). The 'Agile movement' started with a bunch of developers who
were good comparing notes on their processes. They came up with some points of
commonality, and some points from one or more of the others they'd each like
to adopt. These all revolved around the engineering version of the unofficial
USMC motto "Semper Gumby", always flexible. Some call this the agile mindset
(ycmv, i.e. your caps may vary).

"If I have an organization with an Agile mindset, and really rock-solid
product management, Agile processes and tools will evolve out of that. If you
have the Agile mindset and an awesome connection with your customers and are
solving their problems, things will evolve in the right way" \- Todd Little,
CEO Lean Kanban.

Over and over, people like Kent Beck have said that no one set of tools will
work for everyone. Teams need to continually adapt, continually learn,
continually improve, and do what's needed to enable those things.

I love the agile mindset, and the palette of tools I can choose from to paint
a development process for a team that fits the way they work, their needs, and
their customer needs.

OTOH, I hate the "Agile this. Agile that. You got to get certified in them
all" Pokemon-style consultant sales pitches, and feel sorry for those who get
sucked in by them, or who have managers who get sucked in by them.

------
edw
Any movement that gains traction will be corrupted. The moment companies want
to hire people who tick a box, they pull on a supply chain of certification
authorities (which includes, most perniciously in my opinion, grad schools)
that codify and dumb down any set of good ideas and practices so that it's
teachable at industrial scale to mediocrities.

Back in the late Aughties I worked with someone who'd recently graduated from
a design program and was interested in becoming a UX expert, the new-hotness
of the moment. The person wanted to go nearly straight from undergrad to a
Master's program at CMU. I -- being a HCI/UI person myself (and rolling my
eyes at the term "UX") -- counseled doing freelance work for a couple years to
get some practical experience that would provide grist for the grad school
mill. No interest.

I can't say I blame the person too much; big companies want to show their
seriousness by hiring people with credentials, the value of the credentials be
damned.

------
cynusx
As an engineering manager, I prefer to use the word lean instead of agile
because even if the agile manifesto is a great manifesto, the word really has
been hijacked by people in suits who live in their own world far away from
day-to-day engineering work.

Lean is much nicer, it implies it's totally ok to remove
process/meetings/things who don't add value

------
vbtemp
Eating up post-it notes ("issues") and crapping out code - i.e., doing agile -
is just not gonna cut it.

When the end goal is a robust, resilient system that customers depend upon to
suit their needs and your organization depends on for its business, by doing
Agile you're going to end up with something that neither your customers nor
business can fully rely upon (once your system or service is past a certain
level of complexity).

Two major reasons:

1\. A set of agile "Issues" (whether stories or bug reports) do not constitute
a necessary or sufficient set of tasks necessary to produce, release, and
operate a resilient or complex system.

2\. You know the phrase that "Not everything that can be counted counts, and
not everything that counts can be counted"? Agile gives you utterly
meaningless metrics (e.g., story points) that can be counted, but don't count.
What does count depends on the nature of your business or product: Small start
up? Probably revenue or users. Large-scale infrastructure system? Maybe
average latency or uptime. Unless you can directly correlate "story points" to
your bottom line, just skip that clutter in the first place.

Call me old fashioned, but I found that when you bring engineering back into
software development, specifically systems engineering (not "engineering" in
the sense of "I'm a ruby-on-rails engineer"), products and teams are able to
support a high level of confidence and reliability in their work products.
This means (yup) requirements engineering and analysis, QA, Independent
Validation and Verification, etc etc. It does not mean you have to have full
departments for each of these, but at least having someone to "own" each of
these areas (esp for small teams). Again, in the end, no amount of stuffing
post-it notes down your developers throats will replace old fashioned
engineering process and engineering management.

------
viburnum
That first Extreme Programming book was really excellent. Not at all like the
MBA nonsense most “scrum masters” push.

------
ako
So if you can't use Agile, what is the way to manage software development?

There are many industries with complex product design processes, which need to
deliver at a fixed deadline. We expect Apple to deliver new iPhone every fall,
and they meet their deadlines without exception. Same thing for many other
product manufacturers.

There is no reason to assume software development is very different from other
industries regarding product design. Other industries also work with changing
and innovating semi-finished products, components, and new materials.

Donald Reinertsen has written some interesting books on managing the design
process (not related to software development or agile). It offers a lot of
theory and economics behind product design processes. A lot of focus on
reducing the size of Work in Progress.

~~~
horsawlarway
You can choose your features, or you can choose your deadline. You can't
choose both.

Apple delivers a a new iPhone every fall, but they make absolutely no promises
about what it will be.

~~~
ako
Yes, and agile is a framework which ensures you can select your features and
meet your deadlines.

------
linguistbreaker
Agile's not the problem. Micromanagement under the guise of agile is the
problem. Ideally implemented, Agile sort of allows a development team to
micro-manage themselves, but management is usually unwilling to let this
happen.

------
neilobremski
Software developers hate working for the pointed-haired boss too. Agile is
just a name for a process which is a meta "tool" for a company to get its work
done. We're always going to hate working in an environment where management
doesn't understand what goes into the sausage and what's important to do now
that won't cause problems later. And we can all agree that hard work and code
quality are key but I will push to do THOSE under any methodology. If a
company isn't doing them then maybe it's not the process -- maybe it's the
company/culture.

------
matchagaucho
All modern Developers are doing agile, whether they believe it or not.

The agile movement of the 90's was in response to waterfall constraints
imposed by the tools of the 70's and 80's.

The majority of projects today are no longer handcuffed by these constraints.

For historical context, I would suggest reading up on the Scrum vs XP _war_ ,
as one camp pursued a commercialization and certification path to agile and
the other remained largely principle-based.

When I see people expressing frustration with agile, the cause is typically a
byproduct of the commercialization camp.

------
gumby
Agile was designed for small consulting teams (like PwC consulting teams, not
remote software development teams).

I am not be surprised that bits and pieces of it are useful in other contexts
(e.g. standups -- when they really are quick, standing-up touching base).

I am very much surprised by wholesale fetishization/adoption in other
contexts. My GF sees it used by teams that don't even do software development.

Makes me think of that "commoditization of excellence" essay posted here
yesterday.

------
negamax
My own take is that agile simply become tool for non developer actors to
influence development team in (extremely) unproductive ways. It leads to short
term thinking, really strange people practices.

I have only seen it getting exploited. Specially in large orgs, where you are
surrounded by non development team members (people higher up are more detached
to development). So the roles like scrum master etc etc. become important to
them. And quite frankly leads to burnout and toxic environment.

------
president
It's because Agile as a theory (in a vacuum) works but in practice, fails to
be anything but a time sink for most development teams. Agile was supposed to
help teams react to change and allow for elasticity in the development process
but in my experience, managers rarely allow pushing deadlines or allowing for
cutting features. Agile is basically just used by managers as a way to make
sure people's velocity is maximized at all times.

------
2sk21
When I was working on an agile project based on scrums, I developed a real
dread of the daily standup meeting. You don't always have results to report on
a daily basis. On the days that I had nothing much to report, I was implicitly
given the feedback that this was _not_ an acceptable answer. I was simply not
able to lie and always give a positive progress report. This was one of the
main motivations for my quitting that job.

------
budu3
SCRUM is toxic. It is toxic because it dis-empowers the developers who are
doing the actual work and hands that power over to the "SCRUM master". The
SCRUM master is the ultimate bureaucrat -- and a proxy for Management -- in a
heavily bureaucratic methodology. The job of the SCRUM master is to guard and
protect the SCRUM process. Often to the detriment of the developers and
ultimately the project.

------
cannabis_sam
Any process can be abused all the way to unproductivity.

The problem is literally _always_ some empowered moron in charge, without any
clue what the work actually looks like, yet with the ability to destroy work.

I’m looking forward to a time when companies don’t insist on running
themselves like hierarchical feudal societies... it’s such an immense
efficiency drag, but since it’s the dominant dogma in business, the garbage
continues.

------
amriksohata
Most software developers like the principles of Agile development but its
become a marketing term that high level management don't understand. For Agile
to work, it has to have buy in from the top, hence it often is assumed Agile
means quick results for the business if they follow Sprints. Recruiters market
places using Agile, but never really understand what it means

~~~
qweqwe
By such developer's many people who don't even heard about Agile can knew
about it.

------
fendy3002
The problem with current implementation of agile is it tries to standardize a
process and use it across all companies and all project.

In reality, I've found that every developer are unique. And together with
unique company cultures and projects, the process need to adapt with those
things, and not the reverse.

A scrum may work well in a team / project, while it may not work in other.

~~~
detaro
> _In reality, I 've found that every developer are unique. And together with
> unique company cultures and projects, the process need to adapt with those
> things, and not the reverse._

Which is pretty much the core of the agile manifesto.

~~~
jopsen
I think it's fair to say the manifesto have been misappropriated by authors
who wanted to write thick books.

------
geebee
A daily SCRUM standup is often described as answering three questions: "What I
did yesterday, what I will do today, what impedes me"

When I described a daily standup to my father and brother, a physician and a
university professor, they shuddered a bit. Many people from outside software
do. I've heard this described as _violent_ transparency, and if it seems
intimidating to people on the outside, that may just mean that we, as software
developers, have grown so accustomed to a fundamentally unfair work
environment that we no longer question it. Similar to "interviews" that are
actually whiteboard exams. Did you know that most job types don't interview
this way? Again, my friends who work outside software shudder a bit when they
hear about this practice. It sounds awful, because it is kind of awful.

Now, in spite of my stated belief that it is awful, I did explain (or at least
tried to) why we do it. Software is highly unpredictable, and difficult to
estimate. We pick a task, and work on it, and report on it. This, at least at
first, was to me the essence of agile. Waterfall wasn't working. It is
difficult and, ultimately, unproductive to try to spec out everything in
advance. You have to evolve toward a solution, through repeated iteration and
constant communication. Not a bad idea.

Here's the problem - agile turned out to be a particularly insidious version
of waterfall. The point of all this "violent transparency" was that we
embraced the essential futility of estimates. We make them at as granular a
level as we can get away with, but what we are really doing is reporting in
every day on how things are going, and embracing the fundamentally uncertain
nature of what we do. Well, these standups turned out to be an irresistible
opportunity for micromanagement and a daily application of pressure deadlines.

I view agile as the Nitroglycerine of the software development methodologies.
At some point, you can't keep saying "it would be safe if they'd just use it
more carefully." The inherent instability of nitroglycerin _is_ the flaw. And
agile is just too damn unstable. Any dev who things the customer (could be a
project manager, a boss, a stakeholder from a different department) is going
to "collaborate" if the spec isn't met by the deadline is just shaking a big
bottle of nitroglycerine. And at this point, the daily "standup" will be a
person patiently waiting for the developer to finish making excuses (which is
what these three questions will be interpreted to be), followed by "so are you
going to make your new deadline, or will this be pushed back even further).

In many ways, if hard deadlines are involved, I prefer standard old waterfall.
The original agile manifesto says "customer collaboration over contract
negotiation". Indeed! Sounds great. Let's work together with trust, rather
than lawyering up at every occasion.

Here's the thing - if you're committing to a deadline but the customer (who is
often internal, with "litigation" being complaints to the bosses), doesn't
commit to a spec, well, your customer is protected by a contract, but you, the
dev, are completely exposed. Yes, change is common and must be embraced. If
you'd like to change the contract, I'm all ears, but that will require - yes -
a _renegotiation_ of the contract, including the deadlines.

Otherwise, the agile manifesto, almost seems like it encourages software
developers to be pacifists in the middle of a war zone. Look, if a customer is
going to hold my feet to the fire on a deadline, I am going to hold the
customer to the original spec.

Personally, I got out, found a job in software development where deadlines
aren't a big part of what I do. Not sure if everyone can get a job like this,
but it seems product oriented companies are more likely to work this way than
contracted development projects. Deadlines under conditions of uncertainty are
a pretty hellacious source of stress for me, feels like a kind of roulette,
and while agile in theory had the promise of making it better, the methodology
turned out to be nitroglycerine.

~~~
DharmaPolice
>we, as software developers, have grown so accustomed to a fundamentally
unfair work environment that we no longer question it.

Compared to a physician or a university professor a software developer might
have a low level of autonomy (in the sense of free from being micromanaged)
but developers do better than the vast majority of employees I suspect. Having
to account for your time every day in a standup can get psychologically tiring
but there's so many other jobs where it's much worse. I've worked in places
where being out of your seat for more than a few minutes (when not on a break)
would invite commentary or provoke questions.

(This isn't intended to sound like a "You should be grateful because there is
a kid starving in Africa" thing, just trying to provide a perspective why I
find it hard to feel hard done when so many more people have it worse than me
all around me. This doesn't mean we shouldn't all enjoy more autonomy and
agency in our work.)

~~~
geebee
This is a tough one to answer. Yes, there are harder done people, and I
suppose that is enough to end the conversation.

The only part I'd mention here is that you focus on micromanagement and
autonomy, which alone, to me, isn't really the source of stress. I've had
boring but predictable butt-in-seat jobs with clear instructions. You do your
work at a reasonable pace, you will make your deadline.

The source of the stress is being pressured to make firm deadline commitments
under conditions of complexity and uncertainty, and the organizational
aftermath when you don't make them (ranging from confrontational meetings, to
angry emails to your boss, to threats to your employment, to threats to your
professional reputation). I really have seen them all.

Can't speak to how much of this goes on in other jobs, I'm sure it does --
then again, I don't constantly hear about a "critical shortage" of workers in
most of these other jobs either, which implies to me that people with options
may be rationally choosing to avoid software development in favor of other
fields.

------
oaiey
Typical agile methods squeeze the max out of developers. You optimize
estimates (velocity...), break down the task ahead of time and allocate every
developer maximum out. Since the next release is always around, dept and a
Sprint without full allocation is never there. Essentially, you transfer an
engineer into a factory belt labourer.

~~~
jiofih
How can that be, when engineers are the ones estimating the tasks? You
essentially set your own pace.

~~~
oaiey
Sounds right but is not. We ask them to estimate the feature effort and not
the effort plus other stuff.

It is about the metrics. However, I agree. A smart team would do that.

------
Fellshard
The part missing from agile is the model for what software is and how it is
built. If management don't correctly understand the nature of software
development, they will inevitably manage it incorrectly, tie it to the wrong
accounting measures, and embed an adversarial perspective to their own
development teams.

------
ptx
Regarding the technical debt problem, the manifesto does explicitly say (as
one of the twelve principles) that:

"Continuous attention to technical excellence and good design enhances
agility."

Perhaps that principle could to be emphasized more, but including specific
technical details would make it go quickly out of date.

------
gfs78
We hate Scrum, not Agile, and we hate it because:

#It gives management an easy chance to be abusive. Management abuse seems to
be the norm with Scrum, not the exception.

#The methodology does not take this problem into account. The common answer to
management abuse is that if you are experiencing it, you are not doing Scrum.

------
tboyd47
One strange thing about the Agile Manifesto that people usually miss is that
it's signed at the bottom by a bunch of consultants. Who are these people and
why was it important for them to attach their name to this?

------
droobles
Been working Kanban since June, life is better and I think our company is
putting out more meaningful features than my last job using agile. We also
continuously deploy everyday instead of doing 2 week releases.

------
didibus
I've always been a fan of this slightly inappropriate methodology:
[http://programming-motherfucker.com/](http://programming-motherfucker.com/)

------
ausjke
kanban is for factories to make more cars etc. the boss likes it, the workers,
not so as they're pushed by the rule with less leeway.

agile is for software companies to hopefully build product faster, managers
like it, developer not so, as daily standup alone pressures developers to stay
on track all the time, e.g. less "free" time at work etc.

both are really designed for the owners, not for developers, so it's
absolutely normal when you say software developers hate it.

------
TearsInTheRain
The point that agile produces tech debt is something that wrings true to me
and matches my experience. Any good processes people have implemented to
reduce tech debt?

------
wrnr
Maybe software developers (secretly) hate programming. We have a 2 minute
standup meeting at the end of the day. Believe me, that's the least of it.

------
markus_zhang
Basically, self-organization is much more rigid than on the receiving end of
high-flyers who don't do programming.

------
Timberwolf
Someone (I think possibly John Cutler) made a good point about this, which is
that by now the early and middle adopters of classical manifesto-style "Agile"
have absorbed it so thoroughly that it's no longer something deserving of a
special term, it's merely the way things are done.

This leaves the late adopters, and the sociopaths whose main interest is
extracting money from the late adopters. As a result, it's becoming a safe bet
that anyone using the word "Agile" unironically is either going to inflict
upon you whim-based development with added Post-It notes, or sell you an
enormous slab of process binderware with bonus added two day certification
courses. (From which your managers will return having spent the entire course
answering e-mails on their laptop, and proceed to inflict upon you whim-based
development with added JIRA.)

------
rwmj
I can't say I _mind_ Agile, but don't expect me to do any work when I'm
constantly interrupted by meetings.

------
neogodless
Whatever you are trying to accomplish as a team, you need some things.

You need to know what you intend to build. Depending on whether you're trying
to create a new market or compete in a large field, you might have a clear
picture of the end result, or a lot of ideas you need to try out. Where you
fall on that spectrum should tell you how far you're allowed to plan in
advance. Rarely do you need to change what you're building on a timeline as
short as a week, but of course that can happen, too. But given that planning
and meetings require time, and rework also requires time, you need to find a
balance that works for your team size and the above allowance of planning
based on volatility of your goals.

Someone has to be able to make decisions. Often those decisions are high-level
- what is the market value of the thing you are building, and how many
resources are you willing to allocate. We know in software that estimation is
hard and we will get it wrong, so that's always going to be a thorn in the
side of the decision-makers, and some of them will always try to offload that
responsibility back on us anyway. Still, at some point it is reasonable to
relay how well things are going back up the chain.

You need to be able to share plans, decisions, constraints and a swath of
other information among team members. Some of it will be for builders. Some
will be for decision-makers. Team structure will probably dictate how
important leadership and decision-making is compared to maker details. And
that structure will hopefully flow from the kind of thing you're building,
whether it's just an idea, or something that has to be done a particular way
against a particular cost profile to ensure it's worth doing at all.

There's plenty of room in all of this for ambiguity, for conflict, for human
errors, for ego. For prioritizing the wrong thing (whether that's the thing to
work on, or the thing to measure, or how much of a stink you make about
mistakes.)

Given all of the above, what I don't like about Agile is the tendency to put
off figuring out how you're going to build things until the last minute, and
in the middle of figuring those things out, you change what you're going to
build. If you're building out ideas and moving fast and breaking things, then
that pain I just described is something you have to accept as one of the costs
of being a pioneer. In so many cases I've seen, you're not being a pioneer, so
if you spend a bit more time on planning, you'll figure out what to build and
how to build it, and then each member of the team will buckle down and focus
on the details required to do to the building.

Focus, and less volatility. That's what I want out of the process in play for
accomplishing something. I think the decision-makers mostly don't want to be
caught out making a bad decision, such as spending resources to build
something only to find that the value isn't there - either because of the
market, or the unknowns in resource cost.

------
tobib
"Why software developers hate Agile that is done wrong"

FTFY

~~~
JohnFen
I've worked in a few Agile shops, and it was horrible in all but one. Perhaps
that one was "doing it right".

The thing is that it appears to be extraordinarily hard to do Agile right. I
think that any system that is so difficult to implement correctly is an
inherently flawed system.

~~~
Cederfjard
Might it not be that it's extraordinarily hard to manage software development
in general? Are you aware of any other methodology that's easier to do right
and get the desired results?

~~~
JohnFen
Yes, managing software development is generally hard and there is no silver
bullet. But I do think that the methods that I commonly encountered before
Agile were better in terms of both developer stress and software quality.

Interestingly, in many ways they also weren't all that different from what
Agile is intending to bring. They still involved something analogous to
"sprints", they still allowed for course correction and pivoting during
development, and all of that.

Agile seems to position itself as the opposite of "waterfall", but outside of
large corporate environments, I'd never seen a shop that actually used
waterfall as described by the Agile community.

------
Uhuhreally
yes because programming is exactly like manufacturing cars on an assembly line
or playing rugby.

------
jknoepfler
TL/DR: devs don't hate agile, they hate non-technical enterprise middle-
managers and the people who hire them.

If you've ever worked in an enterprise that embeds non-technical managers on
technical teams to run the show, you've probably seen some flavor of the
following:

The manager starts with good intentions. They try to learn the product, the
team, the rough implementation outline, etc. Over time, due to the delta
between their understanding and the reality on the ground, their job devolves
into:

1\. Attending ill-conceived meetings that generate mountains of noise because
they demand the impossible, the nonsensical, or the redundant.

2\. Communicating this noise to their team through a series of terse bullet
points / JIRA items / trello lists / whatever

3\. Assigning a senior+ engineer on the team to reconcile their list with
reality, and then to do the actual work of translating product requirements
into meaningful units of work for the more junior engineers on the team.

4\. Scheduling more meetings to reconcile the original list of items with the
list of items that now makes nominal sense, producing more noise because
people get upset about items they didn't understand in the first place
changing, or feeling like they've "made commitments to stakeholders" that they
now have to apologize for or backtrack on, etc.

5\. Scheduling meetings to handle the "drama" that emerged when manager A and
manager B had an ego-fight over some insane laundry list of garbage. "Going to
the mat" for their "stakeholders," etc.

6\. Scheduling more meetings with engineers to "fix the process"

7\. Scheduling more meetings to hire replacements for the engineers who burned
out doing both the manager's job and their job while being held accountable to
the latter while hobbled by the former.

8\. Rinse, repeat. Note that the cycle begins afresh with every new manager,
who in my experience have at most a 1-year lifespan on a team because they
were either good enough at looking important in meetings and showing up for 70
hours a week that they got promoted to the next shit-show, or they "moved on
to other opportunities".

This whole ouroboros of noise gets wrapped up in whatever management
terminology is prevalent at the company.

In this situation, the team loses time and energy every time the manager does
a thing. They either have to stop working to correct the noise (which if left
uncorrected festers and becomes worse) or stop working to attend an
unnecessary meeting to make sure it doesn't go off the rails, or whatever.

Agile, which is really just a cover-all in enterprise for a "continuous
planning because we don't ever really know what we're doing" strategy,
multiplies this noise many times over because error compounds upon error
multiplicatively, and it creates a lot of opportunities for error by creating
many decision points.

(Edit: there's a darker version of this, which I've personally witnessed,
where no one pushes back on the insanity because the team is very weak. This
is how you get teams serving static web pages at 2.5 transactions a minute on
giant web service frameworks that cost tens of thousands of dollars a month to
"operate", or pick your daily wtf)

------
jlokier
It's not just management that gets into cargo culting. And it's not just "top-
down" that results in pain in an agile working environment.

Sometimes "bottom up" can be a shitshow too.

I've (tried to) work with developers (special-grade assholes) who were quite
far up their own orifice at using the language of "Agile" processes in an
adversarial but socially point-scoring way. To beat other people over the
head, and even harass people out of their jobs (including management),
implying that anyone who isn't doing what they say, or providing continuous,
detailed arguments why not, is doing software wrong - while producing
mediocre, low-effort, low-results work themselves.

That isn't Agile, but I have seen the language of Agile used to abuse and
pressure in a seriously uncool way. So I'm personally a bit cautious when I
hear Agile advocacy from individuals, until I learn what they really mean, and
how they use it.

Among other things, I listen for whether they have a working empathy gland,
and use their tools and knowledge to lift up people they work with, or knock
them down.

I've also seen it used to ignore proper handling of PII (GDPR-worthy personal
data), via the principle "everyone is equal in the team, so should all have
access to production data". Naturally this causes tensions, when some people
pay attention to PII issues, and some would rather ignore them, perhaps
disagreeing about how important it is, or perhaps just sloppy. (Related, I've
observed a really interesting dynamic between privacy advocates and anti-
privacy advocates.)

And the same with other quality-control issues when the level of care varies
considerably.

At the same time, some people are very happy in their agile teams, and report
that the rest of their team seems to be as well; and they are constantly
shipping good work. It seems to be working for them.

Between all the things, I have the impression that _some_ people's "Agile"
approaches risk a "productivity feel-good illusion", where the perceived
productivity over weeks and months _feels_ great, and there's a happy buzz in
the team, but long-term business-affecting output is sub-par because the feel
good factor and constantly doing useful things misleads people into thinking
they are operating at the best they can be.

And yet, it's not like planning everything, or top down direction changes from
the business arm, makes for particularly good results in software either.

Since it works really well for some, and is used as a tool of abuse by others,
I'm neither for or against "Agile" as such, and instead, prefer to look past
the buzzwords used by each company and team, and look at what they actually do
each week/month, how the individuals feel (not just "the team" but each
member), and what sort of results over time they are producing (measuring
strategically useful outputs, in addition to whether they seem to be busy and
happy).

I think the principle of developers deciding themselves how to develop is an
excellent one, to the extent we can encourage and assist that. But when
developers are in conflict with their peers, and using the language of "Agile"
as part of conflict or even abuse, it can be quite messed up, and may need an
intervention from above.

~~~
morningseagulls
>It's not just management that gets into cargo culting.

I've had the misfortune of attending a meetup for agile coaches. It's
definitely a cult.

------
mieseratte
One of the biggest issues with the scrum (master|lord|bag) model of Agile is
that any process grievances magically transform from "this process has issues"
to "that person is wrong."

------
thedonkeycometh
Dogma destroys agile. If the team is coerced into behaviour that doesn't
create momentum its counter productive, both in terms of morale and buy in on
the end goal.

------
dustinmoris
Agile = Strict process.

Agile = Lots of meetings.

Agile = Releases done on fixed schedule.

Agile = User stories defined by product owner.

Productive Developer = Litte/No process

Productive Developer = Little/No (formal) meetings

Productive Developer = Releases as soon as ripe to release

Productive Developer = Doesn't need product owner. Actual usage and metrics
tell productive developer what to do next.

Agile <> Productive Developer

~~~
spookthesunset
Yeah not having meetings and process is great for a solo developer working in
isolation, but it doesn’t scale to even a single team, let alone a much larger
organization. Once you go past a single person working on a product, you need
some kind of process to facilitate communication.

Once you move beyond yourself you are gonna have a process, either implicitly
or explicitly. I vote that it is best acknowledge there is going to be a
process regardless of you liking it or not and be explicit and intentional
about its formation.

Once you acknowledge that there is gonna be a process you can either start
from a known set of processes (scrum, kanban, waterfall, XP, whatever) and
then iterate on it until it suits your environment. The alternative is to
somehow reinvent the process wheel from the ground up and probably not be as
effective as if you had started with proven processes.

It’s like people who start a project and say “all these frameworks suck!!! I
refuse use them! Bloat!!!”. Six months later you look at their codebase and
surprise, they’ve created their own implicitly defined framework. They won’t
call it a framework, but lo and behold they have a framework. Probably worse
on every measurable dimension than what they would have had if they started
with what’s out there too. Had they been honest with themselves, they could
have saved a ton of trouble being explicit that there will be a framework no
matter what and had been intentional about its creation/adoption.

