One of the greatest advantages of Agile is the ability to release early and often. It stands in stark contrast to the waterfall approach where you finally deliver at the very end if you deliver at all.

Though ROI is notoriously difficult to calculate with many IT software projects, releasing as soon as you have customer value dramatically shortens the payback period for your effort. So even given a project where the expected ROI is pretty much a guess by the sales team delivering some of the necessary functionality in the first few months is a big win. And despite the negative aspects delivering failing faster on a product thats going to go nowhere is also quite a benefit in reducing waste.

A subtle effect involves the ability to deliver much closer to the just enough target. If you release a product and find that it pretty much meets the needs of the customer base, then maybe you end up leaving out that long product backlog. This avoids building a lot of functionality that will never be used. It also makes maintenance and future enhancements easier because the base product is simpler.

With all of these obvious selling point it can still be a very difficult sell inside many organizations. The problem stems from a general lack of trust from customers. They have been involved in a contractual battle for years even with their own IT department. It works something like this:

• Customer: We have this great idea for this new CRM product.
• IT: OK, well just get the requirements together and signed off and we’ll build exactly what you want, but it may take a while.
• Customer: No problem, we’ll put everything in so we don’t have to do change requests. I hate change requests.
• IT: That’s good, but remember we need to control the scope. You know it costs 10x as much to change a system after you start coding, so it really helps to have the requirements fully defined. Give us a really good spec and we can produce miracles.
• Customer: This is great so we can launch this in 6 months.

The unsaid part is that the customer is tossing in everything they might need in the future. If you know you have to wait a long time to get a new system, you have to protect yourself by asking for everything you might want even if you’re pretty sure many of them won’t turn out to be necessary. You really want to avoid the change control process.

IT on the other hand knows the customer will never define the requirements well enough because they never know what they want. They’ll produce some crappy wishlist with a lot of ‘system shalls’ and then we’ll have to be forced into a change control process.

This is a recipe for failure and both sides know it, but it continues because sometimes its hard to imagine something outside of the waterfall. Both sides have long since stopped questioning the value of heavy documentation. (Just yesterday I had a brief conversation with an analyst about what they were working on. They explained for a very small change to an existing product they were writing a 44 page requirements document. I exclaimed about how this seemed like an awful lot, and they just sighed and said “we’ll it’s not so bad, a lot of it is screenshots.” The worst part was the code had already been done and was ready to be QAed, so the document itself has almost no value.)

I ran across the idea of an iteration zero today reviewing Peter Schuh’s Integrating Agile Development in the Real World. He defines it as:

An iteration zero does not deliver any functionality to the customer. Instead the project team focuses on the the simple processes that will be required for the adoption and use of most agile practices. … From a management point of view iteration zero may include

• Initial list of features identified and prioritized.
• Project planning mechanism identified and agreed upon.
• Identification of and agreement upon a team customer, essential stakeholders, and business users and the nature of iterative planning process, such as the time of planning meetings and the length of iterations.

I’ve used the iteration zero approach when setting up for a project before. A lot of times it takes a bit of prepping and planning to get some sort of initial product backlog together for the customer, finding a collocation space, and just getting some software installed.

There is a danger that you get too comfortable with this approach and you’re regularly beginning projects with an iteration zero that doesn’t really deliver actual value. I find most customers just aren’t ready to jump in day one on a Sprint unless they’ve spent some time thinking about the product backlog and what they probably want first. We’re using them less now that many of the teams are fairly familiar with Agile approaches, but they still happen.

This afternoon we held an update on our Agile pilot projects for much of the executive leadership of the company including the CEO. It was led by our agile coach and championed by our CIO.

At this point I’m not sure what to make of the results, but we still have a green light to go forward. The executives were pretty quiet overall which may have just been courtesy of a Monday afternoon meeting. What concerns were brought up centered around two basic items:

• Co-Location
• Dedicating staff

I’m not sure these are the major concerns in other places adopting Agile, but they have been ours. At the end of the day they both involve giving up some measure of control, and that is rarely an easy thing to do for a functional manager.

Given that I really only have one semi-real Ruby on Rails app on my machine I went ahead an threw caution to the wind and upgraded to the newest Rails 1.1.2. No problems until I ran my unit tests and got complete failures with messages like:

test_save_valid_order(StoreControllerTest):
ActiveRecord::StatementInvalid: Mysql::Error: Lost connection
to MySQL sever during query: DELETE from orders

I tried the obvious things like restarting MySQL, but no dice. A bit of hunting found a ticket entitled lost db connectivity after updating rails. That got me thinking it might be something with the MySQL drivers. At HiveLogic they had the following advice:

sudo gem install mysql -- --with-mysql-dir=/usr/local/mysql

Now all of my tests are running fine.

Tim Shadel recommends when doing code reviews to review no more than 5-6 classes for a one hour review session. I violated that rule of thumb last week, and I can see how it burns you out just reviewing that much code ahead of time. And I have a feeling when we go through the review Monday we’ll run out of time unless we really push it.

At least it will allow us to better evaluate using a tool for the review process. We’re still waiting on the preview release of Crucible, but now that most of our developers have been pushed into Rational Application Developer we are trying out the Jupiter plugin.