Simple steps towards Agility and Service Management improvement

Dead as a...

There have been many hundreds of words recently written on the subject of Agile Development and IT Operations practices. For the average ITSM practitioner, however, a life where both are interwoven into the organisations day-to-day work seems as unattainable as ever.

Sure, you might work for one of the few organisations that practices DevOps. If so congratulations… you’re one of the cool kids. Maybe you picked up a copy of “The Phoenix Project“** and the authors words resonated with you.

“I should start introducing Agile and Lean concepts into my IT organisation”

It’s not as if these words have fallen on deaf ears as such – it’s just that most ITSM practitioners are struggling to join the dots in their head, not even able to mentally apply Agile/Lean/DevOps to their own environments.

It’s hard to see how you get from your current position today to a position of continuous delivery and business agility, along with the bragging rights on Twitter about how great your aligned development and IT Operations organisations are.

You now want to improve… So what can you do to get started?

I have two quick tips for those IT Operations folk that want to start taking steps towards Agility and Service Management improvement. These tips won’t transform your IT department overnight but they are both cheap and easy to implement (in fact you could do it this week).

Tip number 1: Hold retrospectives

The most valuable skill of a good Agile team is the ability to self-learn. Self-learners have a habit of looking at their performance as a team and can identify positive and negative characteristics from their recent behaviour. By learning from past experiences they pledge to improve in the future.

The mechanism for Agile teams to drive improvements is to hold regular retrospectives.

A retrospective is a time boxed activity (a meeting) that is held at the end of a period of work, or in Agile-speak an “iteration”.

Development teams often work in regular short bursts of work called “sprints”, which in my company are always two weeks long, therefore we hold retrospectives on the last day of each sprint.

IT Operations work is not normally neatly defined in two week iterations – you tend to deal with KTLO work (Keep the lights on – Incidents and Problems) and perhaps projects. However, you should avoid the habit of only holding retrospectives to find improvements at the end of projects or when things are going wrong.

If you want to take a few Agile steps in your IT Organisation my advice is that you open your calendar application right now and setup a recurring meeting for your team that lasts for an hour every two weeks. Take this time to review work from that two week period and identify improvements.

Build self-learning and improvement sessions into your schedule. Don’t leave opportunities for improvements to project post-mortems or to when things have already gone wrong.

So what happens in a retrospective session?

Firstly, it should be a facilitated session so you’ll need someone to lead the team, but this isn’t a daunting task (OK – it is the first time you do it but it gets easier after that). Secondly, it’s a structured session rather than an hour to ‘bitch and moan’ about the Incidents that came in during the last two weeks.

Retrospectives are structured meetings with a clear objective – not a general conversation about performance

The objective of a retrospective is to get a documented commitment from the team to change one or two aspects of their behaviour. Documenting these commitments is covered below in tip number two.

Changing the behaviour of a team is absolutely not as challenging as it first seems, people only need a few things to happen to change their behaviour: to have their opinion heard; to be able to commit to the change; and to be held accountable. The format of a retrospective allows for all of this.

Also with retrospectives we don’t focus purely on examples where things went wrong. I’ve been in many retrospective sessions where teams have focused on unexpected success, have researched the factors that contributed to that and committed to spreading whatever practice caused the success to a wider organisation.

Identifying what worked well for a team in the previous two weeks and pledging to repeat that behaviour is just as powerful as pledging not to repeat negative behaviours.

I mentioned that retrospective sessions are structured. This really helps, especially when a team starts out on a path of self-learning and improvements. The structure holds the meeting together and guides the team to its objective for the meeting – validation of existing working agreements and proposals for new working agreements.

Esther Derby and Diana Larsen, who both inspired me to focus on retrospectives with their book, “Agile Retrospectives: Making Good Teams Great“ describes the structure for retrospectives very well in the SlideShare presentation below. Take time to study and implement their meeting structures.

What should the meeting structure look like?

The recommended meeting structure is as follows:

  • Set the stage

  • Gather data

  • Generate insights

  • Decide what to do

  • Close the retrospective

Each element in the meeting agenda is an opportunity for the facilitator to engage the team and run exercises to uncover what worked well (to be repeated) and what did not work well (to be avoided).

By structuring the meeting and facilitating people through the process you avoid the temptation for people to use the time simply complaining and placing blame for things that didn’t go well.

The meeting structure drives the retrospective towards its objective – an actionable set of Working Agreements for the team to use.

Tip number 2: Use Working Agreements

In a previous role in IT Operations and support I often felt the sensation of “spinning plates”. As soon as we could put one fire out another would flare up. Our problems as a team were that different people worked in different ways which is a real problem in Infrastructure teams.

My solution at the time was to try and write an all-encompassing “rule book” which described how we as a team react to any given circumstance. We’d build this “rule book” up over time and end up with a comprehensive document to remove confusion on how to perform work.

I’m sure you can imagine the outcome – we started.. we didn’t get that far.. as soon as the rule book was of any decent size it became out of date and unwieldy.

What my team then really needed, and the way that my Agile development team now works, is to have a lightweight document explaining the rules of the road. We call this document our “Working Agreements”.

What should Working Agreements look like?

  • They should be small enough to fit on a single side of A3 paper

  • Agreed upon by the team

  • The output of retrospective sessions, worded to enforce good behaviour or to prevent negative behaviour

  • Should be reviewed during each retrospective – do we need this Working Agreement now or is it part of our standard behaviour.

  • Should be very visible in the area

Having a lightweight set of agreements that the team commit to and that are reviewed regularly are a great way to drive cultural and technical changes that actually stick! Rather than review meetings that mean nothing once the team leave the room.

In summary

Driving improvements to a team means you are trying to change peoples behaviour which is never an easy task. Teams will change if some basic needs are met. They need to be listened to, they need to commit to the change and they need to be held accountable for future behaviour.

This is possible in your IT Operations teams today – hold regular retrospectives to identify what works and what does not. Get the team to commit to working agreements which are agreed by the team, meaningful and visible.

Let the improvements commence!

** If you didn’t nod when I mentioned The Phoenix Project then you aren’t one of the cool kids and you better find out what it is… pronto!

Image Credit

Future of ITIL workshop – a little insight

AXELOS

The following comment piece is contributed by Stuart Rance of HP and Stephen Mann of ServiceNow.

Yesterday a number of ITSM professionals convened in London to talk about the future of ITIL. From the get-go, it was stressed that the purpose of the meeting was to provide input to AXELOS’ thinking and not to make decisions.

Who was involved?

It was a passionate group of people that represented: ITIL authors, examiners, consultants, service providers, vendors, penguins, and AXELOS. The attendees were:

Of all the qualities we might look for in a SAM Managed Services Provider - proven track record is key.
AXELOS CEO, Peter Hepworth and ITSMPenguin

And of course ITSMPenguin. Everyone had opinions and ideas to share and it was a good mix of people.

Some attendees travelled a long way to attend: Anthony from Houston, Sharon from Canada, Jayne from Florida, and Rob Stroud would have attended from New York but for personal reasons. Even though most of the attendees reside in the UK, they work for global organizations and as such have global experience and global views. Not withstanding this, we all agreed on the need for more input across geography, culture, industry, and language.

If you wish to provide your input please respond to this blog (in the comments section) or email AXELOS direct.

Community input

You can already see much of the input from things people have already shared with the ITSM community:

Scope and content of ITIL

The discussions included the scope, content, and structure of both ITIL and the ITIL exam system. And started with people suggesting ideas for strategy and principles for ITIL going forward. It was surprising how long this took (shouldn’t we already know this?) and not unsurprisingly everyone agreed that ITIL should be driven by business and customer needs.

Other suggestion related to:

  • Having a visible set of values
  • Separating architecture and structure from narrative and examples
  • Collaboration with a wide community of practitioners, examiners, trainers, consultants, vendors, and industry bodies across geographic and industry boundaries
  • An emphasis on relevance to end-user organizations
  • Quality being more important than time to market.

From a content perspective, AXELOS introduced the concept of what it calls the “Onion Model”, shown below, that encompasses the previous feedback on how there is a need for different types of content and, importantly, community input to the ongoing development of ITIL.

photo

Where:

  • The centre has the very stable ITIL core
  • The next layer has modular content such as role or industry-specific information
  • And then further layers have more practical content such as templates, guides, and case studies
  • The very outside layer is community owned and community driven with AXELOS and the community curating and promoting this

Content is able to move inwards as it becomes accepted best practice.

                                       Training and exams

Of all the qualities we might look for in a SAM Managed Services Provider - proven track record is key.
The workshop group

We discussed the importance of people, culture, and organizational aspects. In particular the need for more practical guidance about how IT organizations can benefit from the experience of others, and how they can start to gain value from ITIL within their own organization.

There was a lot of passion around training and exams. An interesting point was the absence of guidance on the development of skills such as negotiation and management as part of effective IT service management. Everyone recognized the need to make the exam system more valuable to both individuals and employers. But there was a consensus that that any change requires more input, more time, and needs great care not to disrupt the status quo. Again, if you have an opinion as to the future of ITIL exams, please respond to this blog or email AXELOS direct.

Next steps

Following day two of this workshop (a second blog will follow), AXELOS will continue to seek out global community input.

If you want to follow what’s happening, please look for their communications on Twitter or Google+

As always, thoughts and comments are encouraged.