This is the first of a 3 part series on Agile Service Management (ASM).
IT Service Management (ITSM) has been around for almost 27 years: the capability of taking a process, creating a high-level view by collaborating with others and then iteratively introducing each step until fully introduced. For me, a process is a way of work: buying something, onboarding a new employee, resolving an incident are all examples. What we missed was someone to then continue the process as part of their job; an accountable person. Yes, I know that we had many roles defined but, in my experience, once a process was defined, the review and improvement of that process in short, iterative timeframes rarely occurred.
Therein we missed a trick. We should have treated the creation of a process with the same mindset that we use to create products based on various agile techniques. We should have created a way of ensuring these questions were always being addressed:
- Who does what when?
- How do they know they are doing good or not?
- How can they improve?
- Why are they doing this to begin with?
- Is there anything we can automate or use technology to help us?
- If we are doing this now, what is our current situation and if we did something different, would it matter? To whom?
ITSM is collaborative. Sometimes though, to get that collaboration you have to adopt and adapt not just the ITSM books but also the learning from other movements, such as Agile or Lean. You get Agile Service Management (ASM).
ASM ramps up the capabilities of teams that need to create, manage and improve the value streams associated with using or managing technology. ASM completes the cycle of idea to realisation that some Agile Dev/PMO teams want, or the Service Management improvement aspects that OPS and service partners need. ASM helps coach that improvement.
Agile Service Management suggests 2 new roles, not 2 new people in your organisation necessarily, but at least that someone should have the accountability for:
- Working hand in hand with the PMO or Product Owner daily
- Looking at a list of actions that must be performed to improve a process on a daily basis
- Converting these actions into value-oriented user stories
- Collaborating with others to ensure these actions are completed against an agreed understanding of DONE
- Looking at ways to make the process even better over time and against cost/benefit
- Instilling agile thinking into the management of IT services
- Helping the Team adhere to Scrum practices and rules
- Removing impediments whenever possible
- Ensuring that for a sprint, the right people or other resources are available
- Serving as a facilitator, educator, protector and coach
Lots to do! The DevOps institute and the Scrum Alliance therefore have suggested that if people learn the basics of Agile/Scrum and ITSM in a blended manner then the roles of Agile Process Owner (APO) and Agile Service Manager (ASM) could be introduced. The APO would have a strong partnership with the Product Owner and the ASM would pair with the ScrumMaster. The processes of how to do work and the technology required would now be readily available for the teams doing the work. Best of all, they would work together to make the processes better and share that knowledge across the organisation.
How these two roles work and coordinate work, feedback, interactions with others and sustaining improvement will be discussed in the next two parts of this blog over the rest of this week. I will also give you several examples of how we have applied the roles to help teams and organisations.
If you can’t wait to learn more, or interested in becoming a Certified Agile Process Owner or Agile Service Manager, then look no further than Ranger4 by visiting our training page here.