Ways of Working

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 workloads such as maintenance tasks or when something breaks. 

With Agile thinking and methodologies, you typically associate with Software or Product Teams.  Except for a 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 it does not end in divorce.   But adopting new ways of working, is very much a journey where your company and teams need to be brought along for the ride.

Yes, IT Teams can adopt and adapt ITSM and Agile Methodologies: Kanban: Adopting and Adapting Agile for IT Teams and Beyond

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 put DevOps in 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.  It’s not really a match made in heaven, more like married at first sight!  To enable the coexistence of ITSM and Agile there needs to be some serious groundwork 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.

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 where 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 needed to be in place:

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.

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 into that or not.  Having guiding principles also enables and empowers teams to make their own product or solution-related decisions that are aligned with organisational strategy or direction. For example, Build Smart – Automate, write tests first and APIs second being cloud-ready but put a price on technical debt.

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, which had to get both business and technical approval without slowing down development or sprint team velocity.  I did this by ensuring appropriate automated workflow was in place, so that if a development release was required a link to the Request for Change (RFC) was emailed to all Software Architects (technical approval), and then the correct Product Owner (business approval) and finally 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.

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 of 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.

Technology

The use of technology and tooling more specifically is always a contentious issue as everyone 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 choose the right technology solution that best suits your organisation and the way they want to work to support an Agile IT Service Management environment. 

The main point is 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.

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 utilising 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 levels 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?

Regardless of whether you have self-supporting teams or a separate shared services model, you can use both ITSM and Agile to gain process and operational efficiencies built on strong foundations that can then support your organisation’s drive to be more customer-centric.  If required Agile Service Management may also help underpin your organisation’s evolution from IT Operations to a DevOps model because the underlying technology and processes will already be in place. 

Also, by putting in some guardrails 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 ITSM 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.

Have you used ITSM and Agile together as part of your technology team’s way of working?

I am not alone in this thinking: Agile ITSM: How Agile & Service Management Can Work Together