Using Scrum for IT Service Management

My IT Service Management team provide Incident, Problem, Change and Configuration Management services in line with ITIL. Our work is highly variable and ranges in complexity since we primarily support other IT professionals in their IT operations.  Agile is the chief service delivery methodology in our organisation and so we have adopted and tailored Agile's Scrum methodology as our way of working. I have been fortunate enough to present on this topic to numerous conferences but time doesn't allow me the opportunity to explain how we work in great detail to interested peers.

I thought I'd share more detail on how my team has adopted Scrum, and this article assumes you already know some basics of Agile or Scrum. As a side note, my team as a whole uses Scrum; the Problem Management analysts use kanban for their daily business-as-usual (BAU) work (managing problems/known errors). In this article, I'll focus on the team's adoption of Scrum.

The main reasons and drivers for the team to adopt Scrum were:

• to deliver and improve services faster to our customers;
• greater transparency in the work for our four interrelated services;
• greater voice in how the work was prioritised and managed;
• greater visibility of our progress;
• to regularly inject improvements in the way they worked; and
• to meet and discuss their progress while some members worked from home (support virtual teamwork).

Team Guidelines

The team has a social contract that outlines their expected behaviours in their day to day work. In regards to our way of working, here are some of our guidelines:

• Sprints are 2 weeks long, start on Wednesday and end on Tuesday. Lose 1 day per sprint for iteration planning, retrospective and showcase.
• Iteration planning, retros and showcases are attended in person or via teleconference.
• All story cards must be labelled either 'planned' or 'unplanned' so we can measure where our effort is being spent per service;
• Each service lodges one BAU/regular maintenance card as a container for all work of this nature (aka we don't raise a new card for every interaction or BAU request since that simply duplicates information from our ITSM tool);
• All story cards must have acceptance criteria, so anyone can see what needs to be achieved for a story to be classed as 'done'.
• All story cards go into the backlog. No cards should be in the iteration without the Iteration Manager’s knowledge.
• Stand-ups start at 0930 every business day, and they are virtual (use screen sharing of JIRA & teleconference). We have no physical wall.
• Our wall has four columns: To Do, In progress, Test & Done.
• Be prepared to discuss, at a high level, what you did yesterday, what you'll do today and raise any blockers;
• For our retrospectives, team members are encouraged to prepare their What worked well, What didn't work well and What still puzzles me prior to the meeting.

Roles

There are two key roles in our Scrum, Iteration Manager & Product Manager. Their duties include:

Iteration manager: (rotational role for team members)

• Book the daily stand-ups, iteration planning meeting, showcase and retro. Facilitate planning poker and email out the planning/retro meeting outcomes to the team.
• Allocate or action tasks from the retros.
• Update the iteration information in JIRA.
• Release completed iterations.
• Facilitate the daily stand-up and launch phone conference for the team.
• Show the burn down chart at the end of the stand-up
• Facilitate the showcase with team leadership and team members.

Product manager duties: (ITSM team leader)

• Groom the backlog fortnightly and confirm priorities of cards in the backlog with customers & team
• Ensuring that the team is working on the highest priority cards for the customers/stakeholders.
• Groom the Risk Register for accuracy and progress on mitigation actions.
• Highlight team progress to senior management.
• Be an escalation point for the Iteration Manager.

Tools

We use three tools: JIRA (Scrum management), Microsoft Lynx (screen sharing) and teleconference (voice). We don't use a physical wall since we regularly have team members working remotely.

Reporting

Our main reports include:

• Daily burn down chart.
• Percentage of work that was planned vs. unplanned.
• Retrospective feedback and action items.
• Risk Matrix (review of open risks).

Our way of working or adoption of Scrum has evolved over the past 2 years and continues to do so. Sources of influence on our way of working include changes in business or department strategy, staffing levels, technology, lessons learnt, and work environment. Regardless of the source of change, Scrum has allowed us to adapt quickly and also continue to improve services to our customers.