The Agile Manifesto, published back in 2001, made way for huge strides in software development. Agile methodologies have allowed for the industry to operate within shorter feedback loops and work more efficiently, enabling businesses to evolve into their best version.
Agile initiatives, however, can lack the fine print, so to speak. In the pursuit of brevity and the desire not to be overly prescriptive, agile can be sold or interpreted as a cure-all. Faster delivery, stronger teams and better software are noble goals, but so is caution. It might sound controversial to say, but it is also the reality. There will always be improvements that can be made to existing systems or new technologies to chase – but balancing and prioritizing efforts, while difficult, is key for real progress to be made.
The implementation of DevOps is helping streamline this balancing act and bring more pieces of the Agile Manifesto to fruition. DevOps allows the joining of development and operations for faster delivery and better software. But when an automated test fails and the build pipelines turn red, the intentions of the software bleed through and reveal the behavioral driven development used to create it. However, when implementing DevOps in particular, companies must be cautious about losing interaction with individuals over the pursuit of tools and processes. Responding to change means more than how quickly you can change 10 servers at once.
With DevOps comes experimentation – being agile in approach to solutions and acknowledging that not every path will lead to success is a must. Context, therefore, is key. And just like any agile framework, DevOps requires buy-in. Even if the development and operations teams are working in harmony, it cannot amount to much if the culture stops at the metaphorical IT basement door. Without the backing of the whole of the organization, continuous improvement will be confined to the internal workings of a single group. To paraphrase the healthy living advice ‘this is not a fad, this is a lifestyle change.’
The crucial understanding and shared ownership of committing to DevOps is coincidentally what is missing most from the DevOps efforts. Speaking to the wider community, there is often a sense that the tools are the key, and that once in place, a state of enlightenment is achieved. That sentiment has shifted. For example, people today understand that tools alone don’t make great websites, it’s the teams of people all working together that make for a great digital experience – the same approach should be applied to DevOps.
Technologies, such as the cloud, are shining examples of what DevOps can achieve, but they are also enablers. DevOps offers built-in security and scalability, yes, but also ushers in increased ability to collaborate. More and more companies are using collaborative tools, and more “what ifs” are being considered. Customizable websites and phone apps are great examples of how low code can open up IT for small businesses, but understanding the limitations is also important.
Fast and easy to use, user interfaces make the possibilities seem endless, particularly workflow engines and all sorts of new visual automation tools. But a word to the wise – when you are having to play “spot the difference” between screenshots because there is no export option for your data, it’s time to choose a different tool for the job. Experience is useful and learning from others reduces the learning curve and shortens the feedback loop between you and your customer – which is what DevOps is all about.
You can find more information on our Managed DevOps solution here.