
Three things I don’t like in the agile community - adambyrtek
http://www.andybrandt.net/669/three-things-i-dont-like-in-the-agile-community
======
Vic-nyc
I am a developer, and in the past I used to be a proponent of "agility". These
days if I am interviewing for a job and I hear that the company is using
"Agile practices", I generally try to avoid it like the plague.

I believe there are 3 main factors for software projects to succeed: one is
the technology and the skill level of the tech team; the second, very
important, are the business requirements (are we building the right thing, and
with the right priorities?); the third is the level of communication between
team members. Now "Agility" (Scrum/etc) really addresses only the 3rd point.

And herein lies the dogmatism that others have mentioned -- a lot of these
companies who do "Agile" usually do so because they have serious problems, and
they think "Agile" is a magic bullet that will solve them. This is extremely
wrong and dangerous - if your problems are caused by crappy technology or
(very often) by the fact that you don't understand what you're trying to
build, then throwing scrum meetings at developers will alienate them even
further.

What I also see in these companies that are so adamant about Scrum/etc, is
management who doesn't understand technology. Therefore they use the "Agile"
weapon as one of their only ways to give them a sense that they are in
"control" of the situation. They neglect the other parts because they don't
understand them.

------
raganwald
Odd, I haven't met any. I'll repeat that, ANY agile practitioners who suggest
that other agile practices are doing it wrong. And unless I misunderstand the
original Agile Manifesto, it's all about valuing certain things over other
things, not about saying the other things are wrong, and certainly not really
about specific practices.

The analogy I would draw is to the relationship between ideals of code beauty
and design patterns. Design patterns aren't the goal, they're particular ways
of achieving an ideal that people have discovered work well under certain
circumstances.

Likewise, the practices aren't the goal, they're implementation details. I
can't even understand how to say a practice is wrong, the things I judge are
the degree of communication, the amount of discovery, the flexibility to
pivot, and so on. Practices are how but not what.

p.s Get off my lawn!

[http://weblog.raganwald.com/2007/10/three-blog-posts-id-
love...](http://weblog.raganwald.com/2007/10/three-blog-posts-id-love-to-read-
and.html)

~~~
westajay
My town had a lot of early agile projects in the first part of the decade. The
consultants only talked about the successes and not the many failures at
conferences. Specifically WRT scrum and XP. I can tell you about a scrum
failure that was in the 10's of millions of dollars.

I've had many negative experiences with less effective consultants using agile
as a way to convince the client that they are all wrong and the only way out
is more consulting guidance. In fact, I worked for some time at a consultancy
where I am sure this was their business model.

There's more than one path to the finish, and "agile" sold itself out as a
vapid marketing term years ago.

~~~
Ramone
I'd be interested to hear about (1) that scrum failure in the 10's of millions
of dollars, and (2) what you prefer instead of Agile.

(I'm a developer on a scrum team and really think it helps us, but I'm not
dogmatic about it or anything... I'd like to hear about the other side. I'm
surprised that a huge scrum failure is possible because the customer is
generally shown everything at regular small intervals, so it's hard to imagine
how a project could get so far off course.)

edit: grammar

~~~
raganwald
I don't know about that SCRUM failure, but the original XP project was a well-
documented failure:

[https://secure.wikimedia.org/wikipedia/en/wiki/Chrysler_Comp...](https://secure.wikimedia.org/wikipedia/en/wiki/Chrysler_Comprehensive_Compensation_System)

One way to explain things is to say that teams like Agile whether it's
effective or not (for some definition of effective). Another way to explain
this is to say that Agile can't make you succeed, but it's the fastest and
cheapest way to fail.

When _I'm_ selling snake-oil, I prefer the latter explanation.

~~~
Ramone
"Another way to explain this is to say that Agile can't make you succeed, but
it's the fastest and cheapest way to fail."

Well said... That really cuts through to both the reality of Agile, and the
key advantage.

------
stevenp
I think dogmatism is the worst of the three problems. So many teams seem to be
looking for a catch-all solution for running a productive team. What I've
found is that each team I work on does much better if we're open to
experimenting with different processes in order to find what works best for
our team.

The company I'm at now has more than 6 teams, many of which work in different
ways.

Some use online scrum boards, some use physical ones. Some track projects only
with story points, some use actual hours or days.

The point of agile (at least as I understand it) is to get your team in flow
so they can ship value to customers. Being too religious about process seems
to be a recipe for frustration.

------
TamDenholm
I worked a 2 month contract at a company that employed agile techniques and i
found them to be nothing but superfluous minutia. Thats not to say they dont
work for the company as a whole, but i was 1 guy working on 1 project by
myself.

I was brought in to tackle a specific problem and sort it out, i was just
given what i needed and i got on with it, but was forced to partake in the
daily stand up meetings and weekly team meetings, which for me specifically
were just a waste of time.

The stand ups were at 10am which meant that even though the company had
flexible hours (awesome) i had to be in at at least 10am, whereas i'd prefer
to walk in around 11am-noon and stay late. Also, my part of the weekly 2 hour
team meeting was 5 minutes long and nothing else was relevant.

My point here is that i'd like people not to try to force principals to fit
into every situation, cuz they wont, it'll work for some things but not
others, just keep that in mind.

PS: Atlassian sounds like an awesome company but JIRA sucks.

~~~
wccrawford
We just moved to agile at my company, and it was rough at first, but I think
things are much smoother now. Our standup meetings are for the teams, not the
entire company, so they are short and sweet. Everyone on the team knows what's
going on, and that's it.

We also have an assigned standup time, but it's after the latest developer
gets there. We have set hours we have to be there, but we got to pick those
hours individually. We just have to stick to them. That's good for both
management and your team members.

It sounds to me that the problem isn't agile, but how the company is applying
it. If you use a hammer like a screwdriver, you're going to be disappointed.

------
duncanj
I think I can explain some of the dogmatism seen with XP practitioners. XP is
a set of practices for customers, developers, and communication. XP
consultants think that teams should try all the practices. Most XP people
don't oppose removing or modifying a practice, but they don't see why you
should remove it before you've tried it, especially when the reason is
something like, "Pair programming will never work here." Try it for real, then
make it your own.

In discussions between agile groups, XP people are often confused by, say,
Scrum, because the Scrum consultants teach fewer practices and use funny
vocabulary. But I'd say that most XP people would prefer to work in a Scrum
environment than in many more traditional environments, and they would say so
if you asked them.

~~~
mattmcknight
Another aspect of XP is that pair programming is a replacement for code
review. If you drop pair programming, you should consider a compensating
practice.

------
100k
If I'm reading him right, he doesn't like that Agile is dominated by
consultants, meaning people who teach other people how to be agile.

I agree with that, but I think there's a further problem: a lot of the people
practicing agile are consultant developers. They take on a project, apply
their "agile methodology", and build some software. As the project goes on and
begins losing its luster, the contract ends, and the consultants are on to the
next Shiny Thing.

With this kind of environment, people don't have to face the long term
consequences of their technical decisions.

(I think this is also why there is so much "what's cool this week" churn in
the Rails world.)

I would like to see an agile methodology come out of a successful product
team, that applies it for years.

------
yannickt
One thing I would add to the list is: _relative_ lack of evidence. Now don't
get me wrong, unit testing, continuous refactoring and pair programming are
very helpful when applied in the right context. But there is a lot of code out
there that was written with no overt agile enthusiasm, and this code is
working just fine. I always roll my eyes when I hear or read things like: "if
you don't write your tests first you're doing it wrong". I'm very happy that
TDD and daily scrums work for you, but I won't convert to your religion unless
you show me a search engine or a web browser written with agile consultants on
site.

------
adambyrtek
Ward Cunningham: 'The word "Agile" has worked hard for ten years. I forgive it
for being tired.'

<http://twitter.com/#!/WardCunningham/status/27668990943>

------
benbjohnson
I'd like to add something to your list: Adding an entirely new vocabulary to
learn. Velocity, story points, etc. I don't mind learning new things but most
of these terms are just the repackaging of existing ideas.

