
Maybe Agile Is the Problem - signa11
https://www.infoq.com/articles/agile-agile-blah-blah/
======
zbentley
The core issue, I think, is that software development remains unpredictable in
many very common situations (for a whole lot of reasons, most of which are not
technical). Management and planning requires predictability, so we devise
systems like Agile to attempt to impose predictability. This addresses the
wrong problem: the work itself is unpredictable, no matter how predictably
your sprints start and end and how well you fit X% of a project into each
sprint. Things improve (in many cases thanks to systems like Agile) until they
hit a local maximum constrained by that fundamental unpredictability, at which
point planners and management are still unhappy, so more process is imposed,
abd eventually we end up in the situation described by this article.

Usually,causes of the fundamental unpredictability remain unacknowledged and
unaddressed beyond a superficial level.

~~~
zepto
I wonder how Apple gets round this?

~~~
konschubert
By never announcing things before they’re ready?

~~~
zepto
This seems to work very well. Why doesn’t everyone do it?

~~~
konschubert
You get a short-term boost out of announcing something. Some companies feel
they cannot wait for that boost until they’re done.

------
markodjurovic
All these new nonsenses are a problem. Those who understand them can also see
that they are nonsenses, and those who do not understand them think that they
are superior methodologies.

------
PaulHoule
Following the "12 principles" blindly is just as bad as letting your
organization be rolled by the "agile industrial complex".

The idea of breaking work up into little chunks is great -- it is in no way
contradictory to the ideas in the "Project Management Body of Knowledge" it is
just putting them together in a different way.

In fact, those ideas need to be put together in a way that works for a
particular organization.

In some cases the most important practice is the reduction of "work in
progress", that is, a simple kanban board without a lot of effort into
estimates and deadlines. If you have good build and deployment practices you
should be able to deploy "whenever the business needs it" and not have to wait
for a sprint to finish.

The biggest problem I see is a lack of trust between management and
engineering. If that trust is not there it doesn't matter much which
management methods you use. With agile you will bring conflicts up quicker,
but that just might cause you to burn people out and spin your wheels. If you
work on a longer timescale some people might be able to get work done despite
the dysfunction.

------
kevwil
No, corporate "agile" is the problem. Politics, resistance to change, and
power struggles are what's fatiguing. True Agile is liberating and
invigorating, but unfortunately rare.

~~~
bobm_kite9
So rare that perhaps the meaning of the word has changed irrevocably?

Disclosure masquerading as a plug: I’m writing this at the moment-
[https://riskfirst.org](https://riskfirst.org)

------
raducu
It's the same old bureaucrats who just changed in the "agile" clothes. Because
"agile" is whatever form the bureaucrats want to call "agile".

~~~
vanadium
It even shows up as “agile workplaces” these days, where it most often
manifests itself as open floor seating with no set arrangements—transient
would be the best characterization. FTA, just another example of how the
word’s lost its meaning, this time to the buzzword wars.

~~~
levythe
What do you mean by FTA? I'm not familiar with that TLA.

~~~
vanadium
"From the Article"

