Choose your language:
July 6, 2017
By Michael “Doc” Deady
Address DevOps, or continuous delivery you cannot.
If you’re trying to achieve a DevOps culture shift, you may have surmised tackling such an endeavor with just a definition is akin to solving world hunger with a single Happy Meal. You're right—introducing DevOps is incredibly difficult and it's not for everyone. Over the years I’ve had the pleasure and misfortune of taking part in some very large DevOps initiatives. While I’ve seen some success in uniting the goals and processes of development and ops teams, the time, resources and money spent often outweigh the benefits. I believe this is mainly due to an architecting of the DevOps team that focuses on winning the battles and not the war.
In other words, when developing an action plan to implement DevOps, look at the maturity of each group within the SDLC process versus how applications are delivered to production. Then formulate the plan to implement a DevOps shift in smaller pieces that make both groups feel a part of the winning team.
“When nine hundred years old you reach, look as good you will not.” – Yoda
Most of my background has been on the development side of IT but I started in operations—mainly networking and server administration. I’ve also been part of teams delivering tools like Remedy, ITSM and BSM.
Sometimes when the executive team drops the DevOps buzzword bomb, I wonder how much they really understand the psychology of their operations and development teams. I’ve come to understand that IT operations teams believe their process maturity and business value outweighs that of what they perceive as development’s chaotic processes. Ops teams operate with a conservative, keep-the-lights-on policy, partly because of management methodologies riddled with toll gates like documentation time and resource reviews. They face customer satisfaction issues and shrinking budgets.
On the other side, development-driven teams have numerous technology goals, strategies and methodologies, and they work with a capital project-driven roller coaster budget that leaves no resources for fixing the bugs in production. Basically, development groups operate within the realm of controlled chaos, which makes it hard to see eye-to-eye with orderly ops teams.
This disconnect often plays out when the dev team uses Agile but don’t include the testing teams in the unit, and consider operational support an afterthought. When we exclude part of the team from Agile processes of the business, testing, and operations, aren’t we really defeating the principles of Agile?
For many in the IT industry, DevOps may be a buzzword, but I believe continuous delivery (CD) is an attainable goal—even for development teams who struggle with the smallest of changes. Focusing on some simple key areas that have nothing to do with process will help you achieve continuous delivery in the long run.
To achieve a DevOps culture, you should take these four steps in order:
1. Increase transparency
Does any team or individual have real-time visibility into what another group or person is working on during development and testing cycles? I’ve found most teams try to achieve transparency via verbal communication, probably the most ineffective way to communicate. The average person comprehends and retains an estimated 25 percent of what’s told to them in the first 10 minutes of any meeting. Retention rates drop off sharply after that. Visual methods are your best option to communicate information. This doesn’t mean writing everything down in a daily status report; it means everything you’re working on should be visible to everyone else on the ADM team.
2. Open communications
Clear, real-time communications between individuals, teams and departments within the SLDC and post-implementation is key. One factor is that all communications must meet the four C’s: complete, concise, consumable and correct. Ask yourself if operations and/or the business share a reasonable expectation of development deliverables? If not, you can reasonably assume most of your current problems are due to lack of communication. This doesn’t just pertain to departments; it is true between teams within the SDLC process. For example, is your testing team included in the vetting process on user stories or business requirements? Does development share all unit testing results with the analyst and testing teams? It all boils down to the same thing: No one person or team has a clear picture at a given point within the development process. Status reports aren’t a true reflection of the SDLC process since in most cases they are subjective, inconclusive and have no direct correlation to actual data.
The quickest way to integrate people and processes is actually by addressing that problem indirectly, by integrating their tools. This will help you achieve transparency and open communications, and it also addresses inefficiencies within your teams and the overall process. For example, when a tester finds a defect, count the number step, process, and email that are the generated from that one piece of code. That same defect in an integrated environment can be resolved within hours instead of days—with no emails required.
When I was working as a tester, every single time I escalated a defect to the dev team, a developer would argue with me. I started including more information for every defect to the point where it took me hours to enter a single one—but the arguments only increased. It turns out developers were more upset about the amount of time that had passed—they hate switching their focus. Lesson learned: Integrating tools helps you resolve issues faster and with less fuss. Most people don’t realize that to integrate tools in today’s market may take you less time than this article, but most groups within the SDLC process are so siloed that getting everyone onboard to approve the integration of tools could take weeks—or even months. Is this due to the fact that we lack trust between teams? Improving communications and transparency can help foster that trust, but it also brings us to the fourth leg of the stool: accountability.
4. Introduce real accountability
Only once you’ve achieved transparency, better communications and integration, can you truly address the issue of accountability. Accountability isn’t just pointing fingers, it’s being able to identify and address issues in the most efficient manner to improve delivery. In the ‘70s and ‘80s, when Japanese car manufacturers were outselling and outperforming American-made cars, it was a hard lesson for Detroit to learn. They needed to understand that if you don’t address accountability within your own organization—outsiders surely will.
“The dark side clouds everything. Impossible to see the future is.” – Yoda
Ask your team the question: Is application development driven by the projects or by the business need? Do they use application quality as the only metric, or do they factor in cost vs. quality, and time to market as a competitive differentiator?
It doesn’t matter if you’re an individual contributor or the CIO, change only needs a champion with a plan to be successful. Remember in the case of IT—the dark side leads to complacency, and complacency leads to inefficiency. If you’re looking for a place to start, simply look at solutions that address three aspects delivery critical to business success.
Care to share your own DevOps experience and advice? Leave a comment below.