A year ago, the executives at phoenixNAP decided to embark on a new project – to create a flagship product that would be part of the solutions portfolio. The executives challenged the way products are developed and wanted to explore new ways of launching products swiftly.
Following internal discussions, the decision was to try out a new method of developing products. The decision was to go with a DevOps team.
In this article, Peter Borg, SCRUM Master at phoenixNAP, explains the necessary steps and challenges to be overcome to transition to a DevOps culture.
Steps to Transition to DevOps
Historically the company has faced some issues with a traditional Agile setup, which has led to delays in delivering projects. If a SCRUM team is operating at full speed to achieve a goal, but the infrastructure is not ready, delivery is delayed. Department segregation might create a situation where a supporting team might not have the resources to support a SCRUM team. One department alone does not deliver software products, and that is what we wanted to change by transitioning to DevOps.
1. Create Self-Sufficient Teams
To kick start the new DevOps culture change, we formed a new team whose job descriptions were unique to the company. We moved away from full stack developers to DevOps software engineers, and from SysAdmins to Site Reliability Engineers (SREs).
Note: Check out our article to learn what is the difference between SRE vs. DevOps.
By doing so, we were able to formulate a self-sufficient team, and its goal was to deliver the project at hand. Hiring the right people was vital, in addition to having expertise in specific aspects of the new technology stack where they can deliver the product without relying on people outside the team.
SREs were tasked to code the infrastructure, Software Engineers to develop the applications, QA Engineers to set up the automation testing frameworks, and Software and System Architects to design the solution.
Even though people were earmarked for specific tasks based on their area of knowledge, we promoted the cross-pollination of knowledge. SREs contributed to the software code, software engineers pitched into our Infrastructure-as-Code (IaC), QA was involved with our Test Driven Development (TDD) strategy and Continuous Integration (CI) pipelines, and Architects helped out with development and troubleshooting.
2. Embrace Test-Driven Development
Everyone hates big-bang releases, which causes problems with discovering late integration issues, refactoring complex solutions, and possible product vision divergence.
To not fall into these pitfalls, we opted for test-driven development (TDD). TDD allowed us to break down, implement, test, review, and expand complex solutions while always getting feedback from the Product Owner (PO) as we went along building the product. This iterative approach and feedback loop gave us the ability to continue improving a feature after establishing a strong foundation, which is the first principle in the Agile Manifesto (Kent Beck et al., 2001). The most important consideration to keep in mind when adopting a DevOps approach is to make sure that the team does not tie themselves emotionally to their implementation since it might be there one day but gone the next.
By opting for a TDD approach, we implemented complex problems with non-over-engineered solutions. TDD is an iterative approach to developing features making refactoring easier to achieve while also adding quality to the solution. “Start somewhere and learn from experience” (John Shook. 2008. Managing to Learn: Using the A3 Management Process to Solve Problems, Gain Agreement, Mentor, and Lead).
3. Push the DevOps Culture Change
Introducing culture change is not just hard. It’s exhausting, frustrating, and demoralizing. Pushing a different mindset in a multi-structural organization is a lot harder than building a company culture within a startup.
That is why I believe change can be achieved by treating them in the same manner. If you are trying to build a different implementation methodology within an already established company, it is achievable only if you create a mini organization ecosystem. Form team structures that the company will perceive as a startup when implementing a new project.
You will be faced with restraints, such as “That’s not how we do things” or “We already have different tools for that.” If you hear those statements, you are on the right track. Questioning the company’s processes and tools is the first thing you need to do when proposing a culture change. Consider whether the existing tools and methods are relevant at all.
In our case, by questioning, we were able to leverage Cloud Native technologies as opposed to systems that the company had considered as ‘standard.’ You will not have buy-in from everyone in pushing the DevOps change. However, having support from top executives is critical. It will help motivate people within the company who are less open to change since the vision is supported by higher up management.
4. Test Your Progress
Test the progress of your efforts at various DevOps transition stages.
Start by testing the velocity. You want to be agile and implement solutions quickly. By comparing the ‘startup’ project to other ongoing or historical solutions, you should be able to know whether the DevOps team is delivering faster. It is also essential to gauge the team’s ability to adapt to change. If changes from the feedback loop turn out to be an overhaul of the system, then something went wrong during the design stage.
Secondly, measure success by analyzing the team’s morale. People should be excited and motivated when a new adaptation of implementation is introduced. You will realize that you have achieved this by overhearing someone from the team talking to somebody outside the team, explaining how we managed to solve a problem using the new mentality or technology, which is new to the company. This will spark interest from other teams and, it’s at that point that you’ll realize that the culture change is spreading throughout the organization. Consider that the real measure of success – the new DevOps methodology gets noticed. Other team members want to try out things differently and come to you for advice on how to tackle problems using DevOps solutions.
Learn more about DevOps Metrics and KPIs you should be tracking.
5. Be Uncompromising
When I took on the role of SCRUM Master, I knew I had to deliver a new product and a DevOps culture change as fast as possible. It was imperative to keep both goals aligned throughout the product development phase. When faced with such challenges, buy-in and trust from executives can make or break a culture change. At times, management might not concern themselves about how a project is achieved as long as it’s delivered – even if we have to fall back onto an outdated technology.
That brings me to my next point, start with a blank canvas. Do not try to fit the current company standards into a DevOps way of developing software. Start from scratch and maintain a lean solution. Let the team research the best tools for solving a problem. If they identify a solution that the company is already using, all well and good. If they don’t, then present the new tool to whoever champions the current solution to get their buy-in to changing it. Ensure the team keeps in mind that nothing is set in stone, tools can change, someone might have a better idea, and requirements can change; it’s iterative.
phoenixNAP is a global IT services provider offering IaaS, including Bare Metal and Cloud services, as well as Colocation and Disaster Recovery solutions. Peter’s DevOps team developed phoenixNAP’s latest product – Bare Metal Cloud. It provides our clients the ability to provision servers swiftly with automation tools, and implement an infrastructure-as-code approach.
6. Transition Other Teams to DevOps
Once the DevOps culture change within this micro organization starts to bear fruit, you need to consider the next step – growth.
How to transition more teams to DevOps?
The Toyota Production System (TPS) philosophy (Toshiko Narusawa & John Shook. 2009. Kaizen Express) seems to fall in line with Spotify’s Agile Scaling model. Maintaining an organization structure that is as flat and self-contained as possible is key. That empowers teams, making them more accountable for their successes and failures. Instead of forming departments of same-skilled people, set up ‘Chapters’ where these members form part of SCRUM teams and encourage them to liaise with each other to help solve problems. Promoting constant communication retains the project priority within the team..
Set up knowledge-sharing events to inform other departments about any technical decisions the team has taken. Knowledge sharing will help drive a company-wide transition to DevOps and rally up support across the whole organization. We’ve learned a lot over the past year, and we are continually looking for ways to improve our processes and structure through different iterations. Retaining the mentality of being lean and agile and ensuring the product is a success story will be the most important factors to maintain.
Final Advice on Switching to Devops
The last and most crucial point for anyone transitioning to DevOps is never to give up. There will be times when you will think that embracing a DevOps culture is hard to achieve, but if you have the right support system, from the team, management, and executives, you will get there. A day will come when someone from another team will request a meeting wanting to know how you implemented something.
That’s when you realize that the company is on the right track to accepting a DevOps culture. Spread the philosophy from one team to another, in phases, and take your time to move the entire organization to DevOps.
