00:00:05

In my role as principal flow advisor at test Hop. Now, Planview, I work with and observe dozens of really big companies and retail, healthcare, finance, federal space, telecom, and they're all trying to transform. They're all trying to change how they work. I mean, no company or organization can operate the same way forever. Change is inevitable. So the thing is, the spectrum of preparedness for people who have been delegated to lead transformations and initiatives, often falls between not bad and not good. So in this talk, I'm gonna present some of my observations and suggestions on how I think we can better equip people for success. When it comes to optimizing workflow.

00:01:01

The problem that I see is there's this gap between what's needed and the people delegated to make it happen. Uh, it usually goes something like this. An executive buys into a new way of working, and then delegates the driving of that transformation and organizational change to a director or a manager, a coach who doesn't always have the knowledge or the experience, experience to implement that kind of change. And even when they do, they often don't have the capacity. They don't have the time or the support necessary to affect change. And it's really heartbreaking to observe that it's, it's not an easy win if you're not set up and organized for change.

00:01:54

Looking at this K Ross change curve, the, the genesis of this, uh, change curve was initially the five stages of grief, but it's been adapted and made applicable for business. So what's represented here so well is the turning point. And it's when experimentation starts happening, it's when people are able to come out of their, you know, frustration and, and depression and updating their resume and getting ready to move on, uh, to the point where they can start experimenting. That we start to see a, a change, um, for the better here. And I think that when there's a sense of urgency for optimizing workflow and changing how organizations measure success, then focusing on reducing the cost of this change is, is useful. I think it's essential. So how do we get through this change curve quickly? How do we get to experiments as soon

00:02:58

As possible so that you can build the knowledge and experience, uh, for people who are trying to implement, trying to innovate, uh, their, in their organizations? Uh, I think it's teach people how to experiment and that this is what is needed right now, is to help people learn and feel comfortable with experimenting and presenting their experiments. So I teach people how to experiment quite a bit, and the first thing we address is pain. What hurts? So I ask people this question, what prevents you from getting your work done? What randomizes your day? And this is like a real example from a workshop I just did last week. I, I have found that, and I've done this exercise hundreds of times, people have no qualms, uh, identifying their pain points. And here what is a common pattern here is too many meetings. Um, conflicting priorities, lack of processes and, and standards and business.

00:04:18

Uh, so, so on the team, I ask people what prevents them from getting their work done? That's the team pain. On the left, on the right hand side is business pain. These are the, your internal customers who ask, ask the team to do stuff. They make the requests. And so I ask, what are they grumbling about? And they're grumbling that things take too long. Uh, they're grumbling that they don't understand the roles and who they're supposed to go ask to get their questions answered or to, or to submit their requests to two. Uh, and, and so it's pretty even sided here, or, or there's probably more dislikes though on the left hand side. And most of those have to do with too many meetings and conflicting priorities. Uh, and we're on the business side. It's things take too long and we don't know where a thing is and, and we don't really even know who to go ask for where our thing is.

00:05:18

The second thing that we do is try and understand the causes of pain. What is causing, what is causing these pain points? Now this, in this session, we had about 18 people. They were thoughtfully engaged in identifying these causes. And some of the things that came up were lack of self-service scalability. And that was impacting their capacity expansion, their ability to scale this, and lack of alignment on priorities and processes contributed to too much web. Too many meetings is too much. What, uh, next step was what is the goal? And for this, I want to, uh, show you a real experiment that my awesome colleague Chris Gallivan, is working, uh, with his organization. Chris Gallivan is a, um, another, uh, flow advisor that I work with on our team. So he's doing an experiment with the team. Can you guess what their pain point is? <laugh>, the experiment is called Get Home by 5:00 PM. Uh, they, they're currently in this situation where there's very little confidence on, um, on the business side that they can actually get a release out the door smoothly. And so their pain point is that they're only allowed to, they deploy once every two weeks after hours, and often they don't get home until after 9:00 PM So this is the goal. We'll get home by 5:00 PM They also want to improve the confidence that the business has in their ability to perform, and they wanna improve their flow.

00:07:14

So with this is an A three, and we're using experiments which use data to quantify the outcomes. Basically, here we're just saying, here's the current state, here's what we're gonna do, or here's what we did, and here are the metrics here. We're gonna, here's how we're gonna show the improvements to our flow time. You know, if, if customers are grumbling that things take too long, then we need to measure how long things actually take. I think that to equip people for success, we need to learn how to measure what matters to business partners, especially when it comes to optimizing workflow. Uh, because so often the complaint from business partners is that things take too long. Number four is what steps will you take? What activities will you do? What is your action plan here? The action plan is really to lower batch size each week. Uh, you know, reduce their web. They wanna try and automate part of the deployment process along the way and their timeframe. All experiments should include a timeframe. It shouldn't be open-ended. And here they're gonna do a three week experi experiment with weekly deployments.

00:08:42

And lastly, number five is how to quantify the outcomes. What are the results? What are the outcomes? So in this experiment, the release team ended up getting home by 5:00 PM which was helped by their re reduction in whip, right? Their lower batch size, lowering whip through smaller batch size and automation is so powerful, their flow velocity improved by 30%. Their flow time improved by 10%. Employee happiness went up largely because they got to be home in time for dinner. And the business partners became more confident in it's ability to deliver what they said they were gonna deliver when they said they were gonna deliver it, which was huge.

00:09:38

So let's bring back the change curve here. Now, how do we integrate these lessons learned from these experiments and metrics across the organization? How do we expand this one pocket of greatness or goodness that we have now existing in the organization so that it can help drive other changes, uh, drive systemic improvements across the organization? I think for that, the best, well, I won't say the best, a a really good way to do that is to have a forum to present experiment learnings and data. So we will need to ask people to present their experiment learnings and outcomes. Uh, I would suggest using an existing forum that you already have in place so you don't have to add yet another meeting onto people's calendar. For example, if you have an agile center of excellence, that could be a really great forum to share people's experiments.

00:10:50

Uh, and what, when it comes to experiments that need data, I find these three fundamental flow metrics very helpful because these are things that, uh, customers care about, especially how long things take. So speed metric, we would call that flow time, how long things take end to end from the point where a request was made and you decided to do it to the point where it is available for the person who asked for it to use it. And then we want to measure wip your work in progress, your flow load, and also throughput. We call that flow velocity.

00:11:39

I like to start measuring WIP first flow load. Why, why flow load? Because it's hard to affect change with cognitively overloaded people. I'm, I'm currently working with about a hundred teams from a large retail org, not all at the same time, but you know, last week was the infrastructure networking team, and this is their flow load. So this team has about 13 people in it, and they have altogether a total whip of a hundred seventeen, a hundred seventeen nine, that's average of nine per person. So I ask them, how do you juggle nine things at a time? Well, it turns out they don't really, they set aside other work <laugh> to, to work on the most urgent requests. And so 40% of their WIP is sitting idle, 40% sits idle. Now this is just looking at their, um, feature type work in green because when we look at this view, we can show how much of the work is in a wait state and how much of the work is in an active state.

00:12:53

And so this is in September, um, with that much, you know, average whip here per, um, per story, basically got 66 of them. So, and on the last, on, on the column, the vertical column that we're looking at, they have a flow load of 62, 25, of which are in a wait state and 37 are in an active state. And so work is sitting in a wait state because they're supporting a new data center build out, and they get sucked into development projects doing firewall changes. They get pulled away from their planned work. 50% of their demand is unplanned work. And because unplanned work delays planned work, it's a real pain point for them. So measuring their whip, their flow load and seeing how much of it is sitting idle, prompted conversations on start finishing and stop starting. And why pulling new things into progress before finishing old work is so problematic.

00:14:04

Like most large organizations that we work with, um, this started this, I mean, understanding this pool system here, it started a discussion on what their WIP limit should be. And the quick answer to that question is lower. Just make it lower. A hundred is better than 117. Ideally, the whip limit, which is an enabling constraint by the way, it is determined by the departure rate, the, the throughput, the flow velocity. I say it's an enabling constraint because the WIP limit is what enables people to say, hold on, uh, you know, we're full right now. We don't have any more capacity to take on new work. If, if this new thing is, is a higher priority than the other things, then let us know what we can drop or push back into the backlog so that we can work on this one thing. So departure rate is your throughput, is your flow velocity, and it's basically how many items are delivered over a period of time.

00:15:17

That is the team's capacity. So this networking team delivered 56 work items over a period of 30 days. And this is all their work. Th this is feature request type work defects, technical debt security risks 56. So, so that's a reflection of the team's true capacity. Uh, now we're gonna look at flow time, which is the elapsed time to complete a request from the time that work, uh, begins that you've decided to work on it to the time that that request is available for the customer. Now the image on the left hand slide is the flow time for all the different kinds of work that they were working on. And when you averaged all that out, their full time was 28 and a half days per item. The slide on the right is just feature type work. The these are primarily, they're stories that they're working on to deliver business value versus, um, so revenue generation type work, uh, not so much revenue protection type work.

00:16:35

When it comes to speed, a key decision that needs clarity on is when to start and stop the clock. And, you know, there's different levels of work item types. So in a value stream, it depends on what view you want. You know it, if you're measuring at the epic level, then start the clock when the epic starts, if you're measuring at the feature level, start the clock when the feature starts and ends, uh, here at the story level, that's when the clock gets starts. So here, their average flow time for their stories is 35.8 days, 35.8 days. Um, the main point here is configure your full-time metrics to capture what view you need to improve your, your, uh, decisions and, and not just decisions that impact your team, but decisions that impact your, your business partners, right? Your organization as a whole. Most companies we work with, we measure thousands of product ice streams and, and most of the companies that we work with have an average.

00:17:44

And in, uh, flow time that goes way beyond <laugh>. Uh, the development flow time, you typically development flow time, only two to 12% is in that development state. And the, the end-to-end time is much greater than that, especially upfront with a lot of heavy planning and budgeting and approvals and triage. Triage, uh, and it's, that part is often left out of the speed equation. But when we're looking end to end of a product value stream, we need to capture that upfront time too. And then downstream, if the, you know, build in deployment, if, if the DevOps isn't happening on the, on the release side, then we see a lot of wait time and lengthy, um, cycle times on the end too. Um, so we call this water scrum, fall <laugh>. The, the constraint is not development. The constraint is upstream or downstream.

00:19:02

And when we look at measuring this, I want to wrap up this metrics part by describing little's law for you a bit so that you can become more predictable and how long things are going to take, and more importantly, how much WIP you should have or not have. So there's a relationship between flow load, WIP, and flow time. It's called little's Law, where WIP is a primary factor in the equation. It's obvious when you think about it. Like, you know, when you get on a freeway, your commute home is gonna be pretty fast if there's no traffic. But if the freeway is backed up and it's stop and go, you know, your commute is gonna be longer. That's why WIP is, is so great. It's a leading indicator, unlike flow time, you don't really know how long things take until it's done, right? You can't stop the clock until it's done and, and then measure that. So Little's law is a relationship of averages, and the gist of little's law is that on average, the more items that are worked on during the same time interval, the longer it's gonna take to finish those items on average. So here's the equation where average flow time equals average width divided by average flow velocity.

00:20:38

So what you can do here that I think it's kind of fun because math is, you can calculate what WIP probably ought to be, or at least it could be your north star to shoot for. So this is the, the networking team here and, and we're just looking at their, their stories, right? Just ingrained. This currently doesn't include technical data or risks or, uh, defects. Um, but we can look at solving for WIP in this equation. A little bit of algebra here. So if we rearrange, if we solve for wip, average WIP is gonna equal average flow time times average flow velocity. Now, we need to use, there's, there's some, um, requirements for this, uh, to work to make sense. And one of them is that we have to use the same units of measurement. So we need to, we need to, because flow time is measured in days, we need to put flow velocity into days also.

00:21:47

So this is 30 days, uh, average of 24 over 30 days. So that's about one, one thing a day. We've delivered one story a day. Now each, each story took on average about 36 days. So what should their whip probably be using this equation if their flow velocity is one and, and their flow time is 36 1 times 36 equals 36. So they should probably bring this whip down to 36, and that's likely gonna improve their flow time. They're gonna have less idle work in here. They're gonna have fewer conflicting priorities, fewer dependencies, less neglected work all the time thieves that impact, uh, the team's ability to, to deliver. Um, so this is the, the 36 is really the best case scenario because little's law has assumptions that go along with it. Um, basically the, you know, the average arrival rate should equal the average departure rate and that all the work that is started will eventually be completed. And that the average WIP is in, is neither increasing nor decreasing, and that those rarely ever happen. So 36 would be considered, uh, you know, best case scenario on the web, uh, but it's a lot better than 66. And I wouldn't suggest, uh, I, I would suggest gradually letting this number lower down to 36 here, or to whatever number where you will see smooth flow.

00:23:41

So in conclusion, I think that one of the best ways to help people become more effective at driving change is to teach them how to experiment, learn the pain points, understand the causes of the pain points, and then identify a goal. If, if teams are, if people are, um, reluctant or I, I would just say it might be useful to begin your first experiment with a small goal that is within the team's control. Because if it's going to impact, if it has dependencies across the larger organization, then you are gonna need buy-in from leaders of those other teams. So if you have a lot of experience and you have seniority and you have, you know, social capital and trust and budget, and you have influence to budget, that's one thing that will help you experiment with upstream and downstream, uh, partners to really get the biggest bang out of your experiment. Um, but if you, if you don't have that, if you're like in some organizations where, uh, your, your initiative or your transformation is, is, uh, voluntold or are delegated to people who don't have that kind of experience, then a good place for them to start would be with something within their control, one of their pain points that are within their control of the team.

00:25:31

Uh, so build a coalition of the willing. This is one area where transformations can fail, uh, terribly. My observation is that there needs to be a large enough group of people who actually want to change. And it's not a one person job, it's not a one person job, no matter how competent they are. We need a group of early adopters to help communicate and, and guide change, right? Uh, versus, um, you know, a junior scrum master getting voluntold to implement a huge change initiative. So here is the, uh, takeaways for you. The list of things I think will provide your teams, your people with the capability to affect change, learn how to experiment, allocate capacity for experimentation. 'cause even if you do have really great senior people who can make things happen and have been there for a long time and people trust them and they have

00:26:42

Psychological safety to, and, and influence over budget, if they don't have the time, they don't have the capacity to experiment, then, then that's, uh, gonna hinder the, the progress. Like, like we talk about in the five ideals of the unicorn project. Ideal number three, daily practice, right? This, this, the experiments require daily practice. Uh, fourth there is understand and measure key flow metrics. So flow, time, your whip, your your throughput, your flow velocity, uh, work to build a coalition of the willing and then connect with business partners because they have influence over prioritization and budget. So if you can find one business partner who understands the, the pain points, 'cause they're gonna have pain points on their side too, that is a huge help. And then lastly, be conscious of change curve states and psychological safety and people who might be frustrated or, or depressed and maybe have fear of speaking or presenting their experiments.

00:27:57

You know, we can measure all we want, but if people are afraid to get up there and present their experiment and their data, then then the change is probably not happening. I'm gonna leave you with a few resources, uh, book I'm reading right now, the Value Flywheel Effect by David Anderson. Uh, such a fabulous book. Highly recommend. It is ideas for, um, oh, just all about how to effect change, uh, um, going to a serverless environment and then project to product all about change, moving from project to product, uh, my work on making work visible, all about change. And then two form papers that are fabulous. One is expanding pockets of greatness from 2017. It's, it's, uh, how to connect the pockets of success that may already exist in your organization so you can harness them to drive change, drive systemic improvements, not just individual team delivery metrics. And then winning together. This is from 2021. This is setting the stage for partnership. It's a playbook for aligning technical and business leaders and ideas for connecting business partners to influence prioritization and budget. And lastly, there's the flow framework community, uh, where you can connect with other technology leaders.

00:29:24

So I hope you are able to take a few things away from this talk. Uh, uh, please connect with me and let me know. Thank you.