Agile Support : Not just turning things off and on again
I’ve worked in support now for coming up on 10 years and trying to tell people what I do usually involves avoiding that word “support”. It just conjurs up all the wrong images of socially inept people stuck in a basement of an office who get summoned when customers need to resolve the magic of wifi or simply need toner. Thanks very much “IT Crowd“.
I don’t turn things off and on again.
My support unit is much more than restarting failed services. Much more than explaining customers’ face-palm moments. We have collectively been maintaining some of the highest profile services this country has, and covering a vast array of technologies in the process. Migrating services, upgrading applications and software, building in new features, monitoring server health, and much more beyond.
In the past few years my team have been working in a daily situation we have coined Agile Support. We takeover a project which has been delivered through to go-live using agile methodologies so these customers are fully expectant that the service continues to iterate and evolve regularly. The functionality and requirements may change, new features be required or unecessary elements removed from the service. Continuous development just doesn’t cease after go-live for these customers.
Working closely with the customer’s product owner, the team work through a backlog of user stories. These can range from service extensions, new features, or repair of non-critical defects. This means we have fortnightly sprints, daily stand-ups, backlog refinement, show-and-tell sessions, and restrospectives – everything you’d expect from an agile delivery project. Mostly these are small changes of 1 or 2 days but every now and then something big comes along. For example, right now a team of 4 are delivering a 200 day change to extend a service to an entirely new audience. This is the size of project that traditionally a delivery team would have snapped up but through this Agile Support method we have the agile engagement with the customer. They see, trust, and understand how we deliver change and know that as a company Kainos has the ability to scale up and down the support team as appropriate.
Break-Fix Incident Management
Of course the primary concern of a support division is to ensure the service is stable and reliable at all times. Incident management of breaks in the service, fixing defects, and monitoring the health status of the service’s core infrastructure are crucial elements of any support contract. The quality and standard of projects coming into support these days mean very little effort is actually used to address service issues. Things just don’t tend to fall over as much as they used to. **touches wood** As such it’s quite rare for something dramatic to go wrong that would need lots of effort to fix and more often just need a little poke to get going again.
So – yes – once in a while I still just turn things off and on again.
Managing the balance between these 2 elements of agile support is the key. Get it right and the service incidents are handled effectively and efficiently to make the service manager happy while the product owner stays happy seeing the agreed delivery of change implemented. This model is excellent for the support engineer too as they get real development experience that would otherwise fall to delivery teams in other engagements. Engineers get longevity on a single project rather than going from one delivery to another. They can stop having multiple support projects that could all fall over all at once too. There’s also much greater high-quality customer interaction rather than reporting up through an internal project chain of command to the customer.
Hopefully in the future this will become more normal for a support engagement and I can happily tell people I work in support without them immediately asking me to help their PC find the printer on the other side of the room.