It’s all in the game!

Blog by Paul Wilkinson, GamingWorks (link)

 

Digital disruption is now forcing many IT organizations to embark upon Agile transformation initiatives to adopt new ways of working such as Agile, Lean, DevOps and ITIL®4. Yet many organizations underestimate and struggle with the cultural and behavioral challenges when transforming the way they work.

 

Glenfis organized 2 Phoenix Project DevOps simulation workshops to explore DevOps success factors in addressing these challenges.

 

We asked the delegates what are the challenges they are facing with their adoption of DevOps or Agile ways of working, and what were they hoping to discover by taking part in this workshop.

 

Current challenges:

• Poor communication between Dev & Ops.
• Conflicting focus – Ops on stability, Dev on new ideas and speed.
• Ops end of food chain, not involved and take the blame.
• ‘Get rid of the boring testing’ it slows things down moaned the person playing the business manager role in the simulation, echoing what he hears from his business.
• Conflicting management KPI’s and goals. Somebody has to lose! Causes protection of resources.
• CISO is challenging and gets in the way.
• Hybrid DevOps….. What ‘kind of THING’ is DevOps?
• Lack of belief in value of ITSM and ITIL, a call for ‘No Ops’.
• Business & IT gap, a need to converge on goals.
• Unclear what the ‘Why?’ is for DevOps, what are the goals of DevOps?
• Reduce waste? Be able to do something new with speed? Automation? Change culture? These were some of the answers. It often appears that ‘DevOps’ is the goal.

 

Compare these challenges to challenges we captured from more than 100 organizations at the DevOps Enterprise summit in the USA.

 

The good news and bad news about these challenges is this. The good news is ‘you are not alone, this is normal, it’s all part of the game’! The bad news is this, it is normal, but it will cost time, effort, energy and commitment to deal with these challenges, requiring new leadership, communication and collaboration skills. Not more certificates! But more capabilities!

 

Learning objectives:

These were the learning objectives delegates hoped to realize by taking part in the simulation.

• How DevOps can help bridge the chasm between Dev and Ops – and help realize effective collaboration.
• How DevOps can enable an end-to-end process and help us work better across the company.
• Be convinced about the value of DevOps.
• Learn how a simulation can be used to convince people and support an ‘Implementation’.
• Experience DevOps and get ideas for improvement.
• Assess what do we currently do right, and what we can do better.
• Discover what DevOps really means?

 

‘…….Er……’

 

In one of the workshops the team’s first exercise was to explore ‘What is effective collaboration’?
One of the answers was what we typically hear in global engagements ‘working together to realize business value’.

‘But what behavior will I see that shows that’? I asked.

 

‘….er…’

 

“This is often the point, people don’t understand the desirable behaviors we want to see that show we are working effectively together”.

The team expanded this description ‘People ask what are the goals for success? We see people using goals to make decisions, to prioritize work’.

 

Other behaviors the team agreed:

• Common ownership of goals – ask how does this work contribute to the goals? Confronting each other on choices. Confirming we all understand the goals and priorities.
• Helping each other ‘daring to ask for help’, asking if and how you can help.
• Communication: active listening, asking question to clarify understanding, summarizing, reducing the ‘Yehbuts’ (Yes but!). Respect peoples’ opinions.

 

During the simulation the teams reflected between each round of the simulation and added to this list of desirable ‘collaboration’ behaviors:

• Ownership for WIP (Work in Progress) limits and escalating when full to agree priorities in line with the goals.
• No hierarchy in team stand-ups, no blame feedback.
• The need for team coaching to help practice these behaviors and give feedback and coaching.

 

There are more examples of team discoveries on ‘effective collaboration’ in this posting on DevOps.com. The important point here is that these are behaviors that the team identified, discussed, agreed and practiced.

No gain without pain and pain is part of the game!

The team played 3 rounds of the business simulation. In each round they explored DevOps practices and had to effectively communicate and collaborate. At the end of each round the team had a chance to practice ‘continual learning and improvement skills’, reflecting on what went well and what needs improving, then experimenting in the next round to determine the success of their iterative improvements.

The initial rounds were characterized by chaos. Despite having an agreed list of behaviors these behaviors were not ‘owned’ and there was no ‘feedback’ on these behaviors. As such the teams struggled to collaborate and communicate, they struggled to translate DevOps theory, such as the 3-ways and CALMS into practice.  Having the theory is one thing, but getting the end-to-end team to apply this in practice is something entirely different. They experienced the pain caused by lack of visibility into a complete backlog of work, unclear prioritization, no insight into WIP being done and WIP limits, unclear value goals, no ‘flow’, work was ping-ponging, there were continual disruptions. Some people were frustrated, stressed and angry, they did not understand the new ways of working but did not ask for help, they made assumptions instead of confirming. ‘I recognize this. A lot!’ said one delegate.

During the reflection between the rounds the team made three critical discoveries:

• It is impossible to become experts overnight. Adopting practices like DevOps is all about ‘continual learning, experimenting and improving’. There will be pain and frustration.
• Teams are immature in the beginning and need coaching to help them practice and to give them feedback as well as new knowledge that they can test and apply. Teams will need coaching in the agreed ‘collaborative’ behaviors.
• Managers must empower teams by creating a safe environment to practice, and by allocating time to learn and improve.

 

The teams also recognized that when people don’t behave as agreed it represents in fact a ‘behavioral defect’ – DevOps stresses ‘never pass a defect down-stream’, they also learned the importance of ‘Feedback’, this also includes feedback on behavioral defects. Giving feedback requires a safe, blame free environment and trust. There is more on this in our recent posting on DevOps.com.

After three rounds of iterative improvements the teams had significantly increased the velocity and amount of work flowing through their system, they had also increased business value (in terms of share price and revenue growth). How come?

We finished the session by asking delegates ‘what did you apply today that enabled this improvement, that you need to take away and apply in your organization – your first step in continual learning and improving’?

These were the key takeaways:

• ‘Flow’ – We need to apply value stream mapping. How does work currently flow, how much time to process work? How much waiting time? How much waste and rework? Do this with end-to-end stakeholders.
• Visibility – built by the team, for the team. To show constraints, flow, e-2-e improvement needs, business portfolio targets & goals, priorities, progress, results expected vs results achieved, WIP limits, WIP used, 3:1, 1:3 – Multi-functional capabilities. (3 people should be able to do the same team task, 1 person in a team should be able to do 3 team tasks).
• Stimulate a ‘safe to say stop’ culture – respect this rule. People feel safe to say ‘I don’t get it’, to give feedback, to confront undesirable behaviors. No blame.
• Create coach roles to help embed new behaviors, also ensure that ‘time’ is reserved to experiment, to learn, to improve – match the coaching and improvement focus to specific team maturity and capability to improve.
• Foster a culture of ownership and responsibility – by building ‘flow’ (process) together, building visual management board together, practice calling stop, rotate the facilitation of the stand-up and retrospectives between team members.
• Explore ‘Integrated testing’, build quality in, stimulate ownership for ‘testing IS your work’, focus on ‘never passing a defect (work or incorrect information) down stream’. Stimulate Test Driven Development (not testing at the end).

 

Collaboration is one oft he most important Soft factors

Acording the recent upskilling survey from the DevOps Institute (DOI) there is nothing more important than having good collaboration skills (link). While knowledge of automation and processes is very important for DevOps implementation, good team collaboration is the key success factor. This simulation has clearly shown this to all participants. But how do I promote and demand good collaboration? This doesn’t happen by itself and overnight. This simulation together with an experienced coach is therefore an ideal help in every DevOps journey – no matter where the organisation is today: either at the beginning of DevOps to raise awareness, or when starting to build first DevOps teams or even when the organization is already scaling up DevOps. For more Information about the Simulation, please download the brochure here or get in contact with the coaches from Pontine.