

Good agile vs Bad agile - joubee
http://steve-yegge.blogspot.com/2006/09/good-agile-bad-agile_27.html

======
nopal
I think this post is worthwhile because Steve works for one of the best
software development companies around and because he's an excellent programmer
with a lot of experience.

He obviously knows what he's talking about.

I think what's missing (perhaps because he's not the best person to describe
it) is what a company on the wrong path can do to set things right.

Google has obviously made a very conscious effort to keep their successful
model as they've grown, bit many companies (especially those not started by
techies) have made bad decisions.

How can an IT department -- assuming the department itself gets it -- make
things better?

Unfortunately, lame parties are about the extent of the power most IT
departments (or development team managers) have. They can't shift the entire
culture of the company or start handing out astronomical rewards.

There has to be a middle ground, and it's this middle ground that's so
elusive.

I would be interested in hearing how anyone has driven or been part of a
lasting, positive change within the confines of a larger organization.

------
jrockway
Oldie but goodie. One comment:

 _the kinds of programmers who buy extended warranties and self-help books and
believe their bosses genuinely care about them as people, the kinds of
programmers who attend conferences to make friends_

One of these things is not like the others. I have made many, many friends at
programming conferences. I am not sure why you wouldn't expect this to happen.

~~~
marcusestes
"I'm not here to make friends." <http://www.youtube.com/watch?v=w536Alnon24>

~~~
jrockway
Now I remember why I am ashamed to be American.

------
kakooljay
Great post, especially the bit about life at Google:

\- developers can switch teams and/or projects any time they want, no
questions asked; just say the word and the movers will show up the next day to
put you in your new office with your new team.

\- Google has a philosophy of not ever telling developers what to work on, and
they take it pretty seriously.

It's brilliant management I think: Hire talented engineers, give them extreme
freedom, and choreograph the dance with clever incentives...

~~~
brown9-2
The article was written 3 years ago, so I'd be very curious to hear how much
of that still is accurate today.

~~~
jganetsk
Yes, nowadays, Google "allocates" (the actual word that they use) new
employees to projects.

------
brown9-2
Steve Yegge, if you are reading this: please write a book. I'd buy it!

~~~
angusgr
I'd be overjoyed if he just started blogging again.

I never made it through all of the "Programmer's View of the Universe" series,
but I loved reading nearly all of his other stuff.

------
bmcleod
I'm of the opinion that Agile(Big A) is very useful for creating a system
between companies. When something is an agreement between companies you need
some agreed and consistent method of working out what happens when and
enforcing that afterwards. Agile is much better in these circumstances than
waterfall.

Comparatively, in a startup or internal development project in a software
company there is much more of an ability to not deliver a particular feature
or spend more hours on it.

A startup is likely to find Agile far too slow; whereas, corporates are scared
by how fast and fluid it is.

------
projectileboy
If anyone cares, I wrote an article for InfoQ around this time which gathered
some of the better commentary: <http://www.infoq.com/news/2006/12/future-of-
agile> (buyer beware: I am (or was, at least) biased in favor of agile
methods).

------
nkohari
I vehemently disagreed with this post when it was originally written, but then
at the time I was just being introduced to Scrum. I've since come to
understand his point, and oddly enough, the part at the end where he talks
about project management via queue theory and index cards is precisely what my
startup (<http://agilezen.com/>) is based on. :)

------
diN0bot
these are the kind of discussions i find worthwhile: an honest look at how
something works well and how something fails. too often i see blog posts
pitting A against B, or simply claiming A sucks.

(i guess A v B is a good/bad look at a higher level concept C...)

~~~
stcredzero
Yes, but it's amazing how often people don't bother to move on to C. They'd
rather see the A vs. B slugfest and contribute to it!

------
JulianMorrison
What he's describing as "good agile" deserves a different name. I'd call it
"fluid" because that seems like a really close metaphor.

~~~
ahpeeyem
I wish even agile had a different name, one that isn't so tempting for people
to use incorrectly, with no clue that it means something other than "able to
change direction quickly". I've heard (very non-technical) people cheerfully
volunteer to clients and developers that the project they're involved with is
"agile", but they just mean "we have no real plan, anything can change at any
time" - they have no concept that there's an actual methodology being implied
by what they're saying.

I think using a term like "fluid" would have similar results - "we're using a
fluid methodology so our project will be able to flow around any
obstacle/mould itself to any scenario".

On the other hand these ideas spread so well because it seems like they're
easy to understand...the first thing you think of when you hear something like
Rational Unified Process is men in white coats with pocket protectors.

------
prat
All I could gather from the post is - "great incentives attract great talent
produces great software".

------
spectre
Classic Line: "what metadata is allowed on index cards"

------
ApolloRising
All I can say is that was a fantastic post and thanks for sharing.

