Releasable Software And Releasing

One of the big advantages of Agile software development and Scrum is that you have potentially releasable software at the end of every 30 days. That’s been a really hard sell so far with our product owners.

I attended the Sprint review meeting today for a project that has two of my developers on it. The whole team did a great job and delivered a good chunk of functionality that’s already running on our QA environment. The project is building on an existing application and adds functionality they don’t have right now and compacts information from 3-4 mainframe screens into one web page view. My guess is it would save quite a few of our employees a good chunk of time right now.

It wasn’t really suggested, but our Agile consultant/coach and myself both asked if there was enough value here to release it. The product owner explained that they didn’t plan on releasing it on this Sprint, but that maybe in another Sprint or two. That’s actually really progressive in general for our organization.

My recent experience would suggest that we are adverse to releasing anything that doesn’t have every possible feature the customer imagined:

  • We just launched a 9 month long project that could have easily been broken into 3 releases based on the features.
  • Another Scrum project has been through 4 Sprints and surpassed the functionality of the applications it’s replacing after Sprint #2. They still have at least another Sprint before they can release. The last 3 Sprints are totally focused on an admin interface for configuration which approximately 1 user will use a few hours a month.
  • We’re working on an intranet project that may be releasable with one more Sprint, but the customer is currently thinking of releasing it this summer or maybe even September.

Apparently one of our more difficult challenges will be moving people to ship early and often.