Agile Support

Agile Support
A Discussion on how Agile Support can
enhance a support management
process in an high velocity Agile
environment.
4/17/15 Copyright Cj Wild | Cj@Wrongspeed.co.uk | 415 715 4984

Introduction
Agile Support is a modern support methodology.
By combining Agile best practice and ITIL best practice you can
take benefits from both and have an efficient support process
that drives quality support fixes, measures team utilization
and brings many agile benefits to the support world.
Having implemented and continuously improved Agile
support processes in an ecommerce environment this
document serves to share my insights and thoughts on how,
what, when where and why you could consider doing the
same.

Why Agile Support?
The project world is largely adopting the agile
methodology - why?
Why do project teams choose Agile
Changing priorities
Learning and responding
Self organization
Liberation of product managers
Knowledge distribution
Look at the benefits for support
Priorities change
Teams self organize and respond faster
Liberation of support managers
Understanding that a support team has
a velocity and how interrupts can be
managed

Is it right for my company?
• Are your project / product / development teams following Agile?
• Do you have a backlog of tickets that have breached SLA?
• Could your existing SLA’s be shorter?
• Do your development teams work on bugs that your support team file?
• Could your engineers work faster?
• Could you benefit from quickly and regularly reprioritizing all the tickets in your queue?
If any of the above are answered “yes” then agile support
can definitely bring you benefits!
• If you are a DevOps team, also responsible for support, at the l1 ,l2 or l3 level then you can not only
apply agile support to your support work, but partner it with your development and QA work to
ensure you are accurately managing and tracking velocity and to ensure that each ‘piece of work’
tat you are doing, whether it is a support request, an alarm, a QA issue is tracked either in a sprint,
on a Kanban or in a scrum.
• If you are an operations team, or a NOC, it is likely that your SLA’s are short, so you may not receive
all the benefits, but it may still be worth exploring to see if some of the other benefits make it
worth implementing.

How to get started
• Implementing a new support process is hard.
• You have to find a line in the sand – a date to draw the end of your existing process and the start of
the new.
• It is prominent to decide how you want to implement and what tool(s) you will be using
• Having decided then you must look at your existing tickets. Pick a date where any new tickets will
follow the new process and the new systems / tools( if any were chosen) everything before this
date should be considered backlog.
• Break your backlog into two sets; ‘already missed SLA’ and ‘Still has a hope of not missing SLA’
• As each of your sub teams / pillars/ engineers finishes work on the tickets in the new process, then
have them go back and start on the ‘still has a hope’ or consider creating a sub team just to focus
on these while other teams work the new process .Only when there are no new tickets, and no ‘still
has a hope tickets’ should anyone look at the ‘already missed SLA’
• At this stage you have already introduced a new process and cleared the backlog from your old
process.
• Once all the ‘already missed’ SLA tickets are completed - you are now fully following an agile
support process and no longer have a backlog – This is the Zero Backlog concept – We’ll come back
to that.

What should my agile process be
• Lets take a step back and look at Scrum, Kanban, ScrumBan and Sprint – Four agile processes –
• Scrum
– A scrum, whether it is daily, twice daily, or more frequent allows you to meet with the team, re prioritize work, review blockers, escalate
– These are all critical things in the support world, by having scrums you are giving your engineers a voice.
– Many teams have a weekly meeting, a scrum every day allows them to speak up and say why the issue is blocked.
– Your SLA’s are likely short, structure your scrum meetings around your SLA’s so that your shortest SLA is longer than the time between scrums, so that a
missed SLA is a direct result of a missed scrum or a badly run scrum.
• Kanban
– How many open tickets do you have right now?
– What status are they in ?
Likely you know these facts
What if you took that further and could see that
How many tickets are new, created since the last scrum, how many are being worked on, how many are ’blocked’ pending some data, how many are completed –
pending sign off. How many were closed this period
Split that data into Swim lanes, and understand your issues by system, or by engineer.
Using this data now understand that one engineer or system has all the issues.
Allocate your engineers to teams, or your budget to engineers by system, on more meaningful data, like velocity, or tickets per area, or mean time to fix tickets
per area.
Visually track this data to create a healthy competition between engineers.
• Scrumban
– Combining scrum and Kanban is a great tactic, often adopted in the Agile world. For a Support team new to Agile it allows you to experience the best of both
worlds, and understand what is right for you. Allowing you to micro manage, if necessary and adjust process ad systems until everything is working with your
new support processes - then step back.
• Sprint
– What if you allocate work to engineers, incidents, and set and end time, a virtual release, within your SLA, that these incidents must be fixed by.
– What if you have multiple sprint teams working in a concurrent fashion
– Diagram
– A project may be complex and need week long sprints
– Support can sprint daily, or shorter – depending on your SLA’s - but still reap the benefits of sprint

What should my agile process be (2)
• Support thrives on SLA’s
• Agile does not – it has project dates, release dates items in a sprint.
• You cannot just project manage support tickets
• Preserving SLA’s and measuring these – whilst following agile
principles, combine ITIL best practice and Agile best practice to
allow for an incident management process that is agile.
• Structuring a scrum around not just blockers, but tickets about to
breach SLA brings new methods to manage SLA breaches.
• Structuring the length of a sprint or the frequency of a scrum
around the duration of your SLA brings a new concept to agile.

What should my agile process be(3)
• OK – So now you want an answer – There is no correct answer –
You have to pick a process that works for your business and your
team.
• I think a good starting place is ScrumBan
• Set up a recurring scrum, the frequency should be slightly less than
your shortest SLA, (this is based on an assumption that you are not
an Operations team with SLA’s and expectations for instant
response.)
• Create a Kanban board to show your tickets.
• Until you choose a tool, or if your tool of choice doesn’t support
Kanban, just use tape, sticky’s and a wall.
• Once your team are following the process and you are feeling the
benefits, consider dropping the Kanban board, or introducing
sprints, or changing your scrum frequency.

Tools
• Single system – do not use a different tool to your Development,
Product and Project teams
• Zero tool, whiteboard and Kanban – start simple
• Isolate the tool choice start with the process
• Look at a tool to enable your process
– Heavily customizable to meet with changing demands – fields changes
– Sla management and reporting should be incorporated
– The tool must support your agile goals, if you want to do sprint or
scum or ScrumBan, the tool should enable that with its features.
– Links to alarm systems
– Ease of use for your incident reporters,

Single system benefits
• If you are working with project, product and
development teams who are using an agile tool, and
following an agile workflow. USE THE SAME TOOL
• It is then easier to have them look at your issues, work
on your issues, accept bugs arising from them etc
• You will also make it easier for them to log or track
time, or measure the impact against their velocity
• You also make it far easier to measure and report
quantities of bugs arising from incidents and incidents
arising from features or releases.

Other core suggestions
• Zero backlog
– Support should not have a backlog of hundred of issues
– There should not even be a term backlog in support - it creates
a bad perception.
– There should be a handful of ‘’new’ tickets that are awaiting
prioritization, or were created between scrums.
• Zero Tool
– The simplest way to start and implement a kanban board is to
make a tape and sticky board on a wall, or to use a whiteboard.

Pitfalls
• Agile support is best implemented when coupled with an
Agile Tool, a ticketing system that supports Kanban boards.
If you choose to go down this path – you may discover
resistance to replacing the ticketing system.
• Introducing agile supports has upstream impacts and
benefits to product, Dev and project teams. Be sure to
communicate and it is vital to identify ownership and
scope.
• If a whole organization does not follow the process and just
some teams, you must learn how to manage this. If done
correctly the teams that are agile will look better – if not
done correctly - tickets will sit idle and not updated.

Further reading / notes
• White paper on agile support
– An expansion of this presentation with much more detail
– (coming soon)
• White paper on Jira as an incident management tool
– A collaboration with a colleague of mine on how to
implement the popular Agile tool to replace your existing
incident management tool.
– (coming soon)
• Contact cj
– cj@wrongspeed.co.uk
– 415 715 4984

Agile Support

More Related Content

What's hot (20)

Similar to Agile Support (20)

Agile Support