Conversations from the 2022 SAFe® Summit: Mik Kersten and Dean Leffingwell take a deep dive into Flow

Conversations from the 2022 SAFe® Summit: Mik Kersten and Dean Leffingwell take a deep dive into Flow Podcast Episode Transcript

Speaker 1:

Welcome back to the SAFe Business Agility Podcast. We took a short break to brainstorm new ideas to improve the show, but now we’re back and excited to bring you new stories, perspectives, and updates about SAFe. Thanks for tuning in and be sure to subscribe to the show wherever you get your podcasts.

Welcome to this special edition of the Safe Business Agility Podcast, featuring in-person conversations captured at the 2022 Safe Summit. In today’s episode, find out how it started out as a personal mission turned into a business friendship and a hot topic. Listen as Dean Leffingwell, co-founder and Chief methodologist at Scaled Agile, and Mick Kirsten, CTO of Planview and author of Project to Product, take a deep dive into flow. We hope you enjoy the show.

Dean: Hey, Mick.

Mik: Hello, Dean.

Dean: Welcome to SAFe Summit. Thanks for coming, bringing your company and your brains. I thought I’d share with our audience here why we started talking together. I think it was back at one of the DevOps Enterprise Forums, maybe three years or so ago. You had a draft of a book.

Mik: I had a sketch of these concepts around the flow framework and then flow metrics on a napkin. And I said—I didn’t even know you yet that well back then—but I knew how well you knew flow and how you’d introduce value streams to the community. And I put in front of you. I said, “Dean, please help.”

Dean: I looked at the title Project to Product and I said, oh, this is a book I should have written. So, we bonded as friends since then because we’re on, I believe a common mission, which is that we love the art of solution development, and the science of large-scale solution development. And the combination of the two is very fascinating. And the question that has always haunted me is, is it possible to understand better how we develop solutions, how we use our brains, how we collaborate, how the social aspects and the technical aspects to create, you know, literally the world’s most important systems. And you had a set of insights that I didn’t have, which is, I understood the word flow, but you started thinking much more deeply about flow and you started talking about measuring flow. And when you started talking about measuring flow, and I’m thinking, if flow is the paradigm and it’s measurable, there’s got to be some fascinating IP down this path. So, I engaged with you at that point, made a few comments and we’ve been chatting ever since. So, tell me a little bit about your insights. What started you down the flow journey?

Mik: Wow. Okay. If we go back that far, it was, for me, it was, it was personal, right? It was, as a developer, I realized I spent a decade just writing code and getting all my sort of satisfaction and then passion wrapped up around creating cool software. And I realized, the more I was able to get it out to a user base back in those of development tools, the happier I was and the better the feedback loop, and then the better this, you know, the fastest, this community was, would form around these programming languages we were making. And then all the things that impeded flow, all the things where I was getting stuck were, were causing me all this friction. So I realized, you know, happiness came from flow for me personally, and all the friction and distraction and bottlenecks were things I wanted to get rid of. So, I started doing my Ph.D. thesis around how workflows from not a code perspective—because there’s been so much focus on coding in terms of building alert systems—but from a collaboration and work tracking perspective. Because what I started noticing in the data is it was the collaborations that were causing the bottleneck, right? It just can’t see wait. And, of course, collaboration is good. But when you’re waiting on someone, when you’ve got an approval, when you’ve got a dependency on something you looked, I was then studying open-source projects, you look at the open-source project and that’s where things get, get stuck, on those dependencies between things on needing permission or needing someone to approve a poll request, all those kinds of things. And I think this is what’s so beautiful about what you presented in your keynote yesterday is that I realized, OK, well this flow works for me at a personal level. Then I realized this made sense in my team. And then I think as, as you were already way ahead on this, but I think we had some shared history with Nokia. I was realizing—because that was really my first foray into large-scale and price complexity—I was like, wow, they’re missing flow. And they’ve got all these dependencies.

Dean: And it matters more.

Mik: And it matters more, right? Yeah. Because now all of a sudden it’s not one, it’s not me being miserable. It’s tens of thousands or 10,000 developers being miserable. So that’s what really fascinated me. And I think it’s fascinating to use that. This flow stuff’s kind of fractal, right? It goes all the way up to two portfolios.

Dean: Yeah. Talking about personal flow and talking about no give-back in the old times. So, I did a bunch of interviews as I entered Nokia to try to help. We all tried to help, right? We didn’t want this company to fail; it was 25 percent of the gross national product of Finland. So, we worked really hard to help them survive the digital age, even they’re already digital. And I interviewed some folks there and I interviewed a developer, and I was just saying, you know, how do you feel about your job? And he was doing his Finnish thing: “It’s a fine job and it’s serving me well. And I appreciate the support of the company.” And how do you feel about your job? “It’s a really cool job. I’m able to do, you know, write good code and do good things.” How do you feel about your job? “Well, I’ve been here a year and a half, two years. Nothing I’ve ever written has ever been pushed to the market yet.” Wow. That’s how I felt about the job. So that’s the type of flow that they were suffering from at that point. Right? Yeah. Working really hard trying to transition to agile, nothing was leaving, nothing was leaving the bench, nothing was leaving the desktop, nothing was getting out into production. And that was my epiphany there, which is that stuff isn’t flowing here at all.

Mik: Yeah, exactly. That’s why I think I, I do want to now relate this to what you said. Because I think one of the key moments in your talk that that was eye-opening for me, is when you started talking about queues. And what that developer was experiencing. He was getting his work done but there was a queue forming elsewhere downstream of him. But if the company had just seen and understood the size, that queue and how miserable that was making this developer and potentially more, and the fact they were probably looking at switching jobs. Because if their satisfaction, like mine, came from delivering value to customers, it’s really frustrating. So, you said this thing yesterday where you said like, you know, queues are just a part of flow. It’s not that queues are bad, it’s just that queues are part of a flow system.

Dean: Yeah. A flow without a queue is no work is being done. right?

Mik: Yeah, exactly. It’s an even worse problem than not having a queue. If that developer had made nothing, there’d be no queue of anything to push to production. You painted the picture so well. It’s about understanding and seeing those queues because in the third answer to your question, he actually told you about the queue that was frustrating him.

Dean: Yeah. But it wasn’t called a queue because we didn’t understand that was a queue. And we didn’t understand that was a problem. It’s just some amorphous delay that prevented progress.

Mik: That’s right. And I think this was so fascinating, right? Because that delay was visible for him, but not visible to the organization. And there were, I mean there was that moment where there were some whistleblowers who went right to the board saying how long it was actually taking to push work to production. But somehow at all those levels between that one developer and the top, the CEO, none of that visibility was there. So I think one of the interesting things that struck me was, we need to see queues but we need to see queues at multiple levels. Right? It’s not just enough to talk about this executive level, to talk about the team level. There are all these important things in between and I’m finding that’s where so much of the concepts of flow have not really percolated, and the visibility mechanisms and ways of actually measuring are just not in place yet.

Dean: Yeah. And it seems like flow is such a natural—that’s got to be a good thing. Yeah. Right. So, you laid out some flow metrics and we unabashedly and unshakably—with your permission—copied them into SAFe because it was the only real condensed distillation of what could be measured in flow. And we really glommed onto that. We’ve instrumented those and that’s a big part of our story now that caused me to think differently. It’s like, that’s how you measure a thing. I can’t actually describe what the heck is flow. So I did a really quick, you know, the typical check your book and check the Google, and check Gene Kim’s work. There’s no definition of flow out there. Yeah. It’s like that’s what happens in the stream or that’s why I found psychological flow. Yeah. That search caused us to start thinking differently. It’s like, well, if you want to achieve that, what is it? Right? What are the elements of it? We know the long queues are bad. Well, there are queues that have to be part of flow. So, we kind of sat down and did a little kind of intellectual exercise that says, what is flow? And we started sketching out the elements. And is a worker part of flow? For sure. Are there queues? Absolutely. Should we not have queues? No. You have to have queues, work in process, single piece slope. That’s kind of a joke. Right? I don’t want to have just one thing I’m doing. Like, if I’m blocked, then I’m totally stopped. I’m not flowing if I have one thing I’m doing, so there are elements of batch size. So, when we started working backward and saying, what are the components that really make a flow system, we started thinking, I’ll bet there are clues then as to where the interruptions to flow start to occur. So, that caused us to think about these eight accelerators first from the standpoint, well, that’s probably a problem. Second, from a standpoint, well, flow systems have policies, Kanban is really good at that. That’s one of the things we like about it, right? There’s a definition of done. You move yourself through, you understand when, a thing reaches a state, when it’s ready, and a buffer state, you see it coming. So, you start to see those measures. You start to see it go, but when you see it stick, it’s not always obvious from the data, right? So, we’re thinking, what are the characteristics or what are the actual, you know, the elements of flow that are specific to flow that you could look at and say, is that one working? And then we reversed that and said, well, those are the things that are part of flow. What prevents that from happening? And then the Lean thinking, which I was reinspired by your book. I read that Lean thinking book, probably 15 years ago, the Womack book. And you brought it back and said, really, it’s simple: make value flow without interruptions. And that started me thinking about what it means to make value flow without interruptions. And that started us on this journey that we’re on. And we’re just midway yesterday saying it kind of looks like this. We think these are the elements. And we think if these elements are there and there are problems within the element, it’s not going to flow. And probably they’re going to occur in combination. You’re going to have a policy problem along with too big of a queue. And we’re far from, I think, really answering the question of how you really make flow work. But I think we have insights. Now we have some measures. We have some accelerators and I think we’re on a journey. So what we talked about last night is, we’re not done with this journey yet. We haven’t quite related to how flow produces outcomes that are better. It feels better. My engagement might be higher. I probably have more releases and more releases create better outcomes for the business. And I think that’s a journey that’s still ahead.

Mik: Yeah. And I do have to say, so, first, I’m honored that the Scaled Agile Framework picked up the flow metrics and built on them. Right. Flow predictability, I think, is a key flow metric that I excluded initially just to keep things simple. But over the last four years, I’ve realized the importance of it. So, I think it’s great that it’s there with SAFe. I think that what’s really great to see Dean, and I think you’ve now expanded that body of knowledge around flow, right? People are thirsty for more. The definition, you know, right? Why wasn’t there a definition? I was very glad to see a definition yesterday. It made sense. And the number one thing, I think, for people listening is, just go find it. I know the way I would find it is off your LinkedIn Dean, go find the article that has those eight accelerators. I think those things are all spot on. They match up in rough order, even the data that we see of the flow dysfunctions and all the various tools, all the various value streams that we’ve studied in enterprises on real large data sets. Coming from the Planview Tasktop tools where the number one dysfunction that we see is too much work in progress, too much WIP on value streams, right? And we know that organizations simply reducing, so, starting, stopping, starting, and starting finishing, allowing the teams to finish the work they’ve started while unplanned work is coming in and flow predictability is a mess. But if they just reduce the WIP, flow will accelerate, and people will be happier. So, yeah, I think that, and that closely relates to your number one accelerator.

Dean: That’s right. Yeah. So what do you think happens next? As we start to understand, we have a definition of flow. Now it’s something we put forward. We understand what the constituent elements of a flow system are. We can understand how to measure flow. Where does that take us? What do we want do with that data? What does a business owner executive do when they start to see data matric matriculate about how the flow system was actually working?

Mik: Right. So, I kind of see two paths that need to happen. One is—and that’s why it’s so great to see it in SAFe and to see the work that you and the Framework team are doing—it needs to be understood at higher levels of management in the organization. There’s this great discussion I was having with one of the large banking customers that is actually Lloyd’s bank, and they’ve spoken about this publicly, where the challenge that they were having is that some of the most senior leadership had this false sense of economics around software, where the more work that you push on teams and the more budget you give them to hire next week, the more you get out, right? And we know it’s not like that. We know it takes time for teams to form and for value streams and ARTs to actually start producing high-quality, reliable software quickly. And it comes from MBA programs and these sorts of things where, you know, you decompose work into requirements, and then you throw the work over the fence, which works in some domains, just not the one we work in. So, if we can just leverage this momentum that there is on flow to educate people kind of at the ART layer and above, as we get to solutions and portfolios, where it’s really those operating models that come from quarterly business review processes and, and PI planning, which will stay. But if we could dovetail flow into those, make sure that there’s a key result around improving flow. And that fundamentally in the end is, there’s kind of organizational. And I know Dean, you and I have talked about this a lot. I know it’s near and dear to you, but organizational commitment at the operating model level. And you would say the second operating system level of continuous improvement and continuously improving flow in a data-driven way. I think every one of those teams will be happier because all the things that they know makes their work easier would actually become a part of the way the organization plans.

Dean: When we talked before, one of the things I’ve been watching in my own team and other teams is that to measure something, it usually changes the behavior, the thing that’s being measured. So, with the flow measures that you’ve established, how do we implement those in a way that the teams simply benefit from them and leverage them without driving overhead to say, you need to record this thing this way. You need to record the fact that there’s a buffer state here. You need to make sure to put in the buffer state at the right time, or it’s going to look like it was in the implementation state for too long. How do we do this in a way that actually facilitates team flow and doesn’t cause them to say, well, we’re measuring a bunch of things that don’t have any value here.

Mik: So, Dean, I think you’ve, you’ve highlighted this is a key point, right? If, if we get into this Hawthorne effect, if people feel like they now need to behave differently because of the way they’re being measured, it gets problematic. And I think just to be blunt, we’re not all the way there yet. So, I’ll just give you an example. When I was working on the development tools, I actually, as an experiment, implemented something that would track all the activity a developer was having to know exactly when they were actively working on a particular user story or epic or defect, right? So at that point, I had a data set with kind of the finest granularity for flow efficiency within the scope of what these monitoring tools could see on the developer’s desktop, and that was completely unobtrusive. Because developers worked on an issue and that’s it. You knew when they worked on an issue, then they switched issues and you could see it, but there was a lot of instrumentation that was needed. But I think the core thing is how you’re thinking about it, which is we have to do this without disrupting the way teams work and without them, you know, there’s the gamification aspect of it where obviously if you focus on flow, there’s a natural—and we’ve seen this, which is in the data, which is great—a natural tendency to have smaller batch sizes, right?

Dean: Well, they look better going through the system, but they also go through the system better. And that’s OK.

Mik: But at the same rate, I do think what you’re saying is really important, which is we need to make sure that we’re not disrupting developers. So right now, for example, the way our tools approach this is the activity that we see in development tools like the JIRA, the Azure DevOps, the GitLab, and Git itself, we can actually extrapolate workflow states from that. So we have an approximately correct view of flow efficiency. That’s at this stage, I think good enough. The bigger problem, by the way, that we have, when we actually measure flow efficiency is when there are systems that are not connected. Like, if planning’s having a PowerPoint, we’ve got a big gap there in terms of that value stream and its flow efficiency downstream. Right? If we can’t actually see when this thing is done, when the code has been shipped and it’s in production and cloud or mobile device, then we’re also missing that end-to-end flow efficiency calculation.

Now the good thing, the surprising thing I should mention though, is how much by connecting to the agile tools and maybe tools connected to them—like a PPM tool or a product management tool and the service desk—how much you can actually see on a flow efficiency already. Because when developers get stuck on something, they do tend to move things to a lane or to a workflow state where, you know, I’m stuck on security review. So, the amount of fidelity we get the flow efficiency is surprising, but we do just from normal work activity because people want to indicate when they’re stuck. But I think it needs to always be done this way without disrupting the individual or the team—just connecting to the way they work today. And then I think we will get better and better granularity over time with better tools.

Dean: And some of that’s coaching the teams, right? If you join an agile team that doesn’t necessarily understand the way work flows through your system, or that you might need a buffer state for that, or a simple thing like saying “I’m blocked” is just a very simple thing that triggers a host of different activities. So, what we’re toying with in our team is how to instrument that; what to measure when to know that we just went through an interesting experiment where we had a whole bunch of articles we’re writing. We decided not to accept them until final QA. Well, that’s way down the road, right? So we ended up with these stories that seemed stuck. Yeah, perpetually stuck, and we’re going, “Well, I should split that story. Well, that’s some work at the same time. If I don’t split this story, it’s not going to really show the real flow of the system that the articles are being written.” So, you’re always in that little bit of dilemma, the little bit of tracking overhead, little bit of updating overhead, versus actually being able to see the actual flow of the system. There’s no ideal state, I don’t think. But we have to start with instrumentation that allows us to measure what’s happening. If we can’t measure it, how can we possibly get better outcomes?

Mik: That’s right. And the tools need to get better at actually understanding flow, right? So, in your offering tool, if you were offering an article, it would make it active automatically in your work tracking tool, your agile tool that would help, right? So, I think it will improve over time, but we’re not there yet.

Dean: You wrote a book. I’ve written a number of them. Each one, I look back and I go, “if I had to write that over again, it would’ve different stuff in it.” What would you add to the next version of Project to Product?

Mik: So, I’ve been thinking about this a lot. The only flow metric I would add still is what you did: flow predictability. Now, of course there are others out there, but I think that one is so relevant in terms of understanding, for example, when you put full measurements in front of senior leadership, they want to say, OK, well, what are we committing to? What’s our predictability? And actually, I’ve noticed that telling them if we’ve got something that’s highly complex, you don’t want to aim for 100 percent flow predictability, not 180 percent or 50 percent. And that’s a good thing. And so flow predictability has both effects, right. Of making sure that we were taking care of unplanned work and also understanding when we need to pivot within the planning cycle. And having space for that. That’d be the main one. And then there are interesting things like just given the importance of onboarding tech talent onto these value streams, actually like time to flow to first flow becomes really important. And we measure it closely, how long it takes someone to contribute exactly like that Nokia developer. Because theirs would’ve been one and a half years and nothing because nothing went to production. So for that, for onboarding people, it’s actually really important to understand when they reach their own personal flow. And we can measure that through the same mechanisms.

Dean: Yesterday, I sat in the Voice of the Customer and one team talked about using the PPM metric, right? The predictability metric. And it was looked as if it was like, well, it’s important to do what you say you’re going to do. And it is, but that predictability metric is based upon business value. So, that’s the measure that we have that says, did we deliver the business value that was intended during that particular PI? So, that’s pretty directly coupled to the outcome. Because if our business owners are connected to the outcomes, they’re going to define things for us that really do create the business value. So, it’s not just you did what you said you were going to do. Actually, we delivered the business value that we needed to deliver in this period to meet our customers’ needs. And I think that’s the most important thing about that metric.

Mik: Yeah, Dean, in this long customer meeting I did yesterday, this keeps coming up over and over. And I think what you see in terms of what good looks like and companies that have really embraced flow is that you’ll actually have a flow predictability that’s slow while the business outcomes are actually high. And that’s because the teams are able to make quick decisions within a sprint, pivot multiple times based on input they’re getting within a single PI, and still drive to that outcome. So you’ve basically got very fast planning cycles and very fast adaptation within a planning cycle. So, you’ve got lower flow predictability, but as long as that outcome’s moving you, you’ve got better customer retention or acquisition. That’s great. That’s how flow predictability can really help executives understand that we need to empower the teams to make their own decisions.

Dean: And if they’re not engaged in defining what business value is, that’s not a meaningful metric. That’s right. So, that’s a way to engage them directly with the teams, having a communication discussion about what has value to the business. I think that’s as close as we can get, but it’s pretty close.

Mik: Yeah, that’s right. And then the counterpoint of course is your value streams with 95-percent flow predictability are basically waterfall and they’re not learning anything. And chances are that those business outcomes, they’re not moving the needle on.

Dean: So, I think we’ve pretty well nailed the whole flow business. Right? We’ve got the science down. It’s all done. We’re good to go. Right?

Mik: <laughs>, I think we’re getting started.

Dean: I think we have some work in process.

Mik: We do, but at least we’re applying some science to the ARTs.

Dean: Thanks for working with me on it and look forward to working together in the future as well.

Mik: Absolutely.

Dean: Pleasure. Let’s make flow make sense for everybody out there. Thanks, Mik.

Mik: Thank you.

Speaker 1:

Thanks for listening to our show today. Be sure to check out the show notes and revisit past episodes at scaledagile.com/podcast. Relentless improvement is in our DNA, and we welcome your suggestions for the show. If you have something to share, send us an email at podcast@scaledagile.com.