Embrace Dont Replace Enterprise DevOps Realities
|Freeman Lightner in DevOps Friday, November 6, 2020|
In a recent Software Delivery Leadership Forum session, Shawn Ahmed of CloudBees shared his experience in scaling a software delivery organization and revealed how giving teams the freedom to choose the tools they need helps the business better achieve its objectives.
Today, Ahmed says, every business is a software business, with one top goal in mind: to drive innovation quickly. To make that possible, organizations must optimize development and delivery of software, releasing and iterating continuously. But they also must reduce risk, ensuring there is governance, control and visibility to track and trace how software is being developed and released.
What makes all of this challenging is the sheer number of tools and processes that teams use to create and deliver software. Ahmed shared his story of scaling a 15-developer organization to more than 150 developers, all working on a number of different apps in a variety of highly regulated industries. Although, Ahmed says, it was initially possible to track and understand the framework of tools and processes his teams were using, as the organization scaled, the complexity increased in a way Ahmed likens to moving from two dimensions to three.
This introduced what Ahmed calls the “physics dilemma.” As teams, tools and processes increase, visibility, control and governance drop. It quickly becomes challenging to see what different teams are doing; you don’t know what to focus on, what’s working and what isn’t, where value can be unlocked, etc. At the same time, it’s difficult to create a traceable trail of how software was developed and released – a must-have for highly regulated industries like banking and healthcare. In the end, all of this, Ahmed says, increases risk and slows the pace of innovation as you try to manage these issues.
Ahmed then goes on to describe his first – and admittedly failed – solution for addressing these concerns. Seeing the problem as one of disconnection – teams and processes and tools siloed from one another – Ahmed thought the answer lay in standardization. Under his new system, teams no longer had the option to choose their tools. Instead, they were put into a “box” – an off-the-shelf, all-in-one vendor that provided all the tools and features and capabilities in a single solution that everyone was required to use.
This standardization, Ahmed says, was great for him – it provided the consistency and visibility and governance to keep on top of teams. The problem was, it was making his developers very unhappy.
By trapping teams in this all-in-one box, Ahmed was taking away every other option, all the tools and solutions outside of the box that could make them more effective. Ahmed would ask his teams, “Well, why do you need those tools? Can’t you get what you need from the all-in-one solution?” And while, yes, maybe the all-in-one solution had some of the required functionality or capability, these tools wouldn’t be as mature (or as useful) as tools specially crafted by dedicated vendors. Developers want to do their very best work; under Ahmed’s system, they were lacking the means to do so.
In the end, Ahmed came to the conclusion that the all-in-one box just wasn’t worth it. Now, Ahmed is convinced that, to help everyone find focus and flow, teams need the freedom to choose the specific tools they want/need/love.
He compares it to a person setting up a brand-new laptop. Everyone has their “sweet setup” – the mail app you want to use, the way your desktop is organized, etc. – that enables you to do your very best work, with the fewest possible blockers. When it comes to the larger framework of software delivery tools and processes, developers need their sweet setup, too. Which, for Ahmed, meant he had to suck it up, let go of the all-in-one box and embrace solutions that give teams their freedom.
It’s when Ahmed moved to solutions built around this freedom of choice that things really began to take off. With purpose-built tools and a CI/CD solution that allowed for a growing number of teams, processes and tools – solutions that connected all those elements for greater visibility and harmony – Ahmed’s developers were now equipped to drive innovation quickly and safely, which made customers happier than ever.
To hear Shawn Ahmed’s full story – and get some other perspective on the need for choice in software delivery tools – check out the full recording of the Software Delivery Leadership Forum. And, to see how CloudBees – the unconditional leader in enterprise DevOps – gives teams the freedom to choose the tools they need, visit the CloudBees website.