Lance Knight

My name is Lance Knight, and I work for ConnectALL. ConnectALL is a value stream integration platform. I have this demonstration I put together called DevOps Winners & Losers. We went out and talked to our customers, and we looked at some winning strategies and some of the things going on in the market. This may be a little high level, but it should give you a good feeling for what is going on out there with DevOps and with the consulting companies we are working with.

Just two seconds about me: for the last 15 years, I have worked for companies that are about improving velocity in their system of delivery. I have worked for requirements management companies, testing companies, and integration companies, all on this particular topic.

Why is this relevant? Why is DevOps relevant today? Let me go through some of the points that came up when we were talking to our customers about why DevOps is relevant to them.

There are forces happening with all companies today around digital transformation. They are both internal and external forces, and they are driving change. The two I am going to focus on today are time to market and reaction time to vulnerabilities. These two forces seem to be driving most DevOps initiatives, digital transformation initiatives, and so on.

This is driving speed to be the new currency: getting things fixed, getting new products and features, and getting supporting products and features into the market at speed. Eighty-seven percent of executives surveyed said this is a competitive opportunity. At the same time, 52% of executives surveyed said they lacked a fundamental understanding of IT in order to be effective, and they think their own IT systems are a blocker. DevOps can help them achieve those goals.

This is also forcing every company, whether you make turbine blades or you are a manufacturer, into becoming a software company so you can serve your customers. Banking is an example. Around 2008 and 2009 it was all about the online banking experience. Now everybody wants a mobile banking experience. I recently changed banks because my small community bank did not have the best online experience. Insurance is the same way. The in-bank teller experience is not the same as it used to be; often they are just filling out the form I could have filled out on the website myself.

Digital transformation is happening. DevOps is a big part of it because you have to stay competitive by releasing things faster, but at the same time you have to be overly protective against vulnerabilities. This is true across industries. My first car had no code in it; now there are thousands and millions of lines of code in every car. The way industries interface with customers is changing, and this is driving demand for DevOps, Agile principles, and digital transformation. We are trying to get more and more code to market with more features while exposing more of ourselves to the outside world in a vulnerable way.

At the same time, this has created a tooling explosion. There are more tools for software development today than ever before. When I started coding, there were maybe three or four requirements management systems in the market. Now there are tons of task management systems. Fifteen years ago there was one major testing solution; now there is a plethora. Then you get into CI/CD tools, which all have an effect.

So what is the DevOps problem? Software developers are developing things and want to get them to market, to customers, and to the competitive opportunity. Operations teams have to maintain security, auditability, and traceability. They have different goals and objectives, and it becomes an over-the-wall kind of thing. Product management throws work over a wall to developers too. The whole process is broken when teams are not aligned. These teams have to collaborate and act as one group in order to effectively get new products and features into the market.

We took a survey and talked to customers. We found that 80% of our customers, and customers we believe worldwide, are entering into some DevOps initiative. But about 85% are not getting the success they expect. That is driven by a couple of reasons, including that they are focused on deploying tools. My company offers a tool that helps you be more effective and streamline your value stream, but you also have to look at culture at the same time, or you will not get the value you expect out of DevOps or digital transformation.

Most companies on the DevOps journey have adopted some tools ad hoc, from a quality-to-speed perspective, and need to get to high-performing product delivery teams. Large companies will continue to roll out DevOps solutions and tools at scale, but I think they will achieve the same results from just deploying more tools and solutions unless they address the other pieces that successful DevOps winners address.

DevOps losers need to start again. They are not really focusing on this; they are totally focusing on tools. The things DevOps winners are doing break down into three fundamental areas: culture, process, and infrastructure.

What is DevOps culture? I have a story I call DevOps b*h day. My wife, who is a business analyst, came home upset. She said it was a DevOps b*h day because the DevOps team at her company spent the whole day mad that her Agile team did not groom their backlog right. That reminds me of my old IT days as an enforcer, making sure the process happened exactly my way. IT and software development have to transform into enablers, not enforcers. The backlog issue seems like a coaching moment, not an enforcement moment.

We have to focus on changing culture as well as process, break down silos, and create one teams. A lot of DevOps-winning companies embed operations people into software teams. They do not have to be full time, but they work with those teams as development is happening, so the team can get things out the door quicker because they are aligned.

Get away from the one-hero story. In IT we called that a single point of failure: one person knows how to fix one thing. If that person is gone, the team has a problem. When I was in IT, that person was Emmett; he could fix whatever was going on with the Oracle server and nobody else knew how. Winners move away from that hero perspective and share knowledge better so the team is the hero.

Winners create single teams. You may have a product manager or business analyst on the team, as well as developers and an operational person assigned to the team. That removes the handoff problem. You can also understand dependencies within your system of delivery because you are working together collaboratively. The team shares one common goal: getting new features to market while reacting to vulnerabilities relatively fast.

For process, DevOps winners use Lean principles and systems thinking to improve their system of delivery. They use value stream mapping, systems thinking, flow, and waste.

Lean is not brand new. I learned about it 20 years ago working in IT on the shop floor of an aerospace manufacturer. It is about identifying value, mapping the value stream, creating flow, establishing pull, and seeking perfection. It also connects to integration and automation. You can apply those principles, but you still need to fix culture.

Waste matters. In Lean and value stream mapping, you think about waste to improve the system. Over-processing waste shows up in old IT patterns like requiring signed forms in triplicate to access a folder. Transportation waste in IT is copying files around or recreating artifacts, such as copying an issue from a customer feedback system into a development system. That is waste and needs to be removed.

That is where value stream systems thinking and value stream management come in. A value stream map is useful, and Six Sigma and Lean tools like SIPOCs are useful for process management. But there is confusion between process management and value stream management, and we have to align those and understand the difference.

There is more to this than value stream management. You also need value stream design: map the value stream, see how things flow, then look at waste, fix the value stream, and propose an end-state value stream map or process. Then you move into value stream mapping, value stream management, planning, and moving the organization to align to the principles you uncovered.

DevOps winners test a lot. They do continuous testing, many do test-driven development, and they test throughout the process. That enables continuous delivery.

DevOps winners use metrics: flow metrics, Lean metrics, wait time, delivery time, and how long an idea sits in a queue. CIOs need metrics to report to the CEO what IT does. Metrics eliminate the black box and unpredictability. If a value stream takes two years to do a simple project or product you want to take to market, you will miss the market; you have to shorten delivery cycles.

DevOps winners deploy small changes often. It is easier to pull back a small change if it is not effective than it is to pull back a big release. They use things like feature toggles so that at any moment what they deployed, or the code they changed, can go into production.

On infrastructure, DevOps winners can deploy code at any time. Because they test throughout the process and implement small changes, deployments happen relatively quickly: not months and days, but hours from code submission through testing to production.

They treat infrastructure as code. They track code files and configuration files with code-based approaches so everyone is working to the same revision, whether in UAT, development, or production.

They also deploy a technology roadmap. Because teams work collaboratively, they understand where the technology is moving over time. DevOps winners use these roadmaps to communicate their operational strategy over time for their infrastructure, as part of treating it as code.

DevOps winners integrate their systems to remove waste. They integrate artifacts and systems to remove transportation waste. Defects can flow from ServiceNow into Jira and all the way down the value stream, allowing value stream integration.

DevOps winners automate their pipeline. Code packages move into development and are automatically promoted to QA, removing the time it takes to get code from conception into production. Data, tests, and information stay the same as they go through the process, so continuous testing, feedback loops, and all of that work effectively.

What did we learn? You have to look at the end-to-end delivery system. It is not just the last mile; it is the first mile too. I did a whiteboard session with a financial institution in New Jersey, and they spent more time waiting for a new idea to get approved and budgeted than they did developing it. Defects would go all the way back into that approval process, slowing time to market. In today's world, speed is the new currency, so that has an overarching effect.

Focus on removing waste and use age-old principles. If you are part of a DevOps strategy and want to get restarted, rally the team around DevOps. That does not mean just operations teams; create a group of people who understand the value of improving the end-to-end process.

Understand what it will take to change culture. There are many tools and solutions, but culture seems to be the biggest barrier in some older companies where IT is focused on being enforcers instead of enablers. Map the end value, map the value stream, and make sure you have the right executive sponsor who understands the value of what you are trying to do.

These things can help you move from ad hoc work into high-performance delivery and speed, with excellent quality, delivery of new features and functions, and faster reaction to vulnerabilities. Never before have companies had to release more things in a digital world and at the same time react to greater vulnerabilities. Having an end-to-end value stream helps you do that.

Some outcomes you can expect include 2x results, 60% fewer flaws because you are testing throughout and delivering smaller batch sizes, 168% reaction time to issues, and 30% more frequency in builds. Any questions?