DevOps at Schneider: a Meaningful Journey of Engaging People into Change

Why Schneider decided to go on a DevOps journey

To truly appreciate Schneider’s DevOps journey, let’s first talk about how the need for DevOps grew within Schneider.

Schneider is a large trucking and logistics company in North America. Like many modern enterprises, Schneider increasingly relies on digitizing its business; the applications it develops, deploys and manages are critical assets that keep its business running.

Prior to implementing DevOps, we created silos by treating every piece of infrastructure and application like a snowflake. Perhaps some of you relate to this idea, but by treating every "thing", for example, every server, application, technology, as different and special, we needed different and special groups of people who could love and care for those applications.

On top of that, we applied a waterfall project management methodology, which entailed mapping out a project into distinct, sequential phases, with each new phase beginning only when the prior phase has been completed.

This was, and in some cases still is today, the most traditional method for managing a project.  

Let’s just say this was not a quick process – taking months or longer to deliver value to the business.

What we found was this approach came with its fair share of challenges ...

• Requirements were not clear as there was severe analysis paralysis and a fear of saying "We are done, let’s move to the next stage".
• Changing requirements became increasingly expensive.
• Projects took way too long, increasing their risk of success.
• When the schedule got crunched, the first thing to sacrifice was testing.
• Most of these projects were not delivered on schedule.

As the need to react quickly to the needs of the business became imperative, Agile entered the picture @ Schneider in small pockets in 2015, with a full Agile transformation across Schneiders TECH department in 2016. But what we saw was that we were still not moving as fast as we wanted. We gained efficiency with Agile through planning & prioritizing work and leveraging ceremonies, but when it came to testing and delivering code, we ran into roadblocks as we had not changed any of those processes. Fast-forward to 2017, DevOps had become a buzzword at Schneider - a regular topic of conversation. Because DevOps was the buzz, there was a healthy speculation about why a transportation company like Schneider should adopt DevOps. Is it because it’s a new, trendy thing? Because it sounds cool? Because everyone else is doing it, or are we trying to solve a real problem and make a real impact?

At the same time, there was a huge effort underway to build and implement a new application. As part of this effort, we took the opportunity to really visualize the work, specifically all the teams and all of the tasks required to support this effort. Traditionally, we relied on each team to retain and hold that knowledge, so it was not very visible. But without the work being visible, it’s hard to truly appreciate the end understand how much work is required, the teams involved, and where handoffs occur.

To gain that level of visibility, we conducted an exercise where we looked at the number of teams involved and handoffs required to implement one application in one environment. The outcome of this exercise was eye opening and really fuelled the beginning of our transformation. Our goal was to answer the following questions:

1. How can we do more without adding additional resources, for example, headcount?
2. How can we be more efficient?
3. How can we enable developers to do what they do best, deliver high-quality value to the business?
4. How can we react quickly to the market changes to remain competitive?

The case for change

From the exercise previously noted, we took a step back and captured some of the major factors or themes for our case for change as to why we wouldn't be capable of increasing our quality and delivery speed unless we took action. These themes included the large number of handoffs across teams and environments. Additionally, the themes of limited visibility to work and lack of automation, which cause inconsistency and inefficiencies, were identified, for example.

Wherever possible, we tried to provide metrics of the current state and how we could impact those metrics. Additionally, we found it very important to include statements from stakeholders about the value we will gain from implementing the desired capabilities. This helped illustrate that the TECH@Schneider community as a whole was behind our transformation.

Bottom line - telling your story, no matter how bad it may look or sound, but really pulling back the covers and putting the raw data out there can be uncomfortable, but is absolutely necessary to ignite your case for change. Spend time making your case for change less formal and more meaningful and something people can easily relate to. The best way to do this is by scrapping all those stiff templates, and crafting your case for change like you are writing a story and marketing it like you are making the sale of your life! Some fun ways to do this include using short motion graphic animations vs. boring emails or one-page PowerPoints, scheduling informal town hall meetings to collect feedback and get input on what you are trying to do (or sell), and anonymous surveys for those who are uncomfortable providing feedback in a more formal way. The options are endless, but think outside the box and make it fun.

Engaging people into the change

Collaboration was a big area of focus. Initially, we looked across the TECH department and identified key catalysts and change makers who formed a cross functional team that drove this effort. This allowed us to get input, feedback and alignment across all teams within TECH. Additionally, we formed a steering committee, made up of TECH Directors. These two groups were highly engaged throughout the whole process.

Some other strategies we used were:

• Collecting regular feedback via anonymous surveys; we then used direct quotes from these surveys for our case for change and other leadership presentations and as a baseline throughout our transformation.
• Extending the invite to managers and directors, and other associates across TECH when developing new processes, in all proof of concepts and showcases of the efforts accomplished.
• Holding regular learning and collaboration sessions where we would provide an overview of changes coming soon, get feedback and have open and raw discussions about why, the impact and the benefit -- answering the question of "What does this mean to me?"

Here are some quotes gathered as we were selecting an Application Release Automation toolset:

This is an example of a slide used for a learning session:

Throughout our transformation, it was really important that I wasn't the only spokesperson driving these efforts. My personal goal was that there were enough people across TECH who were just as passionate and excited, who acted as advocates for these efforts by bringing up these topics regularly in their 1x1 meetings with their leaders, having conversations with their peers, and sparking hallway and other important conversations with our leadership.

Speed bumps along the way

The Schneiders DevOps transformation has been a great success, but there were many things we learned throughout the process. We have taken multiple steps forward, but in some cases, it required taking a few steps back first.

For instance, one of our goals was to have a common deployment process by technology, then application, but avoiding the ladder. This was easier said than done in some cases. As we started digging into technologies that were used across multiple teams, we ran into some big, but mostly small, differences in how they were developing and deploying these applications. And for some of our older technologies, it didn't really make sense to invest a bunch of money to rewrite or reconfigure these applications just to get to a standard. Wherever possible, we aligned around a standard, and in some cases, focused on applying that standard to everything new going forward and coming back and re-evaluating the existing applications at a later date. The most important takeaway is that we learned, improved, and will continue to do so regardless of an effort being labelled "DevOps," and that progress is progress. Change will not happen overnight, but small steps in the right direction is still a success.

At the end of the day, change is hard and without leadership support, dedicated time for developers to really digest the "What does this mean to me?" and "How does my work change?" and continual reinforcement and conversation, it will be challenging to be successful.

What we learned on our journey

There are a few key learnings, which may seem elementary, but I feel have been very notable:

1. DevOps is not black and white. You can read books and articles about how to do "DevOps," but the reality is, that may not work for your organization. Does DevOps mean being lean? Does DevOps mean changing culture? Does DevOps mean implementing a bunch of new or cool technologies that you have always wanted to work on? Again it seems simple, but define what DevOps means to your organization and then put that definition up in the hallways, bring it up in every conversation and make sure everyone, if asked what DevOps means to the org, answers with the same response.
2. DevOps and Scope Creep are synonymous - Always come back to the "why" of your DevOps transformation and use your goals and objectives as your true north to validate your progress as you get started.
3. When is DevOps done? This was a question I was asked regularly and the reality is DevOps is never done, but something that I don't think many people are talking about is when does this formal effort or journey become just the way we work? When do we stop the charade and just incorporate these ideals and values into our everyday efforts? And when you get to that point, the next question is how do you best do this? ... That last question is one we are still trying to answer!

Applying DevOps

I would offer the following two pieces of advice for those who are thinking about applying DevOps:

1. Do we have to call it DevOps? Think about this, and all the other buzzwords that have created such commotion across your tech departments in the past (*cough* Agile). These buzzwords are so heavy and, in some organizations, come with great speculation, especially at some levels of leadership. When these buzzwords become heavy, so does the budget, the resources required, the implementation, the formality, and so on. Does it need to be so heavy? Does it need to be so formal? At some level yes, but my honest advice would be to create your own catchy branding around what you are trying to achieve. I do not want to admit how long it took us to align upon and arrive at a definition of DevOps. Had it not been a catchy buzzword and heavy in speculation, I truly believe half of the wirlwind we experienced would have been eliminated and alignment would have been much easier to achieve.
2. Too often in TECH, we spend a lot of time thinking about how to market the products we are developing or enhancing, but when it comes to tech for tech, we really don't market at all. Marketing tech for tech, meaning marketing the technologies, processes, and practices that your technology organization will be using to deliver value to the business, is so critically important. No one wants another boring email or doc that walks them through what is going to change. Marketing the changes in processes, toolsets, etc within your TECH department will not only get people interested, but will also increase buy-in, get people excited and talking to their peers and managers about how much they are looking forward to these changes, and will also get people involved, asking questions, and providing feedback. Think of your tech department as a community, and spend a lot of time developing a plan to market your "DevOps" products, processes, and more to that community - you won't regret it!