BinzBlog – Robert Binzley : robert@binzley.net

One practice that I have come to believe is important is to have regular releases of software that is reviewed by business stakeholders. By regular I mean every 2 – 6 weeks.  These do not have to be full production releases, but they should be to at least a staging or beta platform that business stakeholders can use as if it were the final product.

Regular releases are important for two reasons.

1. Business stakeholders get to see and provide feedback on the product long before it’s complete. Anything that is going off track can be identified, and fixed earlier, which means for inherently less cost than if found later.
2. The development team becomes practiced at releasing user ready software.  If business stakeholders use the released version it must meet a certain level of usability and quality.  If a team only releases once a year, or even less frequently, they are performing a task they do not do often, and most likely do not do well.

We have been releasing every 2 – 4 weeks on the current project I am on and it is working very well.  Through this process we have been able to very quickly react to the requests of our business stakeholders, and we are also very good at releasing updated versions of our software.

Regular releases also help teach a team to stick to a schedule, since the releases themselves become the back bone of the schedule.  In short I believe it’s helpful to release early and often to those business stakeholders who will eventually decide if what you’re working on was worth it to them.

There are some caveats to the above.  A blog post form another blog about this same topic has a comment that points out it might be a bad idea to release early and often for software that has life and death implications.  I would agree with this when it comes to shipping products for market use in those fields.  I wonder if internally it doesn’t make sense to do frequent releases to QA or internal business stakeholders though as a matter of process.  For medical or navigation software I would completely agree final releases should be thoroughly tested and ready.

Here’s another post from a different blog about releasing early that talks about the pros and cons if you are trying to market your product in a stealth like manner.  It makes the point that getting feedback from people who are not your real potential users may not be helpful.  I would agree and many times QA or internal business stakeholders are not the real end users, and their feedback may lead to features and changes the eventual end users won’t like.    I think releasing to internal folks as a proxy to real end users would be better that not having any interim releases at all, in at least you know you are making progress towards a final release that is measurable.  The post brings up some really interesting marketing aspects I’d never really thought of since I am mostly in the code these days.

Old Time Andersen Waterfall

I’ve struggled quite a bit with trying to define what are the appropriate level of requirements necessary to begin coding an application.  Back in my days at Andersen Consulting their methodology dictated a very formal process, the deep V.  As you went down into the V requirements started off with a problem statement, then a scope statement, then functional requirements that were translated into a technical design and at the bottom of the V, implementation occurred based on the technical design.   Going back up the other side of the V were testing steps meant to test the documents at their level on the other side of the V.

The Andersen waterfall looked great on paper and off I went on my projects comforted that the V would lead to straightforward project design, implementation and testing.  What I found was this did not occur.  Maybe if requirements had not changed the waterfall would have worked, and maybe it did on many projects were this was the case.  On the projects I worked on, however, this wasn’t the case.

The situation I encountered often back then, and still today, is that requirements fluctuate.  Not only do requirements flucatuate but it’s only after implementation begins that they really begin to fluctuate.  I would find myself frustrated, pointing a the V diagram, and protesting that these issues should have already been decided.  Slowly I have started to realize that many decisions are not made until implementation begins because it is only then that stake holders start to see their system taking shape.  They rethink decisions they made before they had an actual UI to play with or data on reports.  Based on actual things to look at stake holders refine their thinking and even out right change their minds.  What I have come to accept is that this is how the process really works with any sort of application that is heavily UI driven.  Agile development processes have taken this to heart, and I’m sure if Andersen Consulting still existed today (actually it does it’s called Accenture now) they’re process would reflect a far more iterative process that more readily allows for requirement changes.

The one tool that I have embraced that helps to reign in fluctuating requirements for applications that are heavily UI driven is storyboarding.  Read more…