Let's say you're a Cloudspace client. Let's say you're new to Agile. You've heard people talk about Agile; but how is it actually done?

If I had to give an executive summary, I'd say Agile is a way to sustainably manage projects for the long-term, while still keeping flexibility for the short-term.

Now, that's a great piece of marketing, suit-and-tie-speak. And it's useless for actually figuring out how Agile works. You want to know things like: Agile makes it easy to apply today's lessons learned, starting next week -- not at the beginning of next-year's project. This means the person with the product vision (probably you) can re-evaluate and completely change the direction of a project in under a week.

That's not to suggest we're wild cowboys, riding a code horse from feature to feature, shooting off wildly. We do this deliberately and methodically. This is where the "long-term" comes in. Any programmer with enough Attention Deficit Disorder can drop what they've been working on to start another new thing. However, this only works until around the 8-week mark. With code, once you go past about 8 weeks, you hit a wall and end up managing old code, rather than going forward. It's tragic. We've all seen it before. There are three reasons:

• poor code
• poor communication
• poor planning/bad schedules

Up front, we work with smart people who produce good code. But code is tightly integrated; adding a feature to one part of the code can break another part. The only way to know something really works is to test it. Hand-testing code is monotonous, inconsistent, and unreliable; not a good use of a smart coder's time. Instead, we build automatic tests to give us a heads up when something's changed -- and we deal with it on the spot, not in next month's Q&A session with the review board. We don't just know our code is good, we can prove it.

We make sure that there's good communication among team members by having daily meetings. Every day, the coding team has a very quick meeting to discuss what they've been working on, what they're doing next, and anything that's giving them problems. We know you're seeing value for every day we're on the project. Also, it's hard for problems to last long -- when you're continually looking for them. We also have regular client updates during the week. But don't think we spend all our time in meetings; our daily is only 10 minutes long.

Finally, we plan for the project to change by making feature schedules with a client representative once every week, not once every month. Imagine driving a car with a steering wheel that only worked once every 15 seconds, and you'll know why we plan every week.

Of course, we don't let ourselves get tied down with planning. I've seen rooms of people make a hash of planning the simplest of features. Want to see 30-man-hours spent on deciding if the login button goes *right there* or *two more pixels to the left*? Not if you're paying for those man-hours. We're all about simple planning -- but that's my next post.