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 I’m 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. So we'll talk really quickly about systems thinking, lean principles. We'll talk about integration, and all the different types of integration, through this as well. So would it be a very quick presentation on that and 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 and 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’ve 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 plus employees. We focus on a whole bunch of different things with 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 let me put it 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. You're gonna have bottlenecks. 

You're going to have different parts within your overall system. 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. So, 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, 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. Okay. We all use Acme, right? So what's really cool about Acme, is that 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, where they're not releasing enough to update that. So they keep missing the target. There's a lot of failures and issues with this, which we're all familiar with, if you're old enough to remember this cartoon. So, Stark Industries has a much better product as well. So when we started to engage with them, it really started with a really big white board session where we actually mapped out the end to end system. And we look 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 head 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 was just really interesting pieces here as they create their work items and work packages, on one side and they go to development, network 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 a second test. And you know, 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, 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 we’ve gotta look at the whole system 

As I go into the systems thinking and talking about that, understand that, in the world of software development, the ins and outs of a system, or the artifacts that we use, those artifacts are requirements. Those artifacts are user stories. Epic stories. Their features, their specs. A request goes into the PMO, outcomes 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. So let's talk about systems thinking really quickly. 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 use system thinking. So let's wrap some terms around it. Maybe that'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 a bunch of that kind of scary, isn't it? That's like one of those, what's that video, the one where the, the, 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 unless you use a simple system. So as you can, all can understand and we'll break that down and go through it more. So we all have these, I hope at home colds and 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. That's a nice Maytag. I don't have a nice Maytag at home. So this isn't my dryer, by the way, just, just so y'all know. So if we break that down into a black box type of system, it's pretty simple. I put in cold air and electricity. The clothes go through phase transition and emerge as 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, they're actually elements within here, you got your heater, your drum, your electric motor, your fan, and those are elements. And this is in some part where I think system 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. So, and that's a big part. When you think about systems, you have to take that into context. So in theory, that's our dryer. I have an electric motor that works with the drum. It turns the drum, they all work together and outcomes 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 interferes 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 kind of 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 the 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 that go through a transition here where a work package gets made. That work package becomes a build. They create a release package, or a test package that goes to quality and so on. And along the way, because until I described the relationships, these are just a set of elements.

 Along the way, there's a whole type 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 relation to the artifacts that they use. 

Now, like I said before, that's just the high level. There is so much more into 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 inner human relationships. Everything is a system. These are just some high-level principles that you can use to kind of 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 lean time. And all those things work really well. And I, you know, 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 it 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, you know, identify value, value of map, map the value stream, create flow, enable push, enable pull, I'm sorry, 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 side-pocket 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 and is very high level, and it helps you really tell a good story around what you're doing. And sidewalks are very, very useful as you're trying to look at all the different elements in a system There's other visual aids that a 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 a very engineering, is a little bit overkill. So I used to just use a simple value stream map. We're looking 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, you know, waste, they find this term waste within, within a lean, just a way of putting a term on time. That's wasted on, on things so that you can have a conceptual understanding of what you need to do. There's different areas of waste, there's transportation waste. Transportation waste is physically moving things around, more than just movement waste. 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. Let's move it. 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, with a, a sneaker network fluffy 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 needs to be tested. Wait wastes. We have a lot of waiting waste, within it over-processing 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. I'm hoping we're all familiar. If we're not, that's okay. Different pieces of flow and creating flow. I don't know. I did not personally see this originally when it first aired, but if you all remember that skit from Lucille ball with things coming out, going too fast, they were bunching up the process. If they've applied some of these principles like whip 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 pole things, go through the system of delivery quicker And applying these principles have been very effective. I personally have a family compound. 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, right? So you still need to do it. It's a kanban that 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. And like, none of 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 that allowed for, we reduced batch sizes in the forge, which allowed cycle times quicker, informing, 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 and 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 in doing the same thing, the only difference I had, there was more effective people doing that work. 

There is a constraint I only talk about this really quickly is that in your system of delivery, you want to look through constraints 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 then 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 poll. They weren't getting enough stuff to test. But, you have to look at the whole system and looked for constraints. So when you think about dev ops, it's the whole system. It's not just this DOP 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 system thinking and, lean principles. So this is a value stream of what I just put together. It's a very high level value. Shouldn't be getting more complicated as you go through and you see, 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 lists 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 kind of 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. There's multiple relationships between these and that's what you have to look at. If you want to increase value as well, or clique increase Velocity and even become more predictable. Because if you're only improving each one of those elements, then you only approve on those elements, those elements have feedback. And that's what I'm kind of 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. It's not like I, 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 requirements. 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, 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 service now, 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 dev ops tools, is that part of the systems of, of it all, but you gotta understand the relationships, how everything feeds back. For example, the quality people that are working in quality center, and there are other tools and other solutions, it takes them a few days to have to log back into these tools and enter those tickets. And then it takes a few days for that person to call 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 a 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, right? 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 and 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 and I got to keep track of it. It's in my emails, it would be nice if it was all integrated and we can create one backlog and 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 what 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 service now, that's what this company is using. I can then see that that's dependent and I can understand how long that's going to be, how long it's going to take me to do that user story. I have an operational dependency. So that's the theory of creating one backlog. I've got my sprint backlog in my Kanban backlog. They're connected. They're the same ticket. So this is the, this is the solution, right? Deploy integration hub. Now we have, 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 they'll automatically go into service now that the ticket is received. I'm removing waste by doing that. 

So one of the benefits  we get out of thinking this way, using system thinking, using lean. And I know that I've really, really done a high level approach here. The other benefits I get are I can really define my dev ops journey. What 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 dev ops. I'm going to try to solve, or if you're like me, that's, I'm gonna 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 in 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, lot of times, with these solutions and dev ops 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 solve 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.