Transitioning to an Agile IT Organization
Before you even start thinking about the problems you want to solve with agile and DevOps, you should identify and initiate the conversations that will provide the starting points for adoption.
Join the DZone community and get the full member experience.Join For Free
If you have even a passing interest in software development, you’re likely familiar with the premise of agile methods and processes: keep the code simple, test often, and deliver functional components as soon as they’re ready. It’s more efficient to tackle projects using small changes, rapid iterations, and continuous validation, and to allow both solutions and requirements to evolve through collaboration between self-organizing, cross-functional teams. All in all, agile development carves a path to software creation with faster reaction times, fewer problems, and better resilience.
The agile model has been closely associated with startups, who are able to eschew the traditional approach of “setting up walls” between groups and departments in favor of smaller, more focused teams. In a faster-paced and higher-risk environment, younger companies must reassess priorities more frequently than larger, more established ones; they must recalibrate in order to improve their odds of survival. It is for this reason that startups have also successfully managed to extend agile methods throughout the entire service lifecycle — e.g., DevOps — and streamline the process from development all the way through to operations.
Many enterprises have been able to carve out agile practices for the build portion of IT, or even adopt DevOps on a small scale. However, most larger companies have struggled to replicate agility through the entire lifecycle for continuous build, continuous deployment, and continuous delivery. Scaling agility across a bimodal IT organization presents some serious challenges, with significant implications for communication, culture, resources, and distributed teams — but without doing so, enterprises risk being outrun by smaller, nimbler companies.
If large enterprises were able to start from scratch, they would surely build their IT systems in an entirely different way — that’s how much the market has changed. Unfortunately, starting over isn’t an option when you have a business operating at a global, billion-dollar scale. There needs to be a solution that allows these big companies to adapt and transform into agile organizations.
So what’s the solution for these more mature businesses? Ideally, to create space within their infrastructure for software to be continuously built, tested, released, deployed, and delivered. The traditional structure of IT has been mired by ITIL dogma, siloed teams, poor communication, and ineffective collaboration. Enterprises can tackle these problems by constructing modern toolchains that shake things up and introduce the cultural changes needed to bring a DevOps mindset in-house.
I like to think of the classic enterprise technology environments as forests. There are certainly upsides to preserving a forest in its entirety. Its bountiful resources — e.g., sophisticated tools and talented workers — offer seemingly endless possibilities for development. Just as the complex canopy of the forest helps shield and protect the life within, the infrastructure maintained by the operations team can help protect the company from instability.
But the very structure that protects the software is also its greatest hindrance. It prevents the company from making the rapid-fire changes necessary to keep up with market trends. The size and scale of the infrastructure, which were once strengths, become enormous obstacles during deployment and delivery. Running at high speed through a forest is a bad idea — you will almost certainly trip over roots, get whacked by branches, and find your progress slowed as you weave through a mix of legacy technology, complex processes, regulatory concerns, compliance overhead, and much more.
By making a clearing in the forest, enterprises can create a realm where it’s possible to run without the constraints of so many trees. This gives them the ability to mimic the key advantage of smaller companies by creating the freedom to quickly build, deploy, and deliver what they want — without the tethers of legacy infrastructure.
For example, I have worked with a multinational retailer that, in addition to operating 7,800 stores across 12 markets, manages 4,500 IT employees around the world — which translates to 7 million emails and 300 phone calls per day from distributed operation centers in nine different countries. The major issue was that notification processes were inconsistent on a global level, and frequently failed to get relevant information to the right people at the right time. This, of course, translated into slower response times to issues affecting their customers.
In order to modernize its IT force, the company reorganized into a Service-Oriented Architecture (SOA), featuring separate service groups that owned the design, development, and run of each of their respective systems. This meant that many IT members were given new roles with responsibilities; though most had worked on developing systems, most hadn’t worked on supporting systems. They also integrated tools to enable automation and self-service for end-users. Today, they have a more consistent and collaborative digital work environment, and the result is greater efficiency, happier customers, and more growth opportunities for the future.
Similarly, I worked with a retail food chain that presented a challenge in improving the communication and collaborative capabilities of its teams in food risk management. Prior to IT modernization, in-store staff manually monitored freezer temperatures every four hours — a complex and time-consuming task that was highly prone to human error. If an incident arose, the escalation process couldn’t identify the correct team member to address the temperature issues, so a mass email would be blasted out. There was no way of knowing if the correct team member has been made aware of the issue and had addressed it.
The company tackled this challenge by creating a more robust process for incident management involving SMS messages to identified staff, emails and phone calls to management, and automated announcements over the in-store system. In addition, they implemented an Internet of Things (IoT) program to completely automate and monitor refrigerator and frozen food temperature management. The result has been significantly increased efficiency, transparency, and accountability — not to mention a safer experience for their customers.
As you can see, these companies were able to identify target areas and problems, and create new spaces within their existing infrastructures to allow them to communicate better, and ultimately become faster, nimbler, and more responsive. Any enterprise looking to move toward agile software development and operations should look at technology-based projects and initiatives that will be most impactful in enhancing team focus and culture. Before you even start thinking about the problems you want to solve with agile and DevOps, you should identify and initiate the conversations that will provide the starting points for adoption. Without a detailed map of your infrastructure and the activities within it, you cannot clear a path to complete, end-to-end DevOps adoption.
Opinions expressed by DZone contributors are their own.