Before You Go Agile

Agile is one of the hottest ideas in software development today, and it actually has nothing to do with software per se.  Agile is a project lifecycle methodology based on constant re-evaluation of your project and an iterative approach, where requirements, code, and testing are all being done constantly in small pieces.

Everybody wants to be agile today.  But what will it mean for you?  Here are some things to keep in mind if you want to go agile.

1. You can plan releases for dates or for functionality.  You cannot plan for both.
Agile requirements are deliberately fluid.  If you decide you are going to do A, B, C, and D for your July release, you don’t leave room to add X, Y, and Z if they’re more important.  If you want to maintain a consistent release schedule, you have to be willing to let things remain undone for now.  You’ll get to them in the next release (unless a more important M, N, and O come along…)

2. You will throw away work.
After you have designed, built, and tested a piece, a requirement may come in which requires you to rip out that piece and throw it away.  In fact, if you never throw away any code, you are probably doing agile wrong.  Get used to the idea now.

3. You need to embrace the idea of good enough.
You are not aiming for perfection on every iteration of an agile project.  If it will meet the needs of the customer, it’s good enough for a first pass.  Don’t do more than is necessary to meet the basic requirement.  If more is needed, it can be added as a new requirement with its own priority.

4. Modularity is your best friend.
If you are on a long-term enterprise-level project, I will pretty much guarantee that at some point, a new requirement will come in, and you will realize you need to change some major underlying part of your code to fix it, with implications that ripple through every line of code you’ve written.  To defend against this as much as possible, code to interfaces and keep your code as modular and pluggable as possible.

5. You must schedule work based on priority, not function.
If you have 6 major functional areas you are planning to address in a given release, it can be too easy to say, “We have three sprints, so we will focus on two areas per sprint.”  If you do this, chances are good you will completely miss one (or more) functions entirely.  Instead, do the highest-priority piece of each area first.  If you want to be able to view, edit, and print six different tables, start with building all six tables.  Then add the edit functionality to all six tables.  That way, if you run out of time, you’ll only be missing the least important functions from all tables, instead of missing some tables entirely in a way that might prevent a release from being usable at all.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s