There's a reason DevOps culture values effective communication and collaboration so highly. In an industry where distributed offices full of crucial roles are the norm — and one where even departments within the same buildings tend to distrust one another — any improvement in the way people interact is bound to have some positive results, especially when so many moving parts need to work together for a product to come in on time and under budget.
In fact, team play is so important to DevOps that you could really sum up most of the methodology's goals for improvement with two Cs: collaboration and communication. While it takes more than that to truly become a DevOps workplace, any company that has committed to those two concepts is well on its way.
You may or may not know what so-called "siloization" is, but you've undoubtedly heard these four poisonous words at some point in your career: That's not my job.
In other words, too much buck passing can wreck a project (and the relationship between the departments building it) in no time flat. Nobody likes being forced to do extra work, let alone by people they don't work with on a regular basis. In the development world this practice is often called "throwing it over the wall," and it's characterized by creating or encountering a problem, then passing it to another department.
Worse, all sorts of complications can turn even small "throws" into big problems. In a standard, non-DevOps office, developers, operations and QA staff effectively speak different professional languages, an issue that makes communicating even basic issues and desires difficult. Then there's the fact that many departments are too busy working toward their own goals to think about the overall needs of the business — they can't see the forest for the trees, in other words.
Instead of treating these departments like disparate entities, DevOps culture is designed to break down the silos, cutting back on the not-my-job problem by putting departments in close contact with one another and focusing them all on the same goal.
How do my development and operations departments communicate now? Is there room to shake things up by restructuring the way teams operate? What sorts of skills do my existing personnel bring to the table? These are the kinds of questions you must ask yourself as you transition to a DevOps culture.
The changes can be as small or radical as your business's needs dictate. Cross-functional teams can be a huge boon, for instance, involving putting multidisciplined groups of developers, testers, operations personnel and others together, and then having each member contribute code to a shared, preferably version-controlled repository. By that same logic, some experts recommend hiring full-stack developers, otherwise known as devs who can handle tasks below themselves on the totem pole (think QA and database administration, among others) when needed. While training your devs and ops people on what other departments do won't technically transition you to a DevOps culture, it can yield big results on the communication front.
It's also, of course, best to test these changes before implementing them on an office-wide scale. Try to make too many changes at once, and none of them will go as well as they should've.
While automation and team building don't seem related at first glance, the former definitely promotes the latter in DevOps culture. If the basic challenge behind DevOps is "staying in sync when both sides are moving," as this post from DevOps.com notes, then automation helps by reducing the number of moving parts that need to be synced.
Take automated security testing as an example. In a rapid-deployment environment, it's rarely feasible for developers to follow the standard build-test-deploy way of doing things. If your devs have to send a candidate off to the security/testing people every time they come up with one, cross-talk will undoubtedly take up huge amounts of time — and that's when things are going well!
Platforms such as Veracode's, which automatically test code for security issues on off-site hardware, keep departments in sync while reducing the amount of overhead effort needed for a deployment to happen. When you factor in the importance of consistent security measures, automating at least that part of your development process starts to sound like an excellent idea from every angle.
Communication and collaboration will challenge every software-producing business as rapid deployment becomes the norm. That makes paying serious attention to how your departments work together a smart move no matter what the context. The more integrated and familiar your employees are with one another, the less painful (and costly) communication has to be — a benefit that helps everyone involved in the production process.
Photo Source: Flickr