Agile service management – insight into practice
Agile service management – insight into practice
3. October 2022
Reading time: 8 minutes
In Agile servicemanagement – an overview, the first part of this series, we created a basic understanding of what agile service management is all about and discussed the framework's underlying methodologies such as Scrum, Kanban, Lean, ITIL and DevOps in more depth.
In the second part, we delve deeper into the framework of agile service management and use project examples to show how this can be implemented in practice.
It is important to understand that agile service management does not aim to integrate agility into existing best practices and processes, but focuses on providing the values, mindset and perspective you need to integrate agility into your way of working step by step. This is how you create higher acceptance and sustainable anchoring in your organization.
Roles in agile service management
In agile service management, there are three central roles: the Agile Service Manager, the Agile Practice Owner, and the Agile Service Management Team.The Agile Service Management Team (analogous to the Development Team in Scrum) consists of three to nine experts who work together cross-functionally, without hierarchy, and in a self-organized manner to deliver a completed increment at the end of each sprint.
The Agile Practice Owner (analogous to the Product Owner in Scrum) has authority over the Practice Backlog and is responsible for the end-to-end deliverables. They create, manage and prioritize individual elements of the backlog as well as their requirements for the ITSM process and manage the team accordingly. They are subject to stakeholder management with the goal of maximizing the value of the end product.
The Agile Service Manager (analogous to the Scrum Master) supports the other roles in fulfilling their responsibilities and tasks. Their own responsibility is to communicate Agile thinking and ensure that Agile values and principles are understood and applied both within the team and by stakeholders outside. It is important to understand that a "Servant Leader" acts not as an organizer but as a coach of the Agile Service Management team.
Only when each of these three roles understands and fulfills its specific responsibilities can process design and process improvements proceed successfully and the team work together harmoniously. Or, to put it another way, only strict adherence to these rules ensures full flexibility for the team.
Agile process engineering
An agile process provides as much agility and flexibility as possible and just enough structure and governance as an organization needs to achieve its goals effectively and efficiently. All processes should empower the team to create valuable results. This requires that processes be easy to understand, focus on collaboration rather than process compliance.The advantage of this approach is the so-called "Minimum Viable Process" (MVP) or microprocess. This refers to the minimal execution of a process that meets the needs of customers with minimal effort and ensures feedback.
Minimum Viable Process (MVP)
In this way, the necessary core functions can be provided in a resource-efficient manner with the help of a quick and simple process and improved in the next iteration through stakeholder feedback.
Agile process improvement
The goal of agile process improvement is to ensure service management agility across the entire value chain. The key challenge is to keep the balance between "just enough" and "not too much" structure. Keeping practices, processes, and micro-process agile in day-to-day operations without letting them become too complex or bureaucratic requires long-term commitment and control.Process improvements are therefore not a one-off project, but should be driven continuously and with a holistic approach. In collaboration with the team and stakeholders, the Agile Practice Owner is responsible for identifying creeping trends, reviewing processes for Agile values, assessing their relevance, ensuring that just enough structure is in place, and promoting effectiveness and efficiency.
Formal and indirect artifacts
In Scrum, artifacts serve as orientation - they should create transparency and build a common understanding to support the team in coordinating the planned tasks in the best possible way. In agile service management, they jointly form the framework around the processes.
The following illustrates how the formal artifacts are complemented by indirect artifacts and work in concert to fulfill the shared vision to create value.
The Practice Backlog is a prioritized list of all requirements relevant to a Practice, created by the Agile Practice Owner. The backlog serves as the sole source for all changes and practices and is visible to all stakeholders. As part of Practice Backlog Refinement, the backlog is regularly refined to adjust details, work time estimates, and prioritization.
A User Story is a statement that describes what is desired from a practice from the user's perspective. An Epic is a collection of related User Stories that are worked through over one or more Sprints.
The Practice Backlog is a prioritized list of all requirements relevant to a Practice, created by the Agile Practice Owner. The backlog serves as the sole source for all changes and practices and is visible to all stakeholders. As part of Practice Backlog Refinement, the backlog is regularly refined to adjust details, work time estimates, and prioritization.
A User Story is a statement that describes what is desired from a practice from the user's perspective. An Epic is a collection of related User Stories that are worked through over one or more Sprints.
The Sprint Backlog is a forecast from the Agile Service Management team, which functionalities will be provided in the next increment and which tasks are required for this. At the same time, it visualizes all the work required to achieve the sprint goal (i.e., the goal of the respective sprint) and its progress. The backlog is empty at the end of each sprint and is refilled for the next one.
An increment is - according to the Definition of Done - a completed aspect of the practice. This can be, for example, the improvement of one or more micro processes. It is important that the increment is value-adding on its own. During the Sprint Review, the Practice Owner decides whether the respective increment is released and rolled out.
The Definition of Done is a list of completion criteria to be considered by the Agile Service Management team when creating the practice. It ensures a common understanding of when a work is finished and the sprint goal is reached, thus increasing the quality of the results.
Sprint events
Sprint events support Agile Service Management in establishing regularity, creating transparency and minimizing the need for other meetings. The duration of a Sprint is defined from the beginning and may not be changed. All other events have a flexible time window and may be terminated as soon as their purpose has been fulfilled.
Events i agile Servicemanagement
Practice Planning Meetings (no time limit) are used for planning at a strategic level. They typically span several meetings and aim to identify the value of a practice, understand the underlying architecture, and determine the sequencing of the micro-process. At the end of the planning meeting, the practice's goals and metrics should be defined, risks should be clear, and integration with other practices should be considered. In the spirit of agility, the plan should also be "minimally viable" and thus just "sufficiently detailed."
In the Sprint Planning Meeting (4 to 8 hours), the goal of the Sprint is defined. As part of this, it is defined which increment of the Practice Backlog will be completed in the Sprint, how it will be created, and what dependencies exist. At the end of the planning meeting, the Sprint Backlog is fixed. It is also important to ensure that the Agile Service Management team has all the necessary skills and resources to achieve the sprint goal. The meeting takes place with the Agile Process Owner as well as the entire Agile Service Management Team and is moderated by the Agile Service Manager.
During the Sprint (2 to 4 weeks), an increment - as agreed in the Sprint Planning Meeting - is built based on the elements of the Sprint Backlog. The Sprint is driven by the Sprint Goal. This means that no changes may be made during the sprint that would jeopardize the sprint goal. The Agile Service Manager is responsible for keeping the Agile Service Management Team focused during the Sprint, coaching members such as stakeholders when necessary, and removing obstacles. The Practice Owner, on the other hand, ensures that the priorities within the Sprint are processed unchanged.
The Process Standup (maximum 15 minutes) takes place daily and is used to plan for the next 24 hours. It provides an opportunity to review progress toward the sprint goal, with each team member sharing what has been accomplished since the last meeting, what is planned between now and the next meeting, and what obstacles are in the way. Behind the daily standup is the guiding principle of "fail fast, learn fast." The sooner you identify deviations, the faster you can react and the greater the chance of achieving your sprint goal. Solutions to these obstacles are always found after the standup.
The Sprint Review (2 to 4 hours) is held at the end of each Sprint to review the increment according to the Definition of Done and adjust the Practice Backlog if needed. The Agile Service Management team demonstrates the completed tasks and answers any questions from the Practice Owner, who has a hand over the Backlog, while the Agile Service Manager is responsible for organizing and facilitating. The most important decision made during the review is whether or not to roll out the completed increment. In addition to dependencies and the increment's value contribution, the organization's receptiveness and willingness to change are also decisive factors.
With the Sprint Retrospective (1.5 to 3 hours), the Agile Service Management team has the opportunity to review itself and plan improvements for the next Sprint. Here, questions are discussed such as: What did we do right? What could we have done better? What did we learn? What will we do differently next time? Questions include the composition and skills of the team, other stakeholders, the meeting culture and communication, and tools used. The Agile Service Manager facilitates the meeting and ensures that all members can participate equally.
The Microprocess Planning Meeting (with no time limit) focuses on a single, well-defined activity. Similar to other planning meetings, the goals, metrics, responsibilities, risks, dependencies, and relevant stakeholders are discussed, albeit on a smaller scale and thus with less complexity. The result is usually one or more sprints that focus on precisely this micro-process.
Implement agility successfully
You now know the theory and tools. But what does agile service management look like in practice? The basic thing to remember is that "agility" doesn't fall from the sky. Start simple and stay simple. The agile mindset must first be established within the organization, and that takes time. Increase process maturity holistically and organically through small steps; this is the only way to achieve continuous success in the long run.Establish an agile mindset
In order to anchor the topic of "agility" within the organization, it requires the support of the management on the one hand. This must support the training of employees in this regard and create scope to try out agile working methods in daily operations and thus gradually establish them. In the long run, agile methods ensure an increase in productivity. However, there may be productivity losses at the beginning, which the organization must be able to withstand.Once management commitment has been secured, the next step is to create a uniform understanding of "agility" within the organization. This should involve defining the key terms and principles and providing appropriate training. It is important to understand that this is not a one-time project, but should be driven continuously in order to really embed the agile mindset in all employees. You can achieve this with small steps (e.g. sprints or Kanban boards), so that the introduction of the methodology is driven forward by the employees and is constantly pushed forward and accepted. In this way, you create the basis for introducing agile service management effectively and efficiently.
Set up agile service management
Now really from theory into practice:Set the scope
Define the team
Define the methodology
Fill the Practice Backlog
Start with the first sprint
In the following paragraphs, I will guide you through these five steps and show you what really matters with an implementation example based on my own project experience.
The scope should be defined at the beginning of the transition. It is helpful to start with a team that is generally more open to the topic of "agility" in order to gain initial experience. These team members can support as "change enablers" during the rollout into the organization.
What you define as a practice as an organization is up to you. However, especially at the beginning, it is a good idea to use practices from ITIL 4, such as Incident Management or Change Enablement, as a practice, since their scope is already well defined. Another option is to consider a service such as Workplace Collaboration as a practice. Depending on the specific need, these approaches can also be broken down further. The only important thing is that the scope is clearly defined so that an Agile Service Management team can be established for it.
We have chosen the Workplace Services practice as a first step towards agility. The scope includes hardware such as workplace devices, the operating system, associated applications, and services such as the installation, removal, and replacement of devices.
The next step is to fill the appropriate roles for the defined practice. Above all, the Agile Practice Owner is of central importance here. For example, based on ITIL 4, this could be the Practice Owner or the Process Owner of a service. In their role as Agile Practice Owner, they have responsibility for the corresponding practice and the associated Practice Backlog.
Furthermore, the Agile Service Manager must be staffed. They should have already gained experience in the implementation of Agile Service Management and/or Scrum so that he:she can support the Agile Service Management team in the implementation of the methodology. They should also be well connected within the organization to have a certain "power" to bring in changes.
Last but not least, of course, the Agile Service Management Team is needed. All persons relevant for the implementation of the practice must be integrated into this team, e.g. tool administrators, system engineers, process engineers/architects, process practitioners, etc. All persons involved should ideally have a dedicated position within the organization. All stakeholders should ideally be dedicated to agile service management. This is rarely realistic in smaller organizations, so these individuals can be "shared" with other teams. However, the capacity for the Agile Service Management team must be clearly agreed upon and adhered to.
The previous Service Owner of the "Workplace Services" will now assume the role of Agile Practice. An external certified Agile Service Manager will act as Agile Service Manager (alternatively, of course, an internal person or a certified Scrum Master could also be considered)..
The Agile Service Management Team consists of a System Engineer for the Windows operating system, a Technical Writer for the technical documentation, a Process Architect/Engineer for the design and implementation of processes including their documentation. A Tool Administrator is responsible for the implementation of the practice in the ITSM tool. A Trainer creates the documentation for training employees and conducts this training independently. A software packaging specialist is responsible for packaging the software. Other experts are called in as required.
Not all people are 100% available to the Agile Service Management team. Depending on the individual skills, some people perform several roles or some roles are performed by several people.
The Agile Service Management Team consists of a System Engineer for the Windows operating system, a Technical Writer for the technical documentation, a Process Architect/Engineer for the design and implementation of processes including their documentation. A Tool Administrator is responsible for the implementation of the practice in the ITSM tool. A Trainer creates the documentation for training employees and conducts this training independently. A software packaging specialist is responsible for packaging the software. Other experts are called in as required.
Not all people are 100% available to the Agile Service Management team. Depending on the individual skills, some people perform several roles or some roles are performed by several people.
Before getting down to the nitty-gritty, you need to define the methodology that is adapted to the organization. This means you need to determine which formal and indirect artifacts and which Spring Events will actually be used. To start with, I recommend using it as it is "in the book". Once you have gained initial experience, you can always adjust it according to your specific needs.
Now "only" the Practice Backlog needs to be filled and prioritized. For this, you need to document and integrate all requirements and needs of your customers as well as those of the internal IT stakeholders. It is important to document user stories cleanly so that requirements and needs - and not the solution design - are the starting point in the further course. The final responsibility of the backlog lies with the practice owner.
We document all of our customers' needs as they are described in the book. This means that all change requests are recorded as user stories and documented accordingly. Emergency changes are also recorded as user stories as required and integrated into the sprint at short notice. In addition, "normal" ITIL practices such as change enablement are taken into account.
Then let's get started: Implement the first sprint, gain experience and incorporate it into the next spring to continuously improve. Once the methodology works well with one team, this approach can be extended to other teams. This is where the SAFe approach can come in handy to synchronize different agile teams. More important than the methodology itself, however, is the mindset. In order for the change to agile culture to succeed, it is recommended to use promoters or "change enablers". This can be, for example, your original team, which passes on its experience and thus creates more openness and acceptance towards the agile way of working.
Closing words
Establishing agile service management sustainably in an organization is not a sprint, but a marathon - pun intended. But you need many small sprints to get to the next stage goal, because the end goal does not exist. Agility also means continuous improvement and that, by definition, cannot happen overnight. Take your time, start small, and expand what has proven successful. In this way, you gradually increase the process maturity of your organization and ensure sustainable increases in productivity and quality.Basically, you only need two things: first, the commitment of the management and second, a team with a basic understanding of and willingness for agile working methods. And then you just get started.
I always recommend doing the first sprint by textbook - not because that's the best method. The best method is ultimately the one that is tailored to specific needs of your organization. But it's a version that has been proven to work in this or a similar way for many agile teams and provides a consistent foundation. What works, you do the same in the next sprint. What doesn't work, you change. In this way, you create an agile culture piece by piece, which you can gradually extend to the entire department, division or organization.
An agile team always consists of exactly the experts it needs to achieve the sprint goal - in our case a blog article about "Agile Service Management". Thomas Scherzinger is our certified Agile Service Manager and subject matter expert around the methodology. He was supported by the Agile Service Management team consisting of Julia Heumos (Scrum & agile mindset), Simon Hoefler (DevOps & ITIL), Alex Grozea (research) and Riad Beqiri (copywriting) as well as Practice Owner Melanie Zollinger with the Definition of Done. Many thanks to all involved.
Author
Thomas Scherzinger
Thomas' consultancy focus lies on the introduction and improvement of IT service management, IT project management and the implementation and continuous improvement of sustainable new services for a modern workplace.
Thomas Scherzinger
Thomas' consultancy focus lies on the introduction and improvement of IT service management, IT project management and the implementation and continuous improvement of sustainable new services for a modern workplace.
