Imagine this……..and then turn it into a reality!
Your internal customer and IT personnel are expressing dissatisfaction with the incident management process.
There is a long list of things they believe need to be improved.
The Process Owner collects all of the requirements from all stakeholders as user stories in the following format.
As a <type of user>, I want <some goal> so that <some reason>.
The user story represents a piece of business value. The user stories are always checked to ensure that they will deliver value to the business, customer or stakeholder.
“As a service desk analyst, I want easier categorisation so that I can log incidents more quickly and get them to the right resolver team”.
“As a marketing manager, I want better prioritisation so that the incidents with the biggest impact on my business get dealt with first”.
Some of the requirements are also extracted from the CSI register and converted into user stories.
All the user stories are placed into a process backlog and prioritised by the Process Owner. The product backlog is visible to everybody so they can see all the work that needs to be done.
A cross-functional team of 6 including process owner, service manager, customer, process architect, tool administrator and documenter is formed.
They hold a time-boxed meeting to plan what they are going to work on over the next 2 weeks. As a team they define what “done” looks like so that they are all on the same page. “Done” means that the deliverable will be both fit-for-purpose and fit-for-use. It is the team that determines how the requirements are going to be fulfilled.
The work to be done is placed in a to-do-in-this-period backlog.
The team are self-organising and empowered. There is no one “leading” the team. The Service Manager ensures that any impediments to work getting done are removed. No one can change what the team are working apart from the Process Owner.
Each morning the team meets briefly and each member states what they did yesterday, what they are gong to do today and any impediments they have in completing their activities. The Service Manager deals with these.
At the end of 2 weeks, the team meet again to review the work that has been done. There is little that has not been “done”. The Process Owner places any work that has not been done into the process backlog.
The team also meet to perform a retrospective of the past 2 weeks. This looks at how the team can improve.
The Process Owner reviews the process backlog and ensures that all the requirements are still valid and in the right priority.
The next planning meeting takes place to determine what activities will be “done” over the next 2 weeks.
Rinse and repeat!
Meanwhile in the next building the change management Process Owner is also collecting feedback on their process. Just like the incident management Process Owner, the list is long. The change management Process Owner decides to initiate a 6-month project to overhaul the process and fix all the issues. When the project was complete, the change management Process Owner found out that the stakeholder requirements had changed! The project therefore did not deliver what was needed.
Which Process Owner is going to be more popular with their stakeholders?
The approach that the incident management Process Owner took:
- Met stakeholder requirements faster
- Managed changing stakeholder needs
- Improved collaboration between development and operations
- Overcame constraints in workflow
- Took an iterative approach to process improvement
- Improved the velocity of the team
- Got more “done”
Welcome to the world of Agile Service Management (ASM) and Scrum.
In this world the Process Owner is the Agile Process Owner and the Service Manager is the Agile Service Manager.
Agile Service Management and Scrum introduce the concepts of process backlog, sprint backlog, sprint, and sprint burndown to measure progress, sprint reviews, retrospectives and sprint planning meetings. All meetings are strictly time-boxed. Only the Agile Process Owner can change the team’s work in progress and the ‘user stories’ in the process backlog.
The process backlog can act as a CSI register. Work is organised into short 2-4 week sprints, each having the team work on a sprint backlog taken from the process backlog.
Tools such as Kanban boards clearly show the work to be done, the work in progress and the work completed.
Limiting the work-in-progress allows the team to focus, have more attention to detail and deliver higher quality outcomes.
There is more to Agile Service Management and Scrum and their benefits than I have covered in this brief scenario. So, you may want to delve a little deeper and see if its something you could adopt in your organisation.
It is a very different way of working for many and so organisational change management will need to be employed.
Perhaps start with a pilot on one process and see how it goes? The old waterfall approach is no longer the solution for all process design and process improvement. Remember, once you get to the bottom of the waterfall, its very hard to climb back up again! A rapid and regular iterative approach saves you that climb.