A DevOps process brings a new, more holistic philosophy to product development. Expanding upon the Agile method of quickly and iteratively delivering feature requirements, DevOps also encompasses the necessary system requirements, including everything needed to handle new features in a production system, at a level where the feature will be successful when used.
Much has been written on the positive value of adopting DevOps. Especially from a process and strategy perspective, DevOps improves product development cultures by building with a long-term mindset that intentionally spends time now to save the expense of money, time and loss of competitive flexibility in the future.
The impact of adopting a DevOps process
In theory, no one would disagree with this approach. However, in practice -- in the heat of a financially-driven product delivery cycle -- the temptation among product managers to pass off key system requirements, such as checking system dependencies, install analytics, automate and include documentation, is very real. If there is a nemesis to adopting a DevOps process, it is the incessant push of market pressure to launch new products that improve customer acquisition, retention and revenue. When non-technical managers focus on feature requirements over system requirements, it's likely due to the prioritization of quick and ongoing value to the end user over a long-term system strategy.
While this is a limited viewpoint, this should not be surprising. In most product companies, features are the embodiment of your hypotheses about what customers may want to buy, require, struggle with and desire from your product. What's more, features are much more tangible to non-technical people; they can be literally visualized, mocked up and prototyped, tested in front of customers and so on. Because of this, a new feature grabs the attention and excitement of non-technical stakeholders, your marketing team and C-suite executives who often don't understand what it takes to launch these products from a system perspective.
Organizations must resist this urge to de-prioritize system requirements. Features that are launched without thoughtfully considering the system will undoubtedly become poor user experiences. By ignoring system requirements, well-tested prototypes that are launched in production may very well lag, time-out and crash at scale. Not to mention that without good release automation, deployment can take far too long and be far less reliable, due to errors, conflicts and slower processes. As well, without analytics, there may be no clear way to understand the success, or failure, of the features that have been launched. Finally, if the product is deemed successful or requires improvement, undocumented feature releases will struggle through more hurdles to be improved in future releases.
Combining Agile with a DevOps process
A DevOps process is not antithetical to Agile launch of features. On the contrary, the wider lens of DevOps ensures that the product and features users interact with -- at scale and in a production system -- can be launched with low risk and will work as intended. A high-quality feature user experience demands simultaneous consideration of building a platform that launches reliably through quality automation, is easy to learn from using analytics and is easy to iterate upon applying great developer documentation and scalability practices.
Choose the DevOps process that's right for your programming language
Continuous documentation is an important DevOps process
Start your DevOps process the right way with these best practices