Agile CSI: continual service improvement done right

10034579444_60a0fdc982_zDon’t worry. I am not going to rant on about hypothetical methods or visionary statements. I will not explain why agile is important for the ITSM industry, nor will I explain why agility is crucial for business survival. After all, these are no-brainers, right? I will only use your valuable time to illustrate a practical experience on implementing continual service improvement (CSI), the agile way.

In the past few years I have been privileged to apply lean and agile principles, methods and instruments to many different (IT) service environments. Most of the assignments were focused on delivering more value to stakeholders, improving collaboration between functions and domains, and reducing change lead times. However, one of the most intriguing assignments revolved around creating a culture of continuous improvement for a professional services company.

The problem

First, here’s some context. The customer I am referring to, is in the business of providing professional infrastructure and telecom services to its customers. The IT director realized they had a huge problem, when their largest customer repeatedly complained about their supplier’s reactive behavior. Surely, the customer got what they asked for, but there was no such thing as proactive service management, let alone continuous improvement of processes and services. My customer thought that they had this covered by having an extensive description of a CSI process, according to ITILv3. Yet somehow, no real improvements were initiated, let alone carried out. I profoundly assume this does not surprise you.

ITIL

Looking at the core objective of CSI, I have always applauded this addition to the ITIL set. After all, it recognized the essence of having a flying wheel for improvements throughout the IT service organization and lifecycle. However, allocating a separate process and rather waterfall and administrative approach to achieving this objective, is why ITIL’s CSI falls short in so many implementation attempts. Similar to Imai’s Gemba Kaizen, successful continuous improvement in IT services involves small, bottom-up, incremental improvements, integrated in business as usual. In addition, ITIL fails to address the most important element of achieving continuous improvement: culture. For instance, as long as the culture of the organization does not reward improvements or even does not allow mistakes to be made, those mistakes/errors will be covered up, instead of being visualized, improved and learned from.

Agile

This is where the Agile way of thinking comes in. At this organization, we introduced agile principles (eg. multidisciplinary, self-organized teams), methods (scrum) and instruments (kanban) to address their improvement issues, and to grow towards a proactive service organization. We started off with scrum. First by ensuring all stakeholders had a shared understanding of agile principles, the scrum process and its relevance to support and operational environments. After that, we allocated the roles. The complaining customer picked up the product owner role, whereas the service manager became the scrum master. The primary people involved in the service chain (service desk, design, develop, test, operations, main supplier) were involved as team members.

Then, as a joint effort, the entire team investigated the current opportunities for improvements, both on processes and delivered services. All improvements were collected on a product backlog (i.e. an improvement backlog). We used a uniform format to write them down: user stories. The good thing about user stories, is that they are short and simple, yet always address the “why” question. This resulted in user stories such as below:

agile

In parallel, we used planning poker as an instrument to estimate the improvements. I find this a particularly useful way of estimating both changes and improvements. The relative measure (story points) appeals to the unpredictive and indeterministic nature of so many changes and improvements.

In two weeks time, we had the product backlog filled (i.e. “ready” for 3 sprints), and prioritized by the product owner. So yes, this means that the customer decided where improvements were to be made first. After that, we narrowed down the product backlog into a sprint backlog for the first sprint and started off with a planning session for that sprint. Here, we created tasks for the allocated user stories, which were added to the physical scrum board we had set up. Together with the other, obvious ceremonies (stand up, demo, retrospective), the scrum process was in place and led by the service manager (scrum master). Every day, the team members pulled their actions through the process, picked up and realized the improvements during the 3 sprints.

Results

After three sprints of each one month, 80% of all identified improvements had been realized. And implemented. Result: an engaged customer, visibly happy with the improvements made thus far and confident regarding the proactive capabilities of the service organization. But it didn’t stop there. Yes, we stopped using scrum. After three sprints the backlog almost evaporated. But at that time, it was still positioned as a separate instrument. That is why we incorporated all future improvements on the regular kanban board, which was already used for incidents, problems and changes. Improvements became business as usual. All team members, including the customer, were actively involved throughout the delivery chain, all aimed at continuously improving the service delivery chain. The people involved were all aware of the priorities of their work in progress, and the value of their daily improvements.

I hear you say: this sounds too good to be true. Of course, we encountered several problems along the way. Quite a few team members were skeptical with regard to using agile principles and instruments. Showing them the value of visualization, sharing tasks across the multidisciplinary team and providing insight into the entire delivery chain, really catalyzed their changing attitudes. In addition, it was certainly not easy keeping everyone on track and on focus for the improvements during the sprints, next to their daily incidents, project work and other engagements. Daily stand-ups, management attention and visualizing results have surely contributed here.

The future

Creating a continuous improvement mindset is all about stimulating a learning culture. You are never ready. The same goes here. Having a CSI mindset is not enough to keep learning effectively. Further improvements for this organization include the optimization of measurements, and a further integration of Lean and Agile elements, or from Rob England’s TIPU framework.

Agile CSI is only one example of how agile and lean principles and instruments can help the IT function deliver great services. ITSM has a key role in achieving this, by sharing practical experiences, good practices, but most of all creating the conditions for all stakeholders to improve their work, processes and services.

Want to hear more from me on this topic? Join my BrightTalk webinar on 10th September 2014.

Image Credit

Change and Release Management: What are they? What’s missing?

Daniel Breston
Daniel Breston

This article was contributed by Daniel Breston, Consultant at Qriosity Limited.

I was recently challenged by Mike Orzen (co-founder of Lean in IT practises and my mentor) to answer a simple question: what do you think the purpose of change and release management is in ITIL or any other IT best practice framework?

I started by asking what aren’t they?

Change is not about doing the change, and release is not about managing the approval of a request to change. Change helps me make a decision; it answers the question WHY with a “yes” or “no”. But “yes” or “no” to what?

How many times has a request been approved, but what was delivered did not match what was approved? If IT has no value until it releases something that is usable to a customer, we better be sure that “yes” and “approved” are used for getting an organisation to be competitive, compliant, reliable, secure and cost-efficient as quickly as possible. Lean helps by creating a value stream from idea to solution, in a similar fashion to the ITIL lifecycle of service strategy to service operation. In both cases, the solution to the customer needs to be delivered as timely as possible.

You can’t manually approve every request as this would block the flow in the IT value stream. So the creation of standard change types assist in identifying low-impact, repetitive, and easy to fix types of requests.  LeanIT likes standard work, as once you know if the request or change will not place the organisation at risk of losing a customer or wasting money, you can then automate the decision process to flow the request to the design phase, if required. If it will impose a risk or loss, then the request can be routed to a more formal approval process that can also be leaned over time.

Change should control every aspect of a release (the doing process of an approved change), so we have to look at all of the places change gets involved to help design a fast, flowing stream across IT, and ultimately one that works from the customer (pull) instead of IT pushing releases to the customer.

So where does or should change get involved?

An example:

The above could form the basis of a release process. I am sure more questions are needed, but if we allow the various teams to continuously improve the above, we can release valued services into the organisation. The teams might use lean methods such as kanban boards to control work, kaizen to improve work and agile or DevOPS to get services developed and agreed.  Another aspect of lean that the table demonstrates is waste removal. If the change gateposts help to reduce defects, re-work, wait time between tests via automation or script reuse, for instance, then the flow of the value stream is enhanced end to end. Removing or automating/facilitating the gates in a formal process will also help increase flow resulting in a better time to market, quality enhancement, productivity improvement and cost reduction.

Configuration management – the needed process for ITSM & lean success

To be effective (first) and efficient (second), we need data.  Where are requests, business cases, regulatory and architectural requirements for design, code, tests, or service acceptance criteria kept for example? We turn data into information to gain knowledge to deliver value. Configuration management is the data to knowledge management process. The information in a configuration management database (CMDB) can be used to enhance the way a process, team or tool performs. For instance, if we create a cycle of CCRCCR: (change to configuration to release to change to configuration to release…) to be as fast as possible; then the agility of creating solutions in a timely manner becomes our standard culture or way of working.

How do we start?

I suggest by mapping the value stream, as much as possible, from end to end.  At first you may only be able to do the parts internal to IT but keep adding until you have the entire value stream from requester to customer mapped.  Lean value stream mapping helps improve how an IT organisation, business enterprise and partners create and improve ways of work.  Get as many representatives as possible involved in a mapping exercise and use post-it notes to visualise the current way of working.   Try to get the people that do the work involved as this generates buy-in for future change improvements.  Your post-it notes could include time of steps, teams involved, tools used, etc.  Don’t trust what you create in a conference room.  Go out and see (lean calls this “gemba”) to validate your understanding.

Now return to the conference room armed with your knowledge and improve the flow of the stream (steps). Add a few measures to control the flow of the stream and most importantly BEGIN.  Don’t wait for the tool changes or other procrastination reasons: start using the new way. Check how changes are approved, the steps performed to create a release, the results of any improvement (agreed and tracked) and use the CMDB to maintain the information such as your review of other ITSM processes. You can continue to create a unified view of your IT practices, processes, tools, capabilities, etc. The lean trick is to make checks or improvement a daily part of work, not something owned by the program team, but by the people doing the activities all along the stream. Let them own and celebrate the success.

Set some stretch goals for how long it should take to agree a requestor, how fast to perform a release etc. Look at quality, productivity, stock reduction (number of tests or environments needed) as examples.  PLEASE note that cost is a benefit and if you see that as a target it may be viewed as a job-cutting exercise when it should be viewed as a job enhancement opportunity.

Please let me know what you think and try blending Lean into your ITSM world.  Have fun doing it!

This article was contributed by Daniel Breston, Consultant at Qriosity Limited.

Pink14 Preview: What’s the big idea?

"Sometimes you're so busy putting out fires that you don't have time to improve fire-fighting or fire-safety"
“Sometimes you’re so busy putting out fires that you don’t have time to improve fire-fighting or fire-safety”

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

Standard+Case

A couple of years ago my Big idea was Standard+Case, a topic which I will be running 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.

Slow IT

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-Middle strategy 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.

What do YOU think the next “big idea” will be?


Find me at PINK14:

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