Lance Knight

We're going to talk about systems thinking and Lean principles. We're just going to cover some of the top pieces of that. I'm not going to go too deep. I know that there's probably people that are a lot smarter than me here that understand some of these principles.

So just going to cover the top of them and cover some points, and then talk about how integration can help you remove waste from your system delivery.

So that's kind of what I just talked about, my agenda. We'll talk really quickly about systems thinking, Lean principles. We'll talk about integration, and all different types of integration through this as well. So it'll be a very quick presentation on that. And then we'll have some conclusions and questions after.

First, I'll just introduce myself. I'm Lance Knight. I grew up in Upstate New York, where I started working in the manufacturing industry with aerospace. I bring that up because that's where I learned about systems thinking. That's where I learned about Lean principles and Six Sigma and all those things, when I worked in IT at that time.

Since then, I've done a bunch of other things that you can see. Over the last few years, though, I focused on helping companies achieve higher velocity in their system of software delivery, and most of the companies I've worked for have had that goal. And I've applied these types of principles for quite a while into the software delivery mindset.

A little bit about the company I work for. I work for Go2Group. We've been around for about 15 years. There's 70 different countries. We're 30% growth, 60 employees. We focus on a whole bunch of different things. We're consulting with Atlassian products. We focus on helping people achieve DevOps with those Atlassian products. We're Atlassian resellers. And we have a host of products as well that we offer, one of which is ConnectALL, which is an integration platform.

So now that I've put in the piece that I'm required to put in, let's talk a little bit about the areas that we came to talk about. And why are these relevant? Why is systems thinking, why is Lean relevant?

Well, in order to fix the whole system, you need to think about putting together an end-to-end flow. And you're going to have bottlenecks. You're going to have different parts within your overall system. And if you're not looking at it all together, you may apply a solution in one area but not increase your velocity.

So you need to look through the whole system. And in that, you're not getting any more predictable. You're just getting more predictable in one area, but not increasing your overall total velocity. And also, you can use this for a roadmap. It really helps you build out a kind of a DevOps strategy as you look at the different constraints and areas that you want to fix based upon these principles.

Let's use a real-world customer example. Recently, I've been working with a company called Acme Corporation. I think we've all heard of Acme. I think we all use Acme, right? So what's really cool about Acme is they make some great incendiary devices. And they also make other novelties as well.

They only have one customer that I know of. They may have others, I'm not really sure, but that would be Mr. Coyote here. And they have a problem because Stark Industries is making a better product. And that problem is that the missile guidance systems at Acme Corporation are not getting updated quick enough, or they're not releasing enough to update that, so they keep missing the target. And there's a lot of failures and issues with this, which we're all familiar with that, if you're old enough to remember this cartoon. And Stark Industries has a much better product as well.

So when we started to engage with them, it really started with a really big whiteboarding session, where we actually mapped out the end-to-end system, and we looked at all of this from one phase to the other, from work intake to working code and delivery. And in here, as we were doing that, I started to see that there were issues and bottlenecks, but how do you articulate that without some type of principles and philosophies to do that around? The gentleman's hat over there, he doesn't work for Acme, but he was just hanging out.

So that's what we did. We sat down, we looked at this from intake from IT, intake from customers, intake through their system. And it's really interesting pieces here as they create their work items and work packages on one side, and they go to development. Work package gets worked on. That creates a release package that goes into IT, that gets scheduled for first test, and then that gets passed and gets second test.

And we want to apply some Lean and different principles as we kind of look about that. So I want to talk about systems thinking as you're looking at this.

So one last point on Acme. They have a myriad of tools, and yet they're still not able to improve velocity. They've automated here, automated there. They just haven't looked at where their bottlenecks are. They just focused on implementing tools.

So just because you have release windows doesn't mean you're putting things into that release window. Just because I have automated testing doesn't mean that I'm getting enough stuff, enough features and functions and program code into there to get fixed and put through. So you got to look at the whole system.

As I go into systems thinking and talking about that, understand that in the world of software development, the ins and outs of a system are the artifacts that we use. Those artifacts are requirements. Those artifacts are user stories, epic stories. They're features, they're specs. A request goes into the PMO, out comes a bunch more artifacts and documents.

So when we look at systems and look at the system of delivery, you have to realize that these are the artifacts that we use to collaborate around it.

So let's talk about systems thinking really quick. I've got a bunch of slides on this. It's very high level. But what I tried to do with systems thinking is wrap some context around it. Because in the years that I've been talking about it, it seems like people just say, "Let's use systems thinking." And that kind of stops there because they don't wrap titles, we don't wrap terms around it. It's just, well, let's do systems thinking.

So let's wrap some terms around it. Maybe it'll help when you're doing systems thinking to look for areas where you're having trouble.

So what is systems thinking? From what I know, simply put, systems thinking is a set of elements that go through, that take inputs through a phase transition into emergence for an output.

That's kind of scary, isn't it? That's like one of those... What's that video? The one where the nuclear oscillator goes through the whatever.

So let's break this down of what this really means. Not the term that I've learned to know, but what does this mean? And let's use a simple system so as you all can understand, and we'll break that down and go through it more.

So we all have these, I hope, at home: clothing dryers. This is a simple system. There is some complexity in a clothes dryer, but let's use it from a simple perspective. This is actually a nice one. It's a nice Maytag. I don't have a nice Maytag at home. So this isn't my dryer, by the way, just so you all know.

So if we break that down into a black box type of system, it's pretty simple. I put in cold air, electricity, wet clothes, goes through phase transition, emerges dry clothing. And the time it takes is the cycle time. We'll talk about that in a minute. But it's that simple from a black box perspective.

Now, if we break that down a little bit, there are actually elements within here. So you got your heater, your drum, your electric motor, your fan, and those are elements.

And this is, in some parts, where I think systems thinking really comes together and where you have to use this part that I'm about to talk about, is that if there's no relationship, a set of elements is not a system. So if they're not working together through the functions that they do, and there's not feedback, a set of elements is not a system. And that's a big part when you think about systems, is you have to take that into context.

So in a theory, that's our dryer. I have electric motor that works with the drum. It turns the drum. They all work together, and out comes dry clothes. There's a vent that pulls the air and pushes it through, and so on.

You can also have interference relationships as well, and I'm sure in IT, we're all familiar with some of these, where if the vent gets clogged up, it's interfered and you can't push things through. You have to understand these relationships when you're using systems thinking, and systems thinking is a lot about how these feedback loops and this information works together so that you get emergence.

So let's apply this to my friends at Acme, see if they can understand that a little bit better. That way, we get a better missile guidance system, hopefully, for Mr. Coyote.

So when you look at that big whiteboard session, you have to look through all of this. Now, there are elements in here, and this is the black box part of that: inputs, outputs, business requirements from the business stakeholders and so on. Defects from customers. Unplanned work, of course, goes into here. All those different things go through that.

And from an end-to-end cycle time, this is your complete system. In here is operations. In here are all those other elements. But from an end-to-end perspective, everything flows through. And you can actually go and then tear those different sections down and define the elements, and these are all probably familiar elements from everybody that's attending here today.

I have requirements. They go through. They go through a transition here where a work package gets made. That work package becomes into build. They create a release package or a test package that goes to quality and so on.

And along the way, because until I describe the relationships, these are just a set of elements. And along the way, there's all types of synergies and feedback as you're going through.

For example, QA sends defects back to dev. You can get some operation defects coming all the way back through the PMO to get prioritized. And all these companies are all collaborating through this, and hopefully people are talking as they're moving this along. But they're talking in relationship to the artifacts that they use.

Now, like I said before, that's just a high level. There is so much more in the systems thinking and diving down into it that you could get stuck down there. Some of the research I did in the past on it was all about inter-human relationships. Everything is a system.

These are just some high-level principles that you can use to think about these are elements. These are relationships. This is an amplified feedback. This one's attenuated and is a problem. And you could use this to help kind of define maybe a little bit of the roadmap that you're going through.

So I also wanted to talk a little bit about Lean principles. Now, personally, I first learned Lean principles about 20 years ago, when we were making airfoils for the manufacturing of jet engines. And that's quite a process. That's where I saw flow and lead time and all those things work really well.

And everybody, I'm sure, has seen Lean Thinking, The House of Lean. There's tons of books on this, and there's a lot of things around Lean that is here. I can't really go through every one of these. This is The House of Lean. There's just a lot of different areas there, and they all apply, if put into the right context, to the work that we do on a daily basis in IT and software development.

And the five principles are pretty straightforward: identify value, value map, map the value stream, create flow, enable pull, and seek perfection through that. Always be looking for perfection in that process.

And there's visual aids that go along with that, and there's a whole bunch of different visual aids. This is a SIPOC. A SIPOC is a Lean tool. It means Supplier, Input, Process, Output, Customer. This is a tool I've used in the past that allows me to describe some of the inputs that may come from different feedback, different relationships. It's very high level, and it helps you really tell a good story around what you're doing. And SIPOCs are very, very useful as you're trying to look at all the different elements in a system.

There's other visual aids that Lean has. This is a value stream map. This is the value stream map, and I know a lot of people talking about value stream mapping. This one's right out of manufacturing. You can see where you have peak time, wait time, lead time, all of that.

I've always found that this value stream map, although it's very engineering, is a little bit overkill. So I just use a simple value stream map, where I look at the elements. I put the time in, try to understand how things are flowing through it, so I understand all the different pieces of this particular value stream.

Let's talk about waste and waste management. That's a part of Lean as well. And it's just a way of framing. I find this term waste within the Lean, just a way of putting a term on time that's wasted on things so that you can have a conceptual understanding of what you need to do.

Now, there's different areas of waste. There's transportation waste. Transportation waste is physically moving things around, more than just moving movement around. So movement waste, which is down a few, is where I'm working on something, and I have to turn my back and move over here. That's movement waste.

Transportation waste is actually getting out of your chair, let's say, and going all the way down to the other thing with a sneaker-net floppy drive and doing that.

Inventory waste, we have inventory waste in IT. That's a big, huge backlog of things. Or those are things that are all waiting to go into production that need to be tested.

Wait waste, we have a lot of waiting waste within it. Overprocessing, defects, all of these are different areas of waste that you can look at and try to wrap terminology around what you see when you do a value stream map or what type of waste in there. But value stream mapping isn't always enough.

Flow. We're all familiar with... I'm hoping we're all familiar. If we're not, that's okay. Different pieces of flow and creating flow. I did not personally see this originally when it first aired. But if you all remember that skit from Lucille Ball, throwing things coming out, going too fast, they were bunching up the process.

If they applied some of these principles like WIP limits, cycle time, lead time, wait time, batch, small batches in your system of delivery. And this is Little's Law over here, which kind of describes creating smaller batches to increase flow and so on. But that's about as far into that as I'm going to go, but this really works. I've seen this work well in manufacturing. I've seen it work well in IT. By removing batch sizes, increasing pull, things go through the system of delivery quicker. And applying these principles have been very effective.

I personally have a family Kanban we use. My kids hate it. But we have one. It's very effective in the home. I put numbers on it for rewards for my kids on those Kanban tickets. So if you do this, you get $5. And the thing that they said was, "Dad, how come doing the dishes isn't a ticket with money?"

"Because you dirtied that dish, son." So you still need to do it.

It's a Kanban. It moves through the process, but unfortunately, they kind of embrace it. I had one son who just decided he wanted to take a bunch of the tickets and just do those. I'm like, "No, you have to do this like this."

Anyway, it's a very effective way to manage keeping the house clean, I guess.

And so this works really well from all different parts of business, not just IT, but in manufacturing as well. We reduced batch sizes through the metal foundry process where I was years ago, and we reduced batch sizes in the forge, which allowed cycle times quicker in forming, grinding, and all the other things that we did in manufacturing there quite effectively.

The challenge here, I think, from applying this to IT is that in that process, and this is the challenge with applying some of these principles, in that process, at the same time, everything that went into flow in manufacturing was the exact same set of materials.

Well, IT kind of isn't like that, right? You're not always getting the same set of materials. You're getting different artifacts with different things that you need to do, and there's unplanned work. There's all types of different work that come in and out. So it's a little difficult to really see these results because there's this other side of IT where I'm not getting titanium into the front side of the manufacturing every time and doing the same thing. The only difference I had there was more effective people doing that work.

Theory of constraints. I only talk about this really quickly, is that in your system of delivery, you want to look through constraint, and that's the piece you need to fix first. So if you find constraints using systems thinking and Lean principles, that's where your first part of value is. And if you do all the other things around that constraint, that smallest part, you're not going to improve your velocity.

So for example, we had a company that set up a test automation system. But what they didn't manage was the things coming into that, managing that batch file process. So really what happened is they were able to test quicker. Because they weren't in a pull, they weren't getting enough stuff to test.

So you have to look at the whole system and look for constraints. So when you think about DevOps, it's the whole system. It's not just this Ops area or just this Dev area.

So let's apply what we just did to my friends at Acme Corporation, and let's use both systems thinking and Lean principles.

So this is a value stream of what I just put together. It's a very high-level value stream. You get more complicated as you go through. And you see that I got my times in here. I tried to have them make sense, but they may not. You're looking at cycle time through each one of those areas or elements in the system.

And again, these work packages are a list of requirements. The tests are a list of test packages, a list of requirements with where the code is and how to test it and all of that, and so on. By the way, we did implement Agile here as well, and we try to bring these together through that. So operation is working whatever methodology they want.

And then release certification happens there in the last few miles, and there's feedback loops going on here.

But here's where I say that value stream mapping isn't enough. Just doing a value stream map of everything, you're just going to see everything flow. But you need to apply some systems thinking because there are tons of different feedback loops that are going on here. There's tons of different relationships before-- Tons, there's multiple relationships between these.

And that's what you have to look at if you want to increase value as well or increase velocity and even become more predictable. Because if you're only improving each one of those elements, then you're only improving those elements. Those elements have feedback.

And that's what I'm saying here. Value stream is just one part of the story. If you just do that value stream as specified within Lean, you're not getting those feedback loops. Those feedback loops are probably part of the reason why you can't understand why this new nice piece of software isn't making my life better. Because you're not realizing that that stuff is cyclical.

Like I said earlier, it's not like I put a piece of titanium in one end, somebody does this, they hand it off, somebody does that. Somebody writes a requirement that goes over to Dev. They code against it. They have issues with the requirement. They communicate back. There's a lot of feedback going between these different elements in software development.

So you have to understand these relationships, and you have to put metrics on those as well in the system of delivery.

So for example, I'm in development. I need a system to start programming with. What do I do? I put in a ticket over in ServiceNow, with Operations. That takes me two days to get a system. By the way, that's dramatically improved since I started doing this with some of the DevOps tools, that part of the systems of it all.

But you got to understand the relationships, how everything feedback. For example, the quality people, they're working in Quality Center, and there are other tools and other solutions. It takes them a few days. They have to log back into these tools and enter those tickets, and then it takes a few days for that person to solve the problem. Then they trade emails. They do all this stuff.

If you don't understand the feedback loops with, of course, the value stream, it's not the same as trying to solve the whole picture because of all the communication and all the feedback.

So what can we do? Now, of course, integration to remove waste. Oh, I forgot to talk about that.

There's waste here. Movement waste. I'm moving tickets around. That's how we can bring that back to Lean. There's movement waste, there's transportation waste, there's other waste within the system that we can bring back to those eight principles of Lean in waste.

So having to go from putting a ticket in dev and then keying it in somewhere else, that's movement waste. I have to open another system. I have to put that ticket in. Then I got to keep track of it, it's in my emails.

It would be nice if it was all integrated, and we could create one backlog in whatever tool you want through the system of delivery. That way, if I have one backlog that includes the backlog in my operations, I now know when I'm trying to get predictable what my dependencies are in there.

So I have a user story. I've got a task on it that creates a ticket in ServiceNow. That's what this company's using. I can then see that that's dependent, and I can understand how long that's going to be. So how long is it going to take me to do that user story? I have an operational dependency.

So that's the theory of creating one backlog. Got my sprint backlog and my Kanban backlog. They're connected. They're the same ticket.

So this is the solution. Deploy an integration hub. Now we have an integration hub. There are other vendors that do as well. But you allow these systems to communicate. I set it up where I can create a Jira task, and it'll automatically go into ServiceNow. That ticket is received. I'm removing waste by doing that.

Oh.

So what other benefits do we get out of thinking this way, using systems thinking, using Lean? And I know that I really did a high-level approach here. The other benefits I get are I can really define my DevOps journey. Where am I going to solve first? I can set up a roadmap based upon that.

I found constraints in these areas. These are the first areas within DevOps I'm going to try to solve. Or if you're like me, I'm going to leave that over there. I'm going to get some low-hanging fruit.

Just kidding.

And these are the areas where I can see improvement. And as you're improving the system by removing waste, looking at all the feedback loops and relationships, you are moving forward, and keep using systems thinking to keep reducing that and consistently improving. Keep using Lean principles, looking for waste, and understanding how to communicate those with these principles.

You create a roadmap, and it also allows you to give more of a return on investment because you're using analysis of time and effort. A lot of times with these solutions in DevOps and so on, you're like, "What's my return for doing that?" Well, I can actually tie that to a return.

So we solved the problem. Mr. Coyote here has a missile guidance system that they need simply by removing a very simple bottleneck within the system.

I didn't click that button.

Okay, so we solved the problem. To be frank, I was only told I had 30 minutes, so I can go to questions now on some of these thoughts that I have put out here and go from there.

Thank you.