How you start your DevOps journey in your organization will dictate how successful your DevOps initiative will become. Therefore, let’s get the best out of your first and probably one single shot.
As you already know you can’t really shake the status quo in one go and announce an organizational DevOps transformation on day one. You should first identify teams which continuously tackle with issues and unmet goals. The teams which are definitely conscious about the necessity of improvements and who are the most receptive to consider a different way of working. And teams which are unconditionally willing to serve their organization and clients.
Your mission is to demonstrate quick and early wins from your DevOps initiative and prove to skeptics and naysayers the problems you solve and the value you create with DevOps. And then you will step-by-step replicate these improvements in the other areas of your organization.
This is pretty much how a leader ERP, CRM and SaaS manufacturer from Germany set out its DevOps journey. Their maintenance team was doing one single delivery per year which was quickly resulting in an accumulation of non-released code in various different incident code branches. This made for them extremely difficult to merge their code and to release fully tested and reliable maintenance releases.
Their maintenance development team was first combined with maintenance delivery planning, quality assurance and operational environments management teams. They also started using a joint task and ticket management system to simplify coordination and communication efforts. Then they set out monthly and shortly after two-weekly releases.
Within the first year of this new practice in maintenance group, the team managed to resolve 6 times more incidents compared to the year before. As important as that, the ratio of reopened incidents and associated rework reduced from 39% to 4%.
Having had this significant improvement and demonstrable improvement metrics in the pocket, a small DevOps initiative won major support and credibility in the organization and executive sponsorship for the further expansion to other product and service teams.
Another consideration to get started with your DevOps initiative is whether you should choose a Greenfield or Brownfield product and service.
A greenfield product and service is new in your organization. Therefore, it is for your best interest to build a new, separate team which works in isolation, especially while you are getting started. Thanks to this isolation, your team members will have better chance to break the existing status quo and think out of the box. Furthermore, your team will be hopefully less frequently interrupted due to their former responsibilities in the organization. You task your new DevOps team with tangible IT and business performance metrics and outcomes such as improved sales, improved client engagement, or reduced time to deliver etc. As your greenfield DevOps initiative don’t rely on legacy code and dependencies, it poses less risk for you and your team to start a successful DevOps initiative. However, your success will be less impactful in your organization as your DevOps initiative in greenfield will not prove whether DevOps can solve existing problems in your organization and whether your success can be replicated in the other areas as well.
On the other hand, you can start your DevOps journey with a brownfield product and service too. Many brownfield products and services do already run in your production systems, and they serve your business and clients. If you are from the same planet as we are, your brownfield software application is most likely to have significant technical debt and it doesn’t have much reliable test automation. Due to this nature, starting your DevOps initiative with a brownfield product and service could be more challenging and yet positive throughput from a brownfield DevOps initiative will be more awarding, convincing and impactful at your organization.
Many people wrongly believe that DevOps is not tailored for brownfield products and services. Their wrong belief goes even further to state that DevOps is only for start-up companies. And yet some of the most exemplary DevOps initiatives started in companies with giant and mature IT organizations which have countless business-critical legacy systems and thousands of employees. Amazon, Easy and Facebook are a few examples to name. As described with the SaaS manufacturer case study above, you can initiate DevOps in an already existing organization with brownfield products and services too. In fact, because most brownfield products and services have major gap between their performance throughput and client expectations, they are usually the best candidates to take benefits from your DevOps transformation. For you a good piece of advice to get started with your brownfield DevOps initiative is: To begin with, invest your time to remove or at least reduce the technical debt and then build missing test automation for existing product features and benefits. Otherwise, your brownfield product and service will never allow you to do reliable production deployments in shorter cycles.
During your first DevOps initiative, you can feel free to choose either a system of records or a system of engagement. Systems of records are centralized systems to manage single source of truth in your organization. They heavily master on management of your data including clients, transactions, security and privacy. Systems of engagement are mostly decentralized applications to enable and encourage your clients and users to interact with your organization via omni-channel responsive portals or mobile, tablet and desktop applications.
With your preference of a system of record, your advantage will be that you are going to demonstrate how your DevOps team competently handles time consuming and highly bureaucratic tasks such as compliance, security and privacy. You and your team accomplish this by generating scientific and tangible evidence and by using test automation and telemetry during the whole development and operations life cycle of your product and service. A typical example can be a migration program of your geographically distributed data from your on-premise database servers to cloud by ensuring that your single source of truth still remains compliant to legal, industrial, local and international rules and regulations.
If you prefer a system of engagement, you are going to demonstrate how rapidly and reliably you innovate with quick delivery cycles. This is because most of the visible innovations which result in commercial successes today are originated from systems of engagement. A typical example can be a more intuitive and simplified check-out flow in your e-commerce portal which improves your sales 25%. The moment you accomplish this, your executives will not only adore DevOps, but they will adore you too.
In the beginning of your DevOps journey, don’t waste your time to win conservative teams for your DevOps initiative. Identify the most innovative, open-minded, well-connected and influential teams which believe in the necessity of DevOps methodology and principles. Start small with one or two teams. By using the tips provided above, identify the most appropriate greenfield or brownfield product and service… And appropriate system of records or system of engagement to get started.
After your first success stories these teams you have on board will be your biggest supporters to spread DevOps across your entire organization. Then you extend your coalition to other groups and you increase the number of success stories. These successes will create more and more social proof and trust for your DevOps initiative. Once they see the measurable benefits, you will have more support, sponsorship and attention from your management too.
In the final stage you identify influential destroyers and strong naysayers (Curmudgeons). You can probably beat them by using their own technique which is spreading around risk and fear. You explain them how bad their teams and products will appear and become the last weak chain in your organization if they deny learning and using DevOps.
It is not an easy task to drive any organizational IT transformation. DevOps is no exception. However, by starting small, you won’t be taking much risk. On the other hand never forget that it is one of the most profound duties of any young or seasoned leader to be able to motivate and mobilize her or his team to act for the sake of improved business performance… And to take some calculated risks for the best professional satisfaction.