Fotolia
4 DevOps communication principles to get teams talking
One of DevOps' supposed benefits is better collaboration and communication, but it doesn't come out of nowhere. Address these communication challenges to get everyone on the same page.
The creation of a dedicated DevOps team to manage a build-and-release pipeline and automate deployments can enable functional teams to create, test and release code quickly. But any new team or specialty almost inevitably slows things down.
With a DevOps specialty team, the hope is that the organization will go faster, because the group automates processes that were previously manual and error-prone -- except that it rarely works out that way. DevOps teams' projects can vary wildly. Changes in job roles and team organization create plenty of room for misunderstanding, confusion and mistakes. That might manifest in the building of the wrong features, failure to get teams to adopt features, incomplete features and other problems.
To overcome these challenges, you'll need to develop effective DevOps communication habits. A good place to start is with the executive technical staff.
Establish a clear path
To get DevOps communication right, executives should communicate the vision, set priorities and accept feedback. Typically, the vision will be shared in an annual group or division all-staff meeting, which is far from ideal. In this setting, DevOps will simply be another item on the agenda. This approach is antithetical to a core DevOps principle: smaller-sized changes, more often.
It's difficult for a senior executive to determine what's realistic and what's ideal for an organization's vision. Middle management might blindly follow senior leadership, or they might be disconnected. Discussions with technical staff can make people uncomfortable. If people don't speak up in meetings, or they typically opt to follow the crowd, you might have to seek constructive feedback in a one-on-one conversation.
An executive who manages by walking around and engaging people in conversation can make people uncomfortable, but that's not necessarily a bad thing. DevOps is, in many ways, a service to the technical staff, particularly programmers. Identify their problems, and determine what could accelerate delivery. Set the vision according to these findings.
How tools fit into the communication equation
Tools are a tempting answer to DevOps communication challenges. An ordered list of tools might include:
- wikis and instant messenger over emails;
- email over Powerpoint;
- Powerpoint over formal documents; and
- short documents over missives.
A purist will say that it's still too easy to use all those tools and fail to communicate. Yet the order of preference in the tools also tends to move from fast, responsive, two-way communication toward heavy, plan-driven and push-out-without-feedback tools at the end. The tools we pick really do influence how we communicate.
In respect to setting priorities, the easiest way to do this in DevOps is to make a small, terrible schedule, and then let people react to it. Shake things up a bit. The physical details matter. If it is easy to move things on a schedule, people might. Instead of an electronic schedule, book a room for a month and place sticky notes on the white board that include the features to build. Invite people to move cards around or invent their own.
Cement the product
Line managers -- a group that includes product owners, Scrum masters, various types of leads and the occasional development manager or producer -- take the vision and priorities of the executive and turn them into a product roadmap.
While the vision belongs to the executive, the software teams are unlikely to agree. For product owners, crucial skills include basic listening, empathy and distillation techniques -- except the customer is likely in the same building, not an end user. Take the vision from the executives and run lean coffee sessions with the software teams. Attempt to understand their problems, and use democratic techniques like dot voting to get unbiased feedback.
The concept of DevOps is vague and hazy, so you want to lay things out so that people can respond. Suggest some things, and when people see your ideas -- good or bad -- they will realize what they don't want. This might spur them to tell you what they do want.
Some organizations do not view DevOps as a product, and, thus, don't have a product owner. In that case, expect some confusion to arise from both the staff and the executives about what the team should deliver, and when. Make the information readily available, respond to questions and adapt plans to change as needed.
Don't forget the person
Beware misunderstandings that lead technical teams in different directions. Let's say the DevOps team talks about containers, Kubernetes, Docker, blue/green deploys and infrastructure as code, while the programmers care only about getting code out the door. Unless the DevOps group can explain how these features help programmers, they will face resistance.
Nobody wants to develop a service that no one uses; doing so can even threaten your employment. To avoid that, blur the differences between the groups. Go to lunch. Listen to them, and see how your efforts fit into their day-to-day work.
Be conscientious, sympathetic and patient with your collaborators. If they feel like they don't have any control over a project, or they sense they will lose something, you might face resistance. When that happens, step back. Observe the conflict, but don't participate in it. Find ways to restore your coworkers' sense of control.
Communicate up and down
Ultimately, communicate what you want to do with workers up and down the chain, then listen and adapt.
Break the work into smaller, easier-to-understand chunks. Consider other ways to communicate, such as face-to-face sessions, that enable you to listen and alter your response. Voice or messaging apps are also useful ways to foster two-way DevOps communication.
