MENU

Integrating Agile and ITSM

Posted on by Allgemein, IT Governance, ITIL, Uncategorized

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:

Scrum & ITIL: A perfect fit on high level

Scrum & ITIL: A perfect fit on high level

So, let’s quickly walk through the SCRUM process and you will immediately understand what this buzz is all about:

  1. Service Design: Starting from the approved business case, requirements are gathered in form of user stories & prioritized. The result is the prioritized product backlog.
  2. 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.

Including warranty requirements in the product and sprint backlog planning

Including warranty requirements in the product and sprint backlog planning

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:

How much change control do you need? Balancing flexibility & stability through delegation models and achieving a controlled service environment

How much change control do you need? Balancing flexibility & stability through delegation models and achieving a controlled service environment

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.

Test Automation

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.

12 Antworten auf Integrating Agile and ITSM

    • Hi Prezmek,
      Many thanks for your feedback, people like you that have a deep understanding of both worlds are very precious in these times 🙂
      I agree with most of your points and Yes, SCRUM in itself is Change Control (as it is also an important concept in ITIL). If it comes to the integration into your ITSM processes, I see some challenges in your approach. I wouldn’t handle everything from user story to sprint deployment within the same RfC. They are different change control objects (of course linked to each other). The spring backlog is a subset of the product backlog, which might go into production as release (or not). Applying the right delegation model (most of it under Product Owner change control) and including ITSM roles at the right point in time is imho important. At the end it’s very individual (every company having it’s own balance between flexibility and stability).
      Also, one of the other key points of my blog is including operational service requirements into an early stage of service design (-> product backlog). Of course ITIL is not only operations, it’s in fact very holistic, but this is where ITIL can complement SCRUM, actually taking this into consideration already in service design. So I see it rather as an umbrella you can have around your scrum project.

  1. Ian Clayton sagt:

    Alex

    Excellent article – thank you. IK agree that Agile is an overlay and introduces different gearing (rates of change) for specific scenarios, presently not considered within ITIL beyond the priority/impact discussion. Some questions for you and others to ponder.

    1) How would you incorporate the design of the service experience into both the requirements side and the support side?

    2) How might you factor in the cost of support – total – break/fix and general requests, and offer comparisons with the speed of the agile part of the process?

    3) This assumes a service lifecycle backbone, what about agile and a continuous improvement system, and the situation where an organization does not have a formalized ’service lifecycle‘ but can identify and begin to define a problem and its impact?

    4) How could you reconcile the concepts of sprints and service plans, and wallboards (sprint task status) and the change schedule?

    • Ian,
      Thanks for your feedback. I try to answer:
      1) In scrum initiatives, the design is captured in the prioritized backlog – through user stories. This should include service & warranty requirements, e.g. ‚As a I would like to have service xy available 99% so that I …..‘. A thing that usually get’s forgotten (the SW guys focus on utility), also have a look at the 2nd image. Agile and ITSM complement here really well here and some DevOps ideas go into the same direction
      2) support cost is not part of the model overlay (there is no Ops part), but generally speaking, the better the Design&Transition part, the less cost on Ops side. At the end this is a balancing act / optimization problem
      3) If you look at agile methods – like scrum – they are in itself a continuos improvement system, they promote continuos PDCA with open end. the CSI approach could be extended or replaced by SCRUM, there a already many good practical cases around
      4) Service plans (e.g. part of a prioritized backlog) could be implemented through sprints. Change Schedule: I don’t see a direct link to the sprint board, however the sprint review result should be put under change conrol, as this could be potentially result in a release

  2. Rattan Muradia sagt:

    Thank you for the diagrams as they are very helpful. My experience has seen software being developed in iterations (releases) with each iteration including multiple sprints and delivering a usable product to users. I would like to modify your diagram to show multiple iterations and also how operations provides feedback to the product backlog after each rollout. Are you willing to share the original (if it is PowerPoint or Visio)?
    regards
    Rattan
    Ottawa, Canada

  3. Tess Bui sagt:

    Hello Alex,

    In what you’ve described above, is there a role for the „traditional“ Change Manager to play in Dev Ops? It seems that the Application Owner from Operations and the Product Owner from SCRUM should be the main roles to approve a Change Request, since they clearly understand the changes, their impacts on production, risks and values to the users.

    Our „traditional“ Change managers role was to really review the request and make sure all the documentation requirements are there, but in reality do not have the knowledge or bandwidth to join all the Sprint meetings and work closely with Development for this Leaner model of the Change Management process.

    So, in my view, they will not have a role to play in this process, or have I missed something?

    Thanks,
    Tess

  4. Ravi Velamuri sagt:

    Just wondering, that is the best methodology to do Knowledge transition to new supplier in Agile ITSM world? the transition should be rapid but effective to ensure no disruption to the BAU activities in the production.

  5. I think there are some misinterpretations regarding Agile in general and Scrum in particular. For instance:

    „SCRUM is a specific way to deliver projects, it’s an iterative, adaptive and incremental approach to project management.“ No, Scrum is first and foremost about products, it is not about projects.

    Directly taken from the Scrum Guide: „Each Sprint may be considered a project with no more than a one-month horizon. Like projects, Sprints are used to accomplish something.“ [http://www.scrumguides.org/scrum-guide.html#events-sprint] If anything Sprints are like projects. Again quoted from the Scrum Guide, this time the very first sentence: „Scrum is a framework for developing and sustaining complex products.“ [http://www.scrumguides.org/scrum-guide.html#purpose] There we have it: it is about products, about development and sustainment at that! What’s the value of a product that is not working properly, in the short term and in the in the long term?

    Which brings us to the next point: „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.“ Agile is all about value. For instance, ‚Agile Hero‘ Alistair Cockburn defines it as „the early delivery of business value“ [http://blog.adform.com/adform/q-a-with-agile-hero-alistair-cockburn/] — see above.

    „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).“ Well, no. Scrum and Agile are neither about quality gates nor about gatekeepers. Its about: Collaborate, Deliver, Reflect, Improve. [http://a.cockburn.us/3545] The Product Owner is part of the Scrum Team. Thus, she works hand in hand with the development team. She is not a gatekeeper. She collaborates with the development team. I’ve met many people who state that gatekeepers and quality gates are for the purpose of a common goal. However, in real life people having this role quickly act as, well, gatekeepers and quality gates. Thus, they hinder instead of enable other people who have to „pass“ those gates. A Product Owner who acts as gatekeeper would be a poor Product Owner.

    „Test factory teams need to be involved early and based on the product backlog develop test cases need to be developed and automated.“ Agile is about self-managing, cross-functional teams [https://less.works/less/structure/teams.html]. There are no test factory teams or the like.

    • Hi Martin, thanks for your feedback, good input and I agree with the most. The third one I would challenge: Although I agree that all is about delivering value (a statement which is in itself always true), the issue is in practice that there is a tendency on Dev-Side to only focus on the functional stuff and especially if there is time pressure, the warranty-aspects of value are postponed (It’s considered as something that the Ops People will take care of in a later stage). This is also something the DevOps movement tries to adress.

      • Hi Alex,

        thanks for your swift answer.

        „DevOps […] is a culture, movement or practice that emphasizes the collaboration and communication of both software developers and other information-technology (IT) professionals while automating the process of software delivery and infrastructure changes.“ [https://en.wikipedia.org/wiki/DevOps]

        I agree, implementing DevOps is a (transitional) solution. Like the above mentioned Product Owner, DevOps should be about collaboration. It’s about people and culture — not about processes and tools.

        Actually, integrating ‚ops people‘ into the development team just consequently translate ‚cross-functionality‘ into action. The more cross-functional a ‚development‘ team is, the better.

        With this in mind, DevOps — in the narrower sense; cf. above — is a logical step. A single step as part of a promising journey in the direction of a true agile organisation.

        Kind regards,

        Martin

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

Ähnliche Beiträge

« »