Julia Wester

Hi, everybody. My name is Julia Wester, and I'm an executive consultant at LeanKit. LeanKit's a sponsor here. We don't have a booth, but what we are is a software company that creates visual work management software, so Kanban boards. So it shouldn't be surprising that I'm going to talk to you about lean things, about flow.

And I love being at the DevOps conferences because DevOps and lean are like fraternal twins. There's a lot the same, and then they diverge a little bit into some differences. And it's really hard to do DevOps really well without flow.

So we're going to talk today about taming the chaos, which is, I like to say that I help customers tame the chaos one engagement at a time. So we are going to look at how to do that by unleashing a little bit of flow.

A common problem that I see in a lot of organizations is that there are people that read books, that go to conferences, and we get all excited about the quick wins that we want to make, and we have these grandiose plans. And then we get back to where we work, and we start doing some things. We make some quick wins.

But a few months in, we're like, "I thought I'd be farther along than I am right now. It was harder than I thought to get those few things done," and we're losing steam. The good thing is we've made some improvement. But really what we need to be doing is not letting ourselves get stagnant.

So today, because I see that so often, it's why I want to talk about, okay, great, we did those things. What are some tactical ways that we can sort of bust off that plateau, or use my diving metaphor, dive a little deeper, to get to deeper and more sustaining wins beyond the first few that we make?

Before we start that, I do want to clarify something, because I don't want anyone to misinterpret the fact that I think taking small wins or small steps towards improvement is a bad thing. As a lean coach, I counsel people all the time to make small, incremental, evolutionary steps toward change, because I know that when we make change, there's an adjustment period.

There's a big difference between what happens when we make change and what we think happens. So we think we start here in our current condition, and we make a change, and we're just going to saunter right up to our desired state. But what really happens, and many of you have probably seen this J curve or Satir curve before, is that there's always an adjustment period. And it doesn't matter if it's a good change or a bad change, all change takes adjustment in one form or another.

Now, you may not notice it because the size of the change will dictate the size of the adjustment or the complexity of the adjustment that you have to go through. So when teams take on, or when organizations take on change that's too big for themselves, that they're not ready for, what happens is they end up abandoning their efforts in the middle of that pit of despair because they just weren't ready to take that big change on all at one time.

So really great to take small changes. It keeps us from having good ideas perish in the pit. But we just don't want to get stuck in the shallow end of a lean initiative, a DevOps initiative, a Kanban system implementation.

It doesn't matter why you're there. It doesn't matter if you're there because you just started or if you don't know what to do next. We just don't want to get stuck.

I've identified a few characteristics, at least in a lean implementation, that might signal that you're in the shallow end. And again, having one of these characteristics doesn't mean that you're doing anything bad. It just means you're at the very beginning. So you need to think about how long you've been there and if you need to push yourself forward to a next step.

So first starts with a win. You visualize something about your work or your workflow. That's great. And I'm coming at it from the sense of visualizing the work that you need to get done and the process it needs to go through, your system, your value stream. And then, you might be thinking a bit more granularly, like my continuous delivery pipeline. That's all good, but the point is that we're visualizing something about our work.

Now, the problem is that we don't always have a complete visualization. We may never have one, but generally when we start... Take this portfolio Kanban of sorts here. So I used to be an IT web development manager at F5 Networks, and I reported up to the CIO, and we would all look at this project portfolio chart every week, and we'd really focus on that.

And you could see how very easily an executive might think, "This is all the work we have to do." So if we're only looking at projects, it looks like we could fit a couple more on there. I mean, we got 200 people working for us, right? Why can't we just do a little bit more?

And we have to keep remembering that our visualization helps us manage the work or the things that we're trying to do, and it can only help us with what we put on it. So if we're leaving a lot of things off, we aren't really putting ourselves in a good situation to understand the impacts of making change A on our whole body of work.

We all live in a world of disparate systems, so it's really difficult to do that. But there are also companies like Tasktop, and I'm sure they have competitors too, that specialize in helping us connect our systems so that we can leverage a more complete picture of what we're doing.

The second characteristic is that we probably realize we have a problem with silos and that we need to do something about it, but we are still very far away from having alignment across those. This could really sort of manifest in drowning in handoffs. It could be that we aren't aligned not only on the things that we need to do, but when we need to do them.

I was at a customer recently and we sort of came up with this fun phrase about, "Hey, your agile's bumping into my agile." Because everybody's trying to move so fast, but they're out of alignment, not necessarily on what they're doing, but I'm trying to do this now, and I'm going to do this two months from now, and so we keep running into each other because we're not aligned.

So alignment is at least two different vectors. It's on the what and the when, and we often forget the when.

This next one is a favorite of mine. It is that really we're still in the mindset that capacity management and maximizing that usage is the biggest thing that we need to focus on. I am not going to come out and say that capacity management is a bad thing. I think we all realize that we'd be fiscally irresponsible if we left huge swaths of capacity unfilled.

But we haven't yet realized at this point that sometimes utilizing our capacity to maximum is what causes all of our progress to slow down. We see this in lots of places in nature. We see it in the roads. When we fill the road with 100% capacity of cars, we go to a traffic jam.

We see when we fill the printer with too much paper, we don't just say, "You can do it. Let's cram more in and then we'll get more out." It doesn't happen that way. In general, when systems reach 100% capacity, like servers, they're going to crash. They're not going to do better.

So we have to remember that that also applies to our system, especially because a human system of people working together is so much more complex than some of the other things that we already see this in.

And then the fourth characteristic is that, again, you've already made some changes. You're thinking about improvement, but it's not really baked into the way that you think. We're not prioritizing it. It's exceptional, but in a bad way, because it's usually the exception to have really good sustainable improvements.

And that's because we don't connect our feedback loops. We ask people for feedback, and then eventually they stop wanting to give it to us because they don't see any outcomes from that, and stuff like that. So occasional improvements do happen, but there's no continual focus. And even more importantly, very little measurement of the outcomes so that we can take that learning and apply it back to our next decisions.

So if I had to go back to myself about 2008, that was my first management job, and I gave myself a piece of advice, it would be to measure the outcomes of the changes that I made. Because I would go off of, "Well, that seems like it worked." And one, I would have so much more data for stories right now. But two, I could have really been a lot more specific about understanding what changes made what things happen.

So those are a few characteristics. And like I said, it doesn't matter if we're there, if we're in those places. It's good to know that, and just know that there's a path in the future, so we need to keep moving forward. We don't want to be inert.

We need to understand that just like this fish here, that fish has to swim to stay in place. So it already takes effort to maintain the status quo. A lot of times we don't think about that. We think we can just sit on our laurels and do what we're doing, and at least nothing bad will happen, but that's not actually true.

Other companies are swimming even farther to get ahead. If we're not swimming at all, we're actually moving backwards. So we need to always have this urgency behind improvement so that we can keep pace and hopefully exceed our competition.

So that's why we're here today. It's to get a sense of if we're in this place where we made some improvements and we're feeling a little stuck, what are some ways to help us really make the next few small steps, again, incremental changes, to help us make our system work better as a whole? How do we start getting our work and our ideas to flow through our system so that we can deliver value faster?

And the first is connecting the entire system. A lot of times we start with a very narrow focus. DevOps started that way, and it's definitely grown. It started with two pieces of a system saying, "I'm dev" and "I'm ops," and, "Oh my god, this handoff point between us is so heinous that we have to do something about it."

And we've started to see that's great, but that's not enough. So we start hearing about DevSecOps, DevTestSecOps, BizDevOps, all of this other stuff. It's really systems thinking.

So we want to understand that if we're only looking at isolated handoff points in our whole value stream, all the things that it moves through to get something done from beginning to end, if we're only really looking at one or two points of that, we're not going to make the massive changes or the massive improvements that we could have if we really understood and optimized all of the touch points in our system. So we want to start thinking about that.

So that's the first theme. So tactically, what could I do? How can I start the next step towards connecting my entire system? An easy idea is to look at the work that you do and look at who you need to touch. What are the touch points in that work? You have people that need things from you, and you have people that you need things from.

So I would start with making a list of all of the departments, the people, the teams that need things from you, and I would capture all of that and I would write, "Do these people need stuff occasionally or regularly?" And then I would do the same thing for the other side. Who do I need things from?

And then I would start reaching out to those people, starting with the ones that need things from us. I think there's a small psychological factor to not being self-serving first. You're building social capital that you can then leverage later by reaching out and say, "Hey, I'm trying to be a good corporate citizen. I know that we often work together and you need things from me. Give me some feedback. How am I doing? What could we do better?" And then turn around and start working the other side of that table.

The goal here is just to start building some rapport, some relationships between each other so that when we have a situation, when we have an emergency, we don't need to deal with seven layers of relationship baggage before we can get to the point.

So if we front-load all of that work of relationship building, and it's not easy, it takes the right people with the right people skills. It takes time. It takes energy. So it's not something that you can do in five minutes here or there, but it's worth it if you can get to the work immediately when it's required.

So we want to break down the silos by building relationships. A lot of times we think that we're going to implement this tool and that tool and that'll fix all of our problems, but at least half of our problems are going to require better relationships between people.

So this sounds really fluffy. It's critical to start building relationships before you need them. And then once we have those relationships starting to grow, starting to build, then we can bring everyone sort of together and start to talk about alignment.

Because we know it happens. We know that we have our silos, and the CEO says, "These are our goals." And then we all in our silos say, "Here's how we're going to meet our goals." But we don't often get together and make sure that it's actually going to be possible because we need people from those other silos, but we're just planning for ourselves.

So I had this happen, again, with my team at F5. We were a shared services team, and we dealt with all of the different verticals. And we would get requests from everyone, and oftentimes those actually conflicted. One would say, "I want this," and the other one says, "I don't want that." And we didn't know what to do.

So we brought everyone together and we said, "We're going to talk about all the things everybody wants about their web presence at F5. And we are going to have a conversation and come to a conclusion together about the plan for how things are going to be, and do some relative priorities, and get aligned on timelines so that you're ready when we're ready to do the thing that you want."

So build the relationships, then leverage them to create alignment.

The third thing under systems thinking is to really, really, really look at what you're measuring and the unintended consequences of that.

So this quote is by Eli Goldratt, and you can read, but I'll read it as well. "Tell me how you measure me and I'll tell you how I'll behave. If you measure me in an illogical way, don't complain about my illogical behavior."

So what that means is that we measure lots of things because we think it's really easy. It's easy to get data from here and here and here, and so we say, "Okay, here's our metrics, all these things." But we forget to think sometimes that when we measure something, we're telling people that we value that. And then if my boss tells me they value that, I'm going to work my butt off to try to make that look good.

And sometimes those things, the behaviors that the metrics cause, aren't the things that are going to make your team or your department or your organization successful.

So think about it this way. Look at your metrics. If you're measuring individuals, then you're likely going to see behavior that drives individuals to be the best individual they can be. We have this false concept that the sum of all these stellar individuals makes one great team. It's not actually the way it works. It's the interactions between the stellar individuals that make a good team.

So if we want a good team, we need to measure teams. If we want good departments, we need to measure departments. If we want a good organization, we need to start measuring things about how the departments work together in the organization.

So my advice is to take a look at each of your metrics, maybe even sit down with your team and say, "How could we really ruin the world by trying to make this look the best that it could?" Compare that with the value that you get from it, and you have sort of a metric safety score. Right? Is this worth the time of us measuring it, or is it too risky?

So now that we have a little bit of an idea about our system and we're starting to think in a wider perspective, now we're ready to optimize for flow of work through that system. Usually, we are trying to think about customer value, not just random bits of activity. So not only flow, but flow of value, whether it's to your internal customer or your external.

And I like the image of the river because it really lets us talk about the fact that when water levels in the river are really high, it may not be apparent that there's all these impediments under the surface: rocks, crashed cars, logs. Who knows what's in there? And you just don't see the churn because the water level is so high.

One of the things that is interesting to measure, since we just talked about metrics, is something called flow efficiency. I have a blog post on that if you want to look into more detail on everydaykanban.com. But essentially, it is a representation of how much of the total lifespan of your piece of work it spends in active work time.

We spend a lot of time trying to type faster, trying to do active things faster. But overwhelmingly, the longest pieces of the life cycle of a piece of work are in waiting states, in handoff states. And so if we're not looking at that, we're losing our best chance of optimizing the flow of work through our system.

First, we want to think about doing the right things. I love this quote by Drucker, "Nothing quite so useless as doing with great efficiency that which should never be done at all." Right?

So has anybody seen the movie Zombieland? Double tap the zombie projects, right? Get them off your list. If there are things that have been in process and they sort of stall out, and it used to be an emergency, now it's crickets. At some point, you kill those things and get them out of your way. You're saying, "Someone decided we're not doing this anymore." Things that have been on a shelf for too long, gone.

Also, I get my house cleaned because life's too short to clean your own house sometimes. And I do something that I know is not good. I have so much clutter in my house that in the end, I'm not really satisfied with the job that the cleaners do because they've not moved anything. It's not their stuff. They don't want to break it.

If I could just get rid of all the clutter in my house, you could do a much better job cleaning the important stuff that's left. So if we think of it like that, let's clean the clutter out, get our focus, our visual, our mental actually, focus, then we can work really hard at being efficient at the important stuff.

So important may vary. There's a little work in your organization to help you figure out what the important stuff is. But really protect your time. Don't let yourself waste your time with stuff that's not important.

And Dominica's going to love this, but once you figure out what's important, relentlessly protect your focus. Okay? She talked in her... And she's right there, that's why I'm pointing there. She talked in her talk about how she had a boss that asked her to come to a 6:30 meeting, and she said, "No." That was me, because I was trying to deal with time zones and whatnot. She knew that she needed to write her book, and this was her focus time.

We just really need to understand that we are our own worst enemy at getting things done. We hate to say no. We just continue to collect things in progress, and that's what keeps us from finishing anything. So we want to move to a model of stop starting and start finishing. And one of the ways that we're actually going to be able to do that is by relentlessly protecting our focus. Be the focus police.

One of the ways that we can help with that is to use enabling constraints, like work-in-process limits. Now, what I mean by an enabling constraint is some limit that we put on ourselves that allows us to excel in another area.

So for instance, if I say we're going to limit how much we work on at one time, it's not just because we're sadists, it's because we want to finish work faster, and limiting what we start helps us finish the things that we've already started.

So there are lots of ways to limit work in process. You sometimes say, "Okay, people can only have this many things in progress per person." If you look at Kanban boards, there'll be numbers in each of those vertical lanes. So you may have already heard about that.

One of the things that I want to add is the concept, especially if we're looking at this conference more at a higher level, at the portfolio level, we want to use these kind of constraints to help manage some risk factors as well.

So when we look at our project portfolio, for instance, we know that we have different risk levels. We have projects with high risk, medium risk, and low risk. And one of the things that I learned from some of the tools that Troy Magennis gives us on GitHub for free to help us with a lot of our metrics is that risk translates into more work.

So if a risk actualizes, that equals more work. If you mitigate a risk before it happens, that's work. So I look at high-risk items and I say, "I know we have to do this," but there's the potential that all of this work will sort of explode to make more work at some unknown point when that risk materializes.

So I want to limit how many things I let myself do in that risk category. Maybe a few more in medium and a lot more in low because those are more known entities.

So we can use enabling constraints in a lot of different ways to protect us from our tendencies to keep us from making progress.

One of the things that we have to remember, when we start talking about limiting ourselves, people get really testy because they think, first of all, I can't sit on my butt. That's not going to work. I've never seen anybody have that problem, by the way, so I'm not really worried about that.

But if starting something new doesn't actually help you finish anything faster, and we know that it could slow you down, if we really understand that, then if I did ask you to sit on your butt, would that be the worst thing possible? Not really. It makes sense logically. It's hard for us to understand.

So when we talk about we need to work harder, we don't want to work harder, we want to work smarter. This is one way: understanding how the ways we get in our way, and try to do things like wait to start something until we're reasonably sure that we can finish it. We don't want to waste our most precious resource.

Now, the last theme is to not only continuously improve, but to prioritize it. Make it a really important part of what you do.

One of the best ways to make things habitual is to use cadences. So if I were talking to teams, I would say daily stand-up, biweekly retrospectives, monthly ops reviews. Your meetings may vary what you do. But if you want to have continual improvement, it's not going to happen if you don't get into the habit of talking about what needs to be improved, looking at how things are going.

So I really recommend that you create some cadences. A lot of people think that if you're not doing Scrum or not doing something that demands cadences, that you don't use them. But cadences are a powerful tool, so we want to use those to make ourselves get into the habit of being improvement-minded. Just make sure that you're not wasting your time in the cadences. People don't mind things that actually provide value.

When we do have this opportunity to get feedback from our process, from other people, we want to really cast a wide net. I got to the point one time where I just decided to ask everyone that we had done work for, whether it was through a help desk ticket or on a project, just every two weeks, I was saying, "How did we do? What could we do better? What did we do well?" And always asking for that information.

I didn't let it stop me from improving if no one responded. We still did what we were going to do, but we made sure that we had the opportunity for people to cast a wide feedback net and to give us that feedback.

And then finally, I want to thank Nicole Forsgren for this little phrase, but we have to rub a little science on our work here. We can't just... Well, we can, but it won't be really effective if we just shoot off improvements in the dark.

Okay? It's better if we think about a hypothesis. I see this problem. Here's what I think will happen if I do X. Then we need to say, "Well, how am I going to test that?" Right? Be a little rigorous about the process.

Can't forget to capture results. What were the outcomes of my test?

And then the thing that we do least often are the conclusions. What did I learn from this? How can I feed that learning back into my process, either to improve that or maybe even change my underlying assumptions about what we're doing in the first place?

This is the way that we make sustainable change, using feedback loops, is to loop it all the way back in and have fully intact feedback loops. I think all of these are critical. And sort of the idea is to promote everyone to the title of, not really, but mentally promote everyone to the title of flow scientist. Right? We're all responsible for improving our condition.

It's not a management-level activity. Management can work easily between spaces that sometimes individuals can't get to. But if you're waiting for someone to make improvements for you, you're more than likely going to be disappointed most of the time.

So those are the themes: systems thinking, optimizing for flow, and prioritizing continuous improvement. And in each one of those, it's probably not mind-blowing new things that you heard. But I was having a discussion at lunch earlier that sometimes you need to hear these things over and over, because how many of us are actually doing them, right?

So some things that I'd like to hear from you, ways that you can help, are to give me some answers to these questions. I'd love to hear how people are tracking cumulative progress from their improvements. It's easy for us to get focused on the impact of a single improvement and not really look at how far we've come overall. So I'm curious about that.

And then sort of to help my company, but also me understand how the landscape of organizations are going, is to understand what change had the biggest positive impact on your organizational health over the past year, and what's your organization's biggest pain point right now? That'll help guide me and my areas of study in talking for the rest of the year, or going into next year.

And this URL right up here is a SurveyGizmo link that has these questions in it so that you can answer that. And it also has a space for you to give me feedback on the talk, because I do loop that right back into my next talk at the next place that I go. Because if I'm not doing something right, I want to know about it as soon as possible, so I don't look like an idiot. That's the stance I take with feedback.

So I have a feedback survey right there. I want to thank you for your time. I know that you're getting close to airport time, so I really appreciate it. And I hope you got a lot out of the conference this year and continue to over the next few talks. So thank you very much.