
Agile Failure Patterns in Organizations - swolpers
https://age-of-product.com/agile-failure-patterns-in-organizations/
======
canthonytucci
I see a lot of people using "agile" and Scrum™ interchangeably. Am I just a
deluded fool, or is the agile manifesto completely ignored in practice? People
talk about "agile methodology" and I wonder "doesn't the manifesto explicitly
reject all 'methodologies'?". I thought that was the point. The manifesto is
pretty short already but more or less I understand it as " do what makes sense
to you". It's open to interpretation, but that's the whole reason for its
existence. If companies think there's a magic book or a system to rigidly
define "what makes sense" for all teams on all projects, and that such a
system can/should be purchased if only the idiots working for them would just
follow the rules, they're doomed anyway.

~~~
pcurve
I agree 100%. I work in a big corporate environment. The problem with Agile
is, it doesn't seem to work in a big corporate environment that loves the
followings:

1\. Ability to plug and play bodies (PM, Dev, BA, offshore/outsource)

2\. Having those bodies held accountable individually

3\. Predictable process over progress or quality.

4\. Layers of management.

~~~
VLM
With the minor correction that #1 also applies to divisions (east coast office
vs west coast office) and cross shift (3rd shift ops has the same written
procedures and instincts or whatever as 2nd or 1st shift ops).

Programming is a young profession. On the other hand, design and engineering
and automation are old, and the giants got that way by following pcurve's
list, more or less, not by inventing or implementing Agile. Therefore the
higher people go in management and therefore the more abstracted they get get
from the front line, the more likely they are to completely uninterested in
Agile, as that's just not how big companies are run, even if it works for a
ten person startup. So there's going to be a push from the top to call it
whatever you want but when you interface with the exec suite you'll talk in
terms of micromanaged waterfall because that's how we build jet engines here,
or mining machines, or run a worldwide communications system, or whatever.

------
demian
"Culture of Failure"

Good luck selling that to upper management.

On the contrary, quick iterations are about reducing the risk of building the
wrong thing. Of course in the normal "blaming" corporate culture this won't
work, because departments are always competing over budget and deliverables
that are not "perfect" will be used as ammunition against the department where
the product came from.

~~~
mathgeek
I usually prefer to call it "culture of learning to get back up again after
falling."

~~~
demian
Just "Culture of Learning" sounds great.

~~~
mathgeek
Already used outside of the development world, so I suppose it would be par
for the course on confusion.

------
lojack
> Agile processes are either bent or ignored whenever it seems appropriate.
> There is a lack of process discipline.

This one I don't understand. Isn't it sort of the antithesis of the first core
principle of the Agile manifesto? Shouldn't it be a _good_ thing that the
processes are bent or ignored when appropriate.

~~~
err4nt
Whenever I meet people hiring for tech in Toronto They say things like: 'We
practice XP, We apply agile to agile!", I hear "We have no idea what we're
doing, and no idea how we're going about it but we will change it whether it's
working or not and expect you to jump through a lot of hoops in addition to
getting your work done"

I've seen offices with Gold stars for employees and these huge whiteboards
filled with different milestones and benchmarks for projects. It _looks_
great, but the difference is the work isn't getting finished. I feel like
agile can create a smoke screen (if you're not careful) where you're too busy
seeing how successfully you're on track with agile and miss the opportunities
or failures that are happening in the real world to your product, instead of
inside your process. You can be in great shape as far as agile goes, and still
be losing customers because your work comes months too late.

To me, process should never be more important than product. I come from a
graphic design background where process is very important to ensuring
consistent results, but you can never fetishize the design process over the
results it produces or else you end up with mediocre, commoditized design that
is indistinguishable from the worst stuff coming out.

You couldn't pay me enough to deal with agile in the workplace, I feel like
you'd have to toss an extra 50k on the top nd I doubt anybody would pay me an
extra 50k just to deal with it, so I'll continue working with non-agile folks
who manage to get stuff done, like professionals! Opportunity doesn't wait for
standups, timeboxing (telling people when they are allowed to talk or not),
and micromanagement.

~~~
jacques_chester
I feel like you're rejecting a strawman, rather than basing it on an honest
"suspension of disbelief" experience at a well-regarded agile shop.

I joined Pivotal Labs a skeptic. Now I'm a proselyte.

------
noarchy
More of the "No True Scotsman" apologia for why Agile fails so often. I
especially liked this gem:

>Team members reject Agile methodologies openly, as they do not want to be
pushed out of their comfort zones.

I can't say I'd feel bad if a failed, Agile approach was not in my comfort
zone.

~~~
exelius
I absolutely disagree.

There is no "True Scotsman" argument against Agile, IMO because there is no
such thing as "true Agile". The best description I've heard of Agile is that
it is the bare minimum amount of project management you can do on a project
and still be successful. Beyond that, it's all about what works for each team.
The entire f-ing point of Agile is that it's a generic framework you can adapt
to many different business contexts.

But there are still common reasons Agile methodologies fail. I don't know how
many of these are really failures of "Agile" or just common mistakes that new
teams in general make. But it doesn't really matter, because the two
situations are often inextricable from each other.

~~~
noarchy
>There is no "True Scotsman" argument against Agile, IMO because there is no
such thing as "true Agile".

If Agile is so nebulous as a concept that it can't be defined (only vaguely
described, at best), then perhaps it cannot fail. But it also cannot succeed,
as it apparently doesn't exist.

There may be teams for whom these management methodologies work, and good for
them. I am genuinely curious about how much the success or failure of these
methods have been studied.

~~~
exelius
Agile can be defined, but at its core, Agile is a set of best practices that
by definition can be ignored. It's a collection of optional components that
can produce a functional process when cobbled together in the right way. But
figuring out what works for a team is often a lot of trial and error, so a
skilled "Agile practitioner" can help you look at what has worked for you,
what hasn't, and suggest things to try.

And you're right; when defined this way, Agile cannot fail. Agile isn't a
magic bullet for your development team - at its core, Agile is a method by
which dev teams can more or less self-organize around a set of generally
agreed-upon processes. But it's up to each Agile team to develop those
processes themselves.

I have yet to see an Agile team fail because their Agile process failed. I
have seen Agile teams fail because the team was too inexperienced to provide
their own direction. I have seen Agile teams fail because the dev lead wanted
to play dictator. I've seen Agile teams fail because their business
counterparts kept changing the requirements and demanding impossible things of
the dev team.

I've never seen an Agile team fail because they couldn't figure out how to
assign user stories or because they had no concept of release management.
Sure, those things might be a disaster, but usually (after enough times going
through some painful manual process) some developer steps up and says "Hey, I
think I know a better way we can do this..." And those problems almost never
endanger releases because Agile teams are by their very nature empowered to
solve problems. Sure, the solution may have been inefficient and non-
repeatable, but it worked.

~~~
crdoconnor
>Agile can be defined

I tend to find that if you line up 4 developers and ask them what agile is
you'll get a minimum of 5 definitions.

~~~
exelius
Exactly my point, and why there is no such thing as "true Agile" or a true
Scotsman argument to be made.

And yes, I agree that the term Agile is largely meaningless at this point.
Partly because nobody knows what it means, and partly because it's so
ubiquitous there's no point calling it out on its own anymore.

------
incepted
> Team members reject Agile methodologies openly, as they do not want to be
> pushed out of their comfort zones

Or maybe they have identified Agile for what it is: a snake oil methodology
that's completely unproven, which sometimes works, sometimes doesn't and,
regardless of the outcome is never blamed if the project fails.

Bit like a religion.

~~~
_dark_matter_
>they have identified Agile for what it is: a snake oil methodology that's
completely unproven

Is this a common line of thought? I recently started working for a company
that follows Agile and I thought it was generally accepted as the "next step"
so to speak in software development. I didn't know that there was any
resentment for it. Care to elaborate? Do others feel this way as well?

~~~
techterrier
It's certainly preferable to team of analysts spending 6 months writing specs,
then engineers spending 12 months writing code, then 2 years spent testing and
fixing things only to find out that while that's all been happening the
internets been invented and the original product has no purpose.

~~~
saiya-jin
i've seen exactly 0 of this type of projects you describe in corporate
multinational environemnt (or any other for that matter). in any non-agile
corp i've been, projects are usually a mix, where analysis doesn't finish when
dev starts, testing is ongoing with dev, just shifted a bit. and when these
projects go fubar, it's usually caused my forces far away from delivery team.
rarely, it's really fault of team not delivering, but agian, situation is so
complex and uncontrollable, that putting everything and everybody (including
all stakeholders) into agile wouldn't probably make a big difference in
go/nogo call.

agile approach brings quite a few aspects that developers like and they just
feel right (or at least better), but frankly, it's overhyped. just another
tool/approach to certain set of situations, in certain conditions

~~~
jacques_chester
> _i 've seen exactly 0 of this type of projects you describe in corporate
> multinational environemnt_

I work in Pivotal Labs.

I happen to be working on such a project with one of the world's largest
financial firms. Across the hall from me is another team working with that
company. Behind me are three teams working for a retail giant, in front two
teams working for a large insurer.

In the same office I've seen everything from iphone scroller games, to startup
apps, to microservice migrations, to entire product categories, being created
this way.

Collectively, Pivotal Labs has helped develop thousands of products for
hundreds of clients with a collective business value in the billions.

I invite you to visit any of our offices to see it for yourself. Email me:
jchester@pivotal.io and I'll set it up.

------
VLM
Some common pathological beliefs I've seen, some logical fallacies, some
worse:

The rationalization drive implies failure needs an excuse. Sometimes Agile is
the least strongly defended possible victim. Therefore Agile is bad.

Agile is complicated. The simplest components to explain are also the most
trivial. Something that's only trivial is invariably foolish. Therefore Agile
is bad.

"Most people" are experimenting with Agile. Half of managers / devs are below
median by definition. Its a very realistic prediction that half the time,
Agile will result in below median performance. Therefore Agile is bad.

Every other silver bullet for the past 50+ years has been a scam. Agile is a
silver bullet. No one can explain why this silver bullet is any more likely to
be real than the last couple dozen fads. Therefore Agile is bad.

Agile only seems to scale to a narrow range of team size. Things that don't
scale up, or down, are stereotypically seen as bad by programmers, no matter
if the stereotype is applicable or not to the situation under discussion
(that's why its called a stereotype or bias). Therefore Agile is bad.

Sometimes Agile is implemented as a sub-scheme where the overarching style
remains micromanagement or seagull management or simple chaos. If the cake is
a lie, a thin layer of Agile flavored frosting isn't going to make the overall
dish taste good. Coverups are inherently bad. Therefore Agile is bad.

Agile is impossible to define and really popular. Grok that. At least some of
the bottom half of the median will simply use the word as a checkbox without
ever implementing it. Essentially managers who "have no idea whats going on"
will sometimes describe themselves as Agile as false advertising. Therefore
Agile is bad.

Related to most of the above, the odds of finding a shop actually successfully
implementing true Agile are low. Therefore statistically if an employer says
they're agile that's a sign for applicants to avoid them. And that means the
best people will successfully avoid agile, with all kinds of secondary
effects. Therefore Agile is bad.

------
UK-AL
I think trying to do a big bang deployment of scrum in a slow organisation
bureaucratic organisation is probably a bad idea.

Probably best idea is something using kanban. Map the existing process using
kanban. Find bottle necks, and fix the process. Start changing bits to it.
Start using TDD, maybe user stories, maybe add "sprint" planning meetings.

You might not be implementing "true agile", but its better than complete
disaster trying to enforce everything suddenly.

Also this comment he stated in the comments makes me uncomfortable.

"being uncomfortable committing to an outcome that’s time-boxed"

" sticking to a 5-to-9 mentality "

You shouldn't really being "commiting" to a time box. Its a guess, not a
commitment. You use velocity to get better at the guess. If you miss, oh well
lets get better at it next time by adjusting the story points in a sprint.

He makes sound like he expecting people to work overtime to meet a commitment.
This is not recommended in scrum. You should have a normal work time mentality
and work requirements should fit into normal hours. If you miss the "guess",
you should adjust the next sprint to not include as much. If you work overtime
to meet the commitment, you re-enforce the idea that it is ok to commit a
overloaded amount of work to a sprint. Bad. Bad. Bad. That can be abused.

------
r0naa
> Team members reject Agile methodologies openly, as they do not want to be
> pushed out of their comfort zones.

I love how this equates critical thinking and complacency.

See? I can do it too.

------
jahaja
Why would one adopt a methodology with so many pitfalls?

~~~
noxToken
Other methodologies have their pitfalls as well, but agile is the methodology
that many are adopting from the get-go or changing to. As such, it's head is
on the chopping block. Developers are scrutinizing it to evaluate the trade-
offs. You'll see people celebrating agile as if its the messiah to save all
projects, and you'll see others decrying it as smoke and mirrors.

I think it's important that people are openly (not overly) critical of trends.
It can help people make more informed decisions. The problem then lies with
others trying to wade through vocal idiots masquerading as experts and
legitimate information hidden in the cruft.

~~~
jahaja
Yupp, it's indeed the thing of the day. Reading that list I just wondered if
using no apparent methodology would be any worse. I have a hard time
rationalizing the almost theological adherence to software development
methodologies in general.

------
kraftman
Does anyone else find this hard to read? Small grey type on a white background
makes it look more like terms and conditions than an article.

~~~
kelvin0
Dude, at least pretend to comment on the content and as a side note, comment
on the form. How would you feel if someone commented that way on a matter you
wrote about concerning an issue you consider important?

~~~
kraftman
I'd appreciate the feedback and I'd try and make it more comfortable to read.

~~~
gvb
Good, but giving feedback in an unrelated forum that the author probably
doesn't read is not useful. The page has a "Leave A Comment" box. Give
feedback there.

------
s73v3r
Wait, why would people think that Agile is a substitute for hiring senior
people?

