Sprint Cycles, Production Deployments and are we done yet?

Posted: June 22, 2010 in Agile, Deployment
Tags: ,

In an earlier post, we highlighted “The Definition of Done” concentrating of what factors make up a complete story, that is potentially shippable at the end of a sprint.

In this post, I want to focus on Production releases, integration headaches and how to account for Production Support in later sprints.

Recently, a situation arose where a 3rd party vendor could not react quick enough to the requirements of our sprint. Rightly or wrongly, the decision was made to create fake services to test out the code that was being written, all was merry and bright and there was a good feeling within the team, until reality dawned that there was an imminent production rollout, and our application was far from shippable; due to the lack of integration.

What followed was Death March city, as the team worked through the raft of integration defects, where message contracts between the systems were either incorrectly applied or uncovered edge cases that had previously gone undefined.

A harsh lesson learnt by all concerned. This situation got me thinking about post-production; specifically support, the inevitable patch releases, as end users uncover missing business rules or fine grained entitlement issues etc.

How do we support these in an Agile sprint? The main problem that I foresee is that the developers will have moved on to the next feature delivery in-line with the roadmap; therefore if production issues do arise, that codebase is likely to be 4-6 weeks old. There is the danger that fixes become ‘over engineered’ as the developer may be working on new functions in that area as part of the current sprint, which may affect the fix on the ‘old’ code branch.

Also, there is the issue of delivery, production support estimates are always finger in the air estimates, however if you do not provide sufficient cover, your current sprint may be at risk. The counter argument to this is that if you take too cautious approach, and assign too many points to support, your Product Owner will loose faith, as the team will not be delivering much new functionality.

The approach currently being taken, is to agree a proportion of points for production support (up to 20%-25% of capability), splitting these between our development teams. Within the team there is a rota of who is on support each day, the objective here is to ensure everyone contributes to the current sprint whilst also being mindful of the need to support an old code branch.

In line with my previous post, we are looking to improve our ‘doneness’ relying less on the fakery, or if fakery is required, ensure that future tasks are captured and estimated to reduce pain points in the run up to subsequent production releases. This includes testing considerations such as multi-region testing, external network and compatibility.

Implementing Agile throws up a number of challenges, but I guess the testament to how well you are doing lies in how well you can react and implement new strategies and considerations……

  1. adrianng3 says:


    > agree a proportion of points for production support (up to 20%-25% of capability)
    Good suggestion. Very close to what we do as well. Sometime it turns out not enough but that must be just some challenges of our own legacy.


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