Sitting with a developer from Github at an AWS conference a few years ago, I watched in awe as he reviewed the company’s continuous deployment philosophy and process. The concept was amazing; construct your projects in such a way that you can deploy anytime (in some cases 10-15 times a day). To contrast this, I regularly work with clients where their deployment process can take over 6 weeks from beginning to end (meaning they might have 1-2 deployments a quarter). While the differences between these organizations are many, one key difference can be summed up in one word: DevOps.
What Is It?
DevOps can be a hard and confusing topic to discuss because everyone defines it a bit differently. For the purposes of this article, we will define DevOps as a philosophy that marries agile principles of development with the operations team that will maintain a solution on its infrastructure. Organizations that adopt this mentality have some common characteristics:
- Organizations that embrace a DevOps mentality spend as much time in the early phases of a project evaluating how a project will be tested, deployed, and evaluated once in production as they do on the architecture of the software they are creating.
- Organizations that embrace a DevOps mentality automate nearly every step of the testing, deployment, and environment creation process.
- Organizations that embrace a DevOps mentality can release their software on-demand.
- Organizations that embrace a DevOps mentality can provide concrete data performance of an application in production.
Is It For Us?
In discussions with enterprise organizations, many are quick to assume that a DevOps culture would not be a fit within their organization. They understood that companies like Amazon, Netflix, and Facebook have achieved a high degree of success with this philosophy, but the thought is that kind of success is not possible within traditional enterprise constraints. However, in the past years, we have seen DevOps succeed in many traditional enterprise organizations including USAA, Disney, and Nationwide.
The important question for most organizations to ask is whether they can afford to not develop a DevOps culture. In a recent article, I highlighted key Agile Health Indicators for organizations. One of those indicators was Lead Time – the amount of time it takes to go from idea to production within your organization. While not all organizations can release multiple times a day (some due to compliance and validation rules), long gone is the day when we told users to wait six months for a feature. Organizations who cannot get new features in the hands of their users on a regular basis are fighting a losing battle.
Organizations should take time to evaluate these key questions to determine if a DevOps culture shift is needed within your organization:
- Developer Instances: Does each developer have access to a development instance which closely mimics the production environment? Are the settings / configuration for this instance in version control? Is the instance creation process automated?
- Cloud (if deploying on a cloud platform): Is the application built as a cloud-first application? Are you fully leveraging the functionality provided by the PaaS/IaaS or are you building custom software that mimics what the platform already provides?
- Deployment: Is the entire deployment process to any environment automated? Is the deployment process considered of equal value to the system architecture within your organization?
- Testing: Is a majority of the application and integration testing for your solution automated? Is your application tested on every commit to the source code repository?
If you answered no to any of these questions, it may be time to consider adopting a DevOps philosophy.
Like all aspects of development culture and methodology, DevOps is not a silver bullet. I have worked with organizations that have developed bad DevOps practices which are affecting their quality of delivery. However, one can also not deny the track record of organizations that have embraced DevOps wholeheartedly.
If you are looking to scale DevOps holistically within your agile organization, you should be encouraged that DevOps is a key component of the Scaled Agile Framework. By having DevOps as a part of the shared services team, you can ensure that you have a scalable team which can respond to needs across multiple agile release trains or even across multiple portfolios.
If your organization wants to look at how to adopt a more agile approach holistically, you may want to consider leveraging Universal Mind to perform an agile assessment. This onsite review will enable you to know key areas that need to be addressed to develop an agile culture and eventually a DevOps focused culture.