POSTS

Eliminating Waste - 5 Steps to Optimising Development Support

I’ve been doing a lot of reading recently about value stream optimisation, inspired by The Goal, and The Phoenix Project. One of my own challenges this past year has been to optimise the delivery of valuable software on our development teams and the most impactful place where we have optimised throughput is with regards to defect management and development support. Defects reported after the software has been released have the opportunity to de-rail the rest of your product development plans. Unplanned work of any type eats into the time you can spend building new features. While we should always strive to aim to release software of a high-quality, escaped defects are inevitable and you need to carefully manage the way you respond to them, so as not to disrupt and derail your planned work. Here are the 5 steps we’ve taken to managing the intake of software defects, optimising our development support processes.

1. Plan time to fix defects and address your quality backlog
The first thing we did to optimise our ability to address support issues was to allocate time in our development plans to addressing issues after release. Industry standard is between 10 and 25% of total capacity and this seems to be working well for us. As we get better at building quality in, we’re hoping that the need for dedicated support time will drop.

Each of our development teams allocates a percentage of their sprint to addressing issues in addition to their current planned workload.

2. Allocate dedicated teams to fixing defects
In addition to planned time in everyone’s sprints, we’ve grown a dedicated development support team made up of development and QA specialists. This is important for reducing context-switching and for eliminating the lost time spent when developers have to hop between their planned work and urgent issues.

High priority software issues tend to change in priority very rapidly as new information becomes available. For this reason, we’ve dedicated individuals to this fluid and volatile workload who know that their development time isn’t as stable as others in the department. Clearly, the people best placed to diagnose and remedy a defect are those developers who wrote the software in the first place and, when you’ve a dedicated development support team, there’s a risk that nobody on that team has the expertise required to effectively diagnose and fix certain issues. To mitigate this, we’re rotating people on and off the development support team so that people spend a few months embedded on a feature team and then briefly roll onto the support team; this helps us build a support team made up of individuals who have experience building the features and components we’re supporting.

3. Single-point of contact
Having a single team responsible for responding to production issues has helped us to reduce distractions. It also helps us to have a single place where people can go to when they need development assistance to resolve an issue, and a single place where issues can be escalated.

To make it even easier, we’ve built a dedicated email inbox, a dedicated Jira board, and a dedicated chat channel. This helps us prevent people from trying to directly contact individuals on the development team to get their issue fixed.

4. Kanban prioritisation
Prioritisation of defects is an emotive subject. We’ve helped to diffuse the tension by applying a simple prioritisation mechanism and inviting all interested parties to have their say. Rather than planning x defects in y days, or trying to estimate defect sizes in advance, we’re working through our backlog of defects in priority order. Urgent issues are placed on a kanban board with a limited number picked up to analyse and fix at any one time.

We hold prioritisation sessions twice a week and everyone is invited to have their say on why their favourite issue should be the next highest priority. This has increased transparency and helped us share the responsibility for prioritisation of issues.

5. Regular defect triage
The last phase of change in our optimisation of development support has been to introduce weekly defect triage meetings for those non-urgent issues that didn’t need prioritising instantly. With representatives from support, development, product management and QA, we review each defect to see if it is well understood and clearly documented. Based on the input of interested parties, we determine how to proceed, and where in our priority list each defect lies.

Optimising development support by dedicating people away from the planned development effort has helped to reduce context switching and has made prioritisation more collaborative. We’ve eliminated context-switching for urgent issues and have reduced the cycle time for getting production issues fixed.

comments powered by Disqus