Processes and People
This is the last blog of a 3 part series on Agile Service Management (ASM).
Processes are ways of working that allow someone or thing to let someone or thing get what they want. A supplier gets a request, some steps are performed and an outcome is achieved. It could be to fulfil a request or to pass data from one application to another, it all involves a process (es). Simple! Then why is it that many of our processes are so hard to complete, or are changed without consideration of the effects or are just simply ignored for the way someone thinks it should be done?
Maybe it is because our processes are not people centric. By people I am talking about the people that do them, create them and receive the outcome. Processes are not created by automation. Automation enables a process. So let’s get the people that want something and the people that need to provide that outcome together!
Wait a minute that sounds like Agile or lean! You know that way of working that value interactions and things that work over complex stuff. The Agile Manifesto values and principles are full of statements like this. The various flavours of Agile: Scrum, XP, TDD, BDD, etc. are all ways of creating things such that you resolve the problem of someone wanting something in a way that makes sense by giving them the minimum outcome and overtime making it better if really required.
Ah! I hear the naysayers yell but then ITSM processes get in the way. I challenge you to tell me where it says GET IN THE WAY! The ITSM I know and have practiced for over 20 years clearly says have a strategy, design against that strategy, test and deliver that strategy, see how it runs and then improve continuously. PDCA if you will. But focus on looking at the processes and combining them in a way that resolving things or building things make sense.
In my last two blogs ofAgileITSMand Agile Service Manager, I explored the concept of blending Agile and ITSM into one cohesive way of working. To be honest people have been doing this for years but sometimes you need a movement like DevOps to kick start the thinking again. So what would happen if you took the iterative sprint approach of Scrum and used it against ITSM processes?
Think about Resolution Management which is the conclusion of a request to provide or fix something. How would you take the processes of change, test, release, deploy, incident, problem and request and turn them into a sensible way of working? Resolution Management is a Value Stream. Mapping this stream would show the high-level phases from which you could look at time of doing, actual step time, effort, quality and accuracy, people and automation involved. Now plan you can see the issues. Great!
Iteratively this stream can be improved by the people involved. They create the user story, place it in a backlog of work and over time make things better, faster and safer for the process by removing wasteful activities or applying automation.
HINTs: treat everything as a person! Treat the giving of a piece of data from one thing to another as if two people were interacting. It will change the way you view feedback and performance. Also have just a few Indicators of Performance that are KEY to maing the process work each of which can be improved overtime.
Agile Process Owner
The Value Stream, be it resolution or onboarding or funding needs an owner. The Agile Process Owner is the person accountable for taking a way of working and making it better. They own the user stories and backlog, they help prioritise stories to be worked on, they resolve issues that the ScrumMaster or Agile Service Manager cannot and they act as the ambassador to the business and customers that AgileITSM is a great way of working.
The Agile Process Owner is also a mindset so it does not have to be a new role but could be your Product Owner or a business manager. They do need to be significant enough though to have impact on the work being performed to create, manage, improve and apply technology to processes.