9 DevOps and ITIL Tips – “No shouting at each other (please)”

DevOps and ITIL
Share on facebook
Share on twitter
Share on linkedin

“No shouting at each other” – this was the “collaboration theme” in a MarsLander business simulation workshop conducted with DevOps and ITIL stakeholders at a recent client engagement. One of the workshop goals was to create a better understanding of each other and explore how these two worlds can work better together, another was to explore the new ITIL 4 concepts to identify what could be taken away and applied immediately.

This article describes the key discoveries from the workshop delegates, in relation to what they currently experience in their daily work, and in each section offers up a concrete tip for you to take away and apply in your organization. There’s also a number of embedded links to helpful supporting evidence and additional advice.

What is “effective collaboration”

At the start of the day, the team was asked to work in duos. Each duo had to agree on one behavior we would see in the simulation that demonstrates “effective collaboration” and to record these on a flipchart. The header on the flipchart was “No shouting at each other.”

Why did we do this?

When the workshop delegates entered the room, 3-4 independently asked: “Who do I shout at and blame when things go wrong today?!” – a symptom, perhaps, of a blame culture? And a symptom of the suspicion we see around the world, ‘Collaboration? Fraternizing with the Enemy’.

Another reason for this exercise on collaboration was the fact that this is a top-scoring organizational skill according to the recent DevOps Institute global skills survey, and it’s also one of the guiding principles of ITIL 4 – Collaborate and promote visibility.

This exercise was the first step in making visible what the team agrees as desired behaviors:

  • Everybody gets together in a “stand-up” – not just Dev and Product owners
  • Listen – show understanding, let somebody finish talking, summarize what was heard and agreed, ask to confirm understanding
  • Building effective relationships – work to gain trust with other e-2-e team members and the business
  • Be engaged – use the agreed channels of communication and collaboration, actively seek feedback
  • Respect opinions and other viewpoints – plus, seek to understand the points of view and reasoning
  • Reasoning – making a business case for a standpoint
  • Sharing information about status – notify if you can’t meet agreements
  • Trust – earn trust, demonstrate the above behaviors to win trust.

I’m sure you’re thinking, “But there’s more than that to effective collaboration!”  This may well be so, but the point is that the team got together and described what THEY feel is important for now, and THEY agreed to experiment and practice these behaviors.

TIP #1: Do this exercise with your team(s), agree on the desirable behaviors you want to see, and the undesirable behaviors to be unlearnt.

It was only later, as the day developed, that other behaviors were added as a result of the experiences gained in the simulation:

  • Know the agreed, shared goals and how to prioritize in relation to these goals, and know who is able to take decisions about priorities
  • Ownership for the team agreed goals.

The team had started with a set of agreed behaviors and “progressed iteratively, with feedback,” as per ITIL 4 to improve these behaviors.

TIP #2: Include the review of collaboration and communication skills as part of retrospectives or team meetings. See also this blog about “behavioral defects” and their impact.

“L”

During the initial rounds of the simulation, it was clear that “listening” is a skill that needs to be learned and practiced. As one delegate said, “New teams should wear an ‘L’ sign around their necks, the “L” standing for LISTEN, we need to get rid of the ‘Yehbuts’!” This confirms our findings about the importance and the poor status of communication in IT.

Learning to Listen and Respect Opinions

It also became clear that there’s a difference between making a flipchart of behaviors and consistently sticking to them. This is the same as the difference to pinning up a poster of the ITIL 4 guiding principles and actually living them! There’s more on the ITIL 4 guiding principles in this blog.

A coach role was seen as important for providing feedback and stimulating the behaviors. For many teams this is new, and many teams are not mature enough to consistently practice, give feedback, and reflect.

TIP #3: Assign a coach role to teams to help practice and give feedback on the agreed new desired behaviors. They’ll not be sustainable without practice! These coaches must also be trained in organizational change management practices.

DevOps and ITIL… wait a minute! Where’s the business in all this?

It was an interesting observation when, over halfway through the day, somebody asked, “Where are we now in the mission?”

Nobody knew the goals, or the critical business activities and times. Nobody knew or celebrated business achievements so far. “Have we landed on Mars yet?” asked the Systems Engineer.

Prioritization was based on revenue-generating work and customer satisfaction (CSAT) feedback, but not on enabling critical business functionality. It raised a new learning point “Focus on value” – what’s value and value for who? And what about the value “Co-creation” espoused by ITIL 4?

“I just fly rockets.” This was the quote from the Flight Operations Manager, not sharing critical business moments and critical business functionality to help with effective prioritization and not relating these back to the overall strategic goals.

“Governance anybody?” Governance is a key area in the ITIL 4 Service Value System and one that’s poorly applied in the majority of organizations. See this recent governance article on the ISACA site.

Team to Flight Operations: “Why didn’t you tell us?!”

Flight Operations to team: “Why didn’t you ask?!”

As I said, “co-creation”!

Post 8887 diagram 02

TIP #4: Engage your business colleagues and explore key goals, critical business functions, and timing. Also, explore improvement needs. Remember the top scoring ABC (Attitude, Behavior, Culture) card for 15 years in a row is “IT has too little understanding of business impact and priority.”

TIP #5: This is a tip I’ve suggested many times in the past. It fits with the new ITIL 4 Service Value Chain activity “Engage.” Make Monday a “go and meet a user day” – send everybody from IT into the business for one day to explore the user perspective on “value.”

“Vis-ABILITY”

In the simulation, the product owner tried creating visibility into the backlog of work by building a Kanban board. Meanwhile, the team totally ignored this. “This takes too much time and isn’t worth it” said the product owner, focusing only on the features, resulting in the team not having the ability to make the right decisions, prioritize the work, identify constraints and resource conflicts, or determine the status of critical work.

“Just like daily work!” said one delegate! This is why the guiding principle is called “Collaborate with visibility.”

A key takeaway for the product owner at the end of the simulation was to “Make time to create visibility into all opportunities and demands in the backlog, including wastage and toil and improvements.”

TIP #6: Start gaining visibility into your complete backlog of work, identify hidden work and wasted work.

“CAB-al”

In the initial rounds, work was backed up at what the team called the “dreaded CAB.” Only 25% of the changes were related to new business value and people in the change advisory board (CAB) meeting didn’t have the right information. Prioritization was an issue. Sudden last-minute changes, and prioritization by shouting the loudest or who submitted first. There was frustration all round! “This is definitely recognizable,” said a delegate.

Progress… or is that regress iteratively!?

The team played seven sprints in the simulation. Between each sprint, they explored some DevOps and ITIL 4 concepts and experimented with “Progress iteratively with feedback.”  In the beginning, they made a list of reflection points “What went well, what needs improving?” Then they promptly ignored the list, and all carried out small siloed improvements (local optimization versus end-to-end optimization).

So much for “Focus on value” and “co-creation.” The question was “who owns this list?” Answers were “The product owner,” “The service manager,” and “The sales director” – it was unclear who owned end-to-end improvements. Then the question “Who prioritizes the improvements?” – again no answer. Who owns YOUR improvement backlog?

TIP #7: “Start where you are” – interview all stakeholders in a particular value stream and start to identify waste, toil, barriers, and bottlenecks. Visualize these and discuss them as part of the backlog of work to be planned.

In the last round not only were more changes going through, but also more business changes. Also, there were more-frequent releases with fewer defects/issues occurring. How come? These were some of the team discoveries:

  • Identifying all of the types of demands/opportunities going through the CAB
  • Allocating owners to the various value streams that raised changes
  • Map the value streams and the stakeholders and actors
  • The owner of a value stream was made responsible for their own change impact assessment and build by getting end-to-end roles together
  • Improving the change process by removing waste and wait times, clarity of roles and decision making, and insight into current business goals
  • A service manager was included in teams to ensure new changes were embedded in support training and knowledge transfer, and to prioritize service improvement initiatives
  • Reserving time to make improvement-related changes
  • Prioritizing improvements on end-to-end value
  • Sharing of knowledge and delegating standard changes
  • Automated testing was built in
  • Continuous deployment was used on some value streams
  • Problem management was used to reduce changes arising from repeat incidents
  • The CAB was used for changes impacting more value streams or new service offerings.

TIP #8: “Start where you are,” “Progress iteratively,” “Focus on value”, and “Collaborate and promote visibility” – make this above list visible and discuss with end-to-end colleagues which ones would add value to your organization. Add them to your improvement backlog.

The workshop’s key takeaways

At the end of the day, delegates were asked, “What did you apply today that you need to take away and apply in your organization?” Here are some of the key takeaways:

  • If you want this to really work you need to accept short-term pain for long-term gain – recognizing that some short-term pain is needed to allow time to experiment, learn, and improve to scale up the ability to deliver more value in the long term… who is prepared to take the pain?
  • Change prioritization based upon VC+VL+VI (value creation, vs. value leakage, vs. value of improvement). There needs to be a balance in prioritization.
  • Prioritization of incidents (defects and debt) needs to be related to business impact. The business product owner also doesn’t know this. Need to “Engage” with customers for feedback to identify the real impact.
  • Improve the business case for service improvement initiatives – show blockers, waste, toil, value leakage, plus the opportunities for new value creation as a result of improvements.
  • Measure and use facts to support service improvement initiatives and the need to address problems (and technical debt).
  • Communication and collaboration are critical. Communicate in business terms, collaborate based on behavioral agreements (e.g. we listen, we respect). Use stand-ups, retrospectives, and continual improvement workshops to foster collaboration, understanding, and the building of relationships and trust.
  • Include service owners in stand-ups and retrospectives to identify and prioritize service improvement initiatives.
  • Identify the types of demands and opportunities and start to map the value streams with the responsible roles. Use this to identify value, eliminate waste, and agree on priority improvements.
  • Improve visibility of all types of work, as well as resource allocation and WIP. Who is working on what and what are the priorities? Reserve time for improvement work.
  • Shift focus from DevOps (code-to-commit) to BizDevOpsBiz (idea-to-value) and shift ITIL focus from processes to e-2-e value streams.
  • One product owner per value stream. Avoid multiple product owners competing for resources and prioritizing their own KPIs at the expense of other product owners. The product owner needs to own the end-to-end value stream. Not just features but also service quality and value realization.
  • Build relationships with business colleagues. Use measures, use dashboards, engage with the business and end users.
  • Clarity in roles and responsibilities, especially prioritization and decision making.
  • The important role of coaches for teams and skills to conduct a stand-up, retrospective, or improvements session. It needs to be embedded in the team, not a manager’s job.
  • Justify the business case for change to the product owner. If we want the product owner to prioritize improvements, problem management, defects, or technical debt we must make a business case with facts and figures relating to value and impact.
  • Service management needs to walk around on the shop floor and gain feedback into improvement needs. Identifying waste, toil, and opportunities for improvement.
  • Teams need coaching to develop appropriate collaboration and communication skills and to help stimulate continual learning and improvement behaviors.

TIP #9: Organize a similar experiential learning workshop with your team(s) and decision makers to identify your own shared takeaway improvement actions. There are many providers that offer these types of learning interventions, helping to “translate theory into practice” and at the same time provide input to “Progress iteratively.” It’s your first step on the path to value co-creation.

DevOps and ITIL – are we any closer?

What was the common ground?

Throughout the day one or two theory sheets were shown and commonalities explored.

DevOpsITIL 4
The first way of DevOps: Flow. The smooth flow of work, understanding the systemService value system, service value streams
The need to shift from a focus of code-to-commit to idea-to-valueService value chain, from engage to value. Guiding principle: Focus on value
Types of work that flow: features, defects, debts, risks. (Value, Outcomes, Costs, Risks).Opportunities and demands: requests, features, events, incidents, problems. (Value, Outcomes, Costs, Risks)
The second way of DevOps: Feedback. Create short feedback loops that enable continual improvementProgress iteratively with feedback. Problem management was seen as critical for providing feedback. Service management provides feedback from the continual improvement register
The third way of DevOps: Continual experimentation and learningContinual improvement
Collaborate seen as a core skill required.Guiding principle: Collaborate and promote visibility
CALMS (Culture, Automation, Lean, Measurement, Sharing) – SHARING (multi-functional skills)Sharing: “shift-left” is often referred to in ITSM as moving knowledge left (closer to the customer), more knowledge at first call, relieving support teams. Shifting-left in DevOps is more about “build quality in” and “never pass a defect downstream” – problem management helps share knowledge, passing it back upstream to help build quality in

What are your thoughts on “DevOps and ITIL”? Please let me know in the comments.

Director & Owner at GamingWorks

Paul Wilkinson has been involved in the IT industry for more than 25 years and has a broad background in IT operations, IT management, and product innovation and development. He was project team lead in the original BITE (Business & IT Excellence) process modeling of ITIL, an ITIL V2 author, and member of the ITIL V3 advisory group.

He is co-owner of GamingWorks and co-developer of a range of business simulations focusing on IT service management, project management, business process management, business and IT alignment, alliance management and co-author and developer of the ABC of ICT products and publications.

Want ITSM best practice and advice delivered directly to your inbox? Why not sign up for our newsletter? This way you won't miss any of the latest ITSM tips and tricks.

nl subscribe strip imgage

More Topics to Explore

3 Responses

  1. I disagree with how you’ve described Shift-left in the ITSM space vs. in the software development space.

    Shift-left (whether that’s being discussed in a dev context or service context) is about moving work from point of delivery & closer to the point of origin … so in a software context, it means (for example) moving testing upstream so QA is not done as an afterthought. From a support context, it means (for example) moving resolution work towards the end user using tools like self service, and knowledge bases.

    1. Thanks Akshay, Of course you ar right in that definition. Was it in this article you saw that or one of the embedded links? I would be happy, and teams so far confirm it, if we started to shift ;left (or whatever you want to call it) by doing some effective problem management and enabling 1 call to be more effective. Possibly what you refer to was me saying ‘shift left ‘ from ‘usage’ of the system (on the end of the flow), using problem management to feedback up stream helping prevent downstream defects in t future. Hopefully we can catch up sometime soon and discuss it face-to-face. difficult like this. Cheers.

Leave a Reply

Your email address will not be published. Required fields are marked *