For organisations who have or are considering committing to a DevOps approach, that headline must send shivers down the spine.
Bodies such as Gartner do not post headlines lightly and it is clear that some fatigue appears to be setting in with many organisations. Why is this early enthusiasm being overcome by fatigue, replaced by frustration and failure to deliver the benefits hoped for?
How does the dictionary define fatigue?
Fatigue: “a condition characterised by a lessened capacity for work and reduced efficiency of accomplishment, usually accompanied by a feeling of weariness and tiredness”. Fatigue can be acute and sudden, or persist and become chronic. Sound familiar? You are not alone.
Many organisations have started to feel like this within their Change functions. Before you’ve even managed to mature in Agility, you’ve moved onto DevOps, BizDevOps or even DevSecOps. The rate of adoption and change is relentless. Covid’s impact on 2020 has led to increased pressure to modernise ways of working in a pursuit to maintain competitive edge.
But this doesn’t have to be the case, nor should it be. In fact, we want to present a more positive story and try to set the record straight in defence of DevOps. Change Fatigue isn’t healthy and sometimes sets in when we make mistakes in the early stages.
In this article, we have listed many of the DevOps “Anti-Patterns” we often see emerging. To help, we have included some information on what you could do about them. Though snippets of the wider picture, we hope they resonate with some of you.
Anti-Patterns:
Dev and Ops remain silo’s
DevOps is an amalgamation of both “Development” and “Operations” teams. It symbolises the need to form strong collaboration and the removal of silos. Yet, these two siloed parties remain quite independent within the new DevOps function.
A good acid test to this anti-pattern is to ask the question; “when do you first engage the operational team?”. If your response is “before production deployment”, you run the risk of missing the whole premise of DevOps. You must engage Operations at the earliest possible time, in design stages in fact.
You should aim to create a paired type programming collaboration between teams, leveraging their extensive knowledge to your advantage. Operations teams often offer many service improvements which could help the value stream. We recommend you get these ideas into the Ideation funnel. This can also help in converting your company culture from project to product-led.
DevOps and Continuous Delivery confusion
Companies often implement “DevOps” but seem to end up with no more than some test automation and automated deployments. This delivers improvements but fails to deliver the wider transformational changes and values unlocked by DevOps. To achieve the more valuable Holy Grail that is cultural change means overcoming the fatigue that occurs as early setbacks suffer.
Continual monitoring, exploration and the feedback loops we strive to maintain and shorten, are vital to our ability to build the best version of our code, in the shortest time frames possible.
The experimentation enablement DevOps brings to the table is an equally core component, yet often missed or deemed low priority.
Test Automation vs Continual Testing
We see a trend to push hard for Test Automation but this often translates into a tendency to “automate everything” regardless of the ROI delivered. These two test paradigms are often confused but in fact one is a subset of the other.
Continual Testing gives a large clue in the name, it never ends, though this doesn’t mean we will never exit testing. What it actually means is that we agree on a level of testing which all code must pass ahead of any release. We automate replicable tasks and our test teams constantly enhance and maintain all test suites. We further conduct exploratory testing on all code to see if we can break this, providing timely feedback to our developers.
Test Driven Development (TDD) vs Unit Testing
If your development team writes unit tests after your code then you might have a reason to worry. This is smoke and mirrors unit testing. TDD is a complete mindset change.
In true TDD, you continue to think about how to write your code through first creating a test case. You then create code to pass this test case. Upon passing, your code is fit for purpose. You’re thinking about the end goal of this particular piece of code rather than how to code the solution. It doesn’t end there. You should first look to pass your tests, before looking to inspect and adapt your code. This way you’ll create the leanest possible solution to “pass”.
Thus, TDD is not only striving for elegant code, it is also forcing the developer to reduce technical debt.
Continual Exploration, learning and development
One of the largest aspects DevOps culture looks to unlock is the pursuit for continual exploration, learning and development, which “psychological safety” underpins.
This should be a leadership responsibility and aim from the outset. In a DevOps culture, people must feel confident that it is safe to “fail”.
You should aim to build trust in your colleagues, facilitating their creative flair and innovation. This in turn means they will try new ways of working and share their learnings and observations in a relentless pursuit for improvement. The hardest part of this? Being comfortable that not all ideas will work and using these as platforms to learn from.
SoWs not aligning with DevOps principles
On a similar topic, it’s common for the outsourcing of some, if not all, of the software delivery lifecycle. This in isolation is fine. However, the end user wishes to unlock all the benefits DevOps provides, yet will sign up to contractual obligations which puts a dagger through the heart of the transformation. Why? Due to the lack of flexibility to enable continual exploration, learning and development.
It is typical to see a multi-tier supplier approach, all trying to achieve DevOps. However, they limit what they can truly deliver due their waterfall release schedule. Releasing on a cadence-based strict policy means the ability to go to market is now inflexible, complimented by a release management procedure which may not be up to date with modern ways of working. Doesn’t sound too helpful right? Flexibility here is key. Strong working relationships and agreements are critical to enabling both parties to maximise benefit realisation.
Pre-production release process miss match to production
It is far too typical that companies set up a CICD pipeline for pre-production which follows a set of automated scripts that enables them to deploy consistently throughout their various pre-production environments.
This is a great first step and I wouldn’t discourage this; it means we have strong confidence in our process and lowers the risk of deployment to production. So much so that it’s a non-event as we test it hundreds of times prior to release.
This benefit is not realised if the deployment approach is different between production and pre-production. If the steps are significantly different, for instance require a different set of scripts or configuration changes, then we have lost one of the largest benefits a continual deployment pipeline can provide.
In Conclusion
If you have managed to get through this article without feeling like we are describing one of the many challenges your organisation faces, congratulations! You are in a far better place than many! However, if that is not the case and some issues resonate, do not fret- you are not alone.
Projective has extensive experience within this space, having worked across multiple sectors, including large government departments, financial institutions and payments market infrastructure. We can guide you and prevent Change Fatigue.
If you would like to know more then please drop us a line at DevOps@Projectivegroup.com, whether you want to chat about a challenge you have or simply want to raise a question about our article. We like to chat about DevOps, however informally – a virtual coffee is merely an email away!