Tag: meetings

DevOps is all about collaboration, we hear.
“You must collaborate,” say managers initiating DevOps adoption programs.
HR make new posters declaring the corporate values “We value Collaboration & Teamwork.”
Can’t fail!
Then when it appears not to be as effective as we had hoped we tell teams they are “Empowered” to collaborate.
Blank stares!
When things still don’t appear to be working we tell teams they are “self-steering,” “self-organizing, collaborative teams”….
Still, we don’t get what we were hoping for.
Luckily the tool vendors come to the rescue and tell us why it is failing. We need “collaboration tools and software” – Throw some “Slack” at it.
Can’t fail!

This is when we usually get frustrated managers knocking on our door asking about the Phoenix Project DevOps simulation. They are moaning about communication and collaboration! When we talk to the teams they are frustrated and moaning about “empowerment” and managers not “walking the talk.”

In my mind these lack of collaboration skills is not really surprising. Why?

Impression: Well, it doesn’t help when the word has also historically been connected to global conflict situations. “He faces charges of collaboration,” “fraternizing with the enemy.” Dev & Ops. Traditional adversaries?

Interpretation: The interpretation of the word itself is also part of the problem. I googled an English Language Help Desk:

Collaboration: “To work together with somebody in order to achieve a single shared goal.”
Cooperation: “Work with other people by achieving one”s own goals as part of a common goal.”

In an HBR article titled, “There’s a difference between cooperation and collaboration,” it was argued  “… Managers mistake cooperativeness for being collaborative,” adding, “… most managers are cooperative, friendly, willing to share information – but lack the ability and flexibility to align their goals and resources with others in real time.” If managers don’t get it then what chance do the teams have when told – “You must collaborate”!

Induction: Part of our failure to be able to effectively collaborate could come from our schooling. We are chastised at school for asking others for help, for looking to see how somebody else is doing it—”That is cheating”—things are changing with more “collaborative assignments.” Yet, my children (now in their early 20s) were not taught what effective collaboration is, other than discovering for themselves. As my daughter explained about her school assignment, “You have to do it yourself if you want it done because others will slink off and not do it, then my individual grade may suffer.” They are told they need to collaborate but individual performance grades are scored. My daughter once came home stressed and almost in tears, declaring “Oh no! I have been given another collaborative assignment for my most important subject!” Children leave schools distrustful of collaborating.

Indoctrination and Imperative: There is also the historical perspective. When we, the current workforce entered our chosen profession we had decades of functional silos that created a “them” and “us” attitude. This stimulates a sort of “territorial imperative” or “tribalism,” not helped by our own “technology” languages and tribal cultures. We have learned over time that other teams “dump things on us” or other teams “stop us from getting stuff done.” In other words, Other teams frustrate work.  (Territorial imperative—”the drive in animals and man to take, hold and defend a particular area, zone, turf,” —e.g. defending their best practice framework! And attacking others that come near!).

Inconsistency: We then built walls between these teams and if they wanted something from each other they needed to escalate it to their manager. Managers would collaborate or not, especially when they were given conflicting, inconsistent goals and KPIs. Development teams are given goals to release as fast and as often as possible. Operations are given goals to make sure everything is as reliable as possible and available at all times.

I had an example of this “them and us attitude,” once with a board of directors. I split them into two teams and gave each team a pack of ABC cards (Attitude, Behavior and Culture) and within 10 seconds heard, “Oh good, our team will win this!” automatically creating an atmosphere of competition and winning and losing, I hadn’t even explained the task yet! Teams compete.

‘It’ factor: A study by Google (2012) called Project Aristotle, named in tribute to Aristotle’s quote, “The whole is greater than the sum of its parts,” looked into why some teams work and others don’t. One of the key conclusions was that “psychological safety” was the “it” factor, “… a sense of confidence that the team will not embarrass, reject or punish someone for speaking up.” Because we have not learned to collaborate and because we have a “them and us” history often accompanied by blame, there is fear, uncertainty and doubt (FUD) about speaking up, sharing ideas or giving feedback.

In the dark: However, there is another significant reason for poor collaboration, as I have discovered from running hundreds of Phoenix Project simulations with teams globally. It is the fact that nobody has defined the “behaviors” that demonstrate effective collaboration. We assume everybody knows what we mean when we say, “You must collaborate.” Fact: We don’t!

Below are the results of a series of recent Phoenix Project simulations. One of the goals was to learn DevOps practices such as CALMS and the Three Ways, while another goal was to learn effective team-working and collaboration.

I asked the teams at the start of the sessions, “What is effective collaboration? What behaviors will I see today that demonstrate this”?  The teams came up with a list of behaviors (each team came up with a top five or six behaviors; this is the consolidated list from seven teams).

• Transparent communication – “open and honest” and “frequent.”
• Calm and constructive dialogue (no blame, accusations and shouting).
• Feedback “asking for and giving feedback.” Constructive feedback.
• Shared team goals (and cross team). What are we aiming for? Impact on others and their goals. Maybe conflicts that need managing.
• Listen – is it clear and understood? Show that you listen.
• Being open for dialogue, being approachable –not closing the door or hiding behind.
• Giving and taking responsibility.
• Sticking to agreements.
• Central moment to get together (e-2-e).
• Knowing the roles and responsibilities, sticking to responsibilities.
• Mistakes are OK.
• Be proactive to get information needed.
• Equal treatment: “Respect” ideas from ALL
• Don’t HOPE, confirm.
• “Willingness.” Confirm and agree.
• Ownership of responsibilities.
• Clear agenda and purpose of meetings.
• Pleasure – celebrating success.

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

Yes! Was the answer.

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

Yes! Was the answer. Easy! See there’s nothing to this collaboration stuff.

However …

During the simulation it soon became evident that roles and responsibilities were not clear or not being carried out; it was not agreed which information was needed by the business nor when; goals were unclear, meaning that priorities were arbitrary; people did not understand procedures and did not ask for help; assumptions were made (“I told you …,” “I thought you meant …”); people taking responsibility were not respected (“Let’s stop and try and sort this out …”)— everybody just carried on running around! “Headless chickens,” said one delegate; people were not listening to each other; there was a lot of “assumicide”; mistakes were made and people blamed—there was no exploration as to why and what can be done to stop these  mistakes. Mistakes were often corrected by somebody else but without giving any feedback to correct future mistakes; agreements were unclear across the team; there was no end-to-end flow—work and information was ping-ponging back and forward.

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

See how easy collaboration is. Within one hour of making a list of desirable behaviors, they were totally, utterly and universally ignored. Nobody appeared to own these behaviors or to confront each other on them.

After the Experiences in Simulation

At the end of the simulation round we looked at the team scores (number of releases, number of successful releases, business value realized). It wasn’t a pretty sight. The CEO wasn’t happy. The team felt stressed, unhappy, frustrated and powerless.

We explored what this had to do with “effective collaboration.” Had anybody used the list of behaviors? No.
Had anybody consciously practiced these behaviors?
No.
Did anybody give feedback on these behaviors when they were clearly not done?
No.
“Giving feedback feels strange, it feels like we are criticizing and blaming,” said one delegate. Another assumption!

“It’s hard,” said one delegate. “The manager needs to manage this,” said another.
“It was YOUR list and YOU all agreed this, why is this a manager’s job to get you to do what you said you wanted to do?”
There was silence. “It’s not easy, we fall back into old ways of doing things, we need help!”

Is it a Bird, Is it a Plane, Is it a Bus? No, it’s a coach!

As the simulation progressed, the team refined their list of desirable behaviors based upon their experiences. They were coached for two rounds and consciously practiced and experimented with the behaviors. The coach role became a critical catalyst.

In the final round the team owned, and were executing on these behaviors without coaching.
Why were they suddenly executing?
They felt less stressed; they were trusting each other; they felt the positive impact on their work; they saw, felt and shared the value gained by these behaviors. They felt immediate positive consequences from these behaviors.
Why no more coaching?
The team were taking it in turns to lead their own stand-ups; they were giving feedback and correcting their own behaviors. These were the additions the teams made to the behaviors as they practiced them.

• Transparent communication – “open and honest” and “frequent” (Relevant, and timely as agreed with the various stakeholders).
• Feedback “asking for and giving feedback.” Constructive feedback. (Related to agreed behaviors and responsibilities, calling stop, then swarming to solve an impediment, constraint, or remove waste; immediate fact based feedback).
• Shared team goals (and cross team). What are we aiming for? Impact on others and their goals. Maybe conflicts that need managing. Understanding strategic portfolio and how we contribute to strategy, show you understand and agree common goals and prioritize accordingly. Goals for both value creation (features and benefits) and value leakage (risks, debt).
• Leadership within team – team members took turns in facilitating the stand-up and retrospective. This role was respected.
• Listen – is it clear and understood? Show that you listen, sender: Ask for clarification, ask to confirm understanding, listener: summarize what was understood and agreed. Avoid assumptions.
• Being open for dialogue, being approachable—not closing the door or hiding behind. All were engaged and equal in the stand-up and retrospective. All were asked for feedback, ideas, suggestions.
• Giving and taking responsibility. Respecting team behaviors; e.g if somebody calls “stop,” or “respect somebody taking responsibility for an improvement stand-up.”
• Sticking to agreements. Confront people to understand why agreement not met and what can be done about it in the future (e.g conflicting priorities, lack of understanding).
• Central moment to get together (e-2-e). Scheduled stand-ups, retrospectives, and improvement prioritization.
• Knowing the roles and responsibilities, sticking to responsibilities, confirming your responsibilities, confronting people on responsibilities (feedback). Showing that you take ownership.
• Mistakes are OK – no blame, so long as it is used as an opportunity to learn and improve.
• Be proactive to get information needed (or ensure information is available, e.g. visible management board, avoid unnecessary “disruptions).
• Equal treatment: “Respect” ideas from ALL. Ask people for input, engage ALL in ideas generation and decision-making.
• Don’t HOPE, confirm.
• “Willingness.” Confirm and agree – “Willingness” and “ability,” empower to be able. Share knowledge, cross train, coach, help.
• Ownership of responsibilities. Confronting people on responsibilities.
• Clear agenda and purpose of meetings. My role, what is expected from me? What is in it for me? avoid “wasting” time in meetings.
• Team coaching to give feedback on behaviors.
• Create trust by demonstrating team behaviors.
• Check understanding and commitment to “agreements” and confront people (feedback) on agreements.
• Improving own work as a team.
• Asking for and offering help.
• Having insight, overview, visibility.
• Limit WIP (reserve WIP for learning, improving, technical debt).
• Pleasure – celebrating success. Product owner shared results including customer feedback. Team complemented each other.

The teams were then asked to make a list of behaviors and actions they wanted to take away and apply. Their line managers and assigned team coaches were there when the list was made and gave commitment to help guide, coach and empower teams to experiment and practice these new behaviors in their daily work.

The team would prioritize one or two behaviors to start with and consistently practice in the coming weeks. When the new behavior becomes the accepted norm and a “habit” they would focus on more behaviors.  This fits in with the Third Way of DevOps: Continuous experimentation and learning. “Understanding that repetition and practice is the prerequisite to mastery.” And to tie this back to Aristotle the philosopher (not the Google project): “Excellence is an art won by training and habituation … We are what we repeatedly do. Excellence, then, is not an act but a habit.”

Meetings, Including Training Sessions!

And finally, one of our industry’s most popular, and wasteful, examples of collaboration are poorly run meetings, which are the biggest time-sink in organizations and a source of frustration. I include some training classes as forms of meetings.

In more than 100 training sessions in the last year, less than 10 percent have started on time.
Nine minutes late is the average. Delegates say this is normal in their organizations. When I ask people what their own personal learning goals are for sitting eight hours in this “training meeting,” more than 25 percent had not defined this and more than 70 percent had not agreed this with the “sponsor” of the training.

We need to manage our overload of wasted meeting effort. How? One way is the ask for goal and agenda in advance, asking what value you need to bring in and what value you need to get from the meeting; also to limit your time to the agenda items relevant for you or your team.

Efficient collaborators decide when they do, or don’t, have unique value to add—“maintaining focus on what matters.”

The same applies to training, asking, “Why am I going on the training?” “What am I expected to learn?” “What problem is this training expected to help solve?”  “What will I be expected to do differently after the training?” “How will the learning be transferred back to the workplace?” “Will I be mentored and coached?” “Will I be given opportunities to experiment?” “Will I get constructive feedback?” “How can we demonstrate that the new knowledge delivers expected benefits?” This is better than the most common answer, “I don’t know I was told to come to this training!”

A training is also a form of collaboration between you, the trainer and the person sponsoring the training.

There is an “I” in Team, after all. “I” am responsible for my effective contribution to team performance.

— Paul Wilkinson