
The road to hell is paved with agile intentions - cateye
http://yusufarslan.net/road-hell-paved-agile-intentions
======
wpietri
I certainly grant that the faddishness of Agile methods is a giant problem,
and I've grumbled about that before. [1] But I'm not quite getting his point
here.

I agree that wholesale adoption of Agile methods is problematic. But one thing
every Agile approach has in common is an inspect-and-adapt component, so I'd
call wholesale, ritualistic adoption essentially un-Agile. The Extreme
Programming people are most explicit about this: they say that by-the-book XP
is a good place to start, but that they don't expect anybody to stay there.

But when I read his examples, it seems like he doesn't know that. (Or perhaps
that's the people in his examples.) Agile approaches aren't supposed to make
everything better. They're supposed to _expose_ the problems with how you're
working so you can fix them. In the first case, it exposed the client's lack
of interest and the conflicts of interest inherent in their organization. In
the second, it made clear that the backlog was unreasonably large versus staff
size.

Those aren't _unintended_ consequences of adopting Agile methods. That's
what's supposed to happen. Hidden problems are now obvious, which is progress.
He seems to suggest that more planning is the solution, but I think just the
opposite: with both those fictional shops I'd encourage them to fix the
visible problems, and try to do so in ways that shorten feedback loops and
help surface other hidden issues.

[1] [http://agilefocus.com/2011/02/21/agiles-second-chasm-and-
how...](http://agilefocus.com/2011/02/21/agiles-second-chasm-and-how-we-fell-
in/)

~~~
cateye
The problem is that such an organizational change not just _exposes_ the
problem: it makes it _worse_. The intention also usually isn't "let's make
things visible". So, the unintended consequence is that things are amplified.
And no, in such a situation this will not feel like progress.

I don't suggest more planning. I suggest more profound thinking before
changing things.

Edit: you edited your comment.

~~~
amouat
But why pick on Agile? The organisations clearly had problems that needed to
be addressed which went beyond software methodologies. Should they choose a
waterfall development model because it might hide the problems better in the
short term?

I agree that more thought may be required. But that has nothing to do with
Agile. If anything Agile should be commended for bringing the problems into
focus.

~~~
cateye
Agile vs. Waterfall is a false dichotomy.

The problem is that Agile approaches are perceived and promoted as a solution
for these kind of problems. And I don't see well known Agile consultants do
anything to change this view. That's why I wrote this.

~~~
wpietri
For all X, most X consultants see X as a solution for your problem, almost
without regard to the problem.

That isn't an Agile problem, except to the extent that Agile is the flavor of
the moment. It's a problem with the industry. And really, with people in
general.

Many people want to buy magic beans. Some people will sell magic beans, either
because they are cynical jerks (which is rare) or because they don't
understand beans all that well (which is common). That doesn't make beans bad.

------
kabdib
I've been in groups where the management has said:

"Guess what! We're going to be Agile and do Scrum!"

Whereupon they sent a bunch of PMs off to be trained as Scrum masters.

On the first project, Management then said:

"Okay, go do that Agile stuff. And we think it will take you 13 sprints. Also,
here's the stuff you'll be doing in the first sprint..."

Soon after, there were daily management meetings where people's burn-down
rates were being discussed, based on the daily status reports that the PMs
were collecting.

Just another way to micromanage people.

~~~
wsc981
> "Just another way to micromanage people."

I share the same sentiment. And I hate to be micromanaged.

In a previous job a manager actually admitted to me that agile was a means to
get more control over the developers and approach software development more
like factory work, instead of creative work. A few months later I decided to
leave, cause I need some sort of creativity in my approach to work, and for
creativity I need freedom, not constraints.

~~~
UK-AL
I really like agile precisely because of this. I get tasks given to me, and I
can prove the amount of work I have done.

Without metrics, you can end up at whim of managers gut feeling rather than
what actually has been done.

------
CookWithMe
> This company faces the problem that customers often complain about a lack of
> clarity about the process and insufficient quality of the produced websites.

> The department has understaffing and the requests are piling up. The waiting
> times are very high and there are many complaints.

Sounds like they just paved a new road IN hell, not TO hell...

------
DanielBMarkham
I'm happy to upvote authors who want to talk about making the work environment
better for everybody. But I'll also add that in my opinion this is a poorly
structured essay.

The crux of the problem with process is _premature generalization_. People see
a couple, or 4-5 examples of something, and then want to make a rule for all
projects in an organization. There's waaaaaay too much variance for it to work
like that.

Readers face a similar problem when reading about success in startups. There's
a ton of books on how to make a killer startup -- but most all of them rely on
a few examples or a handful of stories. They're long on selection bias and
short on usefulness. Orgs do this same thing all the time.

There's also a mismatch in the model many technologist bring to organizing the
work and the work itself. Since we work with things that move data around and
functions that perform data changes, we begin to feel that a well-run
organization is built on certain data and functions. It's simply the analogy
that is most convenient for us. In reality, we're finding psychological and
social factors are playing a much more important role than sets of rules,
processes, or data structured and handled in certain ways. This is a big
change for many to accept.

Still, always good to hear more voices. It continues to amaze me how you can
take a kick-ass team of 5 guys and conquer the world. You can then scale that
up to a kick-ass team of 100 guys -- and create one of the most miserable work
experiences ever.

Shameless plug: for those interested in reading some of the stuff I've written
about this, check out my blog devoted to the topic: [http://tiny-giant-
books.com/blog](http://tiny-giant-books.com/blog)

------
al2o3cr
"The market is full of similar providers with readymade products for a fixed
price."

In my experience, the market is full of people who CLAIM to have "readymade
products" and who will ASSURE you that they'll be available for a fixed price.

Neither statement is typically true, however - nor is the idea that even
"simple" client problems can be solved without any custom work.

If your firm's clients get mad when an agile process and its risks are
explained, what they're really pissed about is that you won't lie to their
faces during the sales process anymore...

~~~
dustingetz
wallets speak louder than words, and if your clients pay you more than once,
they're telling you that you're giving them what they want. Notably, that
means that you aren't lying, in their eyes.

------
pnathan
The point being made is that the total system of an organization must be
thought about and considered before adopting a new thing. Simply focusing on
one thing only will not magically make everything better. Root causes must be
addressed and symptoms relieved for the total system to function more
smoothly.

------
charlieflowers
The fix for a dysfunctional bureaucratic organization full of in-fighting is
not a better software development process. How it usually plays out is that
switching to a better software process is a tiny step in the right direction,
but the organization is still dysfunctional and bureaucratic.

(Analogy: the person whose body was riddled with stage 4 cancer started
flossing every day. She still died of cancer soon after, but her teeth were
cleaner).

------
gesman
Creating, optimizing and tuning "processes" with a help of buzzword bullshit
is a bread and butter using which the certain layers of management justifies
their, otherwise worthless existence.

Developers often find themselves interrupted by needs to participate in
processes that are necessary to "track or improve the progress" instead of
focusing on making the actual progress happen.

~~~
UK-AL
Its not about tracking for the sake of tracking. Its about finding problems in
the development process and improving them. Its helps identify problems, and
once identified you can make adjustments and fix it. In our sprints people can
'flag' stories if something is slowing them down, and normally you find it's
consistent issue with multiple stories. If you remove it, then you have a
instant productivity boost. When we implemented scrum we found a lot of
stories were going back and forth between requirements and development stages,
so we knew where the problem was.

It's also about guidance. The people implementing the project, probably don't
have accurate representation of customer value, only the customer does. Teams
often have vision of how things should be, but normally its inaccurate and you
implement things with the wrong priorities. The constant feedback from the
customer helps ensure the right things are being worked on.

------
platz
Scrum is not a process? Too vauge..

Also the solution always seems to be inappropriate skills of the developers

~~~
cateye
From the official Scrum guide:

"Scrum is not a process or a technique for building products; rather, it is a
framework within which you can employ various processes and techniques."

[https://www.scrum.org/Portals/0/Documents/Scrum%20Guides/Scr...](https://www.scrum.org/Portals/0/Documents/Scrum%20Guides/Scrum_Guide.pdf)

These are just some examples that wrong causes can get attributed. And yes, a
lot of times there is a mismatch between the skills and the expectations of
the developers. (Without judgment where the error is.)

~~~
benjaminwootton
I find that surprising. I view Agile as the framework, and SCRUM as a specific
instance of an agile process.

With SCRUM dictating that you should have X meetings of Y hours length
producing artifacts A, B, C, that sounds like a process to me....

