Some of my recent blog posts have been on the theme of Improving your ITSM system in a release driven way.
I wrote four posts before pausing:
- A system for ranking enhancement requests by urgency and business benefit
- Implementing the enhancement request system in ServiceNow
- Some Scrum concepts
- Creating the Scrum records in ServiceNow
I paused because.. well my boss is making me work far too hard, but mainly because I wanted to wait until we were able to talk about the new Scrum functionality in our upcoming Berlin release.
Our Scrum functionality in Aspen is perfectly workable - but there are some really amazing enhancements in Berlin that I wanted to talk about and so had to wait.
Before diving into the new functionality in a future post I wanted to talk about the role of Product Owner and how important it is to have an engaged PO to work with throughout your ITSM enhancement project.
I wrote up some slides that you could use to help familiarise your Product Owners with the Scrum proce... Please feel free to download these and modify or redistribute them freely. They contain 2 images that I've borrowed from the Internet so please maintain the attribution for those.
Why you aren't going to succeed without a Product Owner
The role of Product Owner is absolutely critical to the success of your enhancement project. Of the three roles (Product Owner, Scrum master and Development team) it looks, at a first glance, that you could deliver enhancements to your ServiceNow instance without one.
But if you attempt to skip this part of the process and not find a Product Owner you will suffer in the following areas:
- You'll work on features that the business doesn't really care about. You could continually turn out really cool additions to your system that you think are great and get you loads of bragging rights on Twitter. But its likely the business will review your new features with a disinterested look and ask "but what about feature X that we discussed 6 weeks ago".
Without a Product Owner it's easy to go down dead-end routes and deliver features that are only interesting and useful to yourself, whilst the business remains dissatisfied. - You'll compromise on quality. All of the roles in Scrum are responsible for quality, but essentially the Product Owner will be "signing off" on your enhancements. If you are the only person that defines the work, develops the code and signs it all off who is going to make sure it's to an acceptable standard?
- It's a lot easier to get someone else to deal with the users 🙂 That sounds a little arrogant but with a large backlog of improvements it's a lot of work to be responsible for defining features, talking to the users and stakeholders as well as thinking about technical implementation. Divide the work up
Invest time in training your Product Owner
Being a Product Owner isn't a particulary easy task - they will need a full grasp of Scrum terminology and how to use the toolset in order to do their job properly. Spending time making them productive is worth the effort and should be done as early in the project as possible.
If you have multiple Products to work on (for example different stakeholders for IT, Facilities and HR who all use ServiceNow - or perhaps different stakeholders for Incident, Problem, Change and Config) it is likely that you'll pick up new Product Owners as you go along.
It's a really good idea to have a training deck to help them get started. I've included a Powerpoint presentation that you can use to brief your Product Owners and customise for your organisation.
You have chosen Scrum as the framework to deliver enhancements to your ITSM system (in a release driven way!). But why did you chose that methodology?
Scrum is a lightweight framework that is used to solve complex problems. You are using it because it uses an incremental, iterative approach to delivering the enhancements that your business wants.
Using this approach is the right choice because it's more predictable. You are able to give dates when features will be developed, tested and implemented. These dates are based on estimations and a degree of predictability is given as you estimate based on your previous experience.
Using Scrum controls risks as you are constantly in touch with the business (hence the Product Owner) and you are discussing features, progress and problems. Using a iterative approach you are able to detect when the project is hitting problems and you can correct them quickly.
This is in contrast to a "Waterfall" approach where all of the requirements are identified and documented before starting development. A waterfall approach to any software development project is problematic, but especially so for process enhancement.
Achieving process maturity isn't an activity that can be easily mapped out in advance - it is likely that you'll release a process and tools and improve as people adapt to the tool and process.
The Waterfall approach (as illustrated above) increases the time and risk involved in deploying a new enhancement and makes the assumption that requirements won't change between the original request and the deployment of the feature. Probably not that likely 🙂
This graphic, that illustrates the iterative and incremental approach of Scrum, contains some references that become apparent throughout the rest of the presentation. We use the slide here to hint that Scrum works by taking requirements, prioritising them and building a potentially releasable iteration of the product.
Your new Product Owners first need to be aware of the other roles involved in the process.
Product Owner
- Represents the voice of the customer or user
- Accountable for delivering value
- Responsible for the identification of features and then prioritising them against business objectives
- Ideally there is one Product Owner associated with the Scrum team
Scrum Master
- Facilitates the Scrum team and the Product Owner
- Removes impediments
- Ensures the Scrum process is followed
- Aids the Product Owner in maintaining the Product Backlog
Development Team
- Responsible for producing a potentially releasable iteration of software
- Responsible for quality
Having covered the roles involved in Scrum your Product Owner also needs to understand the various artefacts that she'll be working with. There are a few.
It's worth explaining the close relationship between Epics and Stories as there is a potential source of confusion.
Epics allow the Product Owner to define the "big chunks" of functionality required to deliver their enhancement to the business. They are used to map out the product and will be broken down into Stories (smaller chunks of functionality).
It's worth pointing out that we always end up planning Stories into Sprints and executing them (and not Epics)
A release could be one or many sprints. I write here that it is usually at least 2 because we'd like the Product Owner to have a chance to view the enhancement at the end of the first sprint and suggest improvements.
Good chance here to break out of the Powerpoint and show the Planning Board. There are some really great enhancements to the ServiceNow Scrum product that I'll be writing about soon.
Having covered the artefacts and shown the Product Owner where to find each one these graphics show the relationship between Products, Epics and Stories...
...and the Releases, Sprints and Stories.
Having introduced the Scrum artefacts you can now talk about the ceremonies that the Product Owner will be involved in.
Here is the crux of the presentation - How the Product Owner can bring value to the Scrum team and help them build and release enhancements.
The Product Owner should assume responsibility for features that the business requires and keeping those features sufficiently detailed and prioritisied.
Lastly - it is worth highlighting why it is worth the Product Owners time in learning the Scrum framework and investing time into the role of PO.
Being a Product Owner for the ITSM enhancement project means that they control the features from a priority and definition point of view.
They should also feel confident in the teams ability to estimate the effort involved in delivering the story.
The last slide deals with two common complaints from the business with regards to enhancements.
The answer to the question Why can't you make small changes faster? is simply that we can - however it is better to have a well ordered backlog of features. Just because an enhancement is small doesn't mean that it should be done before other work identified by the Product Owner as high priority.
Also, the Scrum process brings a element of quality. If we rush through small changes on a constant basis we'll end up compromising on the "definition of done" for a story which should involved testing and quality assurance
In answer to the question Why have you been sitting on this feature/defect for so long? it is simply a case of the Product Owner having not prioritised it at the top of their backlog.
By constantly reviewing the Product Backlog and ensuring that business requirements translate to a sufficiently detailed and prioritised story we can keep on delivering value to our stakeholders.
A Story being old and not implemented might suggest that either it isn't high priority enough or the underlying business requirements aren't being translated properly.
In summary
Having good Product Owners is essential to the success of your ITSM enhancement project. Feel free to use the attached slides to brief them and get them productive.
3 Comments
