In our most recent blog, we introduced Agile and looked at how an Agile approach to IT service management (ITSM) can deliver real benefits.
If you purchase Certified Agile Service Manager training from ITSM Zone, you get a 30 minute conversation with any of our mentors for free - to help you get the maximum value from your training and identify next steps.
Thank you to all of our mentors who contributed to this article.
Agile works well with other tools including ITIL. ITIL has to adapt to an Agile environment, as Agile allows IT to deliver business requirements iteratively at a pace that the business requires.
I like that it (Agile) meets the needs of the business today. Especially in a digital environment. The business cannot wait weeks for improvements and delivery of new services. They need it NOW! Agile practices allow IT to do that. It’s the idea of fail early, fail fast, fail often. But also fix fast.
On the other hand, DevOps is a organisational construct that brings Development and Operations together during the design and transition stages of the service lifecycle. It continues into the operational stage where the onus is not on operations to fix up a mess but the DevOps team together to make sure that the service delivered is operational and supported on the live environment and meeting the desired outcomes. It gets over the 'dead cat' syndrome. Agile is a method of delivery that allows the DevOps team to delivery iteratively and faster than traditional approaches.
Unfortunately, Agile is very badly understood and implemented in most companies, so it becomes just another fad – another marketing word.
Basically, Agile is common sense (in its philosophy): with the big direction in mind, focus on one step at a time and adapt the detailed plan as you go along. It brings more motivation as people can see progress and can progressively clarify all the elements of a projects which are difficult to conceptualize at the beginning.
Agile is in fact a "philosophy", so it relates with every possible framework in the sense that it helps to interpret any framework in a more pragmatic and realistic way instead of sticking to the "letter" of the framework.
An agile service manager has exactly the same basic objectives as a non-agile service manager. That is to be effective, efficient, deliver value etc. etc. Frameworks such as ITIL identify key processes (and process steps) that provide needed outcomes. These basic steps do not change (e.g. find a root cause through RCA) so it will not affect the use of e.g. ITIL per se neither will it directly affect tools, e.g. service desk. I see Agile service management as being ‘above’ frameworks and tools and being a way of doing things within the tool/framework boundaries but, in a better (more agile) way. It is more a mind-set change (soft) than a structural change. You will still have SLAs! As it is more a mindset of been agile it is only limited by the ’masters’ imagination. I have not used it myself, only studied from close in.
Agile can make operations/service people more aware of the need to be effective and efficient. As with all ‘softer’ improvements the agility must be focused positively and not be allowed to be a by-pass for structure and responsibility – e.g. adequate documentation cannot be described as ‘waste’.
As DevOps is essentially an organisational change away from command and control to matrix management (big challenge is getting line managers to relinquish controls) which should make actions more efficient. Agile is the way things are done within DevOps to eliminate waste.
Where organisations are looking to adopt principles which would first appear to be at odds with the rigid structure of ITSM (e.g. Agile, DevOps), then I can see there might be a need to align the fluid “agile” world with the Service Management world. This would be particularly true of Service Catalogue, Change Management, Incident Management, Service Transition and Problem Management.
I must admit though, whilst it is an issue, most organisation just adapt their processes and refine them accordingly.
IT Service Management has historically been focussed around the ITIL and COBIT frameworks, with set processes defining a way to approach different areas within IT. For many organisations, this still works due to the way that IT is delivered and supported.
However, there are more and more organisations embracing Lean thinking, ensuring that they the maximise value with less resource; do more with less. If being driven as an organisational approach, this quite rightly expects IT to embrace this thinking as well. There is also a growing swell of organisations picking up the DevOps approach to delivery and support, using Agile methodologies to deliver projects such as Scrum or using Kanban practices to help manage workflow. Some are using some or part of these “agile” approaches, while others are starting to embrace them all. And this is where Service Management can get left behind.
All of the above agile approaches enable delivery of “just enough”, thereby speeding delivery and keeping the organisation nimble enough to turn as the market demands. Agile Service Management allows for the development and management of processes that enable just enough control around the delivery and support of services. It should be seen as a way of understanding the lean and agile approaches being used within the development and project delivery arenas while also complimenting existing Service Management concepts to ensure that the operational management aspect of IT does not become the millstone around IT’s neck, dragging it down as development and project delivery deliver at speeds required by th
e wider business.
It was more than a decade back that I introduced and succeeded in Agile methodologies in a key project.
Appreciating the concept of evolving requirements, I ensured that the key vision (read principle business requirement) of the project is accepted & sealed by all key stakeholders. The timeline and cost of deriving the first skeletal but business usable prototype was also agreed. I adopted a subset of organisation policies & procedures for project execution and signed off a set with the QA team.
I selected a team of young, enterprising and professionally matured members. I turned myself from Manager to Coach for my team and Crusader for my organisation. My first team meeting, followed by a workshop, addressed & included Development, Operations and Quality and the entire project evolved around that.
During the lifetime of the project, we realised the value of Agile is not just its processes; rather the behavioural transformation in working with a Vision, in co-ordination & mutual respect; concern for the waste, transparency, social skills & communication, and above all - the individual ownership.
While the customer got a product assuring a better way to do their business; we have got a team granting us a better way of executing projects. We received accolades for both.
Agile service management incorporates the application and integration of agile thinking into service management processes and process design projects. Agile thinking improves IT effectiveness and efficiency and enables IT to continue to deliver value in the face of changing requirements. It is a great compliment to the Certified Scrum Master activities. In fact they are very similar but with a different focus.
DevOps and Agile also complement each other to deploy working functionality into production faster. DevOps is viewed as extending Agile principles and values through operations to reduce the friction in delivering value to the end user, ultimately increasing business agility.
The fact that the reality of a requirement is not always seen or experienced until it’s built, can completely throw a project off the rails when using waterfall methods, so I think Agile’s flexibility makes it easier to deal with frequent business requirement changes and also help a client experience the realism of their choices in a more positive way.
It’s very engaging and in the moment and because you’re working with smaller iterations it’s not so overwhelming. The end-game is still known but bite-size pieces makes the project easier to digest and also less risk of ultimate failure because you can fail fast, fix fast and learn fast. There’s no major disaster at the final curtain call of a ‘one-flow, one-chance’ project.
I like the idea of the ‘thinking on your feet’ and harnessing collaborative thought and experiences from all levels of authority and roles. But the fast decision making is not necessarily everyone’s cup of tea. There are still many organisations that tend to deliberate or procrastinate over issues for a prolonged period or only take decisions by a committee. For some, Agile is a bit like watching the Road Runner and Coyote cartoon. I think Agile can improve in showing greater connection to techniques to the pathway in assisting the slow thinkers in moving to becoming more agile and avoid analysis paralysis.
I think the DevOps and Agile work well together in facilitating the exchange of ideas and expertise, advocating value, group collaboration on impactful events. It’s great seeing people nod their heads in a stand up or if you are shaking your head, the experience is one of trust to be the naysayer or play the devil’s advocate. It’s also pretty cool to know you’re a part of that. Experience that inspires trust. With the two it’s connecting people with people and creating the experience.
The fluidity of process is key in the new digital age. Still, I think not many people know how to interact and use difference frameworks in a cohesive manner. Agile can absolutely be used in conjunction with other frameworks, but I am not 100% sure the IT industry (especially core ITIL practitioners) are letting it.
I think the first point the integration and interoperability of multiple frameworks to suit different organisations or even departments is the strength of Agile, but we as an industry are unfortunately lacking understanding.
For example, DevOps and agile to me are very complimentary. Understanding your business, delivering to the business and integrating with the business are and should be key objectives of any IT organisation, bot h DevOps and Agile enable this.
Other frameworks do also like ITIL, but the lack of understanding at implementation have created a potential monster, which is going to be bypassed in the near future, unless it is re-invented.
Using DevOps and Agile together will reap significant business benefits, save rework, enhance the customer experience and drive business growth through cost alignment, enabling investment to be in the right place. We as an organisation really want and need to move in this direction in order to align ourselves closer to our customers.
IT needs to be fast, highly responsive and yet conservative and secure to maintain the stability at the same time as we support our organization as good as possible. ITSM is really, really good at the second part, to keep things planned, secure, predictable and optimized. However there is a hole with regards to the first part, the being fast and responsive. Our world today changes at an unbelievable pace, with things such as BOYD, IoT and the whole digitalization going on we need to get better at this. Being agile means being quick and learning to focus on what is most important first. Also, the agile manifesto brings a smooth methodology for the construction work, something that is missi
ng in ITSM.
Being a service manager today means that you need to be on your toes, I firmly believe that being agile will help you master the first part of the difficult equation, "move fast" and since most of us are already mastering, or close to mastering "keep status quo", this is where we need to put our efforts to stay in the game.
I especially like the construction support to make our development teams faster and still maintain control. I also like the parallel between a user story (SCRUM) and a Change Request (ITSM), I never really liked working in projects with current service, only new ones, since we tend to work too much time thus missing important changes in the real world. The agile addition to ITSM/service management is effectively closing the GAP between the first and the last CAB meeting. I have seen too many organizations struggle in this exact spot, wasting a lot of time, which in my book means that the CASM role will solve a very real, and for IT devastating, problem.
However, working with service improvement is not the same as construction, so with most organizations already having a way of managing improvements, CASM might be trying to solve something that is already managed.