My last couple of blog posts have been about Improving your ITSM system in a release driven way.
If you missed them go back and read Part 1 and Part 2
The aim of thinking in a release driven way is to make changes to your production system that are high quality and low risk. To make changes that are (demonstratably) tested and communicated well. The hardest part of making changes to an ITSM system is that we are really changing the process that people use - and people are a lot harder to change than technology.
Making continous changes in a non-structured way confuses the users of the system, especially when you ask new requirements of the user: New fields on the Incident form for example. People should be prepared that change is coming.
If you've been reading along, we previously discussed how to gather requirements from stakeholders - in my experience these people will be from different parts of the IT organisation, and also from the Business. My example use case in this article is that we get a request for a new HR process for onboarding employees. Another example would be Facilities needing a method for requesting cleaning services.
We'll also have ideas and suggestions from the users of the system - new tweaks or usability enhancements.
These all need to be logged, verified and prioritised. In my last post I showed a system that ServiceNow customers could deploy to get stakeholders to rank their enhancement requests by thinking about the Urgency and the Benefit.
As a sidenote - I had some feedback that the method of ranking was confusing for some. The idea of plotting enhancements into one of four quadrants (Do Now, Do Next, Do Later, Do at all?) wasn't intuiative for those that preferred a simple ranking system.
Also - the term "Do Now" suggested to some people that those enhancements would be worked on straight away, which might not necessarily be the case. The term "Do Now" simply means that in relative terms to the other features these should considered before those placed in the other quadrants. I only mention it to ask you to vet it with your stakeholders before deploying in your organisation.
It's just an improvement on a flat list of enhancement requests that have to be ranked in some other way. If your stakeholders find the concept of "Do When?" confusing you could try to use 4 quadrants with no labelling and just refer to the top right quadrant as those enhancements that we need to look at first.
Now that we have a list of enhancements that the business would like to see implemented in our system we can start to think about how to get these into production - the detailed requirements, development, testing and deployment of the new features.
The Product Owners meeting
In the first 2 posts in this series we gave stakeholders a process for logging and prioritising new features. Now it's time to get them together and agree on the features that we should start to work on first. Further into this article we refer these people as Product Owners - they are responsible for choosing which features are more important than others.
Using the Benefit/Urgency chart you can now get Product Owners together and ask them to start choosing which requests should be worked on in your first release.
I'm making the assumption that there is one team that will be working on your ITSM system, with multiple Product Owners requesting new features. In this case you can see that agreement, compromise and a view of "the bigger picture" is needed to make sure that everyone agrees what requests are included.
Having a system that fairly ranks requests really helps here - it gives a much fairer view of the overall benefit/urgency of all of the features relative to each other.
My preferred methodology for developing improvements is Scrum.
"Hang on.. isn't Scrum (a) evil, (b) unreliable, (c) incompatible with ITIL/ITSM???"
Anticipating the inevitable outcry from Scrum detractors, let me explain my reasoning for choosing it as our development methodology.
It is the en vogue thing to detract Scrum as a system that is fundamentally at odds with ITIL or ITSM. It's almost as popular as calling for a "burn your ITIL books" day.
Scrum is the process that we'll use to define, develop and test the features that will eventually be released into our production environment. The anti-Scrum brigade will have you believe that we'll be developing on production environments running bleeding edge code.
Nothing could be further from the truth - if you develop on your production ITSM environment you deserve all that you get, and when it breaks feel free to keep both pieces 🙂
We absolutely aren't going to advocate that we take requirements from users and build these on our live systems. Or that we'll just ignore the Change and Release Management processes because we're using Scrum. It's the methodology we are going to use to define requirements, build, document and test these in our non-production environment before going through the standard process for releasing into our live system.
Brief history of Scrum
Scrum (or if you prefer SCRUM) finds its roots in a proposed Japanese manufacturing practice that wanted to find a way to increase flexibility and speed of manufacturing at the cost of quality and design. The authors named the proposed practice the "rugby" approach due to the concept of a cross-functional team that passed the ball (the product) between themselves during the manufacturing process.
The concept was taken into software engineering and made popular between 1995 and 2001, culminating in the publication of the book "Agile with Scrum".
Following Scrum methodology allows us to deliver releases with the features that the Product Owners want to see, complete with testing and documentation. Product Owners will have an opportunity to see the progress that we're making and be able to choose when future features will be implemented, according to the amount of resource that we have to use.
The potential benefits of Scrum
Using Scrum as a development methodology means that the end result that we deliver will be on time, to the correct level of quality (via testing) and with the features that the users wanted to see.
We do this by breaking down requirements into small chunks and estimating how long each feature will take. This is hard in the beginning but after a few releases you'll have a feel for how big certain tasks are to complete.
By scoring each chunk of work we can predict how much effort is involved and advise our Product Owners of a release date. If they feel the release date is too far away we can always defer certain features to a later release.
As we work on each chunk of work we complete all of the development, testing and documentation for that feature before calling it "done".
The result should be a system that has all of the features that the Product Owner agreed on, with a higher level of quality than a system where we write tests at the end (or more likely don't write tests as it's too hard to do)
How Scrum fits in with ITSM deployments
Scrum introduces some concepts that we'll use when planning our enhancements to our system. We need to look at some roles, some objects and some practices. First of all the roles..
The Product Owner(s)
In our Release methodology we need people to act as Product Owners. Ideally we'd like just one to deal with, but reality suggests that your organisations ITSM system is going to be used by multiple parts of the Business, or different Application owners, or different regions with their own priorities.
It's likely that we will have to deal with multiple Product Owners - Meeting with them to decide which features (Stories) we need and when they'll be scheduled (Release Backlog).
The Scrum-master
If you are responsible for the maintenance of your system I envision you to be the Scrum-master. You deal with the Product Owners and you are responsible for getting the development and testing completed ready for your release.
The Development team
Hopefully this isn't also you!! Otherwise you are going to be a busy person. The development team are responsible for configuration of the system and writing tests and documentation. If you are running the system on your own you will be taking on both the Scrum-master and Development team role, but don't panic - this methodology will still work for you.
Those were the roles, now - describing the objects..
Stories and Epics
Rather than try and write pages and pages of functional requirements to describe the feature that the business has requested we break down the list of requirements into Stories.
My test example is a Process Enhancement Request submitted by the HR Director for a new employee on-boarding system. The Product Owners reviewed and ranked the request, and all agreed that this should be put into the first release.
We could sit down with the HR Director and try and write all of the specifications up-front, but instead we are going to write the requirements as Stories.
Example stories for this request would be:
- As the HR Director I should be able to review all open employee onboarding processes in a dashboard
- As a head of department I should be forced to approve new employee requests for my department
- As an Asset Manager I should be assigned a task to add the new employees computer into the CMDB
- As an IT manager I should be assigned a task to create network accounts for the new employee
- As an employee on-boarding form I should make the "line manager" field mandatory
Stories describe individual features that need to be present for the request to be implemented successfully. When people have new ideas for the feature ("Hey - lets assign the Facilities manager a task to get the employees desk ready") this is represented as a new story in the Product Backlog.
To group stories together we create an Epic named "Employee On-boarding process". An Epic is a collection of stories, or perhaps an Epic is a requirement that has multiple features and needs to be broken down into individual stories at some point.
Each story should be assigned a number of points (We'll go into this in detail in a future post) that determines how complex this feature is. If we are working in a large team developing for our ITSM system we would assign the story to an individual.
There's no limit on how many Stories we'd need to fully describe a Enhancement request - it could be as few as one, or as many as 100 - it really depends on how complex the feature is.
We'd also need more information in the story - for example with the first example story ("As the HR Director I should be able to review all open employee onboarding processes in a dashboard") we'd need to work out exactly what information she'd want in that dashboard. A story needs a short description, as above, but could also contain diagrams, examples, sketches, screenshots etc.
The Product Backlog
The Product Backlog is a list of all of the Stories that we've written. I only explained one example request above - the employee onboarding system - which contains a number of stories. The Product Backlog contains all of the stories for all of the requests, so you can imagine this might be a long list.
Some of the stories will be assigned to a Release and to a Sprint within that Release.
Maintaining the Product Backlog is the responsibility of the Product Owner(s) that asked for the Enhancement Request. It may be that you end up writing the stories, but the Product Backlog of Stories (maybe grouped into Epics) is the complete list of features that we are considering. We're also happy for those Product Owners to continually add Stories to the Product Backlog if they have new ideas or requirements.
The Release and Release Backlog
We are talking about adding new features to our ITSM system in a release driven way. A Release describes all of the effort involved in getting the system updated successfully, including all of the training of staff, testing, documentation and development.
You can look at your Release schedule in a few ways - either commit to releasing on a regular basis - every month or every quarter - or based on a set number of features, in which case you won't know when you'll be releasing until you've worked out the effort involved.
I'd recommend naming your releases so that everyone has a focus on what we are working on at a point in time. A good method is to use alphabetical names - (Amber, Brandy etc) which aren't tied to exact dates.
You could also consider working exclusively on new features in a release, or concentrating on bugs or enhancements to existing features.
In either case, we need to maintain a Release Backlog which describes how many Stories we are going to complete in that release. This could be flexible... the Product Owner could ask to add new stories to the release, but they would have to appreciate that the release would be delayed due to the extra effort.
Having Stakeholders add new requirements to a project is something that I'm sure that anyone reading this article would be familiar with. Having a defined Release Backlog with a set of Stories describing the features that we committed to is a real asset when negotiating the addition of work to be added to a release.
The Sprint and Sprint Backlog
The Sprint defines the number of stories that we are going to work on for the next, say 2 weeks. A Sprint is a timeboxed period of activity containing a number of Stories.
Within a release you would want to have at least 2 sprints so that you could review the feature list with the Product Owners to make sure that you are on track.
The Sprint Backlog defines which features people are working on at a given time.
As we draw closer to the end of the Release - when you feel that you are ready to start User Acceptance Testing - you might want to have a Sprint purely for UAT where you drag people from the business to test your new enhancement. During that UAT Sprint you'll only fix issues that testers find that would impact the quality of the release.
The Sprint Backlog contains all of the stories that we've scheduled to complete within that Sprint.
To consider a Story as Done we should be writing the code, writing the documentation for that feature and writing the User Acceptance Testing. The end result is that by the time the Sprint has finished we already have the features documented, tested within the Development Team and ready for User Acceptance Testing from the Business.
This practice of writing the tests alongside the code and making the writing of documentation a condition of declaring the feature as "done" is fundamental to Scrum. It avoids the approach of spending a long time writing requirements, then writing the code and then the tests in a serial fashion. When we develop features for our system we are testing as we go - inviting feedback from users and stakeholders early on in the form of UAT and documentation. We're finding new requirements early and adding them to the Product Backlog asking the Product Owners to tell us when they want them implemented.
In summary...
This has been a brief rush around Scrum without really spending any time in detail on how we should be writing Stories or managing the Sprint. Or writing the tests or the documentation.
There's a load more that I have to cover in this series of posts. Next time I'll talk about the ServiceNow implementation of Scrum and how you can create your Product, Epics, Stories and Releases.
Thanks for reading so far. I'd love some feedback in the comments if you are considering adopting a release driven approach to your ITSM environment.
2 Comments
