
Agile's early evangelists wouldn't mind watching Agile die - prepperpotts
https://builtin.com/software-engineering-perspectives/lean-agile-methodology-software-engineering
======
plughs
My first team, some 14 years ago, had the best experience with Agile. What
made this work

> During planning, everyone understood that the estimates were _estimates_.
> Tasks could take longer or shorter, that was OK and even expected. The goal
> was to improve velocity, not to accomplish every story, every time.

> Engineers felt comfortable taking stories in areas they knew nothing about.
> A stated goal was that every engineer understand every piece of the project.

> Standups were team only. Engineers felt comfortable saying they got stuck or
> needed help or got lost in a rathole and didn't make the progress they
> hoped.

> Demos were important so that the team and the clients could understand what
> had changed and what new features were available.

But it quickly got lost - managers and PMs and Directors got involved and Jira
boards became published for all to see. (In the beginning it was whiteboards
and sticky note). Standups and Demos were all about self-promotion. No one
ever wanted to take on a task they weren't 100% certain they could do. If a
task was 3 point it needed to be done in 3 days or there would be questions.

When I left the last company it had gotten outrageous. Every task should be
completed in three days and in production in five days - and if not that team
was Doing Something Wrong.

( We were told that this was standard FAANG practice, I have no idea how true
that was )

What happened was what you'd expect - shortcuts, tech debt, unit tests
cynically design to pass and meet code coverage expectations instead of
actually usefully testing.

The reality is that any process is going to fail one senior leadership decides
it's a way to evaluate engineers, not create a good product.

~~~
marktangotango
A looong time ago I went through Army basic training. As a BS degree holder I
was given the job of "book man". This meant I carried around the platoon
training book and carried placards to put in signs at various training
locations that told what battalion, company, and platoon we were so if anyone
driving by a gun range, motor pool, or classroom could look and see oh that's
1st platoon, C company, 1st training battalion.

I've come to believe that that main driver for Agile adoption has come to be
something similar. Making visible to outsiders what software development teams
are doing, and making progress (or it's lack) visible to management. I thinks
that's a completely reasonable expectation. Businesses are paying exorbitant
salaries and providing ping pong tables, why shouldn't they have visibility
into what's being done?

Where it becomes toxic is in areas this posts parent indicates; posturing, one
upsmanship, pressure to perform. Effective teams need "safe spaces" to learn,
discover, try and fail. Agile isn't that anymore. Hasn't been for a long time.

~~~
smadge
> Businesses are paying exorbitant salaries and providing ping pong tables

Businesses are paying market rate salaries to employees who generate them
revenue. If anything engineers should be the ones questioning the exorbitant
compensation and perks at the top of the org structure.

> why shouldn't they have visibility into what's being done?

Because they shouldn't be micromanaging. They should be setting high level
goals and expectations and giving teams autonomy and trust. Intrusive
surveillance and low level metrics create perverse incentives that detract
from those high level goals.

~~~
rrrrrrrrrrrryan
But how can they set goals without any visibility into what a team can
typically accomplish in a given time period? How can they identify better
performers and worse performers?

I'm not saying agile is the right solution, (it probably isn't), but expecting
higher-ups to fund a black-box team is kind of naive.

~~~
jiggawatts
Measure the deliverable, not the deliverers.

Reporting on random internal stuff instead of the actual problem at hand is
the #1 problem I see with corporate reporting, everywhere. I see various
combinations of people wasting time measuring:

1) The thing that is easy to measure, typically money or time.

2) The things they "understand", typically people for HR, compliance for
legal, money for finance, etc...

3) The things _their manager_ wants to know, no matter how irrelevant that is
to executing their own job well.

Meanwhile what they _should_ be measuring is the qualities of the end-product
or the overall external customer end result.

It doesn't matter one iota if Bob the Developer Guy missed an internal 3-day
deadline that John the Manager _made up on the spot_ if the end product is a
winner in the market and makes the users ecstatically happy to part with their
money.

This happens everywhere, with everybody. For an IT-centric example, the common
one I see is:

Helpdesk: "The users are complaining that the app is slow"

Admins: "The load is only 10%, but fine, we'll add more capacity!"

Helpdesk: "The app is still slow!"

Admins: "The load is only 5%! They should have no reason to complain!"

Do you see the issue? No, seriously: do you? Because practically _nobody_
does, in my experience. Take a minute.

What happened here is that the admins measured the thing that is easy for them
to measure: the load. There's a cute little bar graph in VMware, or a chart in
their network appliance, or whatever. What they _should_ have been measuring
is latency from the end-user perspective, but that's hard to measure and
practically no product tells you this number out of the box. So their entire
process, their reporting, their troubleshooting, their forms, requests,
_everything_ becomes focused on the thing that they can see and control. Even
if it's pointless, ineffective, and basically a waste of everyone's time and
effort.

This happens with developers in exactly the same manner. Software quality is
_stupid hard_ to measure. Long term supportability is borderline impossible to
measure without a time machine. Technical debt is hard to even explain to a
manager, let alone keep tabs on in terms of numbers. So what's easy to
measure? Time! Deadlines, sprints, release dates, etc... That's super easy.

That's why _inevitably_ the unimportant internal time metrics become critical
to everybody, but the actually important metrics aren't even measured and
become invisible to management until it's far too late.

~~~
brians
As a manager, I want to measure leading indicators of success and failure.
Absolutely, feedback control based on the real output is important. I must
measure that! But I’m always looking for ways to predict that, so I can steer
more gently. What’s a leading indicator of a crisis? A late team struggling to
make a deadline. What’s a leading indicator of that? Mismatch between
estimates and performance. I need to know about bad point estimates because if
I don’t fix it—I mean fix the PM’s misalignment—they’re going to push the team
into something dangerous.

~~~
quanticle
The problem is that these "leading indicators of success and failure" aren't.
A late team struggling to meet a deadline _might_ be a sign of imminent
failure, or it might the team working hard to do something that is genuinely
difficult to do.

The core problem with Agile (most forms of software management) is that it
massively overweights "first mover" advantage. I keep hearing, as a
justification of agile, that software needs to be delivered quickly so that
the company can go to market first, and gain marketshare while its competitors
are still floundering. But, in practice, that's hardly ever true. I can't name
a single product that succeeded solely because it was on the market first. I
can name many products that were first to market and _failed_ because they
were clunky and difficult to use.

Heck, Apple's entire business model consists of being _second to market_ with
a product that is more polished and easier to use than its competition.

Yes, if a developer or team is well and truly _stuck_ (as in spinning their
wheels on the same problem, week after week), that's a problem. But you don't
need Agile to tell you that. A simple weekly status meeting with incremental
demos is sufficient. The only thing Agile does is create a bunch of graphs
that allow management to comfort themselves with "story points" and "velocity"
so that they don't have to confront the hard reality that they have no idea
what it is they want to build.

------
0x262d
Agile/software engineering practices broadly suffer a lot from the fact that
not only is selling software a business model, selling Agile is also a
business model, and when you buy Agile consulting it's impossible to
disentangle whether it's being sold to you because it works or because it
makes that person money. They don't even know because it's their job and they
convinced themselves of its usefulness.

It can still be evaluated on the merits but IMO this greatly pollutes the
speed at which software devs as a broadly conceived community can come to
consensus understanding of this.

Also I think the comparison to lean manufacturing has always been very
shallow. I get the metaphor, I just don't think that human resources in
engineering can be optimized like manufacturing processes. This quote is the
best part of the article:

> "You’d never hear anyone say, 'We help mechanical engineers be agile. That
> would be silly. And I mean that in the worst possible sense of the word".

As for the rest of it, I'm not dying to hear what the person who invented
Agile thinks we should do next lol.

~~~
the_duke
> I'm not dying to hear what the person who invented Agile thinks we should do
> next

Agile has plenty of good ideas.

The problem is the almost religious following and, as you mention, the whole
industry that has sprung up around it.

Even the initiators said that it was supposed to be a rough framework, to be
adapted to your individual circumstances and teams. It was also a (much
needed) counterpoint to the then prevalent waterfall model.

Now we have consultants, people strictly following something they read in a
book or learned in a course, adhering to strict structure of
meetings/processes, and even a big association with a single software product,
Jira. ("You are doing it wrong!")

When you step back, a lot of the ideas make sense, and many teams will even
implement similar workflows without having ever heard about "Agile".

Common sense has to prevail though.

~~~
nradov
When you have a large program team with mixed experience levels who don't
fully understand fundamental principles, sometimes the only way to keep your
sanity is to force everyone to strictly follow a defined agile methodology
(LeSS or SAFe or whatever). That isn't optimal, but if you have to deliver
working software right now you can't wait around to figure out an optimal
process for your unique circumstances. Pick something good enough and move
forward, then improve as you go

~~~
Jtsummers
Agile doesn't ask you to figure out the "optimal process", it asks you to
learn. One of the key things I've seen missed in almost every attempt at
Agile/DevOps/whatever is the retrospective or the learning component.

The team/organization has to become a learning organization. That means a
number of things, but the critical one here is learning from past failures and
successes and incorporating that feedback into their model (ideally
continuously, but in Scrums it'd be the end-of-sprint retrospective). You
start down a path, and you find it's difficult. You don't press on just
because it's the one you selected, that's the way of idiots. You examine the
hardships you're facing, and you address them.

~~~
wpietri
Absolutely. To my mind, the one vital agile practice is the weekly
retrospective where the team looks at how things went, thinks a bit, and
decides to try something in following weeks. Everything else is just tools
people can try applying to solve the problem of the week.

------
james-mcelwain
I don't know if something is wrong with me, but I simply cannot "decompose" a
single feature into 500 different sub-task Jiras.

I understand why it would be super cool if software worked like that, but I
have to iterate on features holistically and sometimes speculatively.

At least for me, software development has never been able to be so cleanly
broken down into "first, implement the button" type tasks.

But maybe I'm just dumb.

~~~
stickfigure
It sounds like you're trying to decompose software into developer tasks, which
is not what (my interpretation of) agile is about.

Forget the developer for a moment and take the user perspective. What's the
first thing the user wants to do? Log in? Ok, that's a story. What's the next
thing the user wants to do? See a list of widget prices? Ok, that's a story.
What's the next thing the user wants to do? Change a price? Story.

If you can't sit down and think of a dozen narratives like this, then the
fundamental problem that you don't really understand how people are supposed
to use your software or what your software is supposed to do.

~~~
jussij
I would think if 'login' was simple enough to write as a single story then
that login feature would be next to useless.

The task of login is more about security, access control, authorization and
tracking, not just giving the user access to a web landing page.

That level of complexity makes it a project in itself.

~~~
stickfigure
That depends on business requirements. In simple cases, auth can be as simple
as dropping a little javascript on the page.

But sure, you can have follow-on stories like "user is denied access protected
resource" or "admin sees resources accessed by user". Enough individually-
useless stories and you end up with a useful app. That's kind of the point of
agile.

------
Someone1234
Agile is the worst form of Software Development Methodoloy, except for all the
others.

Which is to say: To all the people jeering for Agile's demise, please provide
a superior alternative. I came from a world dominated by Waterfall, and I
never want to go back to that. A lot of companies get Agile wrong, and it
isn't a panacea, but it is much closer to what developers are naturally
inclined towards (e.g. rapid incremental improvements) than Waterfall ever
was.

So I challenge anyone who wants to replace Agile, please lean into how
developers work rather than trying to mold their work onto your rigid front
loaded methodology. Trying to bring in ideas of other industries, like
engineering or architecture, that build physical goods and only have one shot
at is a folly.

~~~
ebiester
I think you're debating a strawman there. The argument is not that we need to
return to other pre-agile SDLC methodologies but rather take what we've
learned and go further. From the article:

> Now, continuous delivery is what’s expected, and the industry is ready for
> the next thing. But that next thing shouldn’t be another methodology,
> according to Mary.

> There is no methodology in my field of software engineering that can
> conceivably last more than five to eight years,” she said. “Everything that
> is 10 years old is obsolete. Everything that is 20 years old is archaic.”

> Furthermore, she said, methodology requires codification. Beginning with the
> Capability Maturity Model (CMM) in the ‘90s, software development
> methodology meant developers had to show they had standards and that they
> followed them, rather than demonstrating that their standards were
> constantly in flux depending on consumer needs. That’s the definition of
> quality standards lean manufacturing practitioners in Japan originally
> espoused, Mary said, and they’re not compatible with methodology. Instead,
> they’re all about learning.

> To that end, Mary is excited about all the ways artificial intelligence will
> allow software engineers to learn better and faster. Automated testing,
> continuous deployment and cross-functional collaboration are now table
> stakes, Mary and Tom agreed. Cutting edge companies will discover the next
> great approach through an engineering mindset and a willingness to learn.

___

Consider that Mary and Tom Poppendieck were responsible for many of the Lean
inclusions of the agile movement, which (largely) came from watching plant
manufacturing at Toyota. Similarly, much of the DevOps movement was tied to
this as well. If you want to talk about what is next, it is likely taking a
first principles look at what we're doing today, questioning best practices
again, and saying, "if we were going to make a manifesto in 2020, what would
it look like?"

~~~
Someone1234
You claim I'm "debating a strawman" but then quote the article that literally
says they have no alternative in mind (my chief critique) and point towards
artificial intelligence to solve the issue _somehow_.

The only "strawman" here seems to be taking my point about pre-Agile
methodologies out of context, and using it to dismiss the entire idea that
this article is unconstructive/has no actionable solutions.

~~~
ulisesrmzroche
You don't need to provide a viable alternative when you criticize something,
this is a false dilemma.

~~~
Someone1234
Nobody you replied to said they shouldn't be _allowed_ to criticize Agile.

The criticism in this comment thread was that their advice wasn't actionable,
not that actionability was a prerequisite in order to criticize Agile at all.
There was no false dilemma here because there was no choices provided (false
or otherwise), merely a weakness in an argument raised.

------
lunias
IMO Agile has become regulatory capture. It's a means by which non-engineers
can extract value from a booming market which doesn't directly benefit from
their skills.

That being said. I think there is a lot of wisdom in the original agile
manifesto. The core principles are solid, but the methodology has clearly been
co-opted by consultants and supported by management looking to increase the
headcount under themselves.

I've often struggled to understand why my team is made up of only 20%
engineers with the other 80% pretending to create value by holding meetings to
tell engineers what to build next when I feel like it's your clients that
should be doing that.

Ultimately it's engineering that becomes the constrained resource which leads
to technical debt in favor of pushing out product's features.

I would venture a guess that most engineers have used (critically) more
software in their lives than any non-technical person driving the development
of the product. Why then are engineers not the most consulted people on the
efficacy and value of new features? I think there is a big myth out there that
engineers are incapable of directly handling client feedback.

~~~
omerbensaadon
This completely short-sells the role of good designers in an organization.

Creating the _right_ thing is extremely hard.

~~~
lunias
Forgive my omission I didn't have designers in mind when I wrote that.

Here is what I think: I would place designers closer to the engineering
(necessary) side of the spectrum. Designers do in some cases build tangible
things, are very technical, and they approach refinement from angles of impact
that some engineers may be unaware of.

I do think there are quite a few interpretations of what a "designer" does
across many industries. In the field of software did you have in mind
architects, UX, product, something else, all of the above?

The definition of engineer includes design in both it's noun and verb form:

"a person who designs, builds, or maintains engines, machines, or public
works." "design and build (a machine or structure)"

But the definition of designer makes no mention of engineer.

As such, I would enforce that my designers are actually engineers and stay
away from "pure" designers that do not have the technical foundation necessary
to validate their designs. Design in a lot of ways is an emergent property of
the engineering task at hand - unless we're talking about purely artistic
pursuits.

------
tremoloqui
The terms "agile" and "Agile" have two separate meanings.

Big 'A' \- "Agile" is waterfall re-branded - an excuse for corporate empire
building and business as usual. It involves lot's of meetings and not trusting
those who build software to do the right thing.

Small 'a' \- "agile" is the implementation of the manifesto, which basically
comes down to smart people figuring out how to work together towards a goal,
often by taking small steps.

Until the terminology is sorted out the discussion can't help but be confused.

~~~
ska
In my experience "agile" was a loose rebranding of ideas that had been around
for a long while (see all the other non-waterfall approaches that predate it)
and "Agile" (i.e. the manifesto) was just one attempt at one of these sort of
methodologies.

Once it got popular, "Agile" was co-opted by all the usual players (cf
"extreme" before it, to a lesser degree).

The important idea is "agile" vs. waterfall, whether or not that includes
anything directly recognizable as "Agile". Or call it something else, doesn't
really matter.

Recent history shows you can certainly do things directly recognizable as part
of the Agile methodology while demonstrably not being agile, so modulo the no
true scotsman fallacy it's a much less fruitful distinction to draw.

~~~
tremoloqui
Most good ideas predate their branding.

~~~
ska
True, but they were already branded albeit not as successfully. And this is
very much one of those things that is somewhat evergreen - it just gets a new
branding every decade or so.

I guess I'm saying "Agile" was/is one of several, and that's ok (good even).
It's worth not getting bogged down on the "Agile" part and focusing on the
more essential things.

------
mywittyname
I've been through three full-fledged "agile transformations" in my career. I
hate agile so much. I hate it because it encourages dogmatic behavior instead
of rational behavior.

I think it has survived so long because it provides its practitioners with two
ace excuses: when things fail, they say, "what we did wasn't really agile,"
and when somebody proposes and improvement they don't like, it's always, "that
sounds like waterfall." A team can't recover from their agile transformation
until both of those phrases disappear from the team lexicon.

> “Way too much of Agile has been not about technology, but about people and
> about managing things and about getting stuff done — not necessarily getting
> the right stuff done, but getting stuff done — rather than what engineering
> is about,”

I'm not sure agile was ever designed to fix this. The whole process is really
handy-wavy about the actual engineering: "we'll just make this a spike." The
process also demonizes documentation and design work, which is antithetical to
most engineering.

That being said, I love iterative development, and I like the concept of
stories as descriptions of functionality. But I do think agile, as taught by
most consultants, is really designed for consultants who build CRUD web-based
applications. Sprints are timeboxed so consultants can charge by the spring,
and stories lack implementation details because companies hiring consultants
don't want or need to know how their sausage is made. The further away your
product is from that area, the less effective agile is; some companies really
need to design their sausage well, up front, because they are going to be
eating it for years.

A process that's built up over years has become the way it is typically for
good reason. And in my experience, teams forced to transition to agile will
end up shoehorning their existing process into "agile" and calling it done, so
most executives don't really see how their "transformation" failed.

~~~
woutr_be
> I've been through three full-fledged "agile transformations" in my career. I
> hate agile so much. I hate it because it encourages dogmatic behavior
> instead of rational behavior.

I'm going through that right now, in fact for the past two years our team has
been transforming into agile. Although when I say team, it's more the
developers that are forced to work in an agile way. The business is still very
much waterfall, but for them it's okay. If they want to throw a new story into
the sprint, they'll just call it being "flexible", and adjusting to business
requirements. It's not because they can't plan two weeks in advance.

There's also way to much time spend on story points, I always assumed these
were estimates, to get a sense of how much can be achieved, if a story runs
over, so be it. However here, these are seen as deadlines, a 3-point story
shouldn't take longer than a day or two. Our "scrum master" is constantly
asking wether we can achieve all our stories this sprint, what's the point of
even estimating if you're going to do that. And recently, we now have to plan
our two week sprint, day by day, committing to 2 week plan before the sprint
even starts. There's nothing agile about that to me.

------
bane
It's gotten to the point where it seems that the projects that do more of the
Agile "stuff" move much slower because they're spending so much of the working
time doing that stuff than slinging code. Where I'm at, we're running
something around 4 dozen projects at once and the teams that really focus on
doing all the ceremonies are simply left in the dust by the teams that don't.

Here's another anecdote, a couple big teams that went the full SAFe route
spent 3 years building something that ended up being thrown away and replaced
in 4 weeks by 3 staff working part-time who were just given some instructions,
some deadlines, and told to go code.

It's become repeatable, big teams toiling for years getting outpaced by
smaller, more "agile", teams.

The balance has gotten out of whack again and it's really time to start over
again. When I go back and read the original manifesto, what I see today in
modern practice looks nothing like what was intended. The point in too many
shops has been to accomplish the Agile things, not to deliver.

~~~
jpswade
In your anecdote, though I don't doubt the situation, it seems to me that
something has gone wrong.

The manifesto itself says:

> Deliver working software frequently, from a couple of weeks to a couple of
> months, with a preference to the shorter timescale

I get the impression as to what you're witnessing is, water-scrum-fall...

See: [https://i.imgur.com/6eqk7eF.png](https://i.imgur.com/6eqk7eF.png)

On the flip-side, your team of renegades managed to deliver in 4 weeks, while
being great, I would question how sustainable that is. Also I get the
impression they had skin in the game.

> what I see today in modern practice looks nothing like what was intended

You're 100% right. I don't think it means agile should die, I think it means
people have forgot what it set out to do.

Scrum existed before agile and is a framework to help people work in an agile
way. However people have got too wrapped up in the orthodoxy and have forgot
what agile is actually about.

My mantra is simple: Release early, release often, listen to the customer

When I first got into software development it was because of open source
software. On the SourceForge website, under the “Promoting your project”
section, you’ll see it say “Release early, release often. Frequent releases
state loudly that your project is alive”.

Years later, I learned that this philosophy was popularised by Eric S. Raymond
in his 1997 essay The Cathedral and the Bazaar. Only, his version also says
“listen to the customer”, an important part that’s all too easy to forget.

~~~
bane
> My mantra is simple: Release early, release often, listen to the customer

I just wanted to amplify this simple, elegant, statement. I don't have anymore
to add, but this is a better statement than the entire Agile industry has
managed to produce.

------
RcouF1uZ4gsC
> At the time, software development was suffering from a mistaken belief: that
> building things fast and building things well were fundamentally opposed.

I thing “good, fast, cheap; pick 2” is still generally valid.

~~~
riazrizvi
Note to self: Remember whenever you think "Good,fast,cheap; pick 2", it frames
your choices as either "produce something not-good" or "produce something and
take your time or hire lots of people". You are again regressing to your
ivory-tower-inventor tendency, you spend too long perfecting and the
perfecting gets worse and worse. Instead it's "fast+cheap, fast+cheap,
fast+cheap" to minimize the time between customer-hypothesis and customer-
trial. You do that until you achieve "good enough". This is the surest and
most economical way to achieve "good". This is agile.

~~~
MattGaiser
> until you achieve "good enough".

Or until the ever-growing pile of garbage that agile produces gets too tall
and tips over. Then you throw away the codebase and start again :).

~~~
analyst74
This is the way.

------
vpeters25
Every time I see an "agile sucks" post, I take the time to read it and every
time (so far) I have found they blame the process for some key part of agile
they missed. Quote from the article:

“Way too much of Agile has been not about technology, but about people and
about managing things and about getting stuff done — not necessarily getting
the right stuff done.”

This is the whole point of agile: progress on iterations, inspect and adapt at
the end of each iteration.

Your team might build the "wrong stuff" for an iteration, realize it
(inspect), then make a course correction (adapt). If you end up delivering the
"wrong stuff" is because you didn't follow this very core principle of agile.

I find it hard to believe these so called "Agile Early Evangelists" can make
such a statement. Their background in lean development should have made the
familiar with empirical process controls, from where lean and agile come from.

My guess the author quoted them selectively to fit the "agile sucks" narrative
of the article.

Edit: expanded last 2 paragraphs.

~~~
ebiester
So, it gets complex.

I have been privileged to work in a company that really thought about and
worked to prioritize the four values on the left. I would follow those agile
coaches to any place they wanted. I have been a staunch defender in real life
and online, because I've seen it work very well. I also have been on teams
with other processes and seen how much worse it can be.

I will take the values of agile and push for those, and I'll take the lessons
learned such as quick feedback loops, continuous integration, relative
estimation, automated tests (which came from people like Kent Beck and Robert
Martin pushing them so hard alongside agile), and the good stuff.

However, after seeing how badly it can be weaponized against developers, I'm
certainly ready to throw out the bathwater, and I think this is what they're
talking about. I've seen far too much cargo cult agile and far too much
command and control with a light layer of SCRUM.

We have agile "coaches" who have never learned to code! They take a set of
color-by-number technical practices but don't understand how or why they
matter! I had to correct someone's slide that got the four values wrong, and
their consulting group apparently had been copying and pasting them
incorrectly from presentation to presentation!

The values and principles of agile are great. The current implementation has
some serious debt.

(And while we're at it, we could update it. Too many people misunderstood the
documentation part. Continuous attention to technical excellence needs to be
upgraded to a value. Delivering frequently today means days instead of weeks.)

~~~
vpeters25
> However, after seeing how badly it can be weaponized against developers, I'm
> certainly ready to throw out the bathwater, and I think this is what they're
> talking about.

Poor management is a separate issue from agile. Even so, I would rather stay
on a poorly managed agile shop than go back to a waterfall shop.

As far as the "values on the left", I like to explain them as a 55/45 split
(and adjustable depending on your reality): we still deal with processes and
tools, we just take a second to think whether a process is actually needed
when we can just talk to someone instead.

Example: on a small team, you might just ask "can someone please approve my
changes?" instead of having a whole jira workflow with code reviews and
approvals.

~~~
ebiester
Again, you're fighting a strawman.

The only alternative to Agile isn't Waterfall. The right alternative is
probably something entirely new.

~~~
loopz
The alternative is always Doing What Works. Alot of Agile is superfluous
Waste. With time it'll only grow more added layers of inefficiencies. The true
costs and risks always get hidden away.

------
legitster
There are many fingers to point here, but I point mine at bigger consulting
firms like Accenture. I have first hand experience with their miserable
"agile" process at Microsoft.

If you want a stapler, you have to schedule a meeting 3 weeks in advance with
2 team leads and 3 contractors who decide what sprint "getting a stapler" will
be assigned to. Then "getting a stapler" gets pushed back two sprints because
some priority came along (a vice president somewhere just learned that his
binder was on hold for four months). An Accenture contractor from India
informs you that a hole punch is on the way. Apparently you checked the wrong
box on the stapler requisition form, so you have to start the process over
again.

Then the Accenture quarterly deck shows they met 97% of all stapler demands
for the quarter! Isn't life so much more easier and more measurable now? But
they will need to hire more contractors to keep up with capacity.

~~~
MattGaiser
That is Agile as a religion.

------
vbtemp
For the past several years now, each time I join a new team or project, my
first objective is to detach and destroy the "Agile" process workflow.

When you finally liberate a team from Agile, it's just breathtaking how much
you can focus on delivering working software that gets deployed with quick
iterations that's closely aligned with the business and customer's needs. When
free from the tyranny of Agile, teams can be effectively self-organize, remove
micro-managers, and quickly adapt to changing needs and requirements. My
experience is that staff are usually much happier, more productive, and less
stressed once agile is gone.

I mean contemporary Agile as pushed by corporations and those awful "coaches"
(who never seem to be actual developers) --- if you were you design a system
whose end goal was making great developers unhappy, unproductive and locked
into a dysfunctional system, Agile would be it.

~~~
trimbo
> it's just breathtaking how much you can focus on delivering working software
> that gets deployed with quick iterations that's closely aligned with the
> business and customer's needs

That's literally the agile manifesto.

"Scrum" is one implementation of what agile was trying to achieve. Maybe
that's what you're thinking of?

~~~
Jtsummers
There's Big-A Agile and agile. The manifesto is really the latter, the former
is a set (different depending on where you are) of very specific practices
that neglect the principles in the manifesto (though, typically, they were
derived from them originally).

Read _SAFe Distilled_ or _SAFe 4.5 Reference Guide_ for what happens in large
enterprises (god SAFe is a fuck up). It consists of some good ideas, but also
some very explicit practices that don't help in every effort (and sometimes
hurt). It is literally the opposite of Agile, which is supposed to be about
flexibility.

If you want to hear about its "success", just remember it was used for F-35's
software...

Big-A Agile is based on the belief that adoption of practices is sufficient,
and that deep understanding is unnecessary. This is the realm of cargo cults.

~~~
vbtemp
> If you want to hear about it's "success", just remember it was used for
> F-35's software...

This is the example I use all the time!!

Maybe agile is great when you're making an online shopping cart for a
e-commerce website, but the idea of using Agile for complex, engineered
systems is laugh-out-loud hysterically absurd. And this does not just mean
spaceflight software, it basically means anything more sophisticated than a
CRUD app.

~~~
dankoss
Totally agree. I believe Agile works well in environments with shallow tech
stacks, but it has worked terribly in my experience in product companies that
build hardware, FPGA dev, embedded software, and other disciplines that can't
deliver on two week increments or increments that align well with other
disciplines.

~~~
Jtsummers
Agile can work well in embedded, I've seen and done it.

The thing people have to forget is the notion of "deliver on two week
increments". It's not about delivering a product that can be fielded each
increment, in the case of an embedded system, but about delivering something
that has some improvement or new testable component. I can't make an embedded
radio handle, in two weeks, a completely new message type (well, depends). But
I can do things in each two week interval that is verifiable. I can show that
I've actually received the new message, that I can send it back out, that I
can pass it through the various internal processors (if multiple processors
are used) or processes (if a single one). Then I can start transforming it,
storing it, changing other things about the radio state based on the message
contents. Each of those is independently verifiable and completable within a
short period of time. But taken as a whole, it's a 6-month project. The agile
way has you make those small things, verify them, and then move on to the next
thing. I can deliver (to the test team, to others using the system) the
partially-completed system, it just can't be fielded (and that's fine).

And that's not unique to embedded. If you only focus on things that can be
fielded in each increment, you'll never develop the more complex tasks, or
address the tech debt.

------
raiyu
Can we just replace agile, and every modern management practice with some mix
of common sense, talking to the customer, talking to the team, and being able
to voice concerns to upper management where people actually listen instead of
running their own agenda? =]

~~~
hn_acc_2
But this is the root of all these issues... Because everyone has a different
perspective that underlies their "common sense," so this system of unspoken
agreement just falls apart.

When you throw in the incentives of compensation and career advancement,
politics and human nature are bound to corrupt the process further.

This is why codified process will always be better in the long run for most
companies, because it's the only tool possible for combatting this

~~~
asplake
...until codified process becomes the problem. It never ends!

~~~
brazzledazzle
People that corrupt a process are often the ones it’s designed to stop. It’s
not even done with ill intent more often than not.

How do you create a paradigm or process that can be amended adapt to a
persistent threat without that amendment process itself being used as a tool
to corrupt it?

~~~
asplake
I completely agree that you don’t need to assume ill intent. But by that same
token, the fact that a paradigm or process isn’t invulnerable does not mean
that it shouldn’t be used.

Bureaucracy, heavyweight process, and all rest are ways that systems protect
themselves. Wasteful though, which is why new paradigms such as Agile come
along.

Now the Agile ecosystem has become corrupted by a process not comparable to
all the above. Not solvable by those means either. It’s a toughie.

------
adwn
> _Women dominated computing professions from their inception in the 1940s all
> the way through the 1960s. As the scope of computers’ usefulness became
> clearer, however, those jobs started going to men._

Bullshit. Back then, the term "programmer" didn't mean what it means today. A
"programmer" was someone who entered a program into a computer, or even
earlier, plugged in wires according to a schematic. The actual development of
the program was almost exclusively done by men, even more so than today (this
is not supposed to be a value judgement, nor do I want to justify the
situation back then or today).

It's really disappointing to see this tired myth of a supposed "Golden Age of
women in computer science" repeated in the article.

~~~
raarts
Related: the article is misguided on the women thing.

I teach CS in college. I see it every day. Women on average are more
interested to work with people than men. This hasn't changed despite trying to
boost girls' interest in typical STEM fields for 25 years. HR departments have
been pouring money into this like mad. Hasn't moved the needle. Research has
shown that girls don't fare worse in math tests if they are told beforehand
that girls are worse at math. In countries where the sexes are treated more
equally men more often choose thing-jobs and women more often choose people
jobs.

Who thinks that if society would treat everybody completely equal, all
occupations would end up exactly even distributed across the sexes? There are
real differences between the sexes.

The push towards exact equal distribution in everything is futile, hasn't
worked and will not work.

I think it's more important that people can choose to do what they want to do.

Sounds like a rant, sorry.

~~~
jayd16
This is simply inaccurate, at least in the US. The percentage of women in STEM
has gone up. The percentage of workers in the computer field is lower than the
rest and declining.

Your premise also confuses me as I would argue software engineering is more
people focused than, say, lab work.

~~~
lunias
Even if the percentage of women in STEM has gone up do you disagree with the
assertion that: "Women on average are more interested to work with people than
men"?

I believe that while societal factors have contributed to women pursuing
specific career paths, if one was to factor that out or course-correct in some
way you'd still see less women in engineering due to their preferences.

Is it wrong to feel like on average men and women are different in their
preferences? This is not to say that there are not men who exhibit
traditionally female preferences and vice versa. If we could undo the last
2000 years of societal programming (and run a new experiment) I think we'd see
different preferences in men and women then we see today, but I seriously
doubt you'd see 50/50 engagement across the board because men and women are
distinct - although they certainly share a common set of attributes.

------
at_a_remove
I was exposed when it was still eXtreme Programming (back when "extreme" was
the most nineties adjective you could have) and didn't much care for it then.

I keep hearing it touted as this kind of universal cure-all but I just do not
think it is applicable everywhere. On a personal level, the more any given
thing is touted to me as the solution for any and all problems, the more
suspicious I grow. The more fervor, the more I draw away. The more cultish it
seems (convert, adhere, rituals, special names, and then finally the
narcissism of small differences in practice as exemplified by that old Emo
Williams routine), the less I want to participate.

The more I have seen it shoehorned into places where it seemed ill-suited, the
more this was revealed to me, yet the evangelism continues. Nothing like
watching the tape backup guy, suffering from a flare of gout, hobble over to a
room to perform his "stand-up" routine to hammer that home. Of course, we
"probably weren't doing it right," but the more I have seen the slavish
adherence to the strictures of Agile the more it seemed like this was an
exercise in polishing a boss' resume so that he could say he had done The
Things when he went elsewhere.

Reader, he did.

Perhaps the Agile that can be critiqued is not the eternal Agile.

~~~
MattGaiser
The project where extreme programming came from.

[https://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compens...](https://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compensation_System)

Not a good start

------
dragonwriter
The weird thing is that all the criticisms of misplaced focus in agile made in
the article were criticisms commonly made _by_ early Agile evangelists
(including Poppendieck!) of pre-Agile approaches, and the things pointed to
that are needed which make Agile irrelevant are the things that Agile methods
were specifically advocated as superior for by those evangelists.

The real problem doesn't seem to be that Agile is irrelevant, it's that Agile
(and this is actually fairly quickly explicit in the Manifesto and
accompanying Principles) cannot be limited to a siloed tech organization but
must fully incorporate the business sponsor of the project, whether that's the
firms business management for a software/services firm, whether it's an
external customer for a firm doing bespoke software development, or whether
it's an internal customer for an IT organization doing enterprise-internal
development. And despite that being clear in the Manifesto and Principles, it
very often is the case that “Agile” is seen as something the tech team is (or
worse, _does_ ) that stops at their boundaries, and that fundamentally doesn't
work.

There are other equally serious problems, like ritualistic adoption of fixed
processes being described as “Agile”, which it clearly is exactly what Agile
is most opposed to; the use of the phrase “Agile (or Scrum) ceremonies” is a
clear sign that an organization has been infected with this toxic mindset.

------
_jal
Having been through "agile conversion therapy" at two different companies and
then having seen what the companies actually did several months later, I think
most of the value of 'agile' has been realized. To get much more out of it,
you need some combination of a more capable culture and better disciplined
people.

And I'm not talking about just engineering - I'm mainly talking about
customers and management.

Most of the gains come from tighter feedback loops between engineers and other
stakeholders than tend to happen without an intentional effort. This works
because it is simple - tell teams to talk amongst themselves every day, get
feedback from customers more incrementally than you otherwise would, etc.

Most of the rest of the promised gains need better disciplined customers and
managers - ill-defined specs, dropping projects to pick something else up,
only to switch back a couple months later, managers who don't pay enough
attention to what's being done until it is too late, etc.

Perhaps the problem is that it is a management fad aimed at engineers. It
needs a v2 aimed at nontechnical people, "become competent at asking for what
you need".

~~~
dropit_sphere
In practice, this can only happen in a few ways:

\- development becomes a 1st-class "business" activity a la accounting, sales
---not that you necessarily _do_ it as aanger, but you're looked down on if
you can't

\- a culture of "ask about the internals" becomes prevalent, where anyone who
bought software without knowing how it worked was looked on as an idiot

\- developer coup

------
flohofwoe
Call me jaded, but that's probably because the cow stopped giving milk, and
they need to come up with a new cult/religion/ideology to continue selling
books and conference tickets (and consulting gigs of course).

~~~
baryphonic
I think Zed Shaw had the best (or at lest most entertaining) take on being
jaded about "agile." Though, fair warning, it is even more vulgar than the URL
indicates. [http://programming-motherfucker.com/](http://programming-
motherfucker.com/)

He subsequently gave a talk comparing agile (and open source and consulting
and startups and...) to fascist propaganda.
[https://www.youtube.com/watch?v=c5Xh2Go-
jkM](https://www.youtube.com/watch?v=c5Xh2Go-jkM)

I'm not promoting it or saying I agree with it (I actually disagree with quite
a bit of it), but it is entertaining.

------
Yhippa
Nearly everywhere I've worked the quarterly earnings report is the problem.
Due dates mean that time has to be managed so any attempt to use a methodology
seems to regress to some not fun way of developing software.

In places I've worked without the pressure of the quarterly earnings report
I've seen that developers tended to use whatever methodology worked best. It
could be Agile, pair programming, or just walking over to each other's desks
and talking on IM.

------
commandlinefan
I don't want it to die, I want it to become what it was originally supposed to
be.

~~~
kerkeslager
Agreed.

As far as I'm concerned, "agile" refers to the principles on this page[1], and
ONLY the principles on this page. Not Scrum, not Lean, not Kanban, not Xtreme.

The problem is, it's hard to sell a set of principles. To understand people
and interactions takes months of working with people: it's much easier to sell
them a process or a tool and leave. Customer collaboration requires building a
relationship: it's much easier to negotiate a contract for your client and
leave. Responding to change requires you to stick around and see what changes
happen: it's much easier to sell them a plan and leave. And to arrive at
working software you have to get a lot of things right: it's much easier to
sell a bunch of documentation for software that doesn't exist, and then leave.
Money ruins everything: the reason agile had to explicitly deprioritize the
things on the right side of the list in the first place is that all the
incentives in a software company push you toward the wrong priorities. The
things on the right side of the list are all quick, easy wins that look good
on a quarterly report.

There are companies who I've worked with who do agile (the principles) well.
There's nothing wrong with looking at Scrum/Kanban/whatever as inspiration, as
long as you realize that they're just processes: individuals and interactions
matter more. There's nothing wrong with using Pivotal/Jira/Trello/whatever, as
long as you realize they're just tools: individuals and interactions matter
more.

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

------
genezeta
Speed. Sometimes I wonder if people mean speed as in velocity, or if they mean
the drug, seeing as they seem to obsess so much about it.

> Engineering is about seeing a problem, understanding it and using the
> technology you’re good at to solve it as quickly as possible.

Everywhere you turn to there is someone thinking that speed is the most
important thing ever. Everything must be done _quickly_. The best way to do
something is _quickly_. If something takes longer, it's clearly worse.

Even in an article about "the problems with Agile", people still fall into the
trap of speed.

Engineering is clearly _not_ about solving problems "as quickly as possible".
It's about solving them in the _best_ way possible, where you first define
"good" as a balance between all the advantages and all the disadvantages of
each possible solution. _Speed_ is but one of the factors you evaluate.

~~~
boris
The need for speed is the direct result of worse is better.

------
alangibson
I'm not here to defend Agile, but one of the things people get perpetually
wrong is thinking about Agile as methods and tools. Agile is actually a set of
values and principles. You were supposed to fill in your own methods and tools
to support Agile values and principles, but everyone basically just said 'too
hard; do Scrum'

~~~
Buttons840
[https://www.halfarsedagilemanifesto.org/](https://www.halfarsedagilemanifesto.org/)

~~~
alangibson
> and we have mandatory processes and tools to control how those individuals
> (we prefer the term ‘resources’) interact

This was/is literally true at a place I worked. Their official enterprise
Agile process includes a long list of mandatory documents, one of which is a
list of all sprints and sprint goals for the duration of the project, that
must be checked into a document control system.

~~~
Ididntdothis
"we prefer the term ‘resources"

I so hate the use of the word "resources". so dehumanizing.

------
xnx
One of the all-time most cursed diagrams I've seen:
[https://www.scaledagileframework.com/](https://www.scaledagileframework.com/)
. I could not believe it was not parody.

~~~
karatestomp
Message aside, that is a _terribly_ organized diagram. It looks like someone
dumped all the things they wanted in it on the screen, moved them around just
enough that they weren't overlapping, then simply... stopped, having done no
actual organization.

~~~
MattGaiser
> having done no actual organization.

So it was done using agile diagram methods?

------
_bxg1
Agile is one of those words that's come to mean nothing at all. It can be
anything from "iterate fast and do weekly stand-ups" to "spend all of your
time allocating point values to planned sprint tasks so that management feels
like they're in total control". It's been co-opted by the very bureaucracy it
was designed to reign in.

------
empath75
I was saying in a team meeting the other day that using jira stories as any
kind of performance metric is wrong-headed and counterproductive and metrics
should focus on the business value provided by the team and people looked at
me like I grew a second head.

~~~
bob33212
I had a situation where the CEO was bringing up complains from the PM to me
about how there were so many Jira issues in the back log that I should have
been hiring more people.

I said that it would take me 5 minutes to go into Jira and close out all the
existing issues if that is what they are worried about?

~~~
karatestomp
I've written something similar on here recently, but to repeat: I am, at this
point, pretty sure that trying to combine manager-facing and team-facing
planning/tracking/task/reporting tools into one thing is fundamentally a bad
idea.

~~~
empath75
The problem is that jira gives you a unified interface into all the stories
that all your teams are doing, while not doing anything to track the business
value they’re providing.

------
illuminated
The main issue my teams have been facing with Agile methodologies is the
number of the workflow interruptions built in. The only team members happy
with those interruptions were Scrum Masters and PO's but that's because those
were parts of their flows, so they had to have them in order to have their job
done.

The only long term solution for us was to have days dedicated to Agile
ceremonies and days where no team member can be interrupted based on an agile
ceremony need (there were few exceptions, like critical bug discovery, etc.).
In weekly sprints, we had at least 3.5 days of uninterrupted time and in two-
week sprints we had 7-7.5.

That changed a lot the pace of those sprints as people had a lot of time to do
their job and everyone was happy.

~~~
anthonyrstevens
By "ceremonies", are you referring to daily standups? And/or something else?

~~~
illuminated
Everything but the daily standups... We had each day to begin with it, and it
was great as it provided a more broad visibility into what is being done, if
there are any issues, etc. But every other agile related meeting was a
ceremony we have tried to manage as best as possible while not blocking its
benefits.

------
cesium
When something develops to an extreme, it becomes its opposite. This is true
for "agile". Agile has become synonymous with "Jira", which is a direct
contradiction of its original premise. The original "Agile Manifesto" states:
Individuals and interactions over processes and tools, Working software over
comprehensive documentation, Customer collaboration over contract negotiation,
Responding to change over following a plan. Ask somebody these days what agile
means and they'll tell you "Jira" or some other tool combined with heavy
process. Another example of people confusing the means for the end itself.

~~~
temac
And also ask people if they really want all of "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 might not really make sense in some industries...

And if they really want to consider all of that in a dichotomous way. Who
really does not want "working software", and why would I even have to "prefer"
that? this is just too much fundamental that we could as well say: we don't
want to work on garbage projects, and it is stupid to have an extremely good
documentation of a pile of crap. But why jettison documentation if "working
software" is not even considered optional to begin with? I fucking want
stellar documentation. Because why not? I'm tired of reading source code all
day to try to understand what things were even supposed to do...

In some industries "agile" in its original definition can make sense. In
others, not at all. Yet, tons of people will pretend they do "Agile"
regardless of what it is, what they _think_ it is, _and_ of what they do. This
is sometimes some kind of management virtue signaling; except it is not
signaling positive things anymore to those who work.

It really has no meaning anymore. To be honest I'm not even sure it ever had,
as implemented by most, out of the industry it came from (with associated
practices that were also highly contextual)

People should just avoid focusing on fashionable shallow words, and skip right
to the ideas: if all of Agile and even all of Scrum is what will make your
project shine, just do it, but writing essays about it is not really doing it,
nor is pretending it is a kind of universal panacea, nor constructing
consulting services around cult practices. If you must do the complete
opposite; do the complete opposite. And tell everybody you are "agile" without
an once of shame, if that can help raising money or stupid shit like that -- I
mean what is even more agile than doing otherwise than "Agile" if it is a
better idea in your context; so you are not even lying :p

------
peterwwillis
The core of Agile, Scrum, DevOps, XP, TDD, etc, is just to get a developer to
truly understand what it is they're _doing_ and make a meaningful connection
to the real results of it. But before they can ever begin to do that (which is
a huge challenge in and of itself), the organization needs to _get the hell
out of their way_ , but at the same time, _invest tons of money and effort to
help them do what they should be doing_.

If you just "step back" from trying to control the average bunch of engineers,
they will miserably fail, because they have never gone to a school that taught
them how to rapidly drive business value through software. If you hire the
right people, they already learned all of that, and so they'll be successful.

That's how the Netflixes of the world survive. Their organization and process
would seem _totally insane_ to any "average" tech engineering organization.
But it works for them because they learned how to work together the correct
way, the business got the hell out of the way, and it also invested a ton in
helping them do what they need to do.

Agile does not give you any of that. Agile is just a promise of what _should_
be happening, but it doesn't tell you how to get there at all. It's a pipe
dream.

Agile is not the problem, though. It's businesses thinking the engineers are
simple tools to be used to produce widgets, and if they just shove enough
extra business roles and processes around the engineers, that will end up
creating value. But the solution is actually to _remove_ all that extra crap,
and get the engineers to do everything in a way that the PMs and DMs and QEs
etc are no longer necessary.

~~~
betaby
Interesting perspective. Could you please explain what do you mean by
'Netflixes'. What precisely they do and don't (in contrast with less
successful companies)?

~~~
peterwwillis
This talk sums it up, from a lead SRE at Netflix:
[https://m.youtube.com/watch?v=UTKIT6STSVM](https://m.youtube.com/watch?v=UTKIT6STSVM)

------
davnicwil
The process is invented to help to do your job.

Problems begin when that gets forgotten, and following the process _becomes_
your job -- not following the process is doing your job wrong.

Always remember that your job is to build stuff, any way that works.

~~~
AgloeDreams
Spot on. The problem with much of Agile today is that Jira, the product is
sold to management as effectively employee tracking tools that enable them to
know who is good and who is bad and what was accomplished. It tends to turn
engineers into ticket crunchers (chopping their heads off of thinking about
products and isolating them from the customer) and causes planning to be
incredibly near sighted or excessively structured.

------
pragmatic
Speaking of Lean, I remember my mother telling me about their hospital
adopting lean and that meant they could keep only so many supplies on hand in
the lab. I remember thinking at the time "wow, isn't it a bad idea to try to
limit the amount of supplies on hand at a hospital"

I guess we'll have to see if we ever have a major health care crises. Wait...

And we wonder why the hospitals didn't have enough PPE on hand. Did the MBA
virus spread to hospitals and did they misapply methodologies like Lean where
it had no place, except as short sighted cost cutting?

One of the major problems in industry I've seen again and again is management,
etc pretending they know more about the job and it's requirements than the
people doing it.

As Lean originated in manufacturing with the WORKERS making the improvements
and the WORKERS being empowered (anyone could stop the line if there was a
problem) it's bit ironic that a corrupted version was used later to beat
workers into submission and achieve petty cost cutting versus process
improvement as in the health care anecdote above.

------
aeturnum
If you should meet Agile along the road, destroy it!

------
wodenokoto
What is the alternative to agile?

Calling it a to-do list instead of user stories? Not aligning teams on where
we are in the to-do list regularly and removing and adding things?

Agile proponents often say "waterfall", but I have no idea how you would go
about working waterfall day to day.

Would you just make all your user stories/to-do's on day one and never update
them and now you have waterfall?

Having entered the industry long after agile became the new normal, it seems
like the whole discussion is either "stand-up sucks" or people discussing
variations of what is essentially "Regularly report where you are on the to-do
list, often update the teams to-do list", but never "Why not this different
paradigm instead".

Maybe I am lacking imagination, but I am not really sure what a serious
alternative is here.

------
temac
> At the time, software development was suffering from a mistaken belief: that
> building things fast and building things well were fundamentally opposed.
> Mary knew this to be untrue from her work in product development and
> manufacturing, where the ‘lean’ practices that sprung up in Japanese car
> factories and subsequently spread across the globe often ruled the day.

If that's part of the original reasoning, then it was very random. R&D has not
much to do with manufacturing. So I would greatly prefer an actual example
from "product development" rather than car factories...

I mean what build our software is e.g. gcc. I don't know if gcc is feeling
lean, and actually I don't care much :)

------
brainless
So much frustration over something that in theory is so good for building
stuff.

If you go over to [http://agilemanifesto.org/](http://agilemanifesto.org/) and
read these simple 4 sentences, it makes sense:

    
    
      * Individuals and interactions over processes and tools
      * Working software over comprehensive documentation
      * Customer collaboration over contract negotiation
      * Responding to change over following a plan
    

What goes horribly wrong is managers, and their incapability. They do not work
with teams, instead they use agile as a means to simply get updates at the end
of week and set orders down the ranks every Monday morning.

~~~
nicetryguy
\- Individuals and interactions over processes and tools

\- Customer collaboration over contract negotiation

\- Responding to change over following a plan

Would any of these work for, say, building a house?

I hate agile from the bottom of my heart.

~~~
brainless
I can not even try to answer that since they are not even remotely equal. How
often do you change the way you walk through your house, or how the water
flows or the walls look?

Do you launch a new bed in your house to charge people to see every month?

They are not even comparable, like at all. If all you have is hate for
something sure you can not understand it.

~~~
nicetryguy
I have seen and tried to maintain the years of spaghetti code and quick hacks
that Agile projects generate. It is a nightmare. I think i understand it just
fine. It is a flawed premise. Projects should have concrete specifications and
expectations at the get go. I shouldn't be forced to code quickly with a
sprint gun to my head at all times, generating heaps of tech debt by having no
time to retool unstable or inefficient portions of a project, as i am always
busy scotch taping on new features that the codebase was never designed to
handle.

If the customer wants a horse to run 60mph backwards, and the project manager
has no idea that a horse cannot possibly do that, i have to hear why my
"horse" should have been designed with Agile philosophy in mind. Agile is
nothing but a bunch of techno-babble that "sounds good" but offers no
practical advice on how to achieve those ends. It is the scourge of the earth
and would love to see it purged from collective consciousness.

------
arminiusreturns
I recently listened to a lecture about the future of programming, and there
was a sentence that really stuck out to me. The speaker said something along
the lines of "If you go to an agile conference, there aren't that many devs
there and it's mostly management.*

As an ops type usually only on the peripheral of sprints etc I feel I don't
fully grasp the nuances of the different methods enough to really comment, but
that just really got my attention for some reason.

Found the video, linking at the timestamp that includes the manifesto for
agile (which I think has some obvious flaws)

[https://youtu.be/ecIWPzGEbFc?t=3678](https://youtu.be/ecIWPzGEbFc?t=3678)

------
winrid
When I was a manager I'd get the team together every quarter and we'd agree on
"this is what we're going to do" \- and then we'd do it, usually. At the end
of the quarter we'd have to explain why certain pressures pushed things out,
but usually the business cared more that we kept churn down.

For over a year I pushed back on story pointing and things that felt micro
manage-y to me.

It was very hard on me, but it was worth seeing the productivity.

Eventually I was forced to give in to Agile with the big A and left soon
after.

I can't get another management job because everyone wants to do Agile in a way
I hate to manage - so now I'm a developer again... :)

------
ghevshoo
In my experience the main reason that agile mostly sux in large enterprises is
because it is agile in name only. Not a single one of the people who are
responsible from managing the process have even heard of the “agile manifesto”
let alone read it, nor have any of them ever worked as a software engineer. So
in most cases it could easily be better than what it is.

But I object to the authors complaint “and it’s pushing women engineers into
non-technical roles.” and elevating the primacy of engineering above all else.

People come in all levels of competencies and have all manner of skills. I
don’t care if you are a man or a woman. I care about how good you are at doing
the tasks that need to be done to get the job done. And in large companies
there are big jobs that require a lot of people and a lot of coordination.

I work with a woman who is not a very good software engineer, but she is good
at administering and coordinating the work among other software engineers and
she quite enjoys doing those tasks.

While she can improve on some of her skills as a software engineer and I try
to help her with those, the author’s recommendation seems to be that because
she’s a woman, I should push her away from work that she likes doing, that
she’s good at doing, and which is important work to do.

This is objectively terrible advice, but some might accuse me now of male
chauvinism. If so, fine. But I will forward this article to my colleague to
ask her what she thinks and I’ll let her opinion be the ruling decision.

------
kitotik
A lot of the bastardization and commercialization of the Agile core tenets
could have been mitigated by the early pioneers broadcasting the dirty secret:

To deliver any real business value following these philosophies requires an
extremely mature, experienced team. Not just great engineers, but also great
communicators that actually care at least a little bit about the
mission/product/goal.

This simply _does not scale_ and is a complete antithesis of 99% of
organizations culture and hierarchical structure.

------
KingOfCoders
I was a coder in the 80s and did XP in 1999 and became an early Scrum Master
as a developer. Agile has been stolen from developers. The rise of Scrum came
at the same time as the rise of the product manager, and the Scrum PO became a
PM. From then on in many companies it was not about doing the right thing but
getting the most features out of developers, to implement the PO vision, with
little say. We became assembly line workers, put to comfort with high
salaries.

------
brightball
Ultimately, people need agreed upon terms for communicating planning and
expectations.

That's it. The more people are involved, the more complicated the process gets
and all of these approaches evolve out of trying to find an agreeable and
effective way of doing it so that everyone doesn't have to figure out a new
solution every time.

As much of a buzzword hell as it is, I really believe that Scaled Agile
Framework (SAFe) is the closest thing to the right balance of trade offs.

------
joejerryronnie
When I'm hiring scrum masters, seeing "Agile Coach" and "Agile Transformation"
on a resume is actually a bit of a red flag for me. I don't need someone who
can teach my organization how to theoretically run Scrum, I need someone who
can engage with our dev teams, understand the expectations they're being held
accountable for, the challenges in meeting those expectations, and tailor a
methodology (probably Scrum-based) which puts the dev teams in the best
position to succeed and be happy while doing it.

This may be a bit different depending on the make-up and maturity of the team.
Sometimes, we need daily engagement with team members and "structured"
collaboration, other times we just need to make sure everyone understands the
sprint goals and then get out of their way. The challenge has always been when
upper management wants to see a single dashboard which boils all teams down
into a set of pre-defined metrics - and then positively reinforces teams (or
their managers) for hitting metrics instead of delivering solutions. Training
your VP's can be exhausting.

------
jahaja
I guess it's hard to keep methodologies from being co-opted by management for
their own ends, since they do after all have the "power".

~~~
kradroy
I implemented Agile scrum on my team at the behest of my organization. I did
it enthusiastically at first, because I thought it might make a difference. My
opinion changed within the first 6 months. I think it's a waste of time.

Our stand-ups are pointless because they're just status updates. Not much of
consequence can happen in 10 minutes anyway. I ignore our metrics at the end
of each sprint. They're meaningless. Our retrospectives are largely useless
other than giving shoutouts to team members. I feel the sprint structure leads
to Parkinson's law.

This situation, however, is perfectly normal because Agile advocates "people
over processes." My team doesn't give a shit about the Agile process, so it's
mostly like forced physical training but without the fitness benefits.

~~~
swagtricker
Scrum should at best be viewed as training wheels for agile teams. Not the end
state. Good teams abandon scrum for Kanban / Lean concepts once they start
building good collaboration structures, better communication with business,
earn trust by delivering and recognize (as you point out nicely) that the
sprint timebox is artificial B.S. in practice. I think the Parkinson's law can
be a common trap for teams to fall into with the Sprint timebox malarkey.

~~~
vpeters25
This 100%. One of the reasons people hate Agile is because they miss this
point and keep micro-managing.

------
viburnum
Corporate agile is a mixed bag but Extreme Programming is still good though.

~~~
swagtricker
I fully agree. In general, any flavor of agile for software development that
doesn't include the engineering focus that Extreme Programming's technical
practices bring in (fast feedback, refactoring, good testing & design, CI/CD
deployment, team ownership of the solution - weather you pair program or not)
is doomed to become intractable legacy after 12-18 months at the most
optimistic.

------
larkinrichards
I still think agile has a place as a focus for discussion when you're taking a
large organization from a waterfall model (or any model that tries to commit
to delivering a set of uncertain features by a specific deadline) to a more
reasonable and effective process for software development.

In this situation, you'd get shot down for following rigid Agile, because the
process gets in the way of delivering value. What you end up doing is using
the concept of "agility" to sell some agile-lean-hybrid-involve-the-
stakeholders-think-small-and-demonstrate-the-value-of-delivering-value. It's
not about the Method, it's about the outcome.

No one needs to go black-and-white rigid Agile, that's where it went wrong.
But agility is a good way to describe the concept of efficiently changing (and
handling change).

I just feel that every article about capital "a" Agile immediately sinks to
level of pedantry that is a complete waste of time, so... I didn't read the
OP.

------
joejerryronnie
The problem isn’t “Agile”. The problem is organizations which are not good at
software development. Teams which fail with Agile will also fail with
Waterfall or any other development methodology. Teams which generally succeed
with one methodology may find a different methodology a bit more efficient,
but they’re gonna be successful either way.

------
jquast
And just like writing software, when specifications of the agile process are
not clear, almost founded on a “chose your own implementation” scheme, the
result is a big-ridden over-designed and terribly unclear (and endlessly
debated) process. implemented differently at each and every company. Just
grand.

Just like the very process of software design this was meant to aid, they
failed to understand the importance of clarity, brevity, and providing
exacting specifications or instructions.

Fuck you, agile. This is not how engineering should be done in _any_
profession. Thousands of hours of my career has been wasted clarifying this
unclear process to swarms of people who have no single resource to learn from.
And each new company brings a new “we do agile, but....” exception to adapt
to, and damned be if anyone ever writes a single fucking rule of this process
down, so we get to endlessly debate what is this “agile” thing at each and
every opportunity.

------
netjiro
Agile, as commonly encountered nowadays, is mostly just cargo cult. People
chasing dogma and buzzwords with zero understanding of why and when it has
great application and benefits. Just like so many other trends in the past.

Way too easy to "seem" productive while actually being net negative for the
project.

That said, I've had excellent agile projects that have delivered huge value to
the customer at cost and time well below initial estimates.

These days I ask people who shout for agile to actually explain the
fundamentals to me, as though I have no clue. Very rarely do I find anyone who
can hit even one of the four original core ideas and values of "agile":

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

And when I bring up the core ideas, and why they _can_ work really well, I
often see that the people who shout agile actually don't agree with the
fundamentals.

------
AzzieElbab
Here is the talk by Dave Thomas
[https://en.m.wikipedia.org/wiki/Dave_Thomas_%28programmer%29...](https://en.m.wikipedia.org/wiki/Dave_Thomas_%28programmer%29?wprov=sfla1)

[https://youtu.be/a-BOSpxYJ9M](https://youtu.be/a-BOSpxYJ9M)

------
5cott0
Agile is what happens when stakeholders want a car but really need a
wheelbarrow & end up with a skateboard that only has 3 wheels. Product re-
brands it as a scooter and takes a victory lap & now your company culture is
an extremely toxic work environment of implicit & unaccountable power
structures.

------
fourseventy
I like the development methodology laid out my David Cancel in his book
Hypergrowth. I like it because he has founded several large successful
companies and actually used this methodology successfully. Unlike most of
these "agile gurus" who have never sold a product to a customer in their
lives.

------
redisman
In my experience "Agile" whatever that means is still the best of all the bad
options. Is there really a better methodology? I feel like it works pretty
well as long as management doesn't pick and choose the easy parts of it and
then add their own layer of BS on top, which is very common.

------
rafaelvasco
Well, every company I worked with, "Agile" was just a means for management to
keep feeling they're in control, when they're not, there's no such thing as in
control, or to promote themselves with the higher ups.

My best team is me alone, but other than that, the best team I ever had was
one in which there was no meetings, no dailies etc. It was just me and a few
others, receiving the outlines of what the final product had to do, what
inputs and outputs it should process, and then filling this outline with code
and hard work until it was whole. It was far from perfect of course, but we
weren't bothered by unnecessary processes. There was no agile back then
yet....

That said, the methodologies are not the problem. The problem is peoples
attitude and mentality and how they use them.

------
MattyRad
I think the spirit of the article is summarized by Putt's Law
[https://en.wikipedia.org/wiki/Putt%27s_Law_and_the_Successfu...](https://en.wikipedia.org/wiki/Putt%27s_Law_and_the_Successful_Technocrat)

------
helen___keller
I've come to best appreciate agile by calling "agile" whatever practices work
best for my team.

Sometimes we move things in and out of a sprint mid-sprint because new
information came up and it's high priority? It's not ideal (and we'll discuss
it in retro) but that's agile.

We've sat a fat 5-point ticket in our backlog for 3 sprints straight because
it needs a decent sum of meeting time and dedicated attention from multiple
engineers who keep facing higher priority work and not quite having time for
it? That's fine, we're being agile.

Our backlog grooming meeting ended after 8 minutes because we had nothing to
discuss and we're all focused on delivering? Very agile.

~~~
HeyLaughingBoy
Three sprints? LMAO. I've had tickets that sat "In Development" for the better
part of 6 months because higher priority stuff kept coming up, but no one
wanted to acknowledge that we had more pressing work to do :-)

------
d--b
One thing that's for sure is that Agile completely shifted the culture of
software engineering, and generally in a good way. I am very thankful for
that, and I think that this is where Agile has done its job.

Then, the problem with frameworks like Agile is that smart people will use
them wisely, and less smart people will try to apply the concepts without
really grasping the ideas and not really gain anything out of it.

But you can't really prevent people from reading the book, and do stand-up
scrum meetings and sprints and shit...

Unless someone comes up with something else (which most likely will be equally
twisted) Agile is here to stay. I just wouldn't mind watching conversations
about Agile die.

------
lifeisstillgood
Some thoughts I wanted to get out:

I think we need Outcome Driven Development- we define a metric measured in say
graphite, we link a ticket to that asserting the ticket will make the metric
change this way or that, and we commit code to make the metric change

so we start a process of defining what we want, implementing how to measure it
(there could be a null metric and the ticket is to make it not null) and then
measuring our success of changing the metric

this will have organisational impacts as well - no one should take a ticket
without authority span to impact that metric

this will start in the direction of software as literacy or the developer
anarchy

------
zabil
> software developers need to become what they truly are: engineers.

I couldn't agree more

~~~
drapred7
What does that even mean? Its just some vague feel-good platitude like
everything else in agile.

~~~
zabil
Fair point. I wish I could explain, but don't want to try. For the record,
I've been knee deep in Agile.

------
zhenchaoli
Distracting snake oil. That’s what I think about when I hear agile.

------
uDontKnowMe
Tangentially related, has anyone tried to implement the ideas described in
Juval Lowy's new book, "Righting Software" ([https://www.amazon.com/Righting-
Software-Juval-L%C3%B6wy-ebo...](https://www.amazon.com/Righting-Software-
Juval-L%C3%B6wy-ebook/dp/B0822XJZ48))? His methodology of project management
seems much more systematic than week-by-week sprint planning.

------
S_A_P
I’ve worked for 2 big oil and gas firms. I don’t care much about checking
agile boxes. I went from being damn near employee of the month to short list
for being let go when those companies started to live and die by “agile”. I’m
about 50% to blame as it’s a great demotivational tool. The other half is
managers forgetting why they are running those agile projects. I left both
places within 6 months of agile being gospel. Not sad at all.

------
projektfu
I agree with the title but find the reasoning hard to follow. It seems like
the author keeps changing playing fields and tries to stitch a single
narrative.

------
shaunxcode
Csp should replace it. Dog food and turtles all the way down. If you can’t
model your workflow in terms of processes and typed channels with buffers what
business do you have implementing anything more complex (conways law etc.)

THAT said agile was a breath of fresh air at the time and it got us to
question a lot of assumptions related to how we specify and develop software.

~~~
temac
You want to replace Agile with CSP? _Interesting_. Why not replacing Agile
with FSMs, though? Or continuations? Or monads?

------
koonsolo
There are only 2 things your agile team needs: a retrospective and a manager
that wants to improve the process.

Everything else can flow from there.

------
jackcosgrove
I never understood story points. Is it just psychological to use a different
unit of time, so that managers' expectations aren't so hard and fast?

Story points remind me of those weird units of work the cloud providers bill
you for, or the company scrip that a coal mine would have issued 100 years
ago. I call story points AgileBucks.

Why not just use standard units?

~~~
joejerryronnie
I think it’s a purposeful abstraction for relative estimation of a task. Since
nobody is good at estimating the exact number of days a particular task will
take, story points are a way to give a general estimate of task complexity
(usually people end up equating this to a rough timeframe) without having to
commit to a specific number of days.

In our 2 week sprints we have four possible story point values - 3, 5, 8, 13.
If the story should take a couple of days, it’s 3 points. If the story will
probably take the full sprint, it’s 13 points. If the story is somewhere in
between, pick 5 or 8.

------
mindcrime
_Agile 's early evangelists wouldn't mind watching Agile die_

It's easy to say that, but the obvious follow-on question is "and replace it
with what, exactly?" Maybe the answer is in TFA, but I didn't read it yet. I
hope they have _something_ to propose, otherwise this discussion is pretty
vacuous.

------
mjfisher
This seems like as good an excuse as any to share a link to "Modern Agile"
again:

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

I think it's probably a good reinterpretation of the original manifesto that
is a bit more fundamental and a bit more direct. I like the concepts a lot.

------
ChicagoDave
The Agile paradigm has been corporatized and all of its capabilities turned
into heavy process and oversight bullshit. But worst of all, management rarely
sees the need to get involved, especially from the financial management
perspective. It's very often a zombie project management apocalypse in the
making.

------
PeterStuer
There is a surplus of "organizer" roles in IT, call it PM's, call it Agile
Coaches, call it PO's ... for every software engineering methodology. This is
indeed because these roles are far more accesible than the 'hard' engineering
skills in IT.

------
say_it_as_it_is
How many people here refused advice suggesting to go with one's strengths and
instead took a different path in life, developed new capabilities, and
acquired new strengths? Progress was slow and difficult. Yet, you persevered.
You weren't agile, were you?

------
jayd16
Did anyone actually read as far as the sub-header? "Agile" is used to
scapegoat a lot of issues but gender equality is a new on me. Pigeonholing
women into non-technical roles is a problem but I don't see how dumping agile
would solve it.

~~~
bdcravens
Agile _as it is practiced_ has created a new set of roles, like "scrum
master". However, if not agile, that role would probably be called "project
manager", another role that female engineers are often pushed toward.

~~~
therealdrag0
Are they pushed towards it or do they gravitate towards it?

~~~
bdcravens
It seems to me those are two sides of the same coin. After all, gravity is an
external force that takes significant effort to work against.

------
kchoudhu
They've all moved on to newer grifts, and don't need competition from legacy
grifts.

------
zwieback
I thought it was dead already. The people that pushed agile where I worked
already moved on the next hot thing twice. Now programmers may have a chance
to go back to the roots of agile and do it right, without micromanagement from
evangelists.

------
achenatx
the essence of the article is that agile is mainly a project management
methodology. It is for decomposing tasks into chunks that allow you to deliver
something valuable in the given time frame. One of the best parts is that if
you run out of time or money, you have something that is usable with what
should be the most important features.

What it doesnt give any guidance to is how to organize information about how
to build the right thing. If a system is very large, without some methods to
understand and communicate what you are building, it just becomes ad hoc.
Agile is not a product management/requirements identification methodology.

------
postfacto
Agile In Their Own Words

[https://github.com/rayfrankenstein/AITOW/blob/master/README....](https://github.com/rayfrankenstein/AITOW/blob/master/README.md)

------
robjan
The site has blocked Hong Kong (and possibly other) IP addresses for some
reason.

Here's an archive link
[https://archive.is/wip/OFF0F](https://archive.is/wip/OFF0F)

------
zabil
IMHO the Agile manifesto still holds good. It applies to arguments in the
article around processes (and tools) to ironically fix itself.

------
csours
If you consider that science advances, what did Agile improve on, and where
has Agile been been improved upon?

------
a3n
Ugh. I sometimes miss software development, but I don't miss any of this.

------
softwarejosh
proper agiles a way of life, cramming the unproductive types of people into it
was never going to be as good as making a team of agile people

------
atulatul
All movements go too far.- Bertrand Russel

------
charles_f
Agile is not a methodology or a process, it is literally[1] a set of values
and principles which can be summarized by "stop being stupid and trying to
reproduce what they do in construction engineering, and start discussing about
the why and collaborate, doing things that matter, and being flexible, since
after all, we're doing _soft_ware.

The set of methodologies and processes that ensued, as well as the entire
industry of coaches, consultants, evangelists and "practitioners" was probably
coming from a good place - trying to propose an implementation for how to put
in place those abstract values and principles, or to help with that. The
commercialization, envy and corruption that followed is what the problem is.
"Agile" has become a synonym for "cargo-cult brainless implementation of
sprints and stand-ups to copy something called scrum but effectively doing
things in a very much waterfall and old fashion that isn't even remotely close
to the original intent".

The problem is of semantics order. What does need to "die" is the "agile"
industry, with cargo-cultish coaches whose only value is to repeat Scrum says
X, XP says Y, Agile says Z, my other customers do Ω, without trying to convey
the reason behind those implements ; "agile" methodos like "safe" which have
very little agility backed in and whose "Enterprise Architects" proponents
usually don't get any of the intent.

But take a look at the manifesto[1] and tell me that you want it to die, I
feel like the arguments will be very complex. Re: the that we should become
"engineers" (semantics and cargo-cult again), there's a very good reason why
agile applies well to software, but not to mechanical engineers. The economic
equations between those two practices are completely different[2][3], the
"engineering" phase of mechanical engineering is cheap compared to the
production costs and so iterations have effectively an extremely high overhead
cost, whereas the "engineering" phase of software engineering represents most
of the cost, and so iteration and adaptability have a very low overhead.

But saying "agile needs to die" because of how the "agile industry" corrupted
it is similar to saying "email needs to die" because what you see most is
spam.

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

[2]:
[https://www.developerdotstar.com/printable/mag/articles/reev...](https://www.developerdotstar.com/printable/mag/articles/reeves_design.html)

[3]:
[https://www.youtube.com/watch?v=RhdlBHHimeM](https://www.youtube.com/watch?v=RhdlBHHimeM)

------
parasubvert
I’ve been doing XP for 22 years, and was on Ward’s wiki as the C2 project was
being executed, watching the ideas grow in real time. I worked for Pivotal for
the last 5 years. Here are my thoughts.

Agile alone is insufficient to successful products, which the original
proponents would tell you. It’s a body of practices. There are more practices
than just those. People seem to want “12 steps to an easy rich life” and want
to scream when someone offers only 6 of them.

Most of the Agile practices the industry has adopted and evolved without
calling them agile. So in that sense, it’s a “success”.

But agile coaches often are so focused on the original 20 year old practices
and they miss the bigger picture of business and products and supporting
technology, and the evolution that’s taken place in each during that time.

Any software method that is delivering software for users to consume has to be
complemented by outcome-focused approaches like user-centered design, product
development, customer development, and budgetary funding / management
practices that don’t weaponize the use of openness, sharing, and metrics for
political purposes that hurts people’s self worth. If you’re missing those,
agile isn’t going to help you much.

Ultimately just letting engineers be engineers is partly how we got into this
mess in the first place. People don’t know how to organize themselves without
some kind of constraints: design constraints, time, physics, customer
constraints, quality, etc. Talented teams turned loose that ultimately deliver
little of value is a cliche at this point. Agile tries to use time as a
constraint to limit active work in progress to force the delivery of customer
visible / valuable results that can be tweaked. It’s not the only way to
constrain the problem space, but “cost of delay” does have a fairly universal
explanatory value in showing what really matters to a business, as lean
product development and manufacturing has shown. But that might not be the
outcome you’re looking for.

whatever process or practices you do, Agile or not, it has to be organized
end-to-end to be tied to some kind of tangible mission or outcome or else it’s
just a form of self-deception. For example, if we think products need to be
usable and solve actual problems, and that design can evolve, then Product
owners need to speak for the Customers and have the power to make decisions.
Engineers need to be empowered to make the technical decisions. These seem
obvious but they’re rare: committees and political strings attached are the
norm. If you get both an empowered balanced team of product, design, and
engineering you’ve got potential for an engine of collaboration and learning,
which is the whole point. Don’t build projects, build human/techno systems
that grow and improve and evolve.

Agile is also not universally applicable and much of the resentment stems from
a religious conversion therapy or Developer Rehab approach to marketing (even
though some really could use a stint in rehab). Agile is applicable to some
kinds of software (user-Centered software in particular), which happens to be
a big chunk of industry. It isn’t applicable to everything, such as deeply
technical components, pure or applied scientific R&D, or certain kinds of
exploratory work. Nor is it applicable to jobs with set and unchangeable
requirements.

People are best to understand there are a spectrum of practices and processes
suited to different environments and stages of organizational evolution. Or
they could reject such complexity and nuance and just adopt SAFe, I guess.

------
caseymarquis
The article mentions Agile as an attempt to bring lean manufacturing
methodology to software development. I make software which is used as part of
lean manufacturing initiatives (among other initiatives), and see a lot of
different manufacturing environments. I want to point out that lean
manufacturing is often the wrong tool for producing significantly more of
something complex or ramping up production speed of a complex product. In its
defense, you could say that lean should be this tool, but is usually so
misinterpreted or done so incorrectly that it fails to be this tool. (funny
that agile reportedly has the same problem)

Generally speaking, lean is a tool for reducing various kinds of 'waste' and
'doing more with less'. That's the part people seem to focus on anyway. The
problem is that people become myopic. Lean becomes the justification for
premature optimization and focusing on details that don't matter.

Sometimes, waste is good. Or, stated differently, not all waste is equal. If
you have 5 machines that each produce $1000 of value per hour run, and you're
attempting to go lean by rearranging them so you can lay off a $20/hour
employee, then you are focusing entirely on the wrong thing.

Lean is often pushed with the idea that employees shouldn't be standing around
doing nothing, or that you shouldn't produce excess material which will sit in
a pile. The problem with this is it often fails to account for needed excess
capacity, and when something goes wrong, everything falls apart.

The correct move (depending on margins) is usually to hire more inexpensive
humans to stand around and make sure the expensive machines never stop
generating value because you overburdened one of the humans. When you want to
make things faster, you don't stop producing when the next machine in the
process can't keep up (producing a pile of unused parts). You buy another
machine that performs the next process or figure out what it needs to run
faster.

Lean is the methodology most people use when they can't make big changes that
will have a major impact on production. It's a tool for making the existing
(possibly broken) system function better. It's culturally good to focus on
reducing waste, but often it's the waste you're not measuring or thinking
about that's killing you.

Lean isn't bad any more than optimization is bad, it's just not the tool you
typically want to be starting with. I work directly with customers, have no
deadlines that aren't self imposed, and couldn't tell a story point from a
scrum master, so I can't say if the failures of lean manufacturing
implementation extend to agile, but I'd be curious to hear if they do.

A tool I find more useful than lean:
[https://en.m.wikipedia.org/wiki/Theory_of_constraints](https://en.m.wikipedia.org/wiki/Theory_of_constraints)

------
andarleen
“and it’s pushing women engineers into non-technical roles” - wtf

~~~
drapred7
Feminists are always promoting numerous and spurious explanations for why
women seek out non-technical roles The qualities of women themselves being a
sexist and therefor a priori false explanation.

------
tabelle
why are people still talking about agile?

~~~
werber
Because we’re still dealing with it everyday. I can’t even count the number of
basic trainings I’ve gone through and then seen everything they preach go
directly out the window

