Agile Project Planning

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

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


  • Have you read Jim Womack's piece about this same topic except using "Lean" instead of "Agile"?

    By Blogger Jason Yip, at 6:03 PM  

  • Hi Jason,

    I don't think I have read that piece, I'll check it out.

    By Blogger David Churchville, at 9:19 PM  

  • David - interesting info, thanks for helping us to better understand agile by publishing your thoughts and opinions on the subject!

    By Anonymous Anonymous, at 5:44 PM  

  • Thanks for the support, Raven.

    I've found that there are as many definitions of agile (or Agile) as there are practitioners, but positive results tend to come from the same core elements: a great team, fast feedback, and engaged customers.

    By Blogger David Churchville, at 5:53 PM  

Post a Comment

<< Home