
Agile Is Dead – Pragmatic Dave Thomas [video] - dsego
https://www.youtube.com/watch?v=a-BOSpxYJ9M
======
kabdib
Management: "You mean there's a software development methodology that lets us
track dev progress with a microscope, and that eschews planning (which we hate
and suck at anyway)? And _bonus_ it makes us look hip and with-it? Sign us
up!"

I knew Agile was dead the moment that Microsoft managers started to
"implement" it.

~~~
UK-AL
Why? Microsoft consistently develops some of the most popular products.

~~~
na85
Microsoft's products are popular due to excellent marketing, not because of
their technical merits.

Most of their products are mediocre at best, and many of them seriously suck.
Particularly their operating system.

IMHO the only thing MS has produced that's actually good is Excel.

~~~
anko
Visual Studio is awesome

------
jeremiep
I've seen that talk last year, great talk! I really like how he makes the
distinction between Agile and agility and compares the values of the manifesto
with the consultancy industry which spawned around it.

But I have yet to find a manager deeply believing into Agile who'll questions
those beliefs after watching the video. I feel the problem with Agile is that
a lot of the people who enforce it are either not programmers or terrible,
terrible ones.

I have also yet to find an Agile project with actual agility, but that's just
my own personal experience :)

------
spydum
As with anything, I think folks are trying to sell you tools for the "how"
part. The trouble is always in the implementation. His point is very valid
about poor architecture is hard to change... And I think over investment in
tools/process for agile is precisely that.. When you spend more time and money
filling out JIRA tickets and staring at Kanban boards and attended SCRUM of
SCRUMs and hours long standups, you need to reevaluate if your process is
doing more harm than good.

~~~
jamisteven
So true. Im not a developer but work in production, so much paperwork bogging
down productivity.

~~~
EvanPlaice
The question that should be asked in that case is what purpose does excessive
paperwork cover?

In my experience, it's usually poor management looking to cover their own ass
when deadlines are missed and/or establishing a track record so if they need
to fire people they have a legally justifiable reason.

------
nathanaldensr
Agile principles, in an academic sense, are great. However, for agile to work
best, it's my belief that the team needs to be of a similar skill level, trust
each other implicitly, and have the same value system (i.e., "we believe in
writing software for the long-term", "we believe in being disciplined", etc.)
Too often this is not the case. Many things are good _in theory_ but once
applied to real human systems, fail.

~~~
natec425
I disagree with one of your three conditions; I don't think all team members
need to be of similar skill. Particularly, I think agile practices can be very
good for knowledge sharing between senior and junior developers.

As for trust and values, I might combine the two and say that members have to
trust in each others values. For example, I don't want to bother to get my
code reviewed by someone who doesn't care about its quality, and I don't want
to put in the effort to review someone's code if they are only having it
reviewed to satisfy the process. These differences in values can really suck
the energy out of the process.

------
riprowan
The problem I have always had with agile is that it's held up as an
"alternative" to waterfall, when in reality it's orthogonal to the two areas
where waterfall excels: top-down project planning and contracting /
expectation-setting with stakeholders.

Agile is something that team programmers really love for its team-building
qualities, but stakeholders / project sponsors / angel investors will _always_
think in terms of deliverables and timeline.

Waterfall project management is useful because it provides a framework that
stakeholders understand. It is also a requirement any time you are dealing
with a bureaucracy of any sort, where deliverables and dates will be required.

TL;DR don't use waterfall to break down tasks and assign work, use agile for
that. Use waterfall to understand and communicate your project from your
stakeholder's / customer's point of view.

~~~
UK-AL
If your team uses agile, but you report using waterfall. Your reports are not
mapping reality. It's just lies to keep people happy.

Quite simply the order you do things is radically different.

~~~
ssmoot
It's not though. This is why Agile is such a failure. Because people don't
actually read the Manifesto.

It doesn't say planning is unimportant. It doesn't say contract negotiation is
unimportant. It doesn't say timelines and knowing what you're doing is
unimportant.

You can and should do all these things. It's amazing to me that Software
Developers seem to believe their job is somehow unique and it's just not
possible to do simple things General Contractors and real Engineers do every
day.

Agile is just a set of values that amount to "be pragmatic and flexible".

You can totally do that without Scrum and avoiding any sort of planning until
the last possible moment.

IME actual requirements almost never change in software. They're just
frequently not surfaced until code hits the page because little to no due
diligence was done on them. And I very very rarely see a case where an issue
with fulfilling the client's desires as given couldn't have been surfaced and
resolved very early on if someone had just sat down and thought about it for a
few minutes before going off and promising something that couldn't be
delivered in the time or budget allowed.

~~~
kod
It's amazing to me that people compare a job that we have 7,000 years of
experience with (making buildings) to a job that we have 70 years of
experience with (making software).

~~~
dasil003
Also the construction of physical objects obeys unchanging physical laws. The
construction of software is the coalescence of arbitrary logic.

Real engineers decry the lack of discipline in software engineering, but I
don't think it's possible to impose anything approaching the discipline of
physical engineering without radically more constraints, but to do that would
require subdividing software into a large number of much more focused domains,
and even then, the divisions would be somewhat arbitrary.

------
ebbv
I think the problem is that people think Agile is a magic potion to fix
dysfunctional teams and it isn't. Agile only works if your team works well
together. There's any of number of ways for the team or the PO or the
customers to make sure a project fails, whether you're operating in an Agile
way or not.

We switched to SCRUM last year at work and things have been amazing. My tune
may change over time, but when we stick to the system we've developed things
are great. 80% of our time is about getting work done. We focus on one project
at a time and we deliver high quality code.

But there's more ways to make things fail than there are to make it succeed,
and Agile is not a solution to people being terrible.

~~~
JoeAltmaier
I was under the impression Agile was just the opposite - used to give
structure to dysfunctional teams so they could learn to work together? Old
established teams don't need more structure - they have grown processes that
work for them.

~~~
ebbv
Agile doesn't give structure when compared with Waterfall (traditional project
management), usually an Agile system is less structured (at least IMHO), and
will have less meetings, shorter planning discussions, etc.

If your team is dysfunctional Agile will not fix that. Agile _requires_ a
functioning team that can communicate together and invested in working
together.

------
inanutshellus
As a counter--FWIW--Agile works really well for me and my team. We work with 8
people in a "pod", we dogpile onto backlog items and destroy them. We pivot
when the needs change. We trust each other but review the commits anyway. We
don't do scrum-of-scrums (they're a symptom of a problem IMO), we minimize and
mitigate any effects of external dependencies (e.g. our very first task in a
project requiring them is to mock their expected/future implementation)

...

We also eschew software solutions to sprint management, which matters. We also
don't bother with morning stand-ups. ("Wait, you don't do morning stand-ups?!"
\- Yep. Morning stand-ups are training wheels for effective teams, and are
necessary for folks that aren't co-located.)

Anyway. I know that "wait, no, this actually works" doesn't sell books or
tools or get clicks, but just know that folks proclaiming its death are
probably selling you something. Like... video clicks for ad revenue.

~~~
vonmoltke
> Morning stand-ups are training wheels for effective teams, and are necessary
> for folks that aren't co-located.

They're also necessary for teams where people are working on multiple projects
at once. All the happy stories I hear about Agile come from people in your
situation, where you have a team of X all concentrating on a single project.
I'd love to be in that situation for once in my career.

~~~
inanutshellus
Agile does not work well for service teams like tech-ops and stand-alone qa
teams. Strict kanban works better for those.

It still does work well for us even when we have multiple projects. Those
multiple projects are time-sliced rather than resource-sliced whenever
possible. In other words, keep your _team focus_ on one thing for a given day.
It's harder to get buy-in from your team to try it than it is to actually do
and see succeed.

~~~
dragonwriter
You seem to be using "Agile" to mean some particular methodology, probably (at
least, this is usual when this mistake is made), Scrum.

But Agile isn't a methodology; it is a set of principles and priorities for
use in determining (and adapting over time) the right methodology for a
particular operation.

There are a number of methodologies that have been described as a result of
(in theory, at least) applying Agile principles in particular environments.
Scrum is one of those, but so is Kanban (and so are hybrids of the two,
sometimes called "ScrumBan".)

------
character0
I've definitely seen the benefits of agile for my teams, but where it starts
to fall apart is when the focus is velocity. This means management doesn't
really have a clear goal, only that they are getting somewhere quickly. This
leads to burn-out and typically those dev teams have no connection to their
customer either.

------
lanestp
That was a fantastic talk, well worth the time. If I can summarize my takeaway
it would be that Agile or agility is a holistic thought process to guide all
your software decisions. The way people have implemented it is to have rigid
guidelines that lets middle managers micromanage us to death. Sounds about
right!

------
p4wnc6
This is very related to a comment [0] I made on another post yesterday, and
some of the follow-up comments there.

[0] <
[https://news.ycombinator.com/item?id=11544367](https://news.ycombinator.com/item?id=11544367)
>

------
perseusprime11
Agile is dead from day 1 as you can never be truly agile by simply changing
the software development process to agile. What about financial processes like
setting annual budgets. This is what happens when you put a bunch of white
guys in a Lodge in Utah.

------
p4wnc6
One of the main ideas put forward by Thomas is that the generic agile
principles are basically a reflection of gradient descent: take a small step
in the direction you think you should go, evaluate the value of doing so and
the error generated, then repeat. For a well-posed problem, you'll converge
without taking huge steps generating tons of short term inefficiency.

Real world Agile is effectively like taking this gradient descent idealization
espoused by the agile creators and turning it into _simulated annealing_
instead -- a vastly slower, dumber optimization method with no guarantees
about avoiding local extrema.

This analogy carries you pretty far. It's all the extra political,
bureaucratic, micromanagerial stuff that creates the effect of _random_
displacements, as in simulated annealing, instead of _calculated_ ,
_deterministic_ displacements as in real gradient descent. (And hooking up
user and customer feedback as a major driver for the displacements is one of
the worst failure modes for this.)

For me, the trouble is that "real agile" (i.e. the "good" and "not
manipulated" principles) doesn't provide any mechanism for explicitly
preventing this kind of political subversion. It's just too easy for middle
managers and bureaucrats to subvert for their own purposes, while shoving all
the negative externalities of doing so onto lowly developers.

I don't particularly like Agile because I don't think one-size-fits-all
approaches will ever work (e.g. every sprint must be 2 weeks long, every
workflow must involve story points, etc.).

But if I had to think about a way to vindicate Agile and protect it from
subversion, I would suggest it needs some kind of explicit statement that
short-term business concerns are not valid excuses for modifying the process.
Of course, then managers won't like it ... because they _only_ like things
that give them metric surface area with which to politically manipulate the
situation for their changing agenda, and so Agile would become impossible to
sell to huge companies.

It's a Catch-22. Actually good software dev practices that make money, make
customers happy, and live up to quality standards instead of just paying lip
service to them are completely at odds with executives and managers who want
to torch the commons for the sake of short term bonuses and couldn't give two
shits about whether it makes customers unhappy, etc. (because they will have
secured blame insurance against that anyway, and may even make more money from
endless irrational tech re-orgs).

------
matdrewin
Just like in software development, a framework/methodology is not a
replacement for competence. People apply idioms blindly without putting things
into context.

------
daxfohl
I agree with the view on testing. I mostly use testing as an excuse to shape
up bad old code when starting work on existing products, then delete the tests
afterwards.

------
mrharrison
Agile works fine. I find that people are broken and don't want to change, or
they want to adopt some magic formula by talking about it a lot but don't
actually practice it and when they run into problems they blame the process
they weren't practicing correctly. If somebody has a process to change
people's bad attitudes I would love to learn that.

------
Cypher
I saw this a year ago too, its was a good watch.

~~~
forloop
It was on /r/programming 4 months ago[0]. As far as I can tell, HN is behind
the times, these days.

Not only with stories, but also world view.

[0]
[https://www.reddit.com/submit?url=https%3A%2F%2Fwww.youtube....](https://www.reddit.com/submit?url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3Da-
BOSpxYJ9M)

------
brightball
Very much worth watching. Agile is not a noun. :-)

------
ljw1001
if only.

