The DevOps originated from the need to increase the efficiency of individual development and operations teams. Scaling DevOps takes things further, by making a group of distributed teams efficient.
Once upon a time there was a development team. The team members were frustrated with inefficiencies, because they had high hopes: they wanted to become the most efficient team in the world. To achieve their aspirations, they rolled up their sleeves and got to work. They defined the responsibilities of each team member, developed a way to communicate closely, and even removed physical barriers in their workspace and drank coffee around the same table at the same time. They learned to know each other very well, learned to trust each other and became very efficient in their work, delivering great results for the business. Everybody was happy (for a while).
But as the system and development ecosystem grew, also development teams became more distributed and it impacted teams’ collaboration. Developers could no longer interact in the same physical space. Teams with members from different locations needed to focus even more on communication. Ensuring that business and customer knowledge existed in all teams was crucial. Everyone needed to understand what they were contributing to the big picture.
The teams learned that it was highly important to define the frontend and user experience (UX) on a very detailed level, in close interaction with the customer. Business analyst and UX designer roles were critical, really breaking down different parts into high quality stories for developers, all the way to the acceptance criteria. When developers understood the big picture, they were then free to choose how to deliver it.
Defining front-end in a detailed way with UI prototypes helped to avoid and catch possible faults in the earlier phases.
By now every member of every team appreciated that if the front-end works as planned, most often so does the backend too.
Our story doesn’t end here, for the system grew even more, as it gained more connections to other systems provided by other vendors. Instead of one vendor, there were soon ten vendors and multiple teams serving the business. This uncovered challenges in communication and testing between teams.
We now faced a key challenge in scaling DevOps: realizing different maturity levels between teams. As there are always dependencies between different parallel development tracks, teams are dependent on getting test environments and test data from each other. Some projects needed to wait for their test environments for months, while some got theirs within a day. Especially legacy systems and integrations were problematic.
The teams learned that capabilities in all teams need to be on a level that allows deployments in the same rhythm. They grasped that advanced automation enabled committing to 30-40 deployments per week – whereas without automation, the pace would be as little as one release per quarter.
The DevOps transformation journey that I took with our customer really drove home that the key to success in scaling DevOps lies in lifting process maturity, development environments, and automation capabilities to the same level in all teams. There is no single magic trick that makes this happen, but there are certainly valuable lessons that are worth taking into consideration:
As the story above shows, DevOps is not about techniques – it is about culture combined with technical capabilities. Change is possible and reachable, but it does not happen easily. In addition to being a cultural change, DevOps is a strategic choice that requires a strong, continuous business commitment.
You might also be interested in reading: Sometimes basic DevOps practices aren’t enough