Do you ever get a Big Idea? You’ll be talking or reading about ITSM and the proverbial light bulb comes on. You see a connection or an underpinning concept that you hadn’t seen before. Sometimes it appears to be an original insight, one you haven’t heard expressed exactly that way before. And very occasionally it really is novel and it really is right: you subject it to the scrutiny of others and it stands up.
It happens to me. Because I’m privileged to spend so much time interacting with some of the best minds in ITSM worldwide – and thinking and writing about what I learned in those discussions, and applying that knowledge as a consultant – it happens to me quite often, about once a year. In fact I will be presenting on some of these big ideas at the upcoming Pink Elephant IT Service Management Conference and Exhibition (PINK14).
A couple of years ago my Big idea was Standard+Case, a topic which I will berunning a half-day workshop on at PINK14.
Standard+Case is a synthesis of our conventional “Standard” process-centric approach to responding, with Case management, a discipline well-known in industry sectors such as health, social work, law and policing.
The combination of Standard and Case concepts gives a complete description of ticket handling, for any sort of activity from Incidents to Changes.
Standard tickets are predefined because they deal with a known situation. They use a standard process to deal with that situation. They can be modelled by BPM, controlled by workflow, and improved by the likes of Lean IT and ITIL.
Case tickets present an unknown or unfamiliar situation. They rely on the knowledge, skills and professionalism of the person dealing with them. They are best dealt with by experts, being knowledge-driven and empowering the operator to decide on suitable approaches, tools, procedures and process fragments.
ITIL and Lean do fit this S+C paradigm, if you use them in the right situation: Standard responses. S+C extends them with better tools for non-Standard cases: Adaptive Case Management, Kanban, Knowledge Centered Support(KCS)… Better still, this S+C approach might let the ITIL and anti-ITIL camps live in peace and harmony at last.
Last year it was Slow IT. Slow IT is a provocative name. It doesn’t mean IT on a go-slow. It means slowing down the pace of business demands on IT so as to focus better on what matters, and to reduce the risk to what already exists. Think Slow Food, and more recently Slow Business and mindfulness etc.
The intent of Slow IT is to allow IT to deliver important results more quickly. It does this by concentrating on the interfaces between business executives and CIOs. Slow IT highlights the importance of Governance of IT and of Service Portfolio in order to make the right decisions to do the right things in the right way at the right time, to maximise benefit and minimise risk.
Right now the pace of change in IT is approaching human limits. Many IT shops are overwhelmed by change, drowning in projects. More are overheating: working at lunatic pace because the IT community convinces us we have to. Slow IT challenges the hysterias and fads of IT to ensure that these results are really needed as quickly as we think they are. Slow IT is about trying to introduce more measured responses, to bring some sanity to the current dangerous madness that is organisational IT (you can read more on this here).
I’ll be presenting on Slow IT at PINK14. In addition we’ll talk about my Meet-In-The-Middlestrategy to address the Slow IT issues by offering a quid pro quo: Fast IT. If the organisation will slow down the demands on IT, IT will have the breathing space to implement approaches to respond faster, such as Lean, Agile, DevOps, and good old CSI. Right now too many IT teams are so flat out serving the business they don’t have the bandwidth to introduce better methods properly. It’s the old catch-22 of being so busy putting out fires that you can’t improve fire-fighting or fire-safety. Slow IT takes off a bit of pressure, giving the team some headroom, to make improvements.
I hope to see you at the Pink Elephant ITSM conference. I’m honoured to be assembling some of those great ITSM minds at the Pink Think Tank, to address one of the biggest issues facing IT today: how to manage a multi-sourced IT value chain. We’ll be looking to produce tangible actionable advice, so look out for the results. I have a feeling it may be the catalyst for my next Big Idea.
Following on from my review of Day 1 of the itSMF UK Conference and Exhibition, it’s time to take a look at what happened on Day 2.
As the second day started I couldn’t help but look around slightly relieved that I wasn’t feeling as bad as the majority of the other conference goers looked. By all accounts the wine on the table had been completely obliterated and some people (mentioning no names) didn’t even managed to make it down for breakfast!
Talking of breakfast the fare at the Hyatt Regency was a decent spread and didn’t taste too much like it had been standing for hours. My experience of the waiting staff was that they were efficient and courteous, something you’d think would be a given but it never ceases to amaze me how hotels can charge such an extortionate amount for breakfast and then get it so very wrong.
In the Exhibition Hall more revellers surfaced and headed straight for the coffee in an attempt to freshen up somewhat before another full day of sessions. Anyway, less talk of breakfast and hangovers and more talk about the actual conference content…
Service Integration and Management (SIAM) – ITSM’s New Discipline by Kevin Holland, IT Service Management Consultant Specialist
My first session of the day was Kevin Holland’s Practical Tips for Effective Service Integration.
After threatening all the hungover attendees to stay awake or he’d do another Harmonica solo Kevin warned that System Integration is not Service Integration and that there is no need for an expensive supplier…you can do it yourself!
Systems integration is not service integration – how true don't confuse the two! #itsm13
It took me a little while to concentrate on Amanda’s session as I was mesmerized by her fantastic shiny red shoes! Getting Problem Management right is one of those elusive things that is so important and yet difficult to put into practice so I was interested to see Virgin’s experiences.
Over the course of the conference I had heard a few people commenting on how there wasn’t a lot of mention of SM Congress and so I was pleased to find that an impromptu talk by a few of the members who attended the original sessions at Fusion were going to answer some of the questions that had been raised since.
The session was particularly useful to those who were hesitant about SM Congress, as it helped clear the air and display the facts about the initiative.
For those of you that have been on the moon for the last couple of weeks and missed all the SM Congress talk you can find out more about it here. I also recommend taking a look at #SMCongress on Twitter for general discussions about the initiative. If you have great ideas to help shape the IT community and the future of ITSM then please consider getting involved.
My final session of the day was a relatively new subject for me. Kaimar explained the methodology and benefits of DevOps and why Beer is such an important part of forging relationships, although judging by what I saw over the course of the conference any old alcohol will do!
At the end of day two I was thoroughly shattered but hugely buzzed by everything I’d learnt, and I had list as long as my arm of further reading and cool stuff to investigate.
Despite some of the comments that there was a smaller attendance than in previous years, all of the sessions that I went to were very well attended and all of the staff at ICC I encountered were welcoming and helpful.
Some of the vendors I spoke to were concerned that due to the layout there was less opportunity for delegates to pass through the exhibition area on their way from one session to the next. However vendors such as Gaming Works that invested significantly in self promotion via social media and other avenues leading up to the conference hardly saw time where their stand wasn’t attended.
We managed to sneak a few photos with some of the exhibitors:
All in all an enormously enjoyable event that I will not hesitate to revisit.
Thanks for great time , and put my name down for sponsor next year. #itsm13
Regular readers of my blog on The ITSM Review, or over at ScrumProUK know that I enjoy exploring the gap between the worlds of IT Service Management and Agile development methodologies.
Today I wanted to go back to basics, back to square one and start over by explaining why you – as a reader from the world of Service Management or corporate IT – should care about Agile principles and what it can bring to your organisation.
I’m glad to see one commonly held misconception being broken down and disproven recently. The assumption that an organisation cannot be both Agile and IT Service Management orientated.
To introduce principles to those that are unfamiliar, I’m taking inspiration from Tobias Mayer who identified 5 benefits of Agile (in this particular case Scrum) that will help me orientate you.
“A man who chases two rabbits catches none.” ~ Roman Proverb
A core principle of popular Agile methodologies such as Scrum and Kanban is to limit Work in progress. Scrum teams, for example, will agree to take on a small subset of work from the overall backlog within a timeboxed period, normally between 2 and 4 weeks.
By limiting the teams focus and attention on what is most important you enable them to complete work to the appropriate quality standards; and by limiting work in progress we train teams to finish work, rather than start additional work. With focus comes attention to detail and less mistakes, a higher level of quality and ultimately happier customers.
Look around your IT department today as you read this article. Do you see teams that have more work than they can handle? (Probably). Do those teams have a clear understanding of what is most important (probably not)?
How can Service Management teams adopt the Agile principle of providing focus for their teams?
Start by understanding your work. Where does it come from? How does work arrive in your department. Visualise your work by using a tool like LeanKit, Trello or Kanbanize (all have free editions for you to try). Use one of these tools to identify which work items are the most important and challenge the team to finish those items.
By reducing the scope of work that a team is paying attention to you’ll see a change in behaviour, delivery time and quality.
“What if we found ourselves building something that nobody wanted? In that case what did it matter if we built it on time and on budget….” ~ Eric Ries, The Lean Startup
Agile teams work with the principle that plans will change; that we will understand more about the work once we near completion and that no amount of planning really prepares us for the road ahead.
This is true for software development projects where Agile is accepted but of course it’s also true for IT maintenance and operational projects too. How many of your projects delivered exactly as predicted on day one?
Knowing that business requirements will change frequently and that the assumptions made before work begins are normally wrong, Agile teams handle this by working in iterations.
By planning months into the future with “just enough” detail and by focusing in granular detail on only the next 2 week sprint, a team can easily absorb changing business requirements.
By meeting with the business on a frequent basis, by examining the overall plan (in coarse detail) and by re-prioritising against the current business requirements Agile teams achieve alignment with the business. They can plan for the next iteration in detail knowing they are working on the most important thing based on todays knowledge.
It’s no use being perfectly aligned at the start of the project and not having a system to cope with the ever changing demands. Changing requirements in a project are a good thing – it means we will have a better solution in the end.
Do your IT project teams try and control changing requirements… do you welcome them?
How can Service Management teams achieve alignment with the business?
By structuring work so that teams can focus in the short term but change direction to react to business demands. For Service Management teams this might mean short term focus on a set of metric goals to solve a particular business problem. Just having the routine of sitting with the business and reviewing priorities is a great first step.
“I don’t test my code often but when I do I do it in production” ~ Internet meme
Earlier I mentioned Focus as a principle of Agile teams and that by concentrating on a small subset of work that is most important to the business we can train teams to deliver. Rather than having lots of work open and diluting the teams attention.
There’s another benefit in limiting Work In Progress with regards to quality engineering. Imagine a team that has no control over its work and everything is urgent. The team has no Focus and no Alignment with the business – no understanding of what is truly important.
That team is likely to produce low quality work. By trying to complete everything at once they’ll often do just enough to call it done. This results in risk lurking in your infrastructure; the worst kind of work that will leap out on you when you aren’t expecting it. Work you thought was done… but isn’t. Rework!!
Agile teams use the system of limited WIP as well as technical practices and standards to get work done once so they can move on to the next task.
Could you improve the quality of work by defining standards and shielding your team by limiting work in progress?
How can Service Management team promote artful making?
Have a “Definition of Done” for common activities. Not a huge, heavy operations manual that no-one will ever read but a collection of one-page definitions of what it means to be done with a server build, a software installation, a Problem ticket.
Make the definition of done visible and easy to use, your engineers will know when they are finished with a piece of work before moving on.
The best architectures, requirements, and designs emerge from self-organizing teams. Teams that are not controlled but enabled. Teams that stay together long enough to form an esprit-de-corps and that trust each other enough to have passionate debate and disagreement without destroying the teams culture.
The worst experience that an engineer can have is to be presented work that was designed by someone else, work that has no scope for flexibility or creativity, and worst of all to be told how long it will take.
Have you ever worked on a project where the scope, implementation and deadline were predetermined by those that aren’t actually going to do the work? How does that even happen??
Agile teams are self-organising within the constraints of the organisation in which they operate. They receive requirements that describe the business need (The “WHY”) and acceptance criteria (“The WHAT”) and they, as a team, determine the solution (The “HOW”).
Self-organising teams scale much better than command-and-control style teams, where a manager delegates and defines the work.
Why would you want to have your expensive managers involved in assigning tasks and resource levelling? Members of a self-organising team know when they have spare capacity for more work and they pull work into their queue.
How can Service Management teams become more self-organising?
I think this is a simple one – do you have managers that delegate work or leaders that coach teams to success? If you have the former is that the best use of their time and skills? Give the team an opportunity to own their work and determine their own destiny, within the constraints of your organisation.
This loss of control by managers might result in a team more invested in its success, more motivated and higher performing.
“Rhythm is something you either have or don’t have, but when you have it, you have it all over.” ~ Elvis Presley
Agile teams are focused on the regular delivery of value into the businesses they serve. By limiting work to sprints, usually between 2 and 4 weeks long, they are able to continuously deliver work building a partnership based on trust.
Because they focus on a subset of all possible work and they have quality standards they can deliver work of a high quality which deepens that trust.
Short time-boxes focus teams on an objective they have to meet – by self-organising they control the scope of work that is achievable within that sprint. When I started delivering work to a company using Scrum I asked my stakeholders which attribute of the work they valued most.
Was it the speed or the volume of work, or the number of features we delivered? No – organisations rely on predictability and working in set time-boxes, or sprints, makes your team predictable.
Compare this to projects that defer the delivery of value until the end of the project. Rather than release early and often they buffer the features and aim to deliver all in one large batch.
If that deadline is delayed two unfortunate things happen – firstly trust between the team and the business is eroded. And secondly the value represented in the features that are done but not released cannot be realised until all work is delivered.
Do you have a trust between the IT organisation and the business which is built upon a rhythm of regularly delivered work?
How can Service Management teams get that sense of rhythm?
I love the idea of working within constraints. It focuses the mind and makes people be creative. Even if you don’t work in software engineering define a series of 2 week “sprints” for your Service Management team.
Declare an objective for the two week sprint – “we are going to reduce the incident backlog to under 50”. Let the team self-organise and think about your teams objective for the next sprint.
Thanks for Tobias for his 5 attributes of Agile teams that I’ve expanded and commented upon. My aim here was to outline the benefits of Agile to teams outside of the world of software development. I hope that readers that work in IT Operations and engineering can compare the way they work currently against these ideals – all of which are simple and cheap to implement and realise.
Ultimately the ideas of focus, alignment, artful making, self-organisation and rhythm promotes a culture of learning – about the work you handle, about how the team performs and how you interact with the business.
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.
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!
The Met Office has to implemented a new software release and deployment automation solution to reduce the number of software planning, delivery, deployment and execution errors it needs to handle on a day to day basis.
The UK national weather and climate services authority has worked with specialist partner in release and deployment management solutions Cachet Software to implement the XebiaLabs Deployit product.
This installation is intended to enable the Met Office to save time, with tests already showing a substantial reduction in deployment times compared to their in-house solution.
It will also help reduce errors and increase efficiency of preparation and deployment.
Overall, the solution is hoped to increase accuracy, speed and scale for the Met Office’s deployments of new applications and services — the organisation had previously confirmed that it needed a flexible solution that could better scale and support continuous delivery of primarily web-facing services to millions of customers.
NOTE: The team at the Met Office manage hundreds of projects and services across dozens of servers — until recently, release preparations were manual, meaning each step would be subject to time-consuming checks to ensure it was planned and executed properly.
By applying deployment automation best practices with Deployit, the Met Office will be able to reduce the risk of deployment errors whilst enabling an increase in the number of deployments. Deployit will also ensure more efficient performance and deliver the ability to keep track of deployments and report on deployment results, leading to a substantial improvement in efficiency of the service delivery process.
Alan Morbey, Configuration Management Team Leader at Met Office, commented: “At the Met Office our deployments were both increasing in volume and complexity whilst staff resources were limited. Deployment automation using Deployit has allowed us to cope with both of these issues, minimise deployment errors and helped us to further safeguard our production environment, key to delivering services to our customers. Deployit is already showing some very encouraging results, with deployment times being substantially reduced .”
NOTE: The Met Office uses more than 10 million weather observations and a supercomputer to create 3,000 tailored forecasts daily. These briefings are delivered to the general public, Government, businesses, the armed forces and other organisations.
Stuart Kenley, MD at Cachet Software Solutions, added: “Customers today expect up-to-date services at all times, which means IT departments need to deploy more, faster and accurately. Continuous delivery is becoming a must-have for all companies. We are delighted to be working with the Met Office, having been able to help them through the process of selection by conducting a due diligence to choose the best fit for their specific requirements.”