
The End of Agile - interweb
https://www.forbes.com/sites/cognitiveworld/2019/08/23/the-end-of-agile/
======
jdmoreira
It works pretty well for me but that’s because we refuse to engage in
bullshit.

No estimates. No sprints. No Jira. No bullshit!

What we do? Retro, grooming and planning. Standup everyday in front of a
Kanban board with post-its. And we help each other. That’s it!

Seriously, how hard can it be? Building software is not the same as a Ford
model T assembly line

~~~
collyw
As usual no one can agree what agile actually is. Is what you are doing agile?
Some would say no. Some would say yes.

Someone will likely says agile is a lot of shit and someone will reply saying
"you are doing it wrong" without giving any indication of how to do it right.

~~~
jdmoreira
again here is my opinion... The minimum requirement for doing agile IMHO is to
have retros and to iterate the process all the time until it works. That’s it.

But what agile is or is not is just semantics. It’s irrelevant I think. Who
cares if we all follow the same set of rules? People selling certifications
that's who!

~~~
wan23
Same! Whenever I have to explain what agile is I start with retrospectives.
It's the one rule that is mandatory. Standups, sprints, JIRA boards,
grooming/refinement sessions and everything else in a heavyweight framework
like scrum is there to support the principles of agile, but none of it is
actually necessary. IMO every software developer should read the Agile
Manifesto (
[https://agilemanifesto.org/principles.html](https://agilemanifesto.org/principles.html)
) every once in a while and consider whether their process is actually working
for the team.

------
lmilcin
Agile has nothing to do with what is described in the article.

Agile is not dead and will be more important going on. "Agile" (apostrophes
intended) is and will be kept alive by countless managers of different levels
that would like to emulate successful organizations but don't want to spend
time and effort actually understanding what makes them successful.

Please, read something like "Pheonix Project" (Gene Kim, Kevin Behr, George
Spafford) or "The Goal" (Eliyahu Goldratt) to get better informed about what
Agile is.

My understanding of Agile is that it is a shared understanding, commitment for
porsuing goal of serving your organization and your customer as efficiently as
possible. Hopefully, serving your customer is tantamount to serving your
organization, if your organization's values are right.

Agile is not a process. Agile is a drive to seek most efficient process. Agile
means you are honestly critical of what you are doing and are constantly
learning and adjusting to get best possible outcome.

Scrum or Kanban happen to be one of ways to implement Agile but they are not
equivalent to Agile. Agile precludes any single set process because every
product, customer and organization is different and so it is not possible for
a single set process to be best possible process.

Scrum or Kanban are anti-Agile in my opinion because they tend people to get
complacent with the process (yes, we have implemented Scrum so we are Agile).
Being complacent is opposite to what Agile is -- constantly seeking better
process.

------
notus
Honestly, the part about agile I dislike the most is a dedicated scrum master
role. They have very little to do if they aren't split between multiple teams
and instead try to come up with weird ways to add value which usually don't
add any value. We had agile coaches at my company recently and it was one of
the more painful experiences of my career. They would try to add all these
different flavors of grooming, planning, standup, and retro that usually just
led to developers being uncomfortable and wanting to work from home. I'm not
saying agile doesn't work, but it doesn't need to be a full time job and take
up that much of developers time and they sure as hell don't need to inflate
the process and methodology just to feel better about themselves.

~~~
dragonwriter
> Honestly, the part about agile I dislike the most is a dedicated scrum
> master role

That's not a part about Agile, but about Scrum.

Also, the “dedicated” part isn't even essential to Scrum.

> We had agile coaches at my company recently and it was one of the more
> painful experiences of my career. They would try to add [...]

That's a different issue than a dedicated ScrumMaster role, and anti-Agile, as
team ownership of process is central to Agile. Consultants external to the
team (whether internal to the org or external there, too) trying to impose
process is the antithesis of Agile. There might be a role for coaching in
Agile, but it certainly isn't process advocacy.

~~~
notus
Fair points, I tend to conflate agile and scrum since they seem to be coupled
together. I get that the dedicated part isn't a requirement, it just seems to
be part of most implementations I see. I guess my problem is more with
people's implementations.

------
9wzYQbTYsAIc
> work methodologies are moving towards an asynchronous event model where
> information streams get connected, are mapped and then are transformed into
> a native model in unpredictable fashion

Probably the most insightful quote from the article.

------
ljw1001
Agile died the minute someone who never coded anything for money could get a
certificate proclaiming them an expert.

------
sparker72678
No development methodology can eliminate the fact that building software is
hard, and complex data systems quickly grow exponentially in complexity.

Developing and maintaining a large project will be difficult, no matter your
approach.

Which is not to say that all approaches are equal.

Part of our problem is that we want a development/management approach that
works for all types of problems. There isn't one.

------
djmips
"Perhaps the last major holdout of such applications is with the category of
games, and even there, the emergence of a few consistent tool-sets such as the
Unreal Engine means that there's increasing convergence on the technical
components, with Agile really only living on in areas such as design and media
creation." \- In practice, I haven't seen the use of Unreal Engine promoting
the end of agile or vice versa. If what he's saying here is that using off the
shelf game engines means no more need for programmers so no more agile (except
for content) then he's dead wrong. Every game that I've ever worked on using
Unity or Unreal have a significant amount of programming work involved. Some
of them have used agile and others less so.

------
jdlyga
The team I'm on uses Agile, but in practice it's a combination of Agile,
Kanban, and Waterfall. The tasks we work on are usually pretty big and
undefined. And it's nice to meet every couple weeks to plan out a sprint. But
an overall waterfall-like list of objectives drive everything, and we're not
strict about adding or removing things from the sprint. So I don't know what
system fits us best. Agile encourages us to document tickets so they can be
worked on, which is nice.

------
dragonwriter
> The Agile Manifesto, like most such screeds, started out as a really good
> idea. The core principle was simple - you didn't really need large groups of
> people working on software projects to get them done.

That's not the core principle of the Agile Manifesto. In fact, nothing even
vaguely like that is included in the _Manifesto for Agile Software
Development_ [0] or the _Principles behind the Agile Manifesto_. [1]

Now, to be fair, there is a study or set of studies which shows that, for
software projects within a certain broad size range, a team size of 5-7 gets
the project done fastest, and that larger teams not only take more man-hours
for the same size project but more calendar days, and that study is broadly
influential in setting team sizes in teams that claim to be practicing Agile
or Lean development; that's not a, much less _the_ , core principle of Agile,
though, just a piece of empirical evidence that became available when Agile
(at least the name, of perhaps not the actual philosophy) was becoming
popular.

Agile has kind of the same problem as Marxism; the theory is, and the is quite
critical in both cases, bottom up, but most of the practical implementations
throw that out and are top-down.

With Marxism, this might seem like a bigger problem because it is _every
single implementation_ that claims the name has the problem, but in a sense
it's a little _easier_ to distinguish the problem in practice as being
separate from Marxism itself because at least all the real world
implementation point to a particular revision of the theory which contains the
diversions from the original (Leninism). So at least you can point to Leninism
and say it's the problem distinct from Marxism. While there are a few bottom-
up Agile implementations where the teams really are self-organizing and
empowered, the norm is top down implementation of something that at least
superficially resembles Scrum, without any real control of process in the
team, but there is no clearly diverging theory that unifies the top-down one;
they don't claim to be practicing Agile-Leninism but instead plain, vanilla
Agile, though their practices are in no way grounded in the Agile Manifesto or
Principles, but instead the same canned-process management approach against
which Agile was a reaction. So it's a little harder to distinguish based on
what the implementors say is their philosophy, though it's still possible to
distinguish the substance.

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

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

~~~
jdlshore
> there is a study or set of studies which shows that, for software projects
> within a certain broad size range, a team size of 5-7 gets the project done
> fastest, and that larger teams not only take more man-hours for the same
> size project but more calendar days

I'd like to read those studies. Do you have a cite?

~~~
dragonwriter
That specific finding was from what appears to be the 1997 QSM study [0],
though the description I am familiar with it from (Mike Cohn’s _Succeeding in
Agile: Software Development Using Scrum_ , 2010, describes it as covering
projects in 2003-2005 (the author, organization, and number of projects in the
analysis, and the one result chart from the study that is in the article on
the web [1] match between the book and the 1997 one, though, but the chart
showing time to complete by team size isn't shown in the article.)

[0] [https://www.qsm.com/blog/2019/4-key-studies-team-
size](https://www.qsm.com/blog/2019/4-key-studies-team-size)

[1] [https://www.qsm.com/articles/team-size-can-be-key-
successful...](https://www.qsm.com/articles/team-size-can-be-key-successful-
project)

------
winternett
Agile is nowhere near an end...

People just aren't willing to admit the parts of it that are Kool Aid, and the
parts that are useful because it's a profit machine (books, training, merch,
etc)as well as a methodology for getting things done in projects.

I have never seen anyone implement agile fully in my world, it's usually 50%
or below in terms of adoption rate. Passing around a hockey stick is a
gimmicky thing, and I've always avoided the silly ideas, i want to go to work,
stick to the points, get things done right and then go home... Sprint Poker,
passing a hockey stick, agile toys, going to Agile conferences etc can be left
to agile coaches if you ask me.

~~~
commandlinefan
If capital-A “Agile” ever ends, it will be replaced by something with a
different name that takes exactly the same form. How do I know? Because I’m
old enough to remember before there was capital-A “Agile”, and the original
XP/Agile manifesto came along and within a few years was bastardized into
exactly what came before it: the expectation that with enough meetings and
unreasonable enough demands, software development could be a perfectly
predictable, cookie-cutter endeavor, as uneventful as manufacturing sheet
metal.

~~~
winternett
Agreed, before Agile there was Waterfall, RUP, and many other theories of
assembly line management processes. They are all based on starting
universities for the way to produce a product, and these paradigms all came
from auto makers... It's a constantly spinning wheel... Can't be stopped...

------
end-of-remote
It can't come fast enough. It's a worthless methodology, band-wagoned to
irrelevance.

Mark my words, remote work is worse, and will destroy careers.

------
billman
Agile was never a thing, it was always a how.

------
topkai22
Re-

