I've recently read the eBook 'The DevOps Mindset' published by Rackspace which provides some excellent real world examples of how companies have successfully realised DevOps optimized software/application development lifecycles.
DevOps, a movement that encourages and requires the collaboration and far closer communication between Development and Operations departments in order to achieve Continuous Delivery has three broad areas of focus:
DevOps was born out of the increasing demand for companies (not just enterprises) to bring new products and features to market in faster and faster timescales while maintaining a high quality of offering. It has been on the back of this trend that the DevOps movement has been propelled to a business critical status as if you're not able to keep up with your competition or customer expectations we all know the way the story can end.
Rackspace have interviewed four senior level IT executives who have successfully transformed their businesses to fully practising DevOps entities.
James Kenigsberg, CTO at 2U Inc says:
"The first step is opening up the lines of communication between your teams. Remember, the term 'DevOps' is a blend of developers and operations, bringing two silos together. So to achieve true DevOps collaboration, you need your employees to really think and act as one, not just be merged together in name only. By pushing communications from the start, everyone gets a better feel for others' needs and how they do their jobs. They then take those things into account while doing their own jobs - working not just for themselves."Jeff Hackert, Engineering Manager for Riot Games, has similar thoughts and says:
"When I got to Riot there was a culture of certain personal heroics in operations, but the cost was quite high and the resulting silos turned into some real challenges. The team that I started working with that really has a lot to do with this change was working with infrastructure; they were working specifically with Chef, but it was a small team of software developers working to implement technology that both developers and the operations team needed to participate, and there was no scenario in which the silos could remain and we could reach any kind of definition of success."So it is clear that understanding other departments' responsibilities, workloads and personalities is absolutely imperative to create new processes and lines of communication which involve Dev and Ops working together. Jim Kimball, the CTO at HedgServ (a global independent fund administrator) says of his own experience:
"I think the fundamental shift toward DevOps started when we got away from focusing on individual team goals and elevated our conversation to organizational goals and let the teams drive toward them."James Kenigsberg, when asked what he would recommend to another company interested in beginning DevOps, puts these ideas forward very well:
"Align your tech department with your business needs. We have areas specifically aligned with the business (those responsible for learning tools are in Learning Systems; those who run the backend are on Business Systems). Each area is fully loaded with a full stack of every role needed for a full software development lifecycle. Because employees are aligned to the business mission, it makes them not just people completing tasks, but turns them in to a nucleus of your company to achieve your mission. It's not about the amount of code they write or tickets that they close; it becomes their goal to achieve the mission of the company."So here we start to look at the idea of each department having one of everyone which is touching upon the idea of cross functional teams which include both Dev and Ops - something Jim has successfully adopted.
Still on the subject of cross functional teams, Bharat Krish, Vice President of Tecnology for HBO (Latin America) says about his:
"There's a considerable amount of overlap. It's a startup culture, and a lot of times people roll up their sleeves to get things done, so you might find my software developers who develop a product supporting the product as well. If they don't have involvement in support, they may not know the context behind what they're building - they wouldn't know how to enhance the product, So it's intentional that I encourage the cultural overlap."Finally James Kenigsberg goes on to describe his essential components (which although in a different order) describe People, Process and Tools:
- Automation: If you're doing something more than twice, you should think about converting it into an automated task. Automation ensures your process is repeatable and reliable; it standardizes the execution of the task to the best way every time, without any risk of deviations from peer-reviewed code to improve the process for the whole team.
- Transparency: Transparency gets employees from these groups to take an intimate look into what the others are doing, improving communications and business processes for all, not just for this in your department.
- Talent: You want employees from these groups to take an intimate look into what the others are doing, improving communications and business processes for all, not just for those in your department.
In SummaryWhether you want to create higher levels of efficiency, greater levels of productivity or hopefully both, a cultural change will need to take place.
"But how do we change ingrained culture, attitudes and behaviours, let alone break silos?" I imagine you are thinking. The answer could be to book a free DevOps Lift Off workshop to baseline your current DevOps state and plan where you want to take your business utilizing DevOps thinking.