DEVOPSdigest

This is part 2 of a 3 part series in which we explore keys to building high-performing DevOps teams. COVID-19 has shifted the way we work and has changed the dynamic of how we communicate with our teams as many learn to work remotely for the first time. Part 1 explores how to organize your teams around customer value. Now, let's discuss team alignment and collaboration.

Key 2: Team Alignment and Collaboration

Some research that I come back to frequently was done by Google as part of their Project Aristotle(link is external). They did multi-year research on 180 teams to answer the question "what factors are most conducive to high-performing teams?"

The 5 factors they isolated were somewhat surprising, and can be summarized as:

1. Psychological safety: members feel safe taking risks with each other.

2. Dependability: members reliably complete quality work on time.

3. Structure and clarity: members have clear goals and responsibilities.

4. Meaning: members have a sense of purpose in their work.

5. Impact: members feel that their work is actually having an impact.

The issue of psychological safety reminds me of the quote "Where there is fear you will get the wrong numbers" by W. Edwards Deming. Fear functions to inhibit open communication. In a knowledge-working organization that's lethal, as people won't share anything that smacks of bad news. But as the saying goes, "bad news ages badly."

Most of these topics are issues of culture and mission. Nevertheless, tools can help in some of these areas. For example they can help you:

■ Promote timely and transparent communication

■ Track and collaborate on plans and schedules

■ Track metrics and team goals

Very importantly, they can also connect your builders with their impact on end users. Continuous Delivery closes the gap between admins/developers and users, thus increasing motivation. Feedback from users closes the innovation loop. It's almost useless to build something and then have to wait 90 days to get feedback from end users. But if you can build something and start getting feedback within hours or days it's incredibly satisfying and opens the door to constant and incremental improvement.

Tools should ease and facilitate the collaboration process. Just as agile planning tools excel at enabling collaboration around work items, so version control excels at enabling collaboration around code. Ensure that any other tools used to manage testing, deployments, monitoring, etc. also allow for a single view of the work in progress that allows for input from all relevant members of the team.

Alex Sutherland from Liberty IT Solutions(link is external) recently shared examples that illustrate these points based on his own experience of teams he'd been a part of.

"The lowest performing team I can recall being part of was an early SaaS startup. I had been invited to join the team as a QA analyst/ engineer. There were a number of challenges, but there were two main things lacking. One was a well-understood, user-centered design, and a clear, precise mission for how we were going to accomplish that. The second big gap was that we lacked any sort of application lifecycle management tooling to help us iterate quickly on the application. It resulted in kind of a classic failure in application development.

"The team were some really great people and talented engineers, and there were a lot of factors that could have contributed to success. But because we were hampered by a lack of the tooling that we really needed to be successful and a proper design approach, we struggled. Ultimately I left the team, and eventually the startup failed. It was really disappointing to see, since so much time and effort was wasted. Even at that time there were plenty of tools available that we could have utilized, but that hadn't been prioritized or invested in. As sad as it was, that was a tremendous learning experience for me. I did a lot of study afterwards about how we should be doing things to be effective as a team, in contrast to what I had seen on that project.

"In the years since that time I've been blessed to work on a lot of high-performing teams, sometimes by accident and sometimes as a result of focused effort. One of the biggest contrasts was on a project which was frankly a much more adverse environment. We were walking into a project that had been perennially failing. We were the fourth team to come into that environment and there were a host of issues, from failing test suites and broken functionality to lack of documentation and many other things. We had a very small, focused, and determined team with a strong vision from our leadership and strong support for us to be brutally honest with the customer and tell them what they needed to hear, not what they wanted to hear, unlike what they'd been hearing from previous teams.

"There were some inexperienced folks on the team, but we communicated constantly and effectively to support each other. There was no pride or siloed responsibilities like "this is my job. That's your job." We did whatever needed to be done. We identified issues, prioritized them, and we made implementing a continuous integration process a priority. In contrast, all the previous teams had not made continuous integration a priority and thus had failed because there was a lack of transparency and visibility into all the impacts of the metadata and the code. It was a very sprawling and monolithic architecture. But we were able to move from a state of extreme dysfunction and an inability to deploy into production because things were so broken to having a stable, if not yet healthy, environment and codebase within a matter of just a couple of months. From there we were able to move forward to developing new functionality and working through some really difficult migration and implementation issues together.

"It was the combination of the tooling that we implemented and radical transparency, honesty, trust and communication that allowed us to show them exactly where the issues were and what we were doing to resolve them."

Read 3 Keys to Building High-Performing DevOps Teams - Part 3