This is the start of a series of posts designed to serve as a guide to helping you start your journey towards DevOps and to be able to go from deploying once a month to multiple times a day.
Every business and development team have a single goal: delivery of value to customers. No matter how you look at it, regardless of the driving forces for a team, be it working with some cool tech, building something you’re passionate about, cost, time to market pressures or whatever else might drive you, ultimately the one thing that will drive your business is delivering the value to your customers.
Not only do businesses desire to deliver that value to customers, but they also want to do it with a speedy time to market. There’s several answers on how to achieve that because the first thing you need to understand is there is no silver bullet, though there are plenty of ways to try and achieve it that will only serve to upset your development teams – this will almost always lead to loss of employees, demoralised teams and ultimately failure. The main thing to understand is that a successful DevOps transformation requires the right combination of people, processes and tools to all be in alignment, with additional emphasis on the people aspect. Without it, your transformation and potentially your project or product will be doomed to fail. DevOps is a culture and not just what buttons to push. To succeed, you’ll need to change behaviours and mindsets. Yes, you’ll also need to make some changes on the technology front, for instance, to ensure fast delivery, you need to have fast tests, so if your test pack currently takes 24 hours to run, that may very well need tweaking.
There’s plenty of books and data to back up the DevOps movement being the most beneficial way to achieving that increased delivery as well as being able to do it safely and with control, such as The DevOps Handbook and Accelerate, which covers the science behind the handbook and the annual State of DevOps report. All of these provide compelling reasons to giving businesses the success they’re looking for.
So where to be begin? First things first, identify your bottlenecks. Let’s take a fictional company, YASC Ltd, though it is quite probably a story that feels so familiar to you that you can replace YASC Ltd with your company name.
The company want to be able to move faster to stay competitive, they’ve already committed to moving away from a traditional on-premises datacenter to the cloud to not only save money, but be able to remain agile based on customer demand – something we’ll cover in a later post. They’ve also decided to make time to market their highest priority, a familiar story so far, right?
Let’s take a look at the bottlenecks they identified:
- There are too many hand-offs, slowing speed of value and reducing accuracy delivery.
- A lot of manual rules and governance overhead.
- Tooling isn’t suited to agility and everything is manual.
- Current branching strategy slows down releases.
- Deployments aren’t always stable.
- Downtime during deployment.
There’s other issues too, such as a lack of insight into how the application is performing or being used, which means that at present, YASC can’t make informed decisions around what to do with it’s application.
Bottleneck 1: There are too many hand-offs, slowing speed of value and reducing accuracy delivery
The current organisation at YASC is made up of teams with specific responsibility/discipline. Requirements are created by a specific team before being handed over to the development team to be added to the application, which are then handed over to the test team for testing and then handed on to a risk and compliance team to ensure all the governance has been followed, before finally being passed over the fence to the operations team to deploy and operate. A long and slow process that takes over a month from cradle to grave, by which time, competitors have shipped numerous times and the market has changed. If there’s an issue, each silo blames the others and it results in a lot of stressed out, unhappy people and an unhappy business. More to the point, there’s almost always guaranteed to be an issue with changes – the size of the deployments, the amount of testing required and a lack of communication inherent in this model leads to service impairment or delays across teams and a long, slow feedback loop.
In addition to that, with so many handovers, accuracy of information gets worse with every handover resulting in some teams not building or actioning the right thing because the quality of the information they have received at their point in the chain was poor. In summary, the flow of value to customers is lengthy and expensive.
Value stream-based Teams
To achieve DevOps with multiple deployments a day, YASC needs to change to value stream-based teams. A value stream-based team is driven by just that, value. They’re also cross-functional. Remember the image from before with the cogs? Well, now each team has developers, testers, operations people, a product owner and somebody capable of what’s needed for risk and compliance. There are many ways to achieve this, be it with individual roles within the same team, which is great starting point, though the risk there is that you can end up with silos within the team itself – I’m sure you’ve heard people say “that’s not my job,” or “that’s not my problem,” countless times. In an ideal world, you could train up members of the team so that they are T-shaped and able to do all of it. The whole team is responsible for an area of value in the system, they can design, build, test, deploy and operate their area themselves.
At first, this change is going to hurt. There’s a strong chance that your teams will be tightly-coupled, as will your areas of value, test packs and so on. Your teams may even be resistant to picking up operational responsibility for their area of the product. This requires a mindset shift, albeit one that is easier in greenfield projects or newer companies, however, by making your teams responsible for operating their area of the product, putting them on-call too, you’ll soon find that the overall quality of the value shipped will increase.
In my next post, we’ll discuss using automation to create repeatable and reliable deployments and builds.