Eliminate Roadblocks on the Path to DevOps Maturity – InApps Technology is an article under the topic Devops Many of you are most interested in today !! Today, let’s InApps.net learn Eliminate Roadblocks on the Path to DevOps Maturity – InApps Technology in today’s post !
Read more about Eliminate Roadblocks on the Path to DevOps Maturity – InApps Technology at Wikipedia
You can find content about Eliminate Roadblocks on the Path to DevOps Maturity – InApps Technology from the Wikipedia website
CircleCI sponsored this post.
In this article, I’ll outline the common roadblocks that get in the way of maturity and offer some ways to get around these obstacles. This is a followup to my previous article on DevOps maturity, where I wrote about why DevOps maturity is a helpful north star that can guide your team.
DevOps Maturity Blockers
As CTO of CircleCI, Rob helps make big technical decisions and keep teams happy and out of trouble. When he’s not testing and continuously improving with the CircleCI team, Rob enjoys snowboarding, Funkadelic and a viscous cappuccino.
Sometimes management is not yet sold on the value DevOps would bring to the organization. Among other things, they might be stuck in the “we’ve always done it this way” way of thinking. They know that no change is without risk, and even with the potential upside of increased productivity, trading known issues for unknown ones can feel scary.
Just as often, the block comes from within the team — developers are often resistant to taking on the increased operational responsibility that comes with DevOps. We’ve also heard from many operations teams who, tasked with maintaining security and uptime, fear any change that might threaten the reliability of their application.
In other organizations, management all the way up the chain of command is fully bought in on the value of the change. This team is ready to go. But both management and development teams find themselves stuck, faced with all that needs to be done prevents them from starting. They approach DevOps with a waterfall mentality, and this desire to make a big shift all at once blocks them from making any change at all. Anything that looks too big, no one will take on — and for good reason.
If you’re the one selling up the ladder, be especially cognizant of this obstacle — there’s a temptation to want to stop all work and do a complete DevOps 180. There’s time pressure to make a change quickly in order to get early results. Combine that with a never-ending competitive push to get features out the door, and you’ll see why many attempts to switch to DevOps stall out.
Laying the Groundwork for Change
Many of the biggest barriers to DevOps adoption are within and between the minds of the folks on your team — opinions and habits known together as “cultural” issues. But “culture change” is vague and can be a slippery objective if you don’t know where to start. Making an effective change requires first knowing where resistance is coming from. While mindset problems can block change from happening, creating change at the culture level is difficult, and even when done well, is only part of the solution.
As I shared in my last article, there are three main pillars (including culture) that moving forward along the maturity curve requires: fostering a culture of collaboration and trust, a commitment to tooling and automation, and measurement and continuous improvement.
These principles are the hallmarks of mature DevOps organizations but are useful even to teams just trying to get started. In fact, taken together, they will help you address all the blockers your team may face along the way.
For example, if management is not yet convinced that DevOps is a smart choice, you may need to make the case with numbers in order to lower the perceived risk. Thinking incrementally about the change makes it less scary, and will get you the positive results you seek sooner. Instead of asking for six months to make a full-scale transformation, ask: what can you do in an hour? Can you build a CI pipeline for one of your 50 projects, and get some early feedback? Instead of automating everything, can you automate one task?
It Also Happened to Us
It’s so easy to be stymied by a huge change looming in front of you and not know where to start. It happens to us at CircleCI as well.
Last year, our team wanted to simplify the way we expose our configuration, making it more shareable. To be honest, the project felt pretty daunting. Then we thought, “How can we pick one important use case and test that?”
We created a way for CircleCI users to write a piece of syntax and share it locally in multiple places. Then we released it to a group of users to get some early feedback. We were able to measure what people were doing in order to get more get feedback about the syntax itself. That early test led to what is now Orbs, and we wouldn’t have had the confidence to invest fully in that feature without the early positive feedback and adoption.
In the final article of this series, I’ll talk more about how to improve your implementation of automation, collaboration and continuous improvement, and get them working in your business.
Feature image via Pixabay.
Let’s create the next big thing together!
Coming together is a beginning. Keeping together is progress. Working together is success.