Have your legacy IT processes finally hit a wall?
Let’s see if these 3 examples ring any bells:
- Months to deploy virtual servers (tickets are being thrown over the fence)
- Failure after failure releasing code (Dev and QA environments don’t match Prod)
- And worst of all is how the majority of your teams time is spent firefighting
If you answered yes to all 3 examples you probably need a DevOps transformation to improve your IT service delivery.
Still unsure… Let’s keep going anyways…
5 Step DevOps Transition Plan for Beginners
This DevOps For Beginners guide is concise with only five steps. Each of the five steps builds upon the next. There’s no time limits involved because it could take weeks, or months, for transition to begin. Why? Because each pre-existing culture will adapt differently. In my experience it takes at least 90 days for the first signs of the shift to show up. Time is wasting, so let’s get started…
Step #1 – Start with a Culture Shift
Many IT cultures are cold. And many have been following the same practices that were put into place in the 90s. These cultures are normally referred to as “Legacy IT” and though they were very effective decades ago, today they lack the agility and flexibility to adjust to fast pace business changes.
The first step towards DevOps begins with slow-paced group meetings focused on educating departments on the value of DevOps and to discuss that current shortcoming of legacy IT.
The goal here is to build advocates and enlist facilitators who will ban together. During this time it will be OK to share objections to the changes being offered.
After multiple group meetings, lunch and learns, and videos about DevOps; the culture will begin to shift and more people will share the direction. Also during this time it will be very important to get managers and leaders moving in the same direction. This time of transition is critical and can take 90 – 180 days.
Step #2 – Create Feedback Loops
As will be found with most legacy IT departments, they are very defensive. Focused more on defending their technologies and practices rather than objectively looking inward to see if anything can be done to improve.
Normally there will be a history of failures and problems from the past that still cause pain and a lack of trust. You must be willing to move past all this in order to bring about new alliances and confidence.
Each group or department should begin meeting with their customers (both external and internal) and listening to their pains and grievances. Though it is not easy, it will reveal the areas where healing and mending must happen.
Feedback loops can begin immediately and a backlog of problems should be created that can be worked on to deal with any social or technical debt that surfaces.
Furthermore, any corrections should be shared with the customer for their feedback (never assume anything is fixed without hearing back from the customer). And once there is closure with a problem, it should be celebrated by the team providing the service.
No loop should ever be left open. Step 2 will continue as long as it takes and will eventually becomes a fundamental part of maintaining the DevOps culture. This can begin in the first 90 days and the key here is to stop being defensive.
The goal is to learn to listen openly to customer feedback for opportunities to improve.
Step #3 – Merge Forces and Get Things Done
Another problem with legacy IT is “silos”. What are silos? They are technology boundaries that cannot be crossed by other technology teams. Networking, server, storage, and data center teams are silos.
Most of the time each team is working and building their own processes without engagement or consideration of each other, and sometimes even intentionally making things so difficult that building out a simple virtual server can take many weeks because of the rigor of ridiculous requirements.
Note: All at a cost to the business and developers who sit waiting on IT to get it done for them.
If anything, this is one of the most important value-adds there is for a DevOps transformation. And yet, unfortunately, there may be some people who will need to be forced to tear down walls and silos before it’s over.
Some groups call this convergence, whereas DevOps calls it teamwork.The key here is getting technology teams working together to work down technical debt (backlog from step #2).
Tip: A highly effective way to make immediate improvement is to use embedded resources. For example, dedicating a person to sit with the development team (or customer) and work directly with them. This helps build closer relationships while at the same time exposing them to the pain caused by legacy practices.
Step #4 – Automate Release and Deployment Processes
What would DevOps be without improving the turnaround time for releasing code?
As many have found as they researched DevOps, a key value add is the automating of software and code deployments and releases. This normally includes using special tools to build environments fast from templates or scripts orchestrated by run books.
Many of these tools and skills are new, and are in high demand for businesses seeking to move to public cloud using IaaS or PaaS. Once the culture and feedback loops are in place improving processes can begin.
The key here will be finding talent who have expertise with these tools, who can script, and can build the automation processes needed. Read more about automation training.
Step #5 – Continuous Improvement
Once your IT department begins the journey towards DevOps, be prepared because there will be push-back, frustration, resignations, and disruption of the status-quo.
Many will find the changes too painful and will give up for the easier path. And in some cases – maybe there is another solution for them. However, for those who wish to really test the boundaries of new technologies, tools, and processes, continuous improvements can happen as more and more daily systems are transformed and become efficient. All giving back more time to focus on better solutions because less time is needed to put out fires.
At this point you have moved beyond transition and into transformation.
Warning – Let me share a friendly word of advice about avoiding the temptation to build an exclusive team of players who are cherry picked to form an elite DevOps team. In my experience where this was done, it generated a culture of resentment and elitism.
The goal of DevOps should be to enlist everyone so anyone can participate and share in the fruits of success. Tread carefully here so you don’t make the same mistake.
I know this DevOps for beginner’s guide only scratches the surface. And honestly, DevOps isn’t a one shoe fits all solution. It will take some trial and error before you get it going…
But as you begin your transition you may find there are other steps or actions more important than the ones listed above – this is good. Why? Because that means you are sensitive to the NEED instead of just following a set of rules or instructions (this means you get it). Adapting to the need is a true indication you are learning and being transformed. Good luck and thanks for your time and interest.
In this guide we covered processes, now learn about the DevOps Skills you’ll need to cultivate for your transformation success…