 As Domenica said, I'm Julia Wester and I am a consultant or coach or whatever you want to call it at Lean Kit and we make Kanban boards so it's not unusual for me to talk to people about Kanban. And what I really love about today is that all of the speakers that have talked so far have introduced things that I want to talk about as well. So we're planting these little seeds, that's one of Domenica's tips, is plant a seed. If you don't germinate right away, that's okay, just keep watering it. So throughout this conference, we're watering all of these seeds and hopefully eventually they'll start to take root where you're going. And when I go out to help customers, because that's what I do, I go out and I help them see what their work is and how they deal with it and find ways to tame that chaos to make it just a little easier and just a little better for them to get their work done. But what I see a lot happening is that people get started but then they get stuck and they don't know what to do next. So that's actually happening to quite a lot of our user base. It's really easy to do those first few steps. It's easy to learn how to click buttons on tools but it's hard to really make the change, the underlying change that helps you make those big wins. So that's what I want to talk about today is how to get beyond those quick wins and help get some real deep meaningful change in your organization. So I want to start by telling you about a team. And this team, like many of those others that I described, they started visualizing their work. That's the first win that you get. You get your board up and you start to see all of the craft that you've got going on, right? And it's not a pretty picture. It can be really scary. But the win is that you're facing it. Someone said, I can't remember who at this point, that you're embracing reality. And that's exactly what we want to talk about. We don't want to just deal with falsehoods that doesn't help us get any better. And these people, unlike many who just start, had also started limiting their whip. That's a term you've heard a few times, their work in process, how much they allow to get started before they really worry about finishing things. Now, so they had gotten some of these quick wins but they weren't getting the gains they heard about at these conference talks. They weren't getting the Starbucks gains. They weren't getting the other things. But they didn't know what to do. What they ended up doing was yelling at each other. They knew that they had a bottleneck somewhere in their system that things got stuck. But they really didn't know what to do about it. These people are what you hear some coaches refer to as a shallow Kanban implementation. It means my definition of that is that you've implemented a very thin layer of something good. Now you heard about this earlier, this J curve here. I as a lean coach go out and tell people all the time to make little changes. So the fact that people are out stuck with a thin layer of something good isn't a bad thing. I mean it's a layer of something good. And that happens because when we make a change, we think what's gonna happen is you start here and you have this nice little happy path all the way up the mountain to your final destination for now. And then what really happens, no matter what change you make, whether it's hiring a person, implementing a new technology, you have an adjustment period. And the size, the width and sort of depth of that adjustment period really depend on the size of the change. That's why we make a lot of suggestions about making small incremental changes. Because if you bite off more than you're really ready to have, you end up burning to death in this pit of despair, right? And that's where a lot of good changes go to die. You're just not ready for that size yet. That's what we call the J-curve or the satir curve. So we don't want that to happen to you. We're gonna talk about how to get a little deeper, but I wanted to let you know that it was okay to be in that place. And I wanna share with you some ways to identify if you are maybe in a shallow implementation of your process improvement or a combat implementation. And when I did some research for this talk, I mean, I knew what I thought, but when I researched that, I found about four common indicators. And the first is that initial quick win. You've got your view of your reality. And like this board or maybe even worse, there's some boards that look like someone bled on it because there's so much red problems going on. So that's actually a win. Seeing that blood loss lets you stop it. So you have a view of reality, even if it's scary. The second common thing that we see is when people start to visualize their work, they're maybe visualizing about their personal work. So a lot of personal combine boards or maybe the team is visualizing their work as well, but oftentimes we're still visualating isolated teams. And we haven't yet gotten to the part where we can get our head enough above water to look out and see who else is around. And so we want to get there, but usually these teams that are in the shallows aren't there yet. Now, if they are limiting work in process, which is a key component for improvement that we'll talk about later, they're usually doing it to relieve the overburdening of the individuals. And that's often the second quick win, is when I first implemented Combon at NBA.com in Atlanta at Turner Broadcasting. The first thing was that people started feeling this relief. So I could immediately limit what was coming into the system. And people would feel like, finally, I can just focus on this one thing and I know that it's allowed. But I wasn't doing it for any other reasons like flow or business value yet, so I wasn't yet at that level of maturity. And then the fourth identifying factor is probably no focus on continuous improvement. So you might stumble upon a great improvement idea. You may have these occasional feedback loops that work for you. But a lot of times what we see is we sort of have these retrospectives and things fall into the trash can. You know that's happening to you if you go to the next one and you're like, did anybody take notes from the one before? And are we doing anything with that, right? And it's just crickets. So we don't want that to happen. Don't want to waste that time. So again, not bad to be in that spot. But the key is that we don't want to get stuck there. Getting stuck there is what's bad. And I like to think about a couple of laws of science when I think about this potential problem. The first is the law of inertia. And I'm going to paraphrase it, that things at rest tend to stay at rest. And things in motion tend to stay in motion. And when we're thinking about how we want to be moving as a business, as a team, as an org, we want to be one of those people that's caught in the perpetual motion, not the people caught at rest. We don't want to be the next blockbuster, right? That leads me to the next. I feel bad. Everybody picks on them. But they're such a great story of what not to do. And we need those. Maybe we should find some more and stop picking on them. But that leads me to the law of entropy. I think that's what, the second law of thermodynamics or something like that. And it really says that everything is in a state of decay. So there goes the idea that we can stay here in our little status quo and maintain the peace and keep all of the value just as valuable as it is without doing anything better. What's happening is that Netflix and all these other people are moving ahead constantly. And you actually have to swim to stay the same distance apart from them. If you want to catch up with them, you actually have to do even more. So we can no longer think that we can sit down and be complacent and not worry about continuous improvement moving forward. Deming said improvement is not optional. Survival is not mandatory. So you don't have to survive. If you don't want to improve, that's OK. So when this team got super frustrated, all of a sudden, here's how I picture it happening because I wasn't there. The guy got so frustrated. And he said, well, what the heck is our bottleneck? What's going on? And in that moment of frustration, what happened is that they actually started diving into the problem. He was super frustrated and he was yelling, but he was getting somewhere. They started focusing on the issue at hand. And that took them a little bit away from focusing on the people. They were starting to think about solutions. And so he said, what's the bottleneck? What's its throughput? How much can get through that place where everything gets stuck? And even better, are there things that we can put through our system that don't have to go through that bottleneck? So now these people are actually starting to think about how their system works and how things move through it. And without even realizing it, they were starting to get into a little bit of deeper maturity about how to make their business more productive, more productive of customer value. So how can you go from a shallow process improvement mindset to something that is a bit more habitual and deep? How can you find those big wins that people come to conferences and talk about? Are you here in the books like the Phoenix Project or the Goal, all these other things? The way I want to cover that for the rest of the talk is to talk about three overarching areas and then within those areas of focus, maybe I hope that you find them to be tactical things that you can go out to do. I don't want you to hear about these things and go, that sounded nice, but what the heck do I do to make that happen? So I want to give you a few things that you can actually go back to your office on Friday or Monday to do and maybe start you on this journey to dive a little deeper. The first area of focus is what we've heard a lot about whether we've used the name or not and that's systems thinking. We want to think like a larger part of the organization, not an isolated team. Now, Jeff had an amazing story in his talk about that where you sort of pop your head up out of the hole and you start looking around, OK, how does this whole thing work? We need to understand our entire business line, not just your little piece of it. And we're here in Dev Ops, you know, day Seattle. And I look at that as a little microcosm of the concept of systems thinking. So at one point, the Dev Ops were like, what the hell is going on? This is so bad. We have got to do something about this. So they took a handoff in their system. They said, this is so horrible. It cannot be allowed to continue anymore. And they figured out things that they could do to improve that handoff. And that's what all of the stuff that we're talking about really cover. Now, what systems thinking is, is if we take that, that mindset, and we move that to another handoff and another handoff and another handoff and improve that whole value stream that Jeff showed, or that Sarah showed, then we're really starting to think like a whole organism. The thing that is good to remember is that it really doesn't matter to your organization how great your team is if your team isn't helping the whole organization move forward. So the way to do that, again, like Jeff, to just really great example of this, is to start building relationships with other teams. And that actually takes conversations. And you're probably thinking, well, duh, we know this. But how many people are actually going out and building those relationships? We know things, but we don't do them. So one of the ways to tactically get started with that is to look at who needs things from you organizationally and who you need things from, and start making that list and maybe even write down what kinds of things they need from you and what kinds of things you need from them. And then maybe start with the people who need things from you and go out and proactively say, hey, I noticed that you often need this from us. How can we work together and make this better? Maybe we can start attending each other's team meetings and get an understanding of your whole work life, and you can understand ours. And that way, when we have a problem, we don't have to wade through seven levels of relationship issues before we can get to the problem. And then if we go out and help others, then we've built social capital and credibility that we may be able to capitalize on when we need help from other people. So we wanna start breaking down the other barriers. We're already talking about DevSecOps. As soon we're not gonna be able to put that stuff together anymore and we're just gonna have to say systems thinking. So once you do that, once you identify the things that you need from people and the things they need from you, the next thing is to look at your combine board, your visualization. This visualization serves to help you with your problems. You don't serve it, it serves you. So one of the things that we wanna do is take that cross-team information and try to make that as visible as possible. Now we can do that with things like dependencies, and I don't mean code dependencies, like in Maven or anything like that. I mean work dependencies. Like I need this from your team and you need this from me. And so I've got an example of this here. You can do this on a physical board, you can do it in LinkedIn, it really doesn't matter. As long as you're trying to visualize that. So I've got team captain here, he has a project going on and he needs a couple of things from Tony. So they have visualized that on their board and not only that, but they visualize the relationship and that they're dependent upon each other so that everyone can know the impact of what they do or don't do. And then another example of this is I talked to a customer just a few weeks ago and this, one of the teams that I talked to and out of the two wasn't even using visualization yet, they were about to get started on their journey. But he knew enough to know that he needed something from Carol's team over here that was visualizing their work. And he said, I'm gonna get started, but I know that I need information from Carol's team. So if I work with Carol, she can understand the things that I need to know and then she can update her Kanban board so that I can get that information before that work ever hits my team because they were the next step in the process, the handoff point. So he could find out things like, oh, this is missing a document way before it ever even got to him and be ready for that. So visualizing that. We talked about metrics a lot too in this conference and the thing that can break your system is measuring the wrong things. So you can do all of those other things and you can do them very well, but if your metrics are driving the wrong behaviors, it's just all gonna fall down. So Eli Goldrat said, tell me how you measure me and I'll tell you how I behave because everything we measure tells people what's important and what to do to make that happen. And so he said, if you measure me in an illogical way, then don't complain about my illogical behavior because it's pretty much your fault. So you're telling me what to do with how you're saying you're measuring me. And so we see this all the time in organizations with these departmental silos where they're pitted against each other and no one seems to be working very well together. I can almost guarantee you that's because of how they're measured. They're measured by the goals of their department and not the goals of their organization. So we absolutely have to look at this if we want to have any chance of thinking like a system. Start with your team. You can't affect everything, but start where you can and start teaching others how to think about this. Look at your metrics and say, is this fostering, my dev team to be the best, my ops team to be the best, or is it helping us be a better company team? Now once we have our system in place, then we have to start to think about what happens inside of it. So this next area is focusing on the flow of customer value. There's two things there, customer value and flow. I'm gonna talk mostly about flow, but the customer value is important. We don't wanna just focus on personal tasks, the little things that you're just trying to keep track of, that's all important, but we wanna frame that all as in what pieces of value are we trying to deliver through your system? What makes your company money? And you need to know what that is. The flow part is extremely important. What we see a lot in organizations is the concept of thinking that keeping people busy equals the most value for our organization. So we see a lot of things that I would call an anti-pattern like personally named swim lanes or other things that are really engineered to make sure that someone stays busy. And what this does is it makes us focus on capacity management instead of throughput. And it makes Sally and Ahmed and Tamara and Blake, it makes them focus on their work. And even though you see everything else, it's a subtle clue that this is your lane, you stay in your lane, and it takes that aspect of trying to function as a team away. It makes it one little step harder to do. So we wanna remove all of that, we wanna function as one team, visualize the whole body of work, and then we want to make the cards important. We wanna make them about customer value. Now the second thing that we wanna do once we have our board showing the right stuff and sort of laid out in a way that's promote, something called pull, we wanna use something called pull to manage flow. And flow is just like a river, okay? I'll talk about that in just a second. So we want work to have a steady continuous movement from options all the way through deliver. And this doesn't matter what your columns are named here. Most of the time, the teams that I've seen before they know what pull is work in something called a push system. So that means I'm Julia, the developer, I used to be a developer, and so I start work. I learn every time starting is all the rage, right? So I start, start, start, start, start, and I just turn things out because I think that's what's important. And then when I'm done with my piece, I push it to the next step of the workflow and I'm like, here you go. And either no one's there, they're like, holy crap, I've got 4,000 things to do already, right? And so that doesn't help anyone. But we don't realize that yet. A good question to think about is does it matter if you deliver something if no one can pick it up? Right? The answer's no. So one of the things that we can do to build pull into your visual board is to do something as simple as these sub columns. Some people call them sub lanes. Now what this does, two things. It gives a visual indicator to the next step in your workflow that, hey, this is ready for me. When you have time, you can pull it in. That's why it's called a pull system because I'm not pushing it over there, they're pulling it in. So that's the first big one. The second thing is, is that it's much more accurate. If I don't have those columns, I just see a bunch of stuff and build and I have no idea whether it's all actively being worked on or if it's waiting. And once you start working in this kind of system, you start to see how long things actually spend in weight and you find out that that's reducing the weight is where you're gonna get the majority of win from a cycle time or a lead time perspective. If I'm a coder, I tend to think the thing I need to do is focus on how fast I write my code or how great my code is and those are great things to focus on but if 85% of the lead time of a piece of work is stuck in waiting places, then your improvements are gonna be small gains. Really where we need to also start focusing on is reducing the weight but before we can reduce it, we have to visualize it. Once we have pull in our system, then we're really set up to start thinking about the volume of work in our system. And so then we wanna limit our work in process to find problems. And this is the key tool in a Kanban implementation that you need to have an order for it to really achieve its purpose, it being the Kanban system. Now, Taichi Yono that I think that we saw earlier, he said that the goal of Kanban is to make problems rise to the surface. That's the entire goal. Lip limits are an enabling constraint. We constrain us to the amount of work we start so that we can find those problems, fix them and then in the end get a faster delivery of work through our system. So if we do not limit our work in process, we're not gonna find the problems. It's much like a river. If you look at a river that's sort of filled up to its banks and it looks like it's just flowing along, we don't know whether or not it's really a smooth flow or if there's a lot of rocks and logs under that river. So our version of bringing the water level down is to use a whip limit in different parts of our workflow or if you want to just to start, put a whip limit on just the work in process in general, just try to bring it down a little bit, that lets us start to see where our problems are. If we get stuck because of a bottleneck and then we just start more and start more, we never fix that bottleneck, right? We don't make ourselves feel that pain much like we heard from our local coffee company earlier today. So it's really, really important to feel that pain like they said. Now, a lot of people don't know where to start with whip limits and good thing is there's no one right way, so you're not gonna get it wrong. The only wrong thing is to not try it and you want to hit your whip limit sometimes which means sometimes you want to feel that constraint or you don't find the problems but if you hit them every day, you're gonna give up. So you need to find a happy medium of what makes you hit your problems every now and then at a nice enough cadence that doesn't completely stress you out or that doesn't help you at all. We don't want you to give up. So if I had to sum up this whole section, it would be just to remind you that waiting to do something until it can be used or utilized is that elusive thing we call working smarter, right? And not harder. We all know that time is really our most precious resource and we're wasting it all the time by the choices that we make about how we process our work and that's not responsible once you understand that concept. Now the last area of focus is continuously assessing and improving and this shouldn't be too far into you. We want to complete that loop. We want our outputs to be looked at, processed, then we decide we're gonna do something with it or throw it away and then we want that to inform our future decisions. The first thing that helps us get into a concept of continuous improvement is to make it a habit and one of the easiest ways to make a habit is with a cadence. Repetition makes a habit. So here are some examples of certain cadences you may want to implement in your organization to start getting habitual about thinking about improvements at least. Now just because you have a stand up doesn't mean you're gonna improve anything so you still have to do more work but you're thinking about it hopefully. So at Kanban stand up people may wonder why I put the word Kanban there and I do that because I find it's a little materially different from what you think of as your average stand up. You don't get up and ask the three questions, a lot of which have to do with status and that's good to know but that's on the board. We don't need to know what you did yesterday and what you're gonna do today, it's on the board. So we focus on how do we move things to the right, right? We start at the right of our board actually and say okay what's here and can we move any of it? Why not? Can we do anything to help that and we work our way left? We don't talk about things much unless they are exceptions and we figure out how can we help other people remove blockers or just get things done faster? We focus on finishing. And we do that on a daily basis if possible but at least two or three times a week something habitual. And then the next is a retrospective and I like mine blameless, I don't know about you but I like to focus on solutions and not throwing blame around. And you do that every couple of weeks and in my next, well one of the tips in this section we'll talk a little bit more about what to do with your retrospective. And then maybe on a monthly cadence you have an ops review and I don't mean ops like server people, I mean ops like operational review, let's look at how things went and review that on a monthly cadence, look at your performance over the past month and whatever you decide will drive the right behaviors whichever measures you choose and then look at it as a trend as well month over month, year over year to really see how you're moving. When we do those we want to cast a wide net, we tend to be insular and just ask for feedback within our team. But what I started doing when I worked at F5 Networks was that I started reaching out to every person that we touch, every stakeholder we have, every two weeks and say how are we doing for you? I didn't let it hold me back, I didn't wait on them and not do anything if I didn't get their answers but I asked because I know that if I just ask my team I'm getting a very narrow perspective, we're not the customers of our work, someone else is. So yes, we need to understand our feedback because we have to live through the delivery and we have to improve it but we also need to make sure we're doing the right things for the people that we're working for. The third thing about feedback is to make sure you do something with it, okay? We want to focus on outcomes and not only that but we want to be scientific about it. I love Rub a Little Science on it, I don't know if I heard it from Nicole or who but I love it so. Yeah, we want to put some rigor back into our retrospective process. One of the best things I heard from someone is that the goal of their retrospective is to design an experiment. Every time they leave a retrospective an experiment comes out of it and what I mean by experiment is like the actual scientific process. Like here's the thing, I have a thought about that thing, I have a hypothesis that this caused this so if I do this, this other thing will happen and then I determine how I'm gonna test my theory and how I'm gonna check it and when I'm gonna check it, right? Because if you make a change without a hypothesis you have no way to check and see if it's right or not, right? And you might want to repeat that, you might want to have other people repeat that just like a scientist, you need to be a flowologist. What are the experiments I can do to improve the process, the flow through our system? So rigor with a focus on outcomes. We don't want the feedback just to go in the circular file. Now when our team that in the story when they started really diving in to the flow in their system, when they started understanding the impediments, making decisions and experiments on what to do about it, implementing lower width limits and really focusing on making those relationships, what happened is they saw system wide improvements essentially in their lead times. Now it took a long time for their bottleneck to be alleviated, but well before that they saw immense improvement across all other parts of their system because they were treating the whole system and not just an individual piece of it. So that obviously made people happy. You can see these trend lines getting greener and happier. And so people started coming to them and their organizations and saying, hey, you guys are doing this thing. And that looks really awesome. Can you come to my team and help us figure out how you did that thing so I can do that thing too? That's happened to me before. And before, sooner or later, you're gonna become this person who's doing the conference circuit in your organization because these things that after a while seem so common sense are just things that people don't know to think about, okay? And by thinking about these things, we can provide that business value that Jeff talked about in his talk. So I couldn't in this talk without asking you to start thinking about tracking that progress from where you are now to where you want to be, right? You're gonna use all of those things, especially the feedback loops and the measuring where you are, measuring where you wanna go and tracking your incremental progress. There's no one right way to do that. You could always take the Dora assessment and get a little more scientific about that. I'm pointing there, because Nicole was there earlier, she's not anymore. But no matter how you do it, start doing it. So in summary, the things that we have talked about today to improve from where you are, first embrace that where you are is a good thing. Stop beating yourself up if you are about, I'm not here yet, you're here, so that's great. Think about the entire system, where you fit in, understanding what the business really means to you. Think about how you move work through that system. What's valuable and what can you do to improve that? And then finally, feedback, make it a habit. One of the things that I like from SAFE is their concept of everybody takes a new spin on continuous improvement. They call it relentless improvement. I really like that the flavor of that word relentless because that's really what we're striving for. And not just relentless crazy stuff, but actual purposeful improvement that will get us where we wanna go. So if you want to, you can take out your phone now and email Julia at linkit.com, just put the subject Kanban. And I'll send you the slide deck. And I'll send you a roadmap, a Kanban roadmap ebook, free, to help you figure out how to take a lot of these concepts, again, tactically execute them in your organizations. Even though it's from Linkit, it is tool agnostic. You can use stickies, so not trying to give you sales material. It's purely just for you to think about these concepts and tactically deploy them in your organizations. So thank you very much, appreciate it.