Stephen Smith's Blog

All things Sage ERP…

Releasable State

with 5 comments


First an advertisement for a new session just added for Sage Summit:

Session: Sage ERP Technology Roadmap on Sunday, July 10 at 1pm – 2:30pm.

Session Description: Join Sage ERP Product leaders who will be discussing the technology evolution of Sage ERP product lines. This session will cover our product journey to the cloud; technologies being used to deliver rich web experience; developments on the Connected Services front(joining On-premise applications with the Cloud enabling us for web and mobile services); what kind of tools/technology/skills are needed to integrate, customize our products in the web world; and collaboration occurring on common components. There will also be time set aside for open dialogue. This session is for Sage ERP Development Partners only.

Now back to our regularly scheduled programming…

Releasable State

One of the key goals of Agile Software Development is keeping software in a releasable state. There are quite a few reasons that this is a good thing which we are going to explore in this blog posting. This is very much related to test driven development which I blogged about here.

Problems with Waterfall

In traditional Waterfall Software Development you have a number of key phases namely the setting requirements phase then the design phase then the implementation (or coding) phase then the QA phase then the maintenance phase. The diagram below gives an indication why this is called Waterfall.

There are a number of problems with this; one of the key ones is that bugs and defects are found quite late and that these tend to accumulate to quite large numbers. There are other problems with the requirements gathering and design phases but those would be a topic for another day. Generally it’s far cheaper to fix bugs right when they occur and everything about the code is fresh in people’s minds. As the time between coding and discovering a bug increases, the cost (or time) to fix it increases quite quickly. Fixing a bug from two or more stages in the development process ago is especially expensive. These bugs also cause havoc to the scheduling process. Estimating how long it takes to code something is usually marginally accurate. Estimating how long it will take to fix say a hundred or more bugs is really a crap shoot. Usually when Waterfall projects start to fall behind, there is a feeling that you can make it up by squeezing the verification phase, but practically, what happens is that as a project falls behind then the verification phase grows faster, since more bugs are found and they take longer than expected to fix.

Besides making scheduling un-predictable, what often happens in this environment is that you miss a couple of deadlines; the product is feature complete and has a couple of successful beta sites. But QA are still finding quite a high number of bugs and the outstanding bug count is high. What tends to happen next is a rationalization that the bugs that QA are finding won’t affect customers or that they are things like adherence to standards or in obscure corners of the product and that given the two beta sites are happy then why not go ahead and release. The product is then released; many bugs are found in the field, customers are very unhappy. Then there is a huge panic to address these bugs in a first service pack. This then delays the start of development of the next version and guarantees the process will repeat itself. This then lead to quite a dangerous downward spiral.

Generally this is a gloomy prospect that leads to the various software development death marches that you hear about.

Agile to the Rescue

Agile Software Development wants to address this problem in a couple of ways:

  1. Fix bugs right away, don’t let the time between coding and bug fixing happen.
  2. Don’t let bugs accumulate. Fix bugs right away, it is never ok to let bugs accumulate for later.

One of the main tenants of Agile Development is that you want to keep the software in a releasable state. You never want to get yourself into a situation where you know you have to fix a lot of bugs before releasing. The philosophy has to be that if you know about something in the product that would prevent it from being released right now, then that must be addressed immediately. This statement refers to quality and not feature completeness. Features are added one at a time off a priority queue and then it’s up to Product Management to decide the commercial readiness of the product.

Sure you could try to apply these two points to Waterfall, but the process and philosophy of Waterfall works against you. The goal to finish each phase on time tends to drive away good intentions to not let this happen yet again.

The Agile Development process operates by building a product backlog of user stories that you want to implement into the product. These are in a priority order (by business value) so the teams take stories from the top of this queue to implement. These are then implemented in two or three week “sprints”. At the end of each sprint you produce a working increment of your product. This is shown in the diagram below:

The stories in the product backlog are small enough that they can be fully implemented, tested and documented inside of a single sprint. When done, stories need to be “accepted”. Stories are not done or accepted unless fully tested, code reviewed, documented and complete. If a story is not accepted then it isn’t made part of the product, the team doesn’t get any credit for the work and it will need to be completed next sprint. The key point is that at the end of each sprint there isn’t a bunch of half-finished work checked in causing bugs and general havoc. From the diagram you might want to think of each sprint as a mini-Waterfall, however that would be wrong, a sprint is quite different, but again that’s another topic, perhaps for a future post.

If you are a SaaS product, potentially you could deploy the output of each sprint to your live web server and have all your customers immediately benefit from the work performed last sprint. Within Sage we are trying to operate with a SaaS mindset and I previously blogged about that here. Once you have working software, you have a lot of options as to what to do with it. You have far more opportunities to distribute your software, if not live, then to get more customer feedback to provide more improvements in later sprints.

A key to staying in a Releasable State is having a good set of automated testing tools that can be run continuously on the product so that bugs are found immediately and not allowed to creep in. I blogged on our efforts to become a more test driven organization here.

Generally with-in Agile you are trying to reduce accumulated in quality debt and technical debt. These are defects or parts of the program that badly need updating. The more of these that you accumulate, the harder a program is to maintain. With-in Agile you track these and work very hard to ensure you are always reducing these.

The key thing missing from the diagram above on Agile Development is the lack of any sort of regression or final quality validation phase. This is the desired end state; it takes a bit of time to get to a place when you are really confident you can drop these. We are endeavoring to shorten them with each release with the goal of removing them entirely one day. This speeds up our releases, by eliminating this work and makes things more predictable, since otherwise going into regression you don’t know what you will find, and then the time to fix anything found is also unpredictable.

The further you let a project get from releasable state, the less predictable the completion date. Worse you don’t know how much of this accumulated quality debt you are going to have to pay to release, how negatively this will affect customers or how badly this will hamper future product maintenance. To work optimially you need to really keep a hard line on these. The idea of being able to release at the end of every sprint is a good rallying cry to keep these all under control.

Summary

The Agile Development Process’s goal of fixing bugs right away as they are introduced, performing continuous automated testing and removing the regression testing tail end processes provided software development organizations far better predictability in their development efforts.

This also makes your development process far more adaptable in changing direction as business and competitive conditions change. Since it is far easier to change direction when going from releasable state to releasable state as you go from short sprint to sprint.

About these ads

Written by smist08

May 28, 2011 at 4:17 pm

5 Responses

Subscribe to comments with RSS.

  1. Great post! I’m forwarding to the team.

    Bruno

    Bruno Jouhier

    May 30, 2011 at 8:34 am

  2. [...] some newer customer suggestions to make it into a product sooner. I blogged on some aspects of this here and [...]

  3. [...] Usually beyond unit tests, you have a continuous test server that may be using Fitnesse to run Selenium UI based tests. These tests are too long to be unit tests and would slow the build server down. However you want builds to be regularly deployed to this server and the full set of UI based automated tests to be run. Perhaps after it runs the full suite it would re-deploy the latest build (if newer) and run all the tests again and just keep continuously doing this. If a test fails it would immediately notify the appropriate people and demand prompt action to resolve the problem either by fixing the problem, fixing the test or rolling something back. Again the goal here is to detect problems as quickly as possible and to force them to be resolved quickly, not allowing problems to pile up. Generally you want to keep your product in a releasable state as I blogged about here. [...]

  4. [...] really emphasize releasable state, that these big stories are taking you out of releasable state and that this is a very bad [...]

  5. [...] testing, documentation and anything else required. This then leads to the product being in a releasable state at the end of each sprint. In an ideal world you could then release (or deploy) the product at the [...]


Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 264 other followers

%d bloggers like this: