It’s all part of the game!

Guest Author | December 21, 2018 DevOps

This is a guest-authored post by Paul Wilkinson, Director & Co-Founder, GamingWorks. Paul will be speaking further about DevOps at his Pink19 session: DevOps is going to fail…unless

 

An IT Executive's request: ‘I want my operations teams to understand more about DevOps, what it means to them in terms of a ‘mindset’ and behavior shift, and why adopting DevOps ways of working is necessary. We need to shift from a technology focus to a product and business value focus’.

Why this request?

As DevOps truly enters mainstream and Digital Transformation becomes the latest catchphrase, organizations are realizing that DevOps is, as the late Robert Stroud described it, an ‘imperative for survival’. But as Robert went on to add, ‘changing institutionalized behavior is the toughest of all management challenges’.

Increasingly organizations are investing in DevOps training and certification. However understanding the theory such as the ‘Three ways’ and applying the technical concepts like ‘CI/CD pipelines’ is one thing, but aligning and agreeing end-to-end behaviors is something entirely different. And it’s not just team behaviors but also Leadership and business owner changes! Very often the requests from managers, like the one at the start of this article, are about ‘teams…they….them…’ and not about ‘I’ or the ‘Managers’.

The request from the IT executive above reflects the challenges from many delegates at the recent DevOps Enterprise Summit, and reveals that Leadership was seen as the top challenge!

How many of these challenges do YOU recognize? And what can you do to address them?

It’s all part of the game!

Don’t worry if you recognize them, it’s all part of the game when it comes to adopting new ways of working and realizing behavior change!

Increasingly we are seeing the Phoenix Project business simulation being adopted as part of a DevOps adoption Journey. Why? On the one side the simulation is used to help translate DevOps theory into practice, after all, all this newfangled way of working like Kanban, kaizan, stand-ups and retrospectives needs some practice,  and on the other side it is being used to support the necessary culture and behavior change for all stakeholders.

This article briefly describes the some of the experiences of delegates and the key takeaways from a recent set of 3 Phoenix project simulations played in a global organization.

At the start of the simulation delegates, representing end-to-end responsibilities, were asked ‘what are you hoping to discover today’?

These were the top 3 items they mentioned:

  • How to improve communication and collaboration (no more shouting, blaming or saying ‘not my responsibility) between ALL teams.
  • Understand what DevOps is and how it is ‘supposed to work’ (‘We have a ‘DevOps team’ and that isn’t working)!
  • How to recognize and agree bottlenecks and remove ‘waste’.

Collaboration seemed to be the main challenge, and an emotionally charged one, born from frustration with ‘other’ team behaviors, as well as Leadership behaviors. 

The first exercise we did as part of the simulation was to split the team into pairs and ask them ‘What behavior will I, as CEO in this simulation, see today that demonstrates effective collaboration’? The pairs would discuss and write down their behaviors. We then recorded the top behaviors from each pair on a flip-over.

The teams wrote down a whole list of behaviors including ‘Transparent communication – Open and honest’, ‘Feedback - asking for and giving feedback’, ‘Agreeing shared team goals’ A full list can be found in this article on DevOps.com ‘DevOps and Collaboration: Fraternizing with the enemy’.  

When asked “Are these behaviors you want to see more of in your daily work?”

“Yes”! Was the answer.

Do we now all commit to sticking to these behaviors today, in this simulation”?

“Yes”! Was the answer.

Really!

What happened next?

During the simulation it soon became evident that writing down behaviors on a flip-over, and saying ‘we will collaborate’  is not the same as ‘owning them’ and correcting behaviors when they are not being adhered to. In the simulation it soon became chaotic, there was frustration. The business roles were upset, goals were unclear and not being achieved and the list of collaborative behaviors remained an unseen flip-over hanging on the wall.

All in all, just like reality!” declared the teams.

We reflected on what went wrong. It was clear that new behaviors need to be practiced before they become ‘the accepted ways of doing things’. People easily fall back into ‘old ways of doing things’. As one delegate said ‘Giving feedback feels strange, it feels like we are criticizing and blaming”. Another felt that ideas and suggestions were being ignored by the managers in the team, who were busy ‘telling people what to do’, even though they did not know themselves how DevOps practices could work. ‘As a manager it is my job to tell people what to do if they don’t know’.

When the delegate who gave the feedback about ‘ideas and suggestions’ was asked ‘What will you do next time you have a good idea’? The answer was ‘keep it to myself, management is not listening so why bother’!

Within the space of 30 minutes in a simulation, the management style of ‘command and control’ had already alienated the team and reduced the effectiveness of ‘collaboration’. A key concept of DevOps is the third way ‘experimentation’ within an atmosphere of trust. The willingness to experiment was gone.

The team was then coached in the next round and giving feedback. The team felt more in control, there was more trust. The business product owner was happy, business goals were being achieved. The teams started acting as a team and experimenting with the three ways of DevOps. The team took it in turns to run the stand-up and the retrospective between simulation rounds. There was more ‘active listening’ and feedback. It felt good. Results were achieved and Iine managers were not micro managing.

This feels good, why can’t we work like this?’ asked one delegate.

At the end of the day it was time to look back. The team was asked ‘What did you apply today in this simulation that you need to take away and apply in YOUR organization?

These were the key takeaways at the end of the sessions:

People & Behavior:

  • Be clear on your role and responsibilities and of those upstream and downstream. Assign, agree and ensure ‘ownership of tasks’, confirm ‘willingness’ and ‘ability’ and ‘empower to be able to.
  • Take ownership – this creates trust. Saying No! Based upon visibility of WIP, related to goals and aligning to priorities with resource conflicts. Ownership for ‘improvement’ - identify and agree how to remove waste.
  • Agree communication and information NEEDS, upstream and downstream. We make too many ‘assumptions’ and over complicate communication and information flows (multiple fields in tools)!
  • Agree a protocol of communication. Listen, summarize, confirm understanding, don’t make assumptions.
  • Practice effective communication: listen, show understanding, confirm meaning (don’t assume), as a speaker check understanding.

DevOps practices:

  • Frequent feedback with team, e.g. daily stand-up, agree feedback needs with other stakeholders (upstream, downstream and above and below in hierarchy). ‘STOP’ as a feedback tool, whenever a defect is passed or we see ‘waste’ and ‘flow stopping’ call stop and make iterative improvements.
  • Visualize! Build a visual management capability within team, and end-to-end. Let team(s) build VMS to support and enable their work, communication and decision making. Ensure we can see what we are working on in relation to goals and priorities and signal resource conflicts. Visualize improvements and impediments too.
  • Start trying to apply Single piece flow, focus. ‘Stop starting, start finishing’. Use Value Stream Mapping – Make an end-to-end map of a single piece (product) look at waste, where are defects passed, where can testing be built in, upstream and downstream information needs, look at constraints in flow, where is there too much wait time. Make end-to-end dependencies visible.
  • Focus on never passing a defect downstream, working with testing to try and automate tests and working with people downstream to better understand their needs..
  • Stimulate colleagues to look at ‘Integrated testing’, building quality in. Foster a team culture that everybody is responsible for quality.
  • Use problems, impediments, constraints to learn and improve, make improvement needs visible and prioritize them. Ensure WIP is reserved for improvement work as well as business projects.
  • Clarify flow, my (team place) as well as upstream and downstream dependencies (Value Stream Mapping) – identify barriers to flow and waste.
  • Develop more T-shaped skills in team, avoid constraints and bottlenecks.
  • Proactive ‘influence’ – use ‘what’s in it for me’, or ‘what if we don’t’ – what keeps stakeholder awake night or how does stakeholder want to score with his/her stakeholders.

As can be seen above these takeaways were focused on ‘People & Behavior’ and ‘DevOps practices. However, perhaps the most important takeaways were the following two:

  • Know the business goals and how we contribute (or not) to value. Look at work in terms of ‘Value creation’ and ‘Value leakage’. (Balancing between ‘features and outcomes’ and ‘costs and risks’). Often review goals and priorities and ensure all are working to this.
  • Agree what Value is: Revenue, growth, costs, image, reputation, risks and prioritize accordingly. Various stakeholders have different interpretations of value expected. Understand common goals (use these to prioritize) and make visible conflicts with individual and team goals.
  • The Value stream flow is not just Dev + Ops (code-to-commit) but Biz+Dev+Ops+Biz (Idea-to-value). 

These were also key recommendations from experts at the recent DevOps Enterprise Summit. The need to focus on business value and outcomes.

End-to-end behavior change

It is fine having these new insights, and having a willingness to take them away and apply them, but as the team discussed, ‘we don’t have the time to improve, we are filled up with work’. One of the managers who also participated admitted ‘We need to not only foster a culture of continual learning and improving, but we also have to ensure that teams can reserve WIP (Work In Progress) for knowledge sharing, developing cross functional skills and for improvements’.

A product owner who participated also took away an important action item ‘We currently focus on features and do not look at or prioritize issues and technical debt other than P1 issues. ITSM has a different set service levels that conflict with development KPI’s. We need to look at this, we need to look at impact and outcomes, not just features’!

Not a bad set of takeaways for a 1 day workshop with all the stakeholders.  But of course the real test will come when they go back to work. Will they take ownership and ‘walk-the-talk’?

 

About the author:

Paul has been actively involved in ITSM for more than 30 years in the roles of managing consultant, Service development manager and as ITIL developer. Paul was co-author of the ITIL publication “Planning to Implement IT Service Management” and was a member of the ITIL advisory group for ITIL Version 3. Paul is also co-director and owner of GamingWorks, the company that developed the internationally renowned ‘Apollo 13 – an ITSM case experience’ ITSM simulation game as well as Project management, Business & IT-Alignment and DevOps business simulations. He was also co-and developer of the ‘ABC of ICT’ (The Attitude, Behavior and Culture of ICT) publications, having conducted ABC workshops and simulation workshops with delegates representing more than 5000 organizations world-wide.

Like this article? Like

Comments

Post a comment