ITSM and Agile

So, I am assuming we have all heard about IT Service Management (ITSM) and Agile and what they mean to you and your organisation.  Typically, you have IT departments that utilise ITSM practices such as Incident, Change or Problem management to manage work load such as maintenance task or when something breaks.  With Agile thinking and methodologies, you typically associate with Software or Product Teams.  Except for the few rare occasions, I have not seen these two different ways of working; ITSM and Agile functioning well together. I aim to show that it is possible to bring the two worlds together in wedded bliss along with the foundations that need to be put in place to ensure its does not end in divorce.   But in adopting new ways of working, it is very much a journey where your company and teams need to be brought along for the ride.

ITSM and Agile, what the?

So, here’s how I see ITSM and Agile, and what they mean to me:

Agile – brings a rapid build/delivery focus with a disruptive mindset where plans may change, I would DevOps here.

ITSM –  brings process maturity, common sense, governance and structure, such as change control.

To some the notion of ITSM and Agile coexisting could be seen as a match made in hell, where they are directly opposed to each other and could lead to some serious arguments.  Not really a match made in heaven, more like married at first sight!  To enable the coexisting of ITSM and Agile there needs to be some serious ground work laid to ensure that these two do not go the way of seemingly poor match ups, less married at first sight and more love at first sight.

Critical to bringing two opposing ways of working together is to build strong foundations” #itsm #agile Click To Tweet

Laying the foundation for a great relationship

Critical to bringing two opposing ways of working together is to build strong foundations, ensuring there is an environment that both can thrive, it’s definitely a case of “adopting and adapting” to fit your teams and organisation and not being too dogmatic or “by the book” with your approach.  Foundations needing to be in place:

1. People

   Changing the way of working can for some be a major stumbling block to organisation change/transformation, with your people being your most valuable asset it is critical to bring them along for the whole journey. To help with guiding your people through change try establishing an awareness and education program where the benefits of adopting ITSM and Agile methodologies and ways of working need to be clearly laid out, to answer one fundamental question; “what problem am I solving”.  As well as the awareness program you will need to bring in fresh thinkers who are more Agile-minded and can share their experiences and benefits of working in new ways as well as acting as coaches for others.  If you want to change the way your teams and organisation work you will need to have executive or board level support and money as without either your teams will be less willing to accept change if those senior leaders around them are not supportive.  With new ways of working it should just be a case of being the new norm.

2. Guiding Principles

   How are the teams going to work together or how decisions are going to be made. I have used guiding principles as a way of showing teams the vision for the future, so they can buy in to that or not.  By having guiding principles, it also enables and empowers teams to make their own product or solution related decision that are aligned with organisational strategy or direction. For example, Build Smart – Automate everything, write tests first and APIs second being cloud ready but put a price on technical debt.

3. Rigour without the rigmarole

   Using enough governance but not so much to stifle innovation or rate of change. An example here would be what I had previously implemented around Change management, that had to get both business and technical approval but without slowing down development or sprint team velocity.  I did this by ensuring appropriate automated work flow were in place, so that if a development release was required a link to the Request for Change (RFC) was emailed to all Software Architect (technical approval) then the correct Product Owner (business approval) then to the Change Manager, all RFCs were then published in a forward schedule of change so that IT teams could see what had occurred on that day.

4. Working on the right stuff

   A core fundamental principle of Agile and the use of Scrum or Kanban is to limit the amount of in flight work at any one time, usually to a 2-week period. This ensures that there is a focus on quality and what is important to the business or Product Owners.  If you are running a shared services model, then it also gives IT Operations a clear view on what they need to be doing over a set 2-week period.  I have found that if IT Operations take a Kanban approach you can add in new tasks as they arise, such as zero-day vulnerability patching and then move out other tasks that do not have such high priorities.

5. Technology

   The use of technology and tooling more specifically is always a contentious issue as very one has their favourite. As an organisation there must be an agreement as to what should be used to solve a problem (rather than picking a technology solution looking for a problem). Whether you look at Asana, Trello or Jira to track tasks and time or Jira Service Desk, RemedyForce or ServiceNow for your IT Service Management (ITSM) it is important that you chose the right technology solution that best suits your organisation and the way they want to work to support an Agile Service Management environment.  The main point being the need to pick just one solution (per need) so that moving between teams is seamless as well as ensuring there is easy integration between the tooling chosen, for example you may want to use the Microsoft Office 365 suite of tools for collaboration.Right, you have got the tooling nailed, so what platforms are you going to build your products or solutions on? On premises, Amazon Web Services or Azure? with a hybrid approach being the mode of operations for most organisations with any legacy.  Now to support the DevOps mentality you must decide on automation and orchestration tooling (e.g. Puppet, Chef or Salt) to support your scrum teams, a great Architect working with the teams can really add value here by giving them the overall picture of how technology works in an organisation. To be truly successful in any technology choice you must make sure that the same tooling is used across all teams as it makes supporting solutions less complex and all products will be built on a common platform and architecture.

   Where Agile Service Management can be defined as the application of agile principles/methodologies/thinking to ITSM and Agile alike” #itsm #agile Click To Tweet

   Agile Service Management

   Instead of rolling out new ways of working across the whole of IT in one big bang start off small.  Try taking elements from an Agile way of working and utilise that thinking when it comes to Continual Service Improvement (CSI).  This is where you can use rapid delivery/planning through two-week sprints and iterative improvements to bring about quick wins for your organisation and get some runs on the board for the wider adoption of Agile Service management.  Most organisations will already have an approach to improving, and the added planning of taking an Agile approach can also be valuable in bringing a level of structure and rapid delivery/learning to this CSI approach.

   Taking Agile Service Management further

   I was not content with just applying Agile methodologies to CSI, I believe that this may just be the start of a beautiful relationship.  I have applied Agile thinking within a largely ITSM world, being that of IT Operations, where they have utilised a Kanban board using Jira (the task/time management software, which just happened to be the same solution used by the Software Developers) as well as running 2-week sprints, essentially time boxing their work

   The Operations teams would manage all work (except Incident and change management), be it maintenance or other tasks from a software development sprint work, all through Jira.  I also had my Domain Architects attend Sprint planning sessions to ensure any work that was required from the IT Operations teams was known well in advance.  By taking a Kanban approach the IT Operations teams are largely empowered to take on work that they see fit to meet time frames/expectations, such as ensuring patching level are up to date.  I also found that IT teams could more efficiently plan their work because they knew what tasks they had to do as per the Kanban board and could push back on any work that was not already planned or initiate business conversations around priorities.

   Do I hear Wedding Bells?

   “By adopting and adapting Agile Service Management you get to utilise the best of both worlds”

   By marrying (adopting and adapting) ITIL and Agile you get to utilise the best of both worlds, it is also a great opportunity to bring together traditional thinking with new ways of working and getting the organisation, teams and individuals along for the ride rather than force a new way of working on others.  Prove the benefits of taking this approach to each group (traditional thinking, ITIL with new ways of working; Agile) and start with quick wins especially when it comes to Continual Service Improvement and take it from there, get your IT Operations teams, who are usually ITIL focused to solve some of their pain points (what problem am I solving), such as work allocation through the use of Agile thinking/methodologies.

   Regardless of whether you have self-supporting teams or a separate shared services model you can use both ITIL and Agile to gain process and operational efficiencies built on strong foundations that can then support your organisations drive to be more customer centric.  If required Agile Service Management may also help under pin your organisations evolution from IT Operations to a DevOps model because the underlying technology and processes will already be in place.  Also, by putting in some constraints in the form of guiding principles you are empowering teams to be creative around the edges.  But regardless of how you approach the adoption of ITIL and Agile methodologies try starting small with one IT team or product by giving them the correct level of support and coaching you will build up some quick wins.  As you all know we love working on new things, especially if you can see the benefits of doing so.

   Above all, adopt and adapt Agile Service Management to fit your team and organisation” #itsm #agile Click To Tweet

   ITSM is not just for big corporates it can be for start-ups as well: Click here

   How have you gone about bringing ITIL and Agile together? please leave a comment below………………..