Category Whitepapers and Guides
DevOps started as a market buzzword, a term discussed in hush terms in the local watering hole over a Friday working lunch and then farmed by the IT tabloids in a bid to spark curiosity. Little did we know just how far this little buzzword would take us.
DevOps adoption has progressively grown since 2015 and is predicted to continuing rising – with no sight of the DevOps peak thus far. A recent Gartner survey found that 70% of the IT market is focusing on DevOps, with another study showing that 88% of organisations have adopted agile in some way already. But when agile and DevOps are intangible concepts, what becomes the true marker of success for adoption?
Pilot projects are often haloed as a business’s first steps to adopting DevOps, and for those brave enough to experiment with DevOps for the first time, we salute you. Unless you have infinite resources that give you remit to ‘play’ with DevOps with no consequence to business as usual, investing resource into DevOps can be risky – for individuals advocating its introduction, for profit margins if the ROI flatlines and for a business’ reputation if not carried out in the right way.
Transitioning to DevOps is, first and foremost a cultural shift, and then a process and organisational shift. For many, pilots provide the perfect opportunity to influence the culture / mindset of the few before attempting to convert the many. The problem is, once businesses reach the end of this pilot, many are quick to give their success the fisheye effect – distorting the proportion / scale so it encompasses more than what meets the eye. In this case, the claim can be that business-wide DevOps has been achieved, when in reality, only a pocket of change has taken place.
As the saying goes, close, but no cigar.
Let’s take a look at the risks of adopting DevOps and what steps you need to take to true success with DevOps.
Who are we kidding? We all get a little caught up in the excitement of new technology promising to reduce delivery times by 99%, improve security and enable the release of new apps in time with shifts in the market. Who wouldn’t! It’s exciting! And for a c-level, potentially career changing! But whilst in this case there is substance to these promises – it’s true, we’ve delivered the above for our clients using DevOps principles – unless you truly understand what it is you’re signing up for, the pitfalls remain unnervingly large.
Sometimes it is beneficial to run before you walk. Which is why we commend those undertaking pilot projects. But we’d also advise setting your expectations at a realistic level.
Overestimating internal capability is one of the most common challenges we see our clients face. It pains teams and frustrates the leadership as transformation projects are constantly oversold and underdelivered. This miscalculation can come about due to not fully understanding the breadth of the task at hand, the skillset required to carry out the task and/or what to put in place in order to enable ongoing success once the first project is complete. It can also occur if too much dependency is placed on the technology.
If you have the scope to try and fail, take every opportunity you can. Having the time and space to “experiment” will give you valuable insights that can be fed back into your software development process, and help you identify areas within your organisation that might need additional skills.
Being able to release early to beta test will also give you the advantage of having your software quality tested by “real users” in a “real environment”. This comes back to knowing your capabilities. As seen in Apple’s “bug bounty” initiative, Apple recognise that whilst already strong, their competences can be bolstered by opening up their testing to a wider group of exceptional researchers external to their organisation. This isn’t admitting defeat, but rather avoiding a situation where one cuts off their nose to spite their face – and the cost of a hefty fine!
We also recommend placing a greater focus on your people and the process. Technology is no doubt an enabler, but it is your people that will secure your success. And if you are able to adopt a more open-minded, test-first process, this will give you the agility you need to scale.
Success with DevOps doesn’t just mean you’ve built something really cool once. It’s about establishing a culture and inclusive workflow that works for YOUR organisation, all the time, and does the job it is meant to do, effectively. And not just for the short haul. Essentially, we have to acknowledge that we are going to fail, but are able to rely on what we’ve built to help us learn and grow from that process.
Creating a sustainable solution is about looking beyond the immediate goal. Whilst it’s tempting to plug a hole with a cloth, eventually the water will seep through and your ship will sink. Unfortunately, many employ the services of a consultancy for this very solution. They look at the now rather than focusing on future-proofing their capabilities, enjoying short moments of success rather than maximising the return on investment that can be gained by working with a partner who upskills internal teams and puts measures in place to enable continuous improvement through testing, integration and delivery etc…
One way of avoiding the one-hit wonder path is to create a culture that encourages individuals to teach others the principles of how to move forward. Focus on understanding the how and the why during a change program so your business can learn what is needed internally to maintain a state of transformation and the momentum needed for change. Not only can this help you retain talent, it can help you to preserve your customer base.
Take Pokemon Go as an example. Released in 2016, Pokemon Go is now on generation four, with the first instalments of the fifth generation already released to the market. Thanks to these reiterative, progressive improvements, Niantic (the brains behind Pokemon Go) has continued to capture the imagination of its client base, just as they are about to get bored of the product. And it’s because of this continuous framework, Niantic has seen its success continue to soar.
Let’s break this down into two pools of thought. On the one hand, there are those that are not sure what good looks like. They have an idea of what they want to achieve but are not sure what to measure their success against. On the other hand, there are those who have a good idea of what “good” looks like, but don’t know the best ways to get there.
Understanding where success lies is about measuring the impact of change and responding appropriately. Whilst you’ll want to see positive results, it’s ok if change has a negative impact since you’ll be learning from either approach.
It’s also important to ensure that your measures of success align with a longer-term target. Short-termism is a big challenge in organisations, where the reward for your endeavours is often that promotion you’ve been chasing or a pay bump to compensate your efforts. But this can harm the business by demonstrating short term improvements that don’t necessarily play to the organisational objectives.
And even if you’ve put all the above in place, the dial is still prone to move.
One thing to note is that whilst the fundamental underlying principle of DevOps is that there is an explicit definition of what good looks like, to be truly successful, you need to have transitioned into a culture, a mindset that is constantly challenging that assertion.
“Money can’t buy you happiness, but it can buy you a room full of 10X DevOps engineers” (said somebody, somewhere…)
Yes, there is a shortage of talent within the IT industry, but the talent that does exist is quite simply remarkable. And they appear to be quite evenly distributed across the industry. Whilst more established technology enterprises may attract engineers in an abundance, there are an equal number that deliberately stay clear, choosing instead to side with the challenger businesses, the underdogs, the smaller enterprises trying to make their mark on the world.
And then there are those giant corporations injecting tens of millions into open source software. They understand their own technical limitations but want to further the aspirations of others.
But even with $10million in your back pocket and rooms full of talent, your transformation will fold like a house of cards if you don’t have a harmonious mindset geared for change.
If you put ten of your best engineers into a hot air balloon with a suitcase full of money, but left them with no clear direction, roadmap or compelling reason to take off, your balloon will remain very much grounded to the floor. While we recognise that paying people appropriately for the work, they do is important for retention, it’s not all about money or talent. It’s as important to have a team with the drive to make change happen.
The vast majority of our clients live and breathe in highly regulated environments. They are established, have impressive customers bases, but are also the most suspectable to hierarchical layers responsible for creating inefficient structures.
They have effectively created their own glass ceiling.
This point is most potently made when comparing two financial institutions. Take Monzo. Limited in resources, started with no client base and acting completely against the grain, and yet, they geared themselves for success from the go. Not only did they establish a very clear target, they had in place an idea of what good looked like and removed all barriers to ensure they delivered upon this measure. And voila, they introduced a banking solution that enabled customer to use their cards abroad at no cost, to freeze their card on demand and to send money to friends with nothing but a phone number and a thumbs up emoji.
What’s interesting, is this happened way back in September 2015. TWO YEARS later, and we are only just starting to see high-street banks delivering the same service. Despite the fact they had the had the idea presented to them on a silver platter, the evidence that it was a service consumers wanted and both the money and resource to make it happen.
But we know it’s not that easy. Larger, more traditional organisations are scrutinised far more than their counterparts as they often judged as a premium brand. This means higher benchmarks and unforgiving consequences if they get it wrong. Compare this to start-ups. Generally, they set their own benchmarks and have the luxury of being able to beta-test, gaining free testing from their ever-eager audience happy to have received early access to a new application.
So, who’s to blame for such a stark difference? Unfortunately, we’d argue that the fault lies with the more traditional organisations who, whilst exhibiting good behaviours, have set themselves up for failure by introducing a number of barriers. This can take the shape of organisational silos, teams distracted by their own motivations and outdated processes that forget to keep operations teams in a product’s context throughout delivery.
In the case of Monzo, the people behind the consumer-facing technology we interact with are not necessarily “better” than those working for the larger financial companies – they just happen to have a team all pulling in one direction, at the same time.
If you take nothing else away from this article, remember this: the true adoption of DevOps principles is a hard thing. It was never meant to be easy, otherwise everybody would be doing it.
ECS Digital work with enterprises to embrace, then adopt and scale-out agile and DevOps ways of working – and we’ve been doing so for the past 15 years. During that time, we’ve seen complete organisational restructures, witnessed transformations fail and seen change programs stall.
We’ve also seen them be successful, and on the rare occasion, we’ve watched legacies take shape as DevOps was adopted as it was intended to be.
Before we finish up, we wanted to share with you two of the more effective mechanisms we’ve seen our clients adopt to help them reach true success with DevOps. Hopefully you can adopt them in your own digital transformation too:
One mechanism that we have seen work well for our clients is the incubation method. Much like a pilot, by trialling DevOps in a smaller team and giving them all they need to be successful, our client created a platform that enabled individuals to demonstrate what they had learnt through what they’ve done. This in turn saw a continuous testing mindset come into play which scaled across their teams and into the framework of the business.
Another, softer, approach is to advocate DevOps through leadership. Since DevOps is a mindset, being able to challenge people’s views of how they should think differently and inspire your team to think the same is a powerful tactic to achieving change. If you preach what you speak, you and your team will begin to see the world through a DevOps lens – and that’s when things get exciting!