Nicole Bryan

Hello, DOES community. I'm super excited to be here to talk about "The Flow Doctor Will See You Now." I'm delighted to be here with Kate. Oh, Kate, help me with your last name.

Kate Chajka

Chajka.

Nicole Bryan

And Carmen DeArdo. Kate, why don't you introduce yourself?

Kate Chajka

Yeah. So glad to be here. So I'm Kate Chajka, and I'm an agile trainer, practitioner, coach for the last 15, 20 years. Pretty extensive background in software engineering, and now I get to talk a lot about my favorite topic: flow.

Nicole Bryan

And Carmen?

Carmen DeArdo

Hi, I'm glad to be here. Carmen DeArdo. I'm a principal flow advisor at Tasktop, and I help customers try to understand and improve their flow so they can deliver business results more quickly for their customers.

Nicole Bryan

Fabulous. I'm Nicole Bryan. I'm chief product officer at Tasktop Technologies. So with that, I'm going to share my screen. Kate, Carmen, are we seeing the right screen?

Fabulous. So today, we're here to talk to you about "The Flow Doctor Will See You Now." We've already introduced ourselves, so we'll skip this slide.

You might wonder why I'm showing a picture of the fabulous show from the '80s, "ER," but it's really because we believe that learning to practice value stream management with the flow metrics really requires a team of people that can help you identify and remedy the myriad of ailments and problems that you'll uncover as you begin to think and manage from the perspective of flow. And so we believe that large organizations should think of starting a flow practice. Today, I'm lucky enough to have two flow doctors with me here, and I think Kate even has her stethoscope.

There you go. Kate and Carmen are here to talk us through their experiences with different ailments and different common problems that you see when managing from flow. I'm just going to do a quick walkthrough about the core flow metrics, and really to keep with the healthcare analogy, we really think of the flow metrics as the same as the vital signs of the human body. Every time you go to the doctor, there's a common set of things that will be checked: your temperature, your heart rate, your blood pressure. Flow metrics really represent the same, that any organization, regardless of what type of software you're building, you really should be measuring these flow metrics: flow velocity, flow efficiency, flow time, flow load, and flow distribution.

Just quickly, flow velocity is really about how much value is being delivered within a reporting period. Flow distribution: am I putting the right capacity towards features versus debt and defects? Kate and Carmen, I think, are going to talk quite a bit about that. Flow load: are teams thrashing because incomings far outweigh their capacity to deliver? Flow time and flow efficiency: how much time elapses from request to release, and are my processes causing teams to have to wait on work for significant periods of time? These core flow metrics are what we believe can really help an organization in their flow practice, and what can really guide your organization for improvement.

That bird is sitting right outside my window.

Our first ailment, a common ailment: the ever-increasing Treadmill-itis, otherwise known as too much WIP. Flow doctors, I'll let you take it from here.

Carmen DeArdo

Okay. Thanks, Nicole. I think one of the common ailments, as Nicole described, is we see teams where their characteristics are their flow load is increasing, their flow time is also increasing, so the amount of time it's taking to finish work is increasing. A lot of times, we also see the light green color, which is the wait time. It's not uncommon to see that wait time increasing, which means work is waiting longer before someone can actually work on it, and consequently, we see the flow velocity decreasing.

Kate, talk a little about as you're working with teams and you start to see this, how you detect that, and what kind of things do you prescribe as a flow doctor when you see this condition?

Kate Chajka

Yeah. One of the big things we focus on is we'll always be saying, "Stop starting and start finishing." It's really easy, as we start to see that work in process or that flow load increasing, to keep an eye on, like you said, Carmen: the velocity may decrease, the flow time's going to increase.

It's a huge mental model shift because we think staying busy is leading to our productivity. If some work gets blocked, we pull more work in, and that's very natural for us, and it feels like the right thing to do. It feels good to start work. Starting work is easy. Finishing work is hard.

That's the first thing we start to look at, typically. It's such a low-hanging fruit for teams to start with: look at that flow load. When we compare it to the velocity, if we have way more work, way more load than what the velocity says that we can complete, we encourage the teams to maybe form an experiment. What if we took on a little bit less work? What if we started to focus on completing work rather than keep pulling in work? That's a huge shift when we first start looking at this with teams.

Carmen DeArdo

I think that's a great point, Kate. Sometimes I think what we've seen is certain work becomes neglected. What happens is it's almost like in a pond where you only have a current of work that's moving, and then you have work that's kind of in a still water. It appears to be in progress, but really it's not. Is that something that you've encountered a lot?

Kate Chajka

Oh, yeah. Yep. This is really important. You start out the time period, whether you're sprinting or following another methodology or method, and then something really urgent comes in, right? Maybe you have...

Carmen DeArdo

That never happens.

Kate Chajka

I apologize. If we can pause here, my dog's just busted in. I'm so sorry, let me go.

Okay. Carmen, we certainly see we'll have work that was really a priority for one or multiple of our customers at the time. That's why we pulled it in. It was a priority. Then it's pretty common we'll have another really urgent request come in that needs to be expedited. Certainly, maybe we have some production incident or defects. Those become priority number one. Then somebody taps us on the shoulder: "Hey, I just need this one little thing." All these things start to come in, and like you were saying, it basically stagnates.

Are we saying these customers aren't important anymore? Are these needs not important? How did we have all these priorities and then all of a sudden everything else was a higher priority than that? Certainly we see that effect.

Carmen DeArdo

Right. And then that creates a lot of either work being neglected, increases the cognitive load on your team, it may have more context switching. We all know that mentally, when we have a lot of things on our mind, or even in the back of our mind of things that, yeah, I know I'm supposed to be getting to that, and customer's like, "Where's my thing? Where's my thing?" That keeps taking away bandwidth capacity from the team to start to finish things.

Kate Chajka

Yeah. A lot of times we talk about the operational flow, but also that psychological flow, right? Being able to sit and focus for a couple of minutes and give creative capacity to solving the problems in an elegant, kind of graceful way. We've become so used to interruptions and disruptions. Certainly that can actually hurt our delivery. Yeah, so definitely something we keep an eye on.

Nicole Bryan

Great. Let's talk about our next disease. This one is a chronic condition. It is called, "If I Just Stop Looking, Is It Gone? Syndrome."

Carmen DeArdo

Yeah. I think a lot of times, we get into this situation where we're experiencing things and we're kind of accepting it. What we're seeing here is kind of an erratic velocity in load and wait times that are building. Do we really understand what's happening here? Are we really trying to understand what's causing what we're seeing?

It really gets into: do we actually know, and have we made visible what our bottlenecks are? A lot of times, there are great ideas. There's a whole set of DevOps practices on how to improve things, but do we know what practice to play at the right time based on what's actually getting in our way?

What do you see in operation, Kate, as you're teaching this approach?

Kate Chajka

Yeah. I see a lot of times we're looking at where can we focus our time and money for the best improvement, right? If we take a scattershot approach, we may be spending a lot of time and money solving the wrong problem.

Our gut feel may be that this certain area is always the problem, whether it's waiting for approval or waiting on QA or waiting for this or waiting for that. Does it change over time? We talk about in Scrum, we have the Scrum Master, they're looking at impediments or different things like that. But until we really look at the data and look historically, where are our bottlenecks? What's that high-water mark? Where do we frequently see that we're spending time on these delays?

They've always been there, and we've become somewhat numb to them. So putting them front and center and saying, "We have a lot of this waste. Work smarter, not harder." We could spend all this money trying to work faster, but when our time to market is mostly spent in wait states and delays, that's very eye-opening. We're probably maybe 5%, maybe at most 15% process efficient in many areas from everything I hear.

Really taking the time to look at where these bottlenecks are, and being able to address the real root cause of the problems. Removing those delays, removing that waste, and buying ourselves that sanity back. Like we're saying, we're so overburdened, so much work in process, so many disruptions, and just really start to get this flow going.

When we look at some of the graphs and the distribution, when I talk about flow, we see a lot of peaks and valleys in graphs sometimes due to these bottlenecks, all the work piling up. How can we start to smooth that out and improve our flow visual?

Carmen DeArdo

Right. If you go to Gemba and you observe a team, the team's always going to be busy. We're not really talking about the team waiting; it's the work that waits. The work in IT and creative work, it's hard to see. It's not like a factory where you can go up to the fourth floor and look down, and you see inventory. Where is the inventory? Where are the things that are piling up?

As you said, it may not necessarily be in CI/CD. It might be to the left of that. It might be teams waiting for work to flow from the business. I know we've had experiences where half the time and money was spent before something even got into the backlog of a team, and yet there was no attention being paid to that part of the value stream. Or downstream, as you said, waiting for review, waiting for a change approval, waiting for something after these set of iterations.

A lot of times it's like, well, we got to get better at CI/CD. Obviously that's kind of table stakes, but is that really the impediment you have? And if you don't know it, how do you know what you're doing is actually going to fix the problem?

Kate Chajka

And here's one example that's so, and not to trivialize things, but it's really no cost to fix. We found in some cases, waiting for product owner approval. We didn't even know. We didn't assume it was a problem. Well, we sent them an email, or they'll check the tool, or we'll get a hold of them, or certain things like that. So in a lot of cases it's not these huge expensive changes, it's sometimes just changing a little bit how we work together, which is nice. It's an easy fix.

Nicole Bryan

Right. I've actually noticed that a lot of times, just the conversation and acknowledging the fact that there are wait states, and oftentimes hearing customers debate within themselves, like, "Is that an active state? Because I think that's a wait state." Which I think is really interesting because it just brings to the forefront. Carmen, you can talk endlessly about... I often think of Carmen as the chief therapy officer because it's like, hold on, let's just talk about the wait states and the active states.

I think a lot of it is therapeutic for people to just be able to see it with their own eyes, and address it.

Kate Chajka

Well, that's it. Taking control of it, too. That's very empowering. We have more control than we think.

Carmen DeArdo

Yeah, Nicole, directing those conversations, the value really happens. You need the data to get the focus, but then it's addressing the points that come up in those conversations and being able to have the right conversations where the value then comes out of, okay, what can we do? And then see, you're going through that plan-do-check-act continuous improvement. Did it actually help it? Now you actually have data to say it did, and these are the consequences, or it didn't. Our intuition maybe wasn't on, so let's try something else.

It gets you out of this guessing, and as Kate said, it's much more empowering for the team to be able to have the data and be able to try things to improve.

Kate Chajka

Yeah. A lot of times we talk a lot about intuition. We feel things are a certain way, and time and time again, it's been very eye-opening once we look at the data to really realign and readjust. We're thinking things are over here, and they're way over here. So just being able to continue to align and build that new intuition around flow is huge. It takes the discussion.

Nicole Bryan

Fabulous. Let's move on to our fatal disease: death by a thousand debts and risks. Carmen, over to you.

Carmen DeArdo

Sure, Nicole. I think a lot of times what we see is if you look at the flow distribution in the top right-hand corner there, you'll see a lot of red and green, which represents the features and the defects. In this case, you see there's a very small amount, 30% of what the team's actually delivering is feature work, and almost 70% is defects, and very little investment in risk or debt.

I look at the flow items in the sense of revenue generation and revenue protection, and features are what people think about for revenue generation. Defects are protecting your revenue. But then there's also risks, which are protecting revenue, because we know that if you have a risk in production, that's going to hurt your reputation as a company, there's compliance issues. Debt is an investment in future revenue generation.

When you see a picture like this, what you see is: is this going down that debt spiral where because you're not investing in debt, you have a fragile code base, a lot of defects. You're spending a lot of time on defects, gives you a lot less time to focus on features. Then if you look at flow time, what you see is the flow time for features is getting longer and longer.

This can become a fatal disease if you don't understand it and then say, "Stop the presses. We need to start focusing on debt so that we can actually clean things up so that we can then go faster again." Kate, how do you deal with this as you're coaching?

Kate Chajka

Yeah. What I find is this is such a hidden condition. A lot of times, when we talk about risk, security, compliance, regulations, all sorts of really critical things that aren't typically visible until there is a problem and we have to react to it, and they could be significant problems.

Here, we're talking about making it visual, being proactive about it. Again, that empowerment, actually being in control, planning for it, keeping it visual, having those conversations so that, Carmen, as you say, we don't get into this debt spiral because it's really hard to get out of. By having that discussion, just making it visible, being able to talk about it, plan for it, you have the different maturities that your different products might be in, so they might have different distributions for how much feature work is healthy, debt, risk, defects. Having those right conversations, putting yourself back in the driver's seat for it. It can lead to a lot of conversations before the problem occurs rather than after.

A lot of the times the way we introduce this is when you go on a shopping spree with your credit card, a high-interest credit card. We all love to shop. It's paying down the debt that if you don't get ahead of it, especially with this high interest, it can really take control of you. So you get in control of it rather than it taking control of you is usually how we start to look at this debt and risk.

The other really common thing that is interesting that I hear time and time again, almost every session when I talk about technical debt or risk with teams, is: well, the business doesn't want to pay for that. They only want to pay for features. What we start to see is they're paying a lot more by not addressing it than they would by proactively addressing it.

We have to be careful with that concern because if it's hidden and we're charging them for it anyways, wouldn't it be better to be visible and actually have control over it, and end up spending less in the long run on technical debt, risks, or those debts?

Nicole Bryan

I think, Kate, that last point you made is so critical, that the business needs to understand debt and risk matter. If you make it visible to them, it increases their understanding that this is something that it's okay to focus on. I feel like a lot of teams have historically felt they aren't allowed to focus on debt and risk, and making it visible, I think, helps them. Carmen, you probably have a lot of experience with that as well.

Carmen DeArdo

Absolutely. We haven't talked that much yet about the business results, but we know the happiness of the team. There's a lot of emphasis now on engagement and happiness of the team. If you see a team that's happy, they're productive, and productive teams are typically happy.

If you're working in a situation where you know, well, gee, if I could just refactor this code base, we just upgraded this latest library. If we just did a few things, maybe implement one of the DevOps processes, it would improve our ability to go faster. When you can't do that, it hurts the team morale, and nobody wants to work in a place where they feel like, well, if I'm introducing a lot of code changes, what am I going to see? I'm going to see a lot of the defects that we see here.

There's a lot of synergies here to the team feeling that empowerment, feeling the ability to pay down the debt, to do things that inherently they know are the right things to do, and then see that result in increased satisfaction and delivery capability for their customers.

Kate Chajka

Yeah, and I really want to piggyback on that, Carmen, looking at these in conjunction. If you have a team with a really high velocity and it's just going through the roof, and we see that they're not paying down their risk and their technical debt, it's almost like a false velocity because you know you're kind of heading for that cliff where your technical debt and risk will catch up to you.

I always tell people, careful of that velocity. It's great that our ability to deliver is increasing as long as we have that corresponding eye on the technical debt and risk so that velocity doesn't start to tank after a certain point in time.

Carmen DeArdo

Yeah, that's right. You have to slow down to speed up sometimes.

Nicole Bryan

Exactly. Y'all have already begun to mention a little bit about business results, but what I'd like to do is go to our last session. It's not a specific disease, but just things to be aware of: referred pain and pattern recognition.

Carmen DeArdo

Yeah, I think, Nicole, keeping those business results in front of you is important because otherwise flow metrics can become another type of proxy metric, and that's not what we want. In the end, we're increasing flow. Why? Because we want to increase the business results, the value.

What is the value of this product? It could be an external product with a profit and loss, or it could be an internal product that's being used by external products, like with a shared service or capability. Understanding that value and are we doing things to improve that value? The cost, keeping our eye on cost, is important to make sure that, again, part of what the value is, are we managing the costs and then the quality? Because without doing that, you really don't have sustainable value.

Then as we talked about, the happiness, which is not just the happiness of the customer, but the happiness of the team themselves, because that is a leading indicator of things and a lagging indicator. Happy teams are productive, productive teams are happy. Kate, what has your experience been when you're talking about flow and also talking about these business results?

Kate Chajka

Yeah. It's really our North Star. When you start to focus too much on practices, and certainly have learned this the hard way, you start following a practice and just hoping or assuming that it's going to get you the right outcomes. Maybe we'll look at story points or velocity or different things. So to actually have this discussion, we talk a lot about discussions, to talk with our stakeholders and say, "What does value mean to you?" It's such a vague term, right? What is that North Star? What are we trying to accomplish here?

That way, we have the data now, we have where we're headed, and it answers the questions. A lot of times we'll get the data, teams will ask, "Well, what should I do? Should I do A, or should I do B, or maybe C?" The answer is, well, what's going to get us closer to that outcome?

The reason we talk about empiricism or working in a complex environment is that there isn't a one-size-fits-all solution. Here, we talk about high-performing teams, empowered teams, engaging the teams, all these things we've been talking about, is really giving them the data to make sure that they can head in the right direction. That's nothing someone can give us from up high. It's nothing we can read out of a book.

But we can say, all right, we have the data. We know where we're headed, and that really helps guide those decisions. What should we do, and is it going to move us closer to this outcome or further away? It really helps guide the what-do-I-do discussion. A lot of times we assume, oh, if we do this thing, that is the sure path to success, and we're convinced. Then we might do an experiment and find out, oh, actually, it either didn't make a change or actually it took us away from it.

Even just building that habit to say, "Don't assume." Kind of that plan, do, check, adjust. Making sure that we can even get better at making these decisions, going back, checking that it moved us closer to our outcome. This builds in a whole new healthy habit to more effectively achieve these outcomes.

Nicole Bryan

Carmen, do you want to talk a little bit about pattern recognition in our last minute or so?

Carmen DeArdo

Sure. I think there's some patterns that after you see this enough, you start to see. We talked a little bit about some of them already: too much WIP. If your ability in a month is to do X amount of things and your work in progress is 2X, 3X, 4X, you know that you have a lot of things in progress. You may have three, four, five months' worth of work in progress. So you have to ask yourself, does that make sense?

Sometimes we've seen things that we call the stoplight or the Christmas light pattern, where it goes green, red, green, red, where a lot of features are introduced, but then you get a lot of defects, and then you get a lot of features, and then you get a lot of defects. What's going on here? Why can't we get ahead of this so that we're not going through this kind of cycle?

Then we talked a little bit about the neglected work, or unplanned work, as Kate said, where you see this work come in, and it's always getting prioritized. You may see your flow times for defects always under your flow time for features, and then the risks and debt may have the highest flow time. That's giving you an insight to how you're prioritizing your work, because what's getting stopped? It's always the debt and the risk at the expense of the defects, which might be reasonable, but I think you need to understand that and need to understand the implications of some of these patterns when you see them.

Nicole Bryan

Fabulous. Well, that's a great way to end our discussion. I appreciate you guys lending your flow doctor expertise to us, and hopefully this helps large organizations see that you really should begin this concept of a flow practice, so that you can develop experts like Carmen and Kate. Thanks, everyone.

Kate Chajka and Carmen DeArdo

Thank you.