nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Agile principles in an (IT) service focused team?

Kai Becker

I am asked more often: How can we work as a service team with agile principles?
Is Scrum right for us? How can we keep space free for day-to-day business in sprints, but still work on fixed goals? Or should we rather work according to Kanban?

Probably there is no single right answer, it always depends on organization, team and customer. But I would be interested in your experiences in this context. Have you experienced similar situations? Do you work in a similar environment?

I am looking forward to your answers.

Comments

Harald Seyr

Hi @Kai Becker

one day to late: Muss Service Management jetzt agil werden? - CD Meet-up "IT-Service-Management" (cvent.com)

Exzellenter Vortrag, habe viele gute Ideen mitgenommen.

Kontakt: (1) Mathias Traugott | LinkedIn

So wie ich Mathias einschätze, gibt er gerne seine Erfahrungen weiter.

VG Harald

Ivan Ferreira

Hello @Kai Becker .

It’s important to distinguish between agile principles and Scrum. So, let’s go for the agile principles first:

Customer satisfaction: ensure that you are getting feedback from your customers using Jira Service Management. Create a Dashboard with CSAT Information. Act on tickets that get low customer satisfaction, identifying the reasons and establishing an action plan.
Welcome changing: review your ITSM processes and try to remove “waste”. Review your request-types and adapt them to make them more customer friendly.
Frequent delivery: Ensure that your team is resolving/closing the issues and establish an SLA according the service level, impact and the resulting priority.
Business and TI work together: ensure that you understand the real business pain. “Go to the Gemba”. Prioritize and set SLAs according the business view of the impact.
Motivated individuals: take surveys, and meet 1:1 regularly with your support team.
Face-to-face conversation: specially for incidents with high priority.
Working software: ensure that your customer portal is customer friendly, available, and that the products that you support have a good Mean Time to Recover.
Constant pace indefinitely: find ways to free your support team using self-service tools or automation.
Continuous attention to technical excellence: implement problem management and post-mortem reviews.
Simplicity: review your request type forms, workflows and automation.
Self-organizing teams: give your support team objectives, like CSAT score and SLA % achievement. Create Dashboards.
At regular intervals, the team reflects on how to become more effective: find some space to do CHECKOPS.

Now, you have Scrum, with roles, events and artifacts. Every IT Service Focused Team will also have improvements or Kaizen initiatives. You can use Scrum (and a scrum/Kanban software project), to handle these improvements.

CHECKOPS could also be considered a “retrospective”. You could have a Product Owner who sets the vision/roadmap for your service team. You could have a Scrum Master who helps the teams stay focused on their improvements initiatives, remove impediments, while keeping the customers happy. You can do sprint reviews to “demo” new service initiatives implemented (new dashboards, new monitoring, new processes, new self-service tools, new knowledge base articles, etc.)

You can also have Dailys, getting a quick overview of highest priority issues, and if there is any impediment that must be addressed.

Kai Becker

Thanks @Harald Seyr

Kai Becker

Hi @Ivan Ferreira ,

thank you for bringing back the principles. It is always good to remember the basics and not to take the second step before the first.

I will definitely take another look at the topic of CheckOps and also recommend it to our internal service teams. Thanks for the tip!

Omer Meshar_0f60qw

Hi @Kai Becker ,

I am coaching an IT team, that has about 50% of their work planned and 50% unplanned for various service requests that are created daily.

The team is working hand in hand with a Business operations team, that generates many of the system changes that are needed, and work together with the different business teams to unravel their needs from the system.

The IT team, with the Business operations team (their team leader acting as Product owner), practice scrum, work in sprints, plan their sprints based on what they know upfront, while making sure to have enough slack to be able to address the incoming day-to-day requests.

When a new request comes in, which cannot be handled as "support" and needs to be planned and prioritized, then it enters the backlog and waits for the next sprint to be planned.

All in all, this is currently working for us. We are always looking at the slack needed, at the ability of the team to plan and execute their plan, and make adjustments on the way we work.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

agile

itsm