November 25, 2014

Early life support for an Agile team

Whilst building an Agile framework for a client, I came across the term ‘early life support’. I’ve done a fair amount of delivery in my career but not heard this term. It comes from ITIL and means that you must have a documented process for support from the development team for the first X number of days when a product goes into production. It goes to form the contractual guarantee that the development team will still be around when the product goes live.

Imagine the scenario: The team finishes its development, fixes some of the bugs in the testing phase and then it goes live. Job done. Development team goes off to another project, maybe individuals leave the company. In the first month, users actually use the system and find it doesn’t do quite what was expected and isn’t quite up to the quality required. How does this problem get resolved?

The ITIL solution is to contract the development team to hang around for a month to do early life support. Then we have coverage for this eventuality.

In Agile of course, we look to have long lived teams, with shorter cycles for delivery, which is likely to remove this as a problem. It removes it by firstly not having to contract teams to stay around, and secondly, Agile teams tend to take responsibility for the product in its entirety and thirdly because shorter release cycles mean less stuff to go wrong.

However, imagine an Agile team, perhaps using SAFe, where we may have set the iteration cadence at 2 weeks but the release cycle to 3 months. In the first month after release, we may have the same problem.

We need a way to fix these issues as they arise. Early life support in an Agile environment can then be a percentage of story points allocated by the team for X days on supporting issues from production. In our 3 month release cycle, this may be 25% for the first sprint, 20% second sprint, and 10% third for example. The reducing allocation represents the reduction is emergency fixes that need doing.

If the percentage required is too high, then you likely have a lot of technical debt. Or the triage process is not correctly putting items into the backlog for prioritisation, and instead classing them as immediate fix.

It is important to try to keep this percentage as low as possible. If we look to Kanban at the class of service for expediting items, we can see how this slows down the overall flow of delivery. We want to eliminate or remove this overhead if possible.
(Think how much overhead it is in heavy traffic to have a hard shoulder. This is your expedite lane for emergency vehicles.) We don’t want an expedite lane (percentage of time) in our development teams.

Example: 4 lanes of traffic equals a rate of 4 cars per duration off the motorway. 3 lanes of traffic is only 3 cars per duration, that is a 25% reduction.

The best policy to reduce the percentage needed for expedite items, is shorter release cycles and high levels of testing. When this is not possible, we can make the amount of work visible that comes through as support and actively find ways to reduce it.

Examples of things that can reduce support issues are:

• Better testing
• Better BDD testing
• Better or more frequent reviews by the product owner
• Shorter release cycles
• Review the definition of done, is there anything that can be added?
• Look at the monitoring, can any of the items be turned into backlog items rather than expedite items if the support teams new more about the problem?

I’m sure there are a ton more.

Good luck in reducing your percentage allocation to expedited items!

Simon Powers
Simon Powers is an Agile Coach specialising in large scale transformations and agile adoption. He has a background in very large enterprise architecture which has led on to organisational design and agile process refinement. Simon is the founder of Adventures with Agile.