Integrating Agile and ITSM
Every week a new production release and often changing requirements and priorities – this is daily life in agile environments. How does this project delivery approach (usually: SCRUM) fit into existing IT Service Management processes (usually: ITIL)? How do we manage for example the increasing trade-off between flexibility and stability? How do we make sure operational service-requirements are reflected in an early phase of an agile project? How do ITSM-roles and SCRUM-roles chime together? Can ITIL and SCRUM coexist? YES, definitely!
Before we proceed on that, just to make sure that things don’t get mixed up:
- This blog is not about using agile project delivery methods to drive ITSM initiatives forward (I call this CSI 2.0: An very promising, but completely different topic)
- I hope it’s also not one of these wishy-washy “let’s go agile ITSM” blogs, which promote that we now should forget all the processes and become ‘cool agile’. In my opintion, there is on the ITSM-side a lack of understanding, that SCRUM is an extremely structured approach, but within these boundaries promotes the principle of self-organization. Often, only the second part is perceived and ‘becoming agile’ acts as a bad excuse for the chaos.
- So this is rather about how to integrate a specific Project Management approach with ITIL. Especially if agile project methodology is used for existing products or services (being already in operation), a tight integration into your Service Management processes is key.
Developing the Model
Step 1: Understanding the two Domains and their Goals
ITIL and SCRUM do not contradict each other. There is no incompatibility. SCRUM is a specific way to deliver projects, it’s an iterative, adaptive and incremental approach to project management. You can use it for any kind of project, even outside IT, and has become by far the most popular agile methods. ITIL is about best practice IT Service Management. It’s a holistic collection of ideas and processes on how to define, design, transition, run and finally continuously improve services (-> that’s the service lifecylce). ITIL takes the operational point of view into consideration, acknowledging that value to the customer is delivered during service operation and therefore operational requirements must be reflected in an early phase of Service Design. ITIL is agnostic on what PM methodology is used. So ITIL and SCRUM are rather complementary. Similar if you would look at ITIL and Prince. The challenge is how the two interact.
Step 2: Understand how the two Domains fit together on high Level
ITIL and SCRUM fit perfectly on high level. From ITIL perspective, SCRUM starts with Service Design and ends with the delivery of a product or service (well, actually it starts over and over again). I made below graph to illustrate this:
So, let’s quickly walk through the SCRUM process and you will immediately understand what this buzz is all about:
- Service Design: Starting from the approved business case, requirements are gathered in form of user stories & prioritized. The result is the prioritized product backlog.
- Service Transition: This is handled through timeboxed sprints (typically between 1-6 weeks each sprint). Each sprint starts with a sprint planning meeting, in which user stories are included for the next sprint (-> sprint backlog, a subset of the product backlog). Daily standup meetings help to track progress and to eliminate impedimends. The sprint ends on the one hand with the sprint review meeting, in which the new/changed service or product is formally accepted. On the other hand, there is the Sprint Retrospect Meeting, which results in the lessons learned for the next sprint.
Step 3: Tackling the Challenges
Don’t forget Operations
One issue with purely SCRUM-driven projects is that they don’t care about Service Operation and focus very much on the utility (functional requirements) of a new product or service. Solutions are thrown over the fence and especially warranty-aspects of a new service (capacity, availability, security and continuity) are not taken into consideration and at the end of the chain the service doesn’t deliver it’s value. DevOps provides some ideas on how to solve this. One of the big contributions of ITIL is that these operational aspects are already reflected in an early stage of the Service Design phase. Applied to SCRUM, this would mean that already during creation of User Stories and the Product Backlog these requirements are gathered. During the sprint, teams taking care of these aspects (e.g. infrastructure) need to be part of the Scrum Team.
Change Management & Release Planning
From an operational perspective, Change Management acts as a protector of the productive environment, identifying risks of each change and preventing negative impact. More broadly , you can put every change on a Configuration Item under Change Control (e.g. product backlog, which is created in Service Design). The tricky question is to which extend. On the one hand it will give you more stability; on the other hand you add more administration and loose flexibility. So it’s a trade-off. Change Control is also a big topic in SCRUM, for example each sprint end with a sprint review meeting, in which the product owner reviews and approves the sprint. Or in Service Design, the product owner acts as a gatekeeper for each user story (change control over requirements). So putting this picture together, there are many instances of change control:
To achieve the right balance between flexibility and stability it is key a) to decide, what you want to put under change control and b) moreover to apply the right delegation models. For example:
- Change control over the Product Backlog is delegated to the Product Owner. However, Service Operation teams should be involved as well to ensure operational warranty requirements are included as well in the user stories;
- Change Control over the sprint results is delegated to the Product Owner and in case the sprint shall be included in a future release, the regular operational CAB acts as an approver too;
- Change Control over the Sprint Backlog is delegated to the Product Owner, Scrum Team and Scrum Master and the regular Release Planning Team.
Using agile project methodologies means frequent releases. Testing can become a real pain. This concerns less the testing of new functionality, but rather the regression testing (checking if existing functionality has been affected by new release, repetitive). Automating regression tests is key. Test factory teams need to be involved early and based on the product backlog develop test cases need to be developed and automated.
Step 4: Integrating SCRUM- and ITIL-Roles
Scrum knows only three key roles: The Product Owner (‘voice of the customer’), Scrum Master (the facilitator) and the Scrum Team (the developers). ITIL knows many roles, but Service Owner, Change Manager, CAB and CSI Manager seem to be very relevant to me in this context.
- ITIL Service Owner and SCRUM Product Owner: If we talk about existing services, it makes sense that the two roles are incorporated in the same person. Both roles act as a voice of the customer and know the requirements side. On the software side, this is often represented by the Application Owner.
- Change Management: Scrum Master and Product Owner need to be part of the CAB if it comes to the release of a sprint. The Product Owner acts as CAB approver from a sprint backlog point of view.
- CSI Manager and Scrum Master: Continuos learning is an integral concept in Scrum: In sprint retrospective meetings, process improvements are identified. In the daily scrum meetings, impediments which hinder success are eliminated. This is all happening under Scrum Master responsibility. Structural improvements out of the Scrum process should be considered from overall organizational developement perspective and become part of the CSI register, therefore the Scrum Masters and the CSI Manager should liase on a regular base.
So I hope this gave you some ideas on how to bring the two worlds together. Scrum is not just for developing new products in an isolated world. It has become mainstream for tackling Service Design & Transition for existing Services. Finally, we talk here also about two worlds, which historically do not talk to each other. One the one hand the developer guys, on the other hand the operation guys. This is why we needs an integrated & practical approach on how to bring them together and finally a mutual understanding how both worlds work.
Don’t see it as a threat, see it as an opportunity.