As we’ve discussed before, the ever elusive DevOps culture doesn’t form magically. Rather, it is fostered by building a collaborative environment. While there are many ways to skin the cat in terms of what kind of tools organizations use to start collaborating more effectively, the tool set and the process they enable should revolve around some key principles. The following strategies can help guide organizations to choose the right infrastructure to foster a transformative DevOps culture and support DevOps collaboration.

Centralize And Unlock Knowledge

One big mistake some organizations make as they embrace DevOps is they consider their automation tools as knowledge repositories. But things like recipes, manifests and YAML files are great for automation, not collaboration, explains Alan Sharp-Paul, CEO of ScriptRock.

“They are an awful way of storing desired state,” he says. “Desired state should be visible. It should be easy to understand and simple to modify by any stakeholder. If the systems that define your desired state are not open and accessible then collaboration will suffer. When knowledge is locked up, collaboration breaks down.”

Sure, there may not be a super platform for everything, but centralize documentation with pointers out to the right details, says Chris Clarke, senior vice president of product management for CollabNet, who suggests that this place should show how work is spawned and what is being asked of whom, where work is being outputted, where to find all of the tools being used across the development and deployment lifecycle and visualizations, diagrams and step-by-step details about important processes.

“It’s almost like a mall map. ‘You are here,'” Clarke says.

Enable Timely Communication

Of course, knowledge doesn’t stand still and there are always day-to-day snags that come up, so constant communication is fundamental to the collaborative process.  Many DevOps and Agile leaders find the success they see in speeding up iterations stems around the experimentation they’ve done in developing a communication channel that work for their teams.

This usually starts with using a chat platform like HipChat, FlowDock, or Slack, and frequently continues by pairing that with task managers like Trello, Asana or Basecamp.  Many organizations are also integrating IT-specific tools like Git, PagerDuty and Raygun into this mix.

And, increasingly, DevOps teams have been up-leveling that by implementing GitHub’s open source side project, Hubot, a chat room automation bot that helps teams share scripts,  automate tasks and enable simple deployment tasks and keep everyone else apprised of deployment.

The sky is the limit for creative combinations—the key is that the overall stack facilitate timely and meaningful communication across the team.

Find Ways To Visualize Technical And Process-Based Interdependence

So, what about SharePoint to accomplish these goals? The problem with SharePoint, says Matt Selheimer, chief technical evangelist for ITinvolve, is that it really isn’t designed around the workflow and the dependencies of IT-specific work. As he explains, most organizations never get beyond the stage of using SharePoint as a glorified file share.

“That’s not going to help you understand risks and relationships and dependencies and nobody has time to go and read through all those documents and try and parse them anyway,” he says, explaining that a collaboration platform should be able to help various employees track activity around applications, policies, servers and what have you that they have a stake in. When someone else is touching those specific objects, they should be alerted and connected with the resources necessary to look into potential issues, resolve any problems that arise and potentially suggestion improvements on current progress.

Componentize Knowledge

Centralization is important, but that doesn’t mean that knowledge should necessarily be consolidated.

“You need to componentized it correctly—in other words, you don’t try to write a 40-page document, you use a wiki or something that should change pretty frequently,” Clarke says. “I’m a huge fan of continuous improvement in everything, including this.”

Selheimer agrees.

“We don’t think that trying to capture everything in one giant, massive document and have it be reviewed by a committee is effective because it’s never going to get published  It’s going to be outdated,” he says. “Whenever I ask people about what diagrams do they have to use to manage their environment, they always say, ‘Oh, we got Vizios.’ But they’re all six months out of date, right?”