Retail DevOps Case Study: Rebuilding an Engineering Culture

Excerpted from the guidance paper DevOps Case Studies. Download the full paper here.

Written by: Jim Stoneham, Paula Thrasher, Terri Potts, Heather Mickman, Carmen DeArdo, Thomas A. Limoncelli, and Kate Sage

Technology Practices Journey

This study focuses on the different phases of driving DevOps and rebuilding the engineering culture at a retailer.

The retailer required a lot of technology and thousands of applications to support its business, and it had begun changing from a large legacy enterprise delivery machine to a more modern, nimble Agile technology organization. The organization had lost sight of the importance of engineering a while ago, and there was a culture of stopping changes whenever something broke. Because of this culture, IT would freeze production whenever problems arose, which in turn resulted in them needing to push changes in big batches. The IT organization was too complex, with silos inside of silos. Server provisions took many teams, and there was no end-to-end accountability. The system was way too complex, and over the years they had built up a large amount of technology debt. It is here that, driven by a commitment to customers and engineers, the organization’s DevOps journey and the rebuilding of their engineering culture began.

There are four stages in this journey: enabling and unleashing change agents, cultivating and growing a grassroots movement, getting top-down alignment, and figuring out how to scale across the enterprise.

A few years ago, IT leaders realized that the organization needed to step up its game in the multi-channel guest experience. That was a complicated and difficult thing to do. Core data was locked in legacy systems, and it would take three to six months to develop the integrations needed to get at core data. There were multiple sources of truth. The dotcom was different from in-store systems. When they finally did get at the data, there were months of manual testing. In addition, the retailer’s technology organization was very project focused and complicated. It was heavy on the project management side, and there were 20 to 30 different teams, each with conflicting priorities. Development was an exercise in waiting in queues rather than delivering results. They needed to build APIs and expose core and essential retail data, and they wanted to scale APIs and deliver new capabilities in days, not months.

It was then that IT leadership started talking about using Agile, not waterfall, systems. Team members, not contractors, began doing the engineering work, and team leaders insisted on full staff ownership, so that queuing and waiting were decreased, enabling them to get control of the ecosystem. They brought in more modern tools. Then, a couple of years in, they added technologies such as Cassandra and Kafka to give them scale and allow them to keep up with volume. The retailer’s API platform was scaled as the speed of new customer experiences grew. As a result of these changes, they now do 80 deployments per week. The net present value on investment is amazing.

Digital sales were up 42% last holiday season. At the peak of this year’s holiday season, 450 stores will help fulfill orders. APIs and platforms continue to scale. The organization is now investing heavily in tech because leaders understand how essential it is to a successful business.

When the IT organization’s leaders saw the successes resulting from the implementation of DevOps processes, they knew they needed to scale across the entire organization. So, they started a grassroots movement, which included beginning an internal DevOps program. Right away, over 100 people showed interest in learning more about DevOps. The organization went from nobody wanting to talk about DevOps because it seemed like only Silicon Valley web companies were doing it, to increasing numbers of people talking about the amazing successes resulting from it. They also started getting engineers together to talk about infrastructure as code and began to connect to the larger tech community by bringing in external speakers. In addition, because rebuilding the engineering culture meant rebuilding the tech brand, they had the opportunity to have fun branding around their commitment to technology.

After all this, it became obvious that senior leadership buy-in was necessary. The bottoms-up phase needed to work into top-down engagement. To achieve this, they did a lot of momentum building. DevOps and Agile became core pillars and goals, as well as part of the daily conversation, and they did town hall huddle meetings. They also aligned with Thoughtworks’ CI/CD Maturity Model to baseline measure products. They set goals and assigned DevOps champions to help drive practices within their spaces and be champions within their teams. Despite these efforts, they still had hundreds in middle management who had not yet been exposed to the thinking. So, they decided to do an internal mini-DevOps enterprise summit. The retailer’s management became involved in these discussions, and it energized a lot of people.

Once all of these other steps were in place, the next question was how to actually scale across a large organization. First, they focused on structural changes. They moved from a COBIT-based, highly-segmented model, to a product and service model; simplified accountabilities and established key practice areas across the organization; and shifted their delivery model from waterfall and project-based to product-based using Scrum and Kanban models. They also embarked on a tech modernization strategy. Because they had a lot of legacy and tightly-coupled integrations, they needed key strategic capabilities to move to a more modern tech architecture: API based, loosely coupled, lightweight tooling, self-service, and optimized for cloud based and CI/CD practices.

They also needed to change how people worked. They began this process by converging the Agile and DevOps movements. What was once loosely connected became more tightly connected. They then pulled in an effectiveness organization to look at how they could scale learning. Traditional training was combined with a focus on coaching and hands-on immersive experiences. They also created an internal incubator environment, like a transformation emergence center, called the Dojo, which became the place they went to practice their craft. The idea was that teams would come to the Dojo with real work, and coaches would work in an immersive environment to show them how to apply new practices. By doing this, they began creating what an engineering environment should look like.

To download the full DevOps Case Studies Guidance Paper, click here.

- About The Authors

IT Revolution

Trusted by technology leaders worldwide. Since publishing The Phoenix Project in 2013, and launching DevOps Enterprise Summit in 2014, we’ve been assembling guidance from industry experts and top practitioners.

Follow IT Revolution on Social Media

• 
• 
•