DevOps may sound like some hard-to-understand technical terminology, related to software development and programming, but I was surprised to find that the rationale behind it allows it to be implemented in many non-technical companies as well. We can all learn and benefit from DevOps.
On 16 August 2016, the Campfire co-working space arranged an evening seminar with Steve Hodson, principal consultant at Runlevel 7, who took us through the ins-and-outs of DevOps. The event was promoted via the Campfire Meetup group in Hong Kong.
Steve started out by explaining the origins of DevOps, moving on to what it isn’t, the benefits of DevOps, and concluded with its five core principles.
Is DevOps technical?
When I headed into the seminar I was prepared for it to be at a fairly technical level, but Steve took us through all aspects of the matter without it being complicated.
Steve explained that DevOps starts with the two biggest – and separate – teams at a software company, that also provides its software-as-a-service (internally or externally). The two teams were the Development (Dev) team and the Operations (Ops) team.
The job of the development team is to write the code. The operations team then has to make sure the code runs well for a large group of users.
Steve illustrated the two team’s roles with an example from the retail industry where the development team’s task is to write an application for a POS (point of sales) system, and the operations team is tasked with running and implementing it.
In the development stage, the application runs without a hitch and everyone is happy. However, when the application moves to operations, where over 1,000+ POS systems are to run the application, the result may be quite different and problems may occur that are hard to explain. Whose fault is it that the application does not perform the way it is intended to? The development team or the operations team?
Do you need two teams?
When a situation like this happens, it is easy for the two teams, development and operations, to start to blame each other. You start to get poor trust, poor collaboration and poor cooperation between the teams. When the management of the company, who is responsible for both areas, starts to enquire why the application is not working as it should, because in the end it will affect the bottom line of the company, it is easy to start to push the blame: “Hey, it worked fine when we wrote the application in development, the fault must be in how it was scaled in operations” and the operations team pushing back with “We ran the application exactly as it instructed. It must be that the design was not scalable to this level”. At the same time, you can ask yourself, who’s fault is it really that the two parts of the organization do not get along? Was there active and ongoing discussions on what each team was doing, their objectives and their deliverables?
Some companies have “done away” with the two separate teams, development and operations, and have only kept the first one. This is most often the case when a company is small and the number of users is limited. But as a product or application becomes more and more popular, you will need an operations team to make sure the customers get the best experience.
Improving teamwork
How do you then make your development and operations team work better together? What can you do from the management’s side to keep the two parts of the organization in sync? Well, there is a formula for it, and it’s called C.A.M.S, or C.A.L.M.S, where the added L stands for Lean.
In short CALMS stands for:
- Culture
- Automation
- Lean
- Measurement
- Sharing
As Steve went through the different letters in C.A.L.M.S and the thinking behind them, I felt that I was less at a software development seminar and more at a change management seminar. The parts of the company may not be called Development and Operations, the company may not even need to write a single line of code, to still have good use for the thinking behind C.A.L.M.S.
We can all learn from DevOps
When Steve got to the S part in C.A.L.M.S, where he talked about “Lunch and Learn”, “Show and Tell” I was happy to realize that what I thought might be a technical seminar turned out to be a really good event for anyone that needs to get two “opposing” fractions of the same company to work together. So – if you need to change the “we and them” mentality of your company, then you definitely have something to learn from DevOps.
/Jens and Gushi
At the pen for Ripple Effect Consultancy
Contact us for more information
Links:
Runlevel 7: http://www.runlevel7.asia/
Campfire co-working space: https://campfire.work/
Ripple Effect Consultancy 