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