I hope that got your attention. I do not mean containers in the sense of ‘containerization’. Sorry. It was a way to get you to open another blog on DevOps culture, as opposed to DevOps technology.

However ‘Container’ terminology is a cause for DevOps failure.
Why?
A critical aspect for success in DevOps is ‘communication and collaboration’. Very often I see posters of new corporate values pinned on the wall ‘Customer focus’, ‘Professional’,  ‘Collaborative’ ….All container terms. They don’t actually describe behaviors that we can see or measure and are open to 1000 different interpretations by 1000 different people, which makes it hard to get consistent, repeatable team behavior.

‘Effective collaboration’
At the DevOps conference in Athens I conducted a Phoenix Project simulation to explore with a team of managers ‘effective collaboration?’ – ‘What behavior will I see that demonstrates this?’ At first they listed container terms like ‘Empathy’, ‘Respect’ – I asked them to be more specific. ‘What will I see happening that demonstrates this?’

This was the list THEY made.
– Gather together in one room, discuss project goals & what needs to be done
– Defined and agreed procedure to deal with conflict / issues
– Sharing knowledge about goals, agendas, problems of other members
– Be honest if you don’t know ‘no blame’
– Agree and commit to ‘what is best for team’
-Team stand-up
-Team reflection

This was an important activity. Why? DASA (DevOps Agile Skills Association) has developed a competence model which looks at 4 key ‘Skills & Behavior Areas’ and 8 ‘Knowledge Areas’ that are critical for DevOps success. One critical skills area associated with ‘effective collaboration’ is ‘Team building’, which stresses the importance of having a ‘common purpose’ (Degree in which the team has identified, shared and committed themselves to shared goals / common purpose). It is important that a team agrees a common way of working together.

There is no right or wrong about these behaviors. This is what the team themselves said was ‘effective’, what they wanted to see happening. I asked if they would all ‘commit’ to do this for the simulation. They all agreed. As this is what they wanted to achieve in their own organizations.

Round 1
In the first round of the simulation the team totally ignored the list of behaviors. They all operated in SILOS, not as a team. Goals and priorities were unclear. When conflicts and issues arose nobody escalated this or took ownership for resolving. As game facilitator I could hear people mumbling. ‘This isn’t working!’, ‘I am confused about the way of working’, ‘Why doesn’t the VP IT Ops do something?’ There was little evidence of the behavior ‘be honest’ and say you need help. Team members did not ask ‘What are the goals? What did we agree and promise to the business?’ There was no visibility of the work being done……It was time to reflect.

Assessing competences
If we use the DASA competence model to help us review what happened. An important ‘dimension’ in the DASA ‘Team building’ skill is ‘giving feedback’.  The team had clearly failed to address this need. As Mattias Skarin, one of the presenters at the conference and author of the book ‘Real-World Kanban: Do Less, Accomplish More with Lean Thinking’ stated in his conference speech ‘Authority – hold each other accountable for work ‘done’’ before handoff.

A further critical DASA skills area is ‘Personal Leadership’ (Personal Leadership is your skill to act as role model towards colleagues. It means encouraging collaboration and ensuring that you and your team keep sight of the ultimate goal to deliver business value). One ‘dimension’ within this area is ‘commitment’. The team had said that they were ‘committed’ but did not behave that way. Another ‘dimension’ in this skill area is ‘building empowerment’ (Stimulating the behavior to give control to others and being supporting and inspiring). Manager roles did not ask if team members needed help or coaching in the new agreed ways of working.

Ownership
‘Who owns this list of behaviors you made at the start of the day’? I asked at the end of the round.
There was silence then somebody said ‘We all do’.
‘So who looked at it, and who acted as you agreed’? I asked. There was silence.
This is a symptom of a third DASA skills area: ‘Courage’ – taking the initiative, challenging others in the team.

Throw them in the container!
See how difficult collaboration is! It is one thing to have a set of ‘container’ terms defined and pinned up on the wall, like ‘team rules’ or ‘corporate values’, but these need to be ‘owned’ and ‘lived’ and it isn’t just the manager’s job. In a DevOps team you expect everybody to display personal leadership for team behaviors and focus on doing what is right.  If not then you might as well throw the lists into the container or bin.

When teams are starting on their DevOps journey there is a critical role for leadership. For coaching the team, fostering feedback, stimulation people to stick to and confront each other on team rules.

Making improvements
A fourth key DASA skills area is ‘Continuous improvement’. The team was now challenged to hold a ‘retrospective’ to identify and agree some improvements before the next round. First they revisited ‘effective collaboration’. The team identified some new behaviors to add to their list.

– Criteria to prioritize
-Telling business WIP limits only accept what is realistic
-Agree when is team successful. Visualize & measure.
-Know the strategy and goals.

During the next game round they also started practicing with Visual management, and the ‘Second way’ of DevOps – feedback. They practiced calling ‘stop’ when the flow wasn’t working and agreeing iterative improvements. They also started confronting each other when behaviors were forgotten, or when people fell back to the old ways of behaving.

Falling back to old behaviors is normal!

As the ‘Third Way’ of DevOps ‘Continuous experimentation and learning’ states, there is a need for ‘understanding that repetition and practice is the prerequisite to mastery’. This was also confirmed in Mattias’s presentation in the conference ‘the need to focus on changing habits and behaviors’.  But let’s not make excuses and forgive ourselves by saying ‘DevOps is new we have to learn this’ because as Aristotle said around 350 b.c. ‘We are what we repeatedly do. Excellence, then, is not an act but a habit’.

Round 2
The VMS contained (left to right), the Strategic goals for each business division, the features or incidents relating to these goals (prioritized) and an overview of who is working on which initiative and what the WIP limits are. The visibility in the second round enabled rapid decision making and prioritization when resource conflicts occurred. Testers had a better overview of the work that needed testing. Testing was ‘shifted left’ ensuring quality was built in and defects were not passed downstream. What was the difference is scores between the first round and the second round? After all the team had defined desired behaviors as measuring success.

 

Round 1

Round 2

Number of applications deployed

2

4

Percentage of successful deployments

50%

100%

Percentage of issues solved in the same round

0%

50%

But even more importantly Revenue targets had been achieved and an increase in share price by prioritizing initiatives that were aligned to strategic goals.

Finally the team was asked ‘What were your key takeaways? What will you take away to apply in your organization?’

– Collabortion is critical! – but DIFFICULT! (Coach teams). You must ‘want to’ and ‘commit to’ rules of collaboration
– Not ALL work can be done! – Prioritize with business
– Measure everything – metrics matter
– It must be iterative – small improvements
– Saying ‘STOP’ when flow isn’t working and improve
– Visualize the workflow and show WIP and WIP limits
– Clear strategic goals (new business features AND technical debt)
– Test Driven Development – shift left, build quality in

Summary
In 4 hours the team had learnt a lot.
Not only theory, but also using DevOps techniques during the simulation. More importantly they had learnt and practiced effective communication and a CORE DevOps capability ‘Continuous experimentation and learning’. At the same time capturing and committing to concrete improvement actions to take away. Not a bad Return on Value of a training intervention.