Building A Better DevOps Culture Within An Organization
With the advent of DevOps, many companies made the shift. It wasn’t an easy one, but companies made the effort to think it would transform them into an agile powerhouse. Little did they know that DevOps culture would shift so much in the coming years that the very concept of DevOps would change. About a decade ago DevOps was a myth only under operation in companies like Netflix and Facebook. When the concept of DevOps arose, its only purpose was enabling proper communication between Development and Operation teams. Now, DevOps is considered more as a continuous pipeline from planning to production. With changing ideals every few years we need to build a healthier DevOps culture to promote proper adoption throughout the industry.
DevOps Through The Decade
DevOps has seen many eras since the decade that it has been around. We will give you a brief timeline of how it has changed over the years.
DevOps Early Days – Those days were all about uniting development and operation teams to bridge the communication gap. The main goal was to stop the blame game among Operation engineers and developers. DevOps proposed solutions in terms of “communication” but no tools or processes. So, figuring out how DevOps worked was up to the managers.
DevOps and Containers – In the early 2010s is when container technology really got the buzz through brands like Docker that offer platform as a service product. Container technology helped develop tools and technology for DevOps. It took DevOps culture from being merely a “philosophy” to a set of strategies that organizations began to practice.
Everything DevOps – Around 2014 a major shift occurred from DevOps only being about developers and operation engineers to including many other stakeholders. This is when software testers, quality assurance engineers, security experts were also included int the DevOps collaboration strategies. In other words, the whole organization became a part of the seamless mechanisms of DevOps. This lead to the rise of DevOps 2.0 i.e. “Everything DevOps” in 2016.
Continuous DevOps 2.0 – In recent years whenever someone talks about DevOps all they discuss is that it is supposed to be “continuous”. It is not a set of steps that you need to achieve in order for your organization to be fully agile, rather continuous efforts occurring at all stages of a project. This concept of “continuousness” has led to the development of a concept called “continuous everything“.
DevOps Is A Culture
DevOps targets teams across the organization to work in sync right from the start. All teams including Dev, Ops, and QA need to uphold their end of the process to enable successful and on-time completion of the project. This is where DevOps steps in. The cultural view defines how teams should work the way they’re expected.
“DevOps is a culture, not a role! The whole company needs to be doing DevOps for it to work.” -Mike Dilworth
DevOps covers organizations of all sizes leading from Enterprise-level organizations to startups SMB’s. It abstracts management and communication strategies for every organization. All these strategies are only successful upon continuous integration and efforts on the part of senior management and team members. They don’t take you to a specific end state, rather help you continually improve and transform into an agile organization.
Why Do You Need To Change?
With so many deliverables lined up, there is no surprise that organizations need to deliver both stability and new features. This is where DevOps steps in. In a DevOps environment, teams can share codebases and benefit from the continuous integration throughout the SDLC lifecycle. If you haven’t already shifted to DevOps here are a few reasons you need to do so.
DevOps directly influences the speed of development. Since DevOps is all about continuous collaboration between different teams, it increases the speeds developers write code, and when it progresses to the production phase. Usually, teams take anywhere from 6 to 8 months to completely develop a product. Using DevOps this development cycle can be broken into shorter cycles, hourly and weekly ones.
DevOps culture supports the agile development methodology. By boosting collaboration and inducing iterative development cycles and, modular programming practices the work of development and operations teams is made comparatively easier.
The cultural goal of DevOps is to establish within organization practices that provide the user with high-quality software offering outstanding experiences. At the end of the day, DevOps helps organizations maintain meaningful relationships with their loyal customers. With outstanding customer experiences, companies can better their recovery times, lower change failures, and improve deployment times.
With benefits directly relating to better production of software, companies can reap greater benefits as trust increases among their customer base and the word gets out.
How To Build A Better DevOps Culture
Even though DevOps has transitioned from the “philosophy” phase to a full set of strategies and tools, some organizations still aren’t properly implementing the DevOps culture.
“Too often, these teams code themselves into a corner with mountains of proprietary scripts that actually add more waste to the system, instead of removing waste from the system, which is what the driving forces behind the DevOps movement are all about.”
– Mike Kavis, Cloud Technology Partners
We have noticed a few practices over the years that have led organizations to develop a healthy DevOps culture through and through.
This is perhaps the most obvious one since DevOps is all about communication and collaboration. For this reason, it is probably the most important one. It is highly advised that all teams stay in the communication loops at all times. The method of communication may be email, text, or proper communication tools, it does not matter. What matters is that the teams are on the same page.
The communication stream needs to take place from C- level positions down to new hires. We often hear the question “Should we start using Docker, or should we start using Kubernetes?” and it baffles us. The essence of DevOps culture is “communication”. How can you skip to tools and technologies without focusing on that simple fact? These tools are all great ones, but they won’t do you any good unless they enable “good communication“.
The key to building a better DevOps culture requires a serious mindset change. It requires everyone in the organization to step out of their comfort zones and start talking to people that have different skill sets. You can’t just hire a “DevOps engineer” and expect your organization to miraculously shift to a healthy DevOps culture. The transition sure isn’t easy, it requires a big change, but doing so will keep everyone in the loop.
Project Management with a DevOps Approach
DevOps has affected the management just like all other departments. Project managers followed a monolithic waterfall approach towards software completion in usual development lifecycles. DevOps however need the project managers to change along with their dev teams. They can no longer focus on just calling meetings and drawing up monthly charts.
Just as DevOps culture promotes agile methodology in the dev and ops departments, it can work in project management too. You see agile methodology is more than just a software methodology, it is a process of Continous Integration/Continous Delivery, reducing project delivery timelines. Project managers need to set up shorter timelines, checking up on their teams as they follow through the process, rather than calling a meeting at the end of the month.
Projects need to be split using microservices architecture just like development was. Consequently, projects can be split up into much smaller pieces of individual objectives/ deliverables. This strategy gives more velocity to the project progress over time. In organizations following DevOps Culture, PM religiously follow these strategies.
We always follow the agile methodology while developing solutions for our clients. Moreover, when Novateus started to adopt the DevOps culture, we designed our own project management software, Cuewel. We follow a microservice approach for every project, dividing it into weekly deliverables that can be reported accordingly.
Promote Thinking Out Of The Box
Organizations stick to what they know, processes, change management, development cycles, and many more. All employees follow these practices. This mundane approach leads to an overall decrease in productivity. Ever wonder where brought ideas like Uber and Pinterest popped out from? These were minds that think out of the book. They come up with the needs the customers didn’t even know they had.
In DevOps terms, you can look at it through an organizational perspective. Encourage your employees to think of solutions for in-house processes. When given the opportunity, people can come up with a counterproductive solution to problems that have since long existed but never identified.
In a healthy DevOps culture, creative thinking is rewarded otherwise these ideas die down with the flow. Promote a culture where these ideas don’t get belittled or worst bashed, rather taken with a grain of salt and implemented where necessary.
Using Existing Human Resource
Too many blogs suggest general approaches like establish good communication, etc. While that may be one of the most important aspects, some insight into how exactly we should approach this integration is helpful. Right of the bat, people assume the most effective solution is to hire a “DevOps – job title”. This can be an engineer, specialist, or anyone with some experience in DevOps.
While this may be the most obvious one, it is not the most productive or affordable one. Employee retention is as important as any other. The existing human resource is an asset to your organization. They know more about your business processes than any other expert recently hired. Retention is every bit as important as the recruitment of new DevOps employees. Additionally, people are convinced that new talent helps you achieve DevOps operability.
You need to focus on the talent within your organization first, people that are open to change. You can offer training to willing employees. It is six times more expensive to hires new employees than making use of those who’re already working within.
Two Pizza Teams
There’s a new concept of “two-pizza teams” that emphasizes the concept of building small enough teams that can be fed with two pizzas. Amazon has shaken the world of DevOps using this concept. It adheres to the concept of making smaller communication loops within teams. Each team is a microservice that works to develop software within shorter development cycles. The concept behind Jeff Benzos’ concept is quite simple. More people means more coordination, more unnecessary communication, more chaos.
The more communication links each team member has to keep up with, the more dysfunctional the team will become. This simple concept of microservices and micromanagement makes things a lot easier. Members withing a two-pizza team don’t have to face excessive communication overhead atop their already piling workload. The concept that “there’s strength in numbers” is no longer applicable. You should promote small teams that can create, innovate, and test their visions. Functioning autonomously these teams can lead to a better DevOps culture throughout your organization.
DevOps is not a small shift, it requires an organization-wide change. Saying that a company is not excelling solely for the reason that it isn’t able to promote a healthy DevOps Culture isn’t fair. A change this great requires a lot of effort on the part of the organization as a whole. We can advise you to start small. Take a walk around your software house. Spend time talking to your employees, fishing out talent open to adopting this change. Moreover, using some of the tips mentioned above you can pave your way toward a healthier DevOps culture. We think we’ve made our point clear so, what are you waiting for?
Novateus is a custom software development company dealing with the development of software solutions. We have years of experience working with both our offshore and in-house teams. If you need any help understanding anything or have a question please contact us.