Agile Project Planning

ExtremePlanner: Agile Project Management for Distributed Software Teams
Click For Your Free Online Trial

Thursday, September 28, 2006

Google's New Motto: Don't Be Agile?

Steve Yegge of Google has an epic rant about Agile methods and why they are evil.

This article is sometimes rambling, and often grossly unfair in many ways, but let's take a closer look.

Steve talks about "good agile" vs. "bad agile", and generally lumps anything that requires consultants, training, or books as "bad agile".

Google, where he works, is apparently using "good agile" which as best I can figure means that no one is forcing anyone to do anything, there is no defined process, no deadlines, no explicit pressure, and everyone just sort of figures it out. His ultimate weapon is a priority queue.

Certainly Google operates differently than many businesses (as Steve puts it "Somewhere between a startup and grad school"), but since when did poorly defined projects, no deadlines, and chaos make a solid development process?

OK, I admit a got a chuckle out of it, even as I was thinking, "Wow, this guy really doesn't get it". But then I thought, "Millions of people who also don't get it will accept his arguments without ever reading about or trying Agile".

He goes so far as to suggest that even trying Agile is "Dangerous", and that you should throw out your XP or Scrum books immediately.

I was half expecting him to say "Burn her! She's a witch!"

What's really dangerous is letting someone else do your thinking for you and telling you what you can and can't read or try.

He warns of Agile proponents "being slippery" by taking credit for any good effects of an implementation, but explaining away bad effects as "you didn't do it right". I do see this far too often on Agile mailing lists and in other writings, but it's also sometimes accurate. I can wave my arms around and make "Ha!" noises, but that doesn't mean I'm doing karate.

And finally...the one point I agree with in the entire rant: If a process is attempted by 100 groups, and 90% of them fail, maybe it's not a good process (or well documented, or easy to follow, etc.).

But in my opinion, Agile is not about process, it's about philosophy.

Philosophy is difficult to standardize and implement. So we as humans create specific rules and practices that are easy to digest. For example (apologies to my fellow Agilists):

"Do pair-programming all of the time, except when your alone, then put
your cat on the keyboard."

"Write everything test first, especially test code."

"Use index cards, they are magical and will grow into rectangular trees if
you plant them."

"Don't let chickens talk, they make an awful noise." (from Scrum's "Chickens and Pigs" metaphor)

"Four legs good. Two legs bad." (Hmm...maybe that's not from an Agile method)

And because many people don't "get" the philosophy behind the practices, they either become unthinking zealots or fierce, er, "insurgents", leading to a project's demise.

Is it fair to blame Agile for this? Of course not. But what did fair ever have to do with anything in our world?

So how can an Agilist combat this viewpoint without looking "slippery"? Maybe everyone should do what Steve suggests, and stop worrying about standardizing process, and just work on instilling philosophy. Let good practices emerge from smart, capable people trying things, seeing what works for them, and adapting.

But then you'd be doing Scrum, and we already know that's "dangerous", right?

I do worry when I think about how few people actually read original sources and make independent decisions based on their own experiences, versus going whichever way the latest pundit blows.

So do yourself a favor: listen to me for a change and make up your own mind.

For more on agile tools and techniques:
(Tags: , )

Get your copy of the new book! Agile Thinking: Leading Successful Software Project and Teams

Friday, September 22, 2006

How Agile Is Your Development Process?

How agile are we? I've started to see this question appear more and more in mailing lists and discussions.

In truth, it doesn't matter in the least how "agile" your process is, only how effective it is.

The assumption in the question is that being more agile is a good thing, and that if we could only measure it objectively, we could guarantee improved "goodness". I don't think this is true.

Hear me out. I'm not saying that being more agile is a *bad* thing, only that it's not the right thing to measure. Everything in software development (and business for that matter) is dependent on context.

So try things and measure them to see if your effectiveness improves. If it does, do more of that thing until something breaks. Then turn your attention to another factor.

For example, many people come to agile development after experiencing a "death march" type of project where the delivery is late, buggy, and over budget. They are looking for a better way. They adopt an Agile method like Scrum, and expect miracles. When things aren't going well, they say "We must not be Agile enough, let's measure our agility so we can improve it!"

Instead they should be asking questions like:

1. Are we meeting the requirements of our customer, or are there constant misunderstandings?
2. Are we able to make changes to our software efficiently or is it painful?
3. Are developers energized and excited about their work or burned out and unmotivated?

The road to agility is one of trial and error. Yes, you can blindly follow certain practices and if you're very lucky, your team will reach development Nirvana with no changes.

In most other realities, you'll need to inspect and adapt.

Developers are burned out? Try shorter working hours, training, time for pet projects, more collaboration (or less collaboration).

Miscommunicating with customers? Try in-person meetings, more freqeuent releases, weekly demonstrations, onsite customers and so on.

Software difficult to change? Try continuous integration with automated builds, test-first development, pair-programming, peer review, shorter iterations, or add some new talent to the team.

There is no silver bullet. Really.

But there is a secret weapon. Want to know what it is?

Wait for it...

Here's the big secret...

USE YOUR BRAIN!!!! (It's really an amazing thing)

For more on agile tools and techniques:
(Tags: , ,

Get your copy of the new book! Agile Thinking: Leading Successful Software Project and Teams

Wednesday, September 20, 2006

What I did over my summer vacation

OK, that's not really what this post is about, although I did have a great trip to Santa Fe and Taos, New Mexico.

I've taken a little time off from posting here to get back to some life balance, which included some vacation, some exercise, and even a life retrospective (not just for software projects).

It reminded me that the original goal of Agile (XP at least) was to promote balance in development teams after a decade of increasing pressure, insane working conditions, and burnout.

Well, as it turns out, we did some scurrying around here as well to put the final touches on version 2.2 of ExtremePlanner. It's now approaching the second anniversary of the software, which has evolved just like the Agile processes it supports, but I think has retained it's core simplicity and lightweight approach.

This summer has gone by too quickly, but having a chance to take stock of my life and rebalance was a great opportunity. The irony was that my work and management philosophy of agility was momentarily lost in my own life. Glad to have it back!

For more on agile tools and techniques:
(Tags: , ,

Get your copy of the new book! Agile Thinking: Leading Successful Software Project and Teams