Today I want to share some practical advice on how Agile and in particular Scrum can help to drive IT Service Management initiatives forward. Why? Agile delivers results and creates value early. Furthermore it continuously makes sure that these results are aligned to the overall vision. And last but not least: If you do it right, it’s incredibly motivating for the people being involved in it. Motivation and the resulting morale are multipliers for performance – never underestimate this.
Let’s face today’s reality
For many companies, the journey of IT Service Management has been a journey of disappointment. Most ITSM projects fail; they do not demonstrate added value and typically organizations falls back to their original status quo shortly after. Insufficient management commitment, no sense of urgency, resistance to change – we all know these often-mentioned reasons of failure. For me, these reasons are symptoms of something else, which already starts with asking the wrong questions right at the beginning of an ITSM initiative. One typical example would be: ‘Which ITIL process should we implement next?‘. Instead, the right question should be: ‚What you actually want to achieve in long-term (vision)?‘ and translating that into measurable goals and defining how you want to achieve these goals. These goals should be linked to value creation, which means: Increasing ROI and making customers more satisfied. If ITSM cannot make this link, ITSM doesn’t deliver value. Implementing an ITSM process (and its underpinning process roles, organization, and process governance) has no value in itself, but it might be something on the way to create value. There are many other means to improve IT Services and achieve value, you just need to think out of the process-box.
Scrum – get it done
Scrum provides a truly top-down approach, which translates vision into value-creating user stories; these user stories are implemented in iterative sprints, continuously delivering results and keeping the momentum. I call this CSI 2.0, because in my experience it finally brings the traditional CSI approach down to earth, something that works in practice.
Originally known for Software Development, Scrum can be easily used for any other initiatives. It is a suitable approach if you need continuous customer engagement and if the plan is not 100% clear from the beginning,
Instead of beating around the bush with more theory, it’s better to give you a hands-on example how this would work in practice.
(If you just want to organize you daily work with Scrum and something to start with, you also can skip steps 1-4)
1. Develop the Vision
This is the starting point, the long term goal you want to achieve. A scrum initiative without a clear vision is already lost. Applied to ITSM, a good example would be:
‚We give our customers full transparency what our IT Service are, what they cost and how they can be ordered.‘
2. Get the Backlog ready: Development of Themes, Epics and User Stories
Derived from the vision, User Stories define a desired end state and follow a certain structure, which could be for out ITSM example:
‚As a customer, I want at any time go to the the website of my IT Service provider, view the IT Service Offerings and order them immediately, so that I am supported in my daily work in an optimal way.‘
As this is a rather big, unrefined user story, we would call this an Epic, which does not fit into one sprint an therefore needs to be further broken down into smaller user stories and later on into workable Tasks. Some broken-down user story examples:
‚As a Service Catalogue Manager or Service Owner I want to have an idea how IT Services should be described on high-level (Design Patterns), so that I….’ or
‘As a Service Level Manager I want to establish a Service Level Management around the Service Catalogue so that it is ensured that the provided service warranty levels and price meets the customer’s expectations’.
Try to think also out of the ITIL-box, user stories might relate to culture, service excellence or whatever else that is needed to deliver the vision. On top, you might structure these user stories along Themes. In this example, themes could be ‘Service Catalogue Management’ and for sure ‘Service Level Management’.
3. Prioritization of User Stories
After this, you end up with a big list of user stories. Which ones do you want to implement first? The ones that give most value, this is the clear answer of Scrum. There are also additional criteria. One of them is dependency – in our example this means that you have first to be clear about the IT service design patterns, before actually describing the IT services. An ITSM process and capability assessment can give you additional input where there is action needed. And by the way – it is the customer (in Scrum represented by the Product Owner role) which at the end defines the priority
4. Estimation of User Stories
Somehow the hardest part. In Scrum, the implementation of User Stories is never estimated in absolute terms, but in relative terms called Story Points. For this, you take a user story that is relatively small in size and for which the team knows exactly what needs is the effort (small complexity), e.g. ‘Describing the e-Mail Service’. This story is given 1 story point. All other user stories are now estimated relative to this one user story (e.g. ‘5’ if it is 5 times more complex to implement). Planning poker is the preferred method for estimation, as it gives the most accurate estimates.
5. Sprint Planning
Given a Sprint length of e.g. 3 weeks, the ITSM team now estimates how many user stories they can complete in the next sprint. User Stories with highest priority (step 4) are chosen first. If you sum up the story points of all user stories for this sprint, this gives you the velocity of the ITSM team, a metric for the team-performance, which should get better and better over time. At this step, the user stories also might be further broken down into Tasks. For example ‘Get together with the e-Mail Service Owner do describe the IT Service’
6. Sprint Execution including Daily Standup
The user stories that have been previously agreed to be part of the sprint are now developed by the team. The goal is, that when the sprint ends (e.g. after 3 weeks), all sprint deliverables are done. Again referring to our example, this would be in the first sprint rather developing the IT Service pattern, later on the IT Service descriptions themselves.
During the Sprint, Daily Standups are performed (15 minutes max), where each team member reports on what he has done, what he will do and if there are any impediments that needs to be addressed. Everything is made transparent in the Scrumboard, which gives you at any time a status on what has been done and what has to be done.
7. Sprint Review & Retrospective
In the Sprint Review the sprint deliverables are formally accepted. For our examples this could be the concrete Service descriptions that are signed off.
In the following Sprint Retrospective a lessons learned is performed to identify improvements for the next sprint. In my experience the retro is often skipped in practice, but it’s so important to make improvements in the team performance.
Grooming means primarily cleaning up the backlog (the sum of all user stories). Completed User Stories are taken out and new User Stories are developed. In our example this could mean, that after the first sprint, when the Service Catalogue structure has been agreed, new user stories are developed to actually describe concrete services, e.g. the 10 most important IT Services for the next sprint. This actually leads us again to step 5, where the next sprint is planned.
Benefits & Challenges
There are a couple of differences compared to the ‘traditional’ waterfall way, which can bring some significant benefits:
- Continuous delivery of value and feedback: Iterative processes enable the continuous delivery of value and feedback of customer which allow early adoption.
- Customer centric—Emphasis on business value and having a collaborative approach to stakeholders ensures a customer-oriented framework
- No Plan – do – stop: Many ITSM projects fail, because organizations fall back after the project is ‘finished’. If you work with an open backlog, Scrum allows (similar to CSI) continuous alignment and realignment to what you want to achieve.
- Transparency: All information indicators such as a Scrumboard and Sprint Burndown Chart are shared, leading to a transparent and open work environment
- Motivation and resulting performance: Something I mentioned already in the beginning.
Although Scrum is easy to understand, it is difficult to implement. Scrum promotes self-organization and this requires a high level of personal discipline and maturity. In the beginning of a Scrum initiative, failure is normal and important (to improve), but people need to be able to go through that. Also, an agile approach like Scrum is not suitable, if things are 100% clear from the beginning and no adoption and feedback needed on the way.
I hope you enjoyed my today’s blog. My recommendation: Just try it and an start an ITSM initiative the scrum-way. Start with a vision that is clear and agreed by everyone, build user stories around it and implement them in sprint. ITIL can give you some good guidance, how the structure and content of the user stories could look like – but also look beyond that.