Several years ago I was working at a company that had a ton of legacy silo applications that collectively represented the entire process flow that supported the core business. The process flow was made up of years and years of legacy technologies and legacy business processes. The picture below is a generous representation of what that flow might have looked like (the actual flow filled up an entire wall in a conference room and had just as many arrows pointing backward as forward).
After capturing the current state, we embarked on creating the future state by making pretend we were a brand new company starting from scratch. We did this so we would not pollute the desired future state with the constraints from days gone past. We came up with a very desirable flow that is simplified in the following image.
Now, all we had to do was to get from current to future state. Easy, right? Wrong! The future state processes looked nice on paper, but there was this little issue called “People” that got in the way. You see, many people’s jobs were to work on these processes that were bottlenecks and pure waste. Many managers managed people who worked on wasteful processes, and many people loved to create reports that told us what was going on in the business. These people felt rather important. They did not want to change the way they had always done business.
To make a long story short, it was a battle getting the culture to change business processes. What wound up happening is that we compromised (no, we did not shut down the government), and we made many small victories along the way. Our actual or realized processes looked more like this chart.
At least the process was all flowing left to right (the happy path), and we eliminated a lot of backward movement. At the end of the day, we wound up automating a lot of waste.
Why did I share this story? Because I am seeing this same scenario play out in enterprises that are moving to DevOps. Too often, this movement is being driven from a silo, such as the systems administrators, and not by a collective team representing a variety of roles responsible for delivering the product. The result is that the systems administrators automate and improve a lot of “their stuff,” but in reality they are automating waste, just like in my example above. What really needs to happen is development and operations (hence “DevOps”) and even product management should participate in the movement, so that waste is removed from the ENTIRE software development life cycle, not just from the infrastructure side of the house.
The key takeaway here is: remove bottlenecks first, then automate. Don’t automate waste!
Transforming the culture
I passionately follow the teachings of DevOps thought leaders like Jez Humble, Gene Kim, and many others. They all are champions of culture transformations. They promote various methodologies for driving change, such as:
- Lean Management
- Theories of Constraints
- Value Stream Mapping
- The Three Ways
- Game Theory
These methodologies and others are all great for identifying bottlenecks and waste, but what is missing from the conversation is the process and tools for fostering change. This is where John Kotter’s 8-Step Change Model comes in. Once you figure out what you want the future state to be, using the previously mentioned tools, you can achieve that state by using these proven 8 Steps:
- Establish a Sense of Urgency
- Form a Powerful Guiding Coalition
- Create a Vision
- Communicate the Vision
- Empower Others to Act On the Vision
- Plan For and Create Short-Term Wins
- Consolidate Improvements and Produce Still More Change
- Institutionalize New Approaches
The big issue with change is that people need to understand why the change is necessary and what value the change brings. Each person has a different value system, so the the trick is to describe the value in terms of WIIFM (“What’s in it for me?”). In my business process transformation project mentioned above, the WIIFM was very different for many people. Here are some examples.
- C-level execs & sales: Increased sales, speed to market, reduced costs
- IT managers: Reduced maintenance, more stable systems, new technologies
- IT staffers: Retire old troublesome systems, learn new technologies, work on top project in company
- All employees: Increase chance of company hitting numbers equating to better bonuses
The other lesson learned was that promoting change is very much like running for political office. It was as if we were campaigning for votes. We had to have a clear message about what the future state would look like. We had to communicate frequently using every outlet possible (team meetings, company meetings, newsletters, blogs, one-on-ones, etc.). Most importantly, we had to deliver results early and often and have the metrics on hand to prove that the investment was paying off.
I highly recommend reading some of Kotter’s books to learn more. Transforming an organization is very challenging. Whether you are changing business processes, moving from waterfall to agile, moving to the cloud, or driving a DevOps initiative, leveraging a proven methodology for promoting change will increase your odds of success.
Comments are closed.