
Three Ways Agile Has Gone Astray - aard
https://medium.com/@ard_adam/three-ways-agile-has-gone-astray-165acf3fd3c0
======
ianamartin
This article isn't bad, but it misses the number 1 problem with Agile:
Businesses are not agile. Some software teams might start out that way. Some
start-ups may be nothing but the software team in the beginning, with a CEO in
name in order to attract funding. But all businesses are waterfall
organizations. The moment a business signs its first meaningful contract
(money will be exchanged, on this date, for some product that does x), the
company is waterfall.

The "best" (read: most agile) scenario is when the product team bends over
backwards to completely isolate the dev team from the rest of the business and
maintains the illusion that the dev team is operating in an agile manner while
dealing with the rest of the business in business (read: waterfall terms).

But the layers of abstraction in this scenario are too thick and too leaky.
There's no reason to maintain this fiction, and I submit that it's also
extremely unproductive and inefficient to do so.

Every software engineer not at an early stage software startup is working at a
waterfall company. We should stop pretending otherwise and come to grips with
that reality and put more effort into coming up with better ways of dealing
with that.

------
mlthoughts2018
I am not a fan of the general commoditized one-size-fits-all management
approach that goes by the modern term "Agile" (putting aside all the no-true-
Scotsman debates about what 'real' Agile is for now...)

Usually I read articles like this feeling like the author missed the point,
and that it's just some rehashing of the many different ways modern Agile gets
it so wrong.

But this article actually impressed me a lot.

I agree very much that the one of the biggest problems with Agile is the
notion of fixed-length "sprints". Even the basic language of 'sprinting' is a
problem, which begets bad culture and a misunderstanding of different speeds
and priorities for different teams and different paradigms of work, like the
difference between people answering PagerDuty alerts and people researching a
new statistical model ... Those two groups absolutely don't work the same way
or at the same cadence or with the same need for planning, and there are a
million other teams and work types that differ too.

It seems reasonable to use bookkeeping tools like Trello or JIRA, but the
horizon of work should be customizeable and should be adaptive to specific
personnel, teams, workflows, situations, times of the year, etc. If the
interface artificially requires choosing one cadence length, then just make
sure the company knows to ignore it and assign no meaning to it. Then let
teams break things up however they choose.

The other huge one, which the author mentions, is wasting time on useless
group estimation. This one is a gigantic mess and fraught with problems:

\- It can become politicized among the team, seen as a chance to lobby for
whose work is more valuable, or even in the worst cases to try to directly
attack someone else on the team by making it look like their workload is
always lighter.

\- It sparks a ton of bikeshedding. People will argue about whether something
is "a 1" or "a 2" in some totally meaningless Fibonacci units, like OMG who
cares! You'd be better off just assigning it, starting some work, and asking
for updates. You'll know when something creates a surprise blocker or involves
way more work than expected.

\- Managers always claim that they just want velocity numbers for ballpark
understanding to aggregate up to higher level managers, but it's not true.
They really want to cherry-pick statistics and charts from that nonsense to
sell other managers on stories about progress, road maps, etc. So you
basically turn your expensive software developers into Mechanical Turkers who
are manually punching in meaningless Fibonacci numbers for no other reason
that giving middle management the opportunity to datamine juvenile Excel
charts. In the end, none of it corresponds to deadlines, workloads, etc.

\- Agile support staff, like Scrum masters and coaches and shit, always have
their own take on it that superficially sounds like it's more humane and
focused on holistic workflow health, but really is just double-speak for
capitulating to the stuff management wants. For example, I had an Agile coach
once who swore that all our troubles with time getting wasted on story points
estimation could be solved if we created "gold standard" example stories, like
a canonical 1-pointer, canonical 3-pointer, etc., and just used these during
our planning meeting. I could see the painful sincerity in his expression, and
I couldn't help but think, "this guy doesn't know anything about software
engineering at all ... he just wants us to think positively about what
management is making him make us do."

On the third point that the author made, about group code ownership, I think
the problem ties back in with the estimation problems. For example, the author
writes,

> "Rightfully, everyone should have read access, but things go wrong when
> everyone has write permissions..."

It's not so much that literal write privileges are the problem. Rather it's
about fluffy policies like, "everyone's opinion should could equally towards
code review" or the idea that everyone has equal say in the chosen
architecture, design idea, etc.

It sounds nice and democratic, but in practice it's just more surface area for
bikeshedding and time wasting. I find it's a lot better to explicitly take
into account who has expertise in which topics when weighting whose opinion to
use. Letting people act as mini-dictators regarding a certain implementation,
or have creative control over an API design, is often a lot better than trying
to get consensus on everything.

Besides, the bigger picture is that you want to use code review and testing to
make nice iteration loops over your code and your choices anyway. So if
someone has creative control and gets an API done quickly, you can do code
review and let someone else iterate on some refactoring during the next cycle,
or later when there is time. Over time, the code begins to reflect a
compromise among the design preferences of the team, but in a way that always
maintains testability and gets checked through acceptance tests and CI.

Compared with a design project that flames out before it even starts because
you have multiple competing design doc proposals and bitter arguments about
whether to use OOP or functional programming or this library or that library
... Most of the time just assign it to someone with skills in that area and
move on.

No story points, no two-week implied deadline or progress check in, no feeding
of meaningless Fibonacci numbers to middle management, no speaking about the
creative process of software design with language like "sprinting."

No time wasting with useless group discussion for assigning story points. No
time wasting with bikeshedding and stylistic debates about how to solve a
problem or start a design solution.

Just use common sense, and then during the rare times when your team actually
flags something up for group debate about a design idea, you'll be more
confident that it has a good signal-to-noise ratio, and your team's work won't
be judged by arbitrary Fibonacci numbers.

~~~
commandlinefan
The problem with agile methodologies, or any other software methodology, is
that they can't solve the problem that the managers pushing them want solved:
predict, with near certainty, how long it will take to create a non-trivial
bit of software. The old XP that modern "agile" grew out of explicitly
reminded adopters that this was, by definition, impossible, but that reality
was cast aside when it was found to be too inconvenient. So we have legions of
people pretending something that is demonstrably untrue is true.

~~~
vannevar
_The old XP that modern "agile" grew out of explicitly reminded adopters that
this was, by definition, impossible, but that reality was cast aside when it
was found to be too inconvenient._

It may have been cast aside by somebody, but not by agile practitioners. The
reason that many managers still _oppose_ agile is precisely because it
explicitly rejects the predictability that the traditional waterfall promised.

