The Flow Framework with Dr. Mik Kersten
[00:00:00] Hello and welcome. I'm your host Adam Hawkins. In each episode, I present a small batch, with theory and practices behind building a high velocity software organization. Topics include DevOps, lean, software architecture, continuous delivery, and conversations with industry leaders. Now let's begin today's episode today.
[00:00:25] I'm honored to speak with Dr. Mik Kersten. Mik Kersten is the author of the best-selling book, project to product which introduced a flow framework. He's also the CEO of Tasktop. I introduced the full framework on small batches through an episode on the four types of work. That episode is a wonderful prelude to this conversation.
[00:00:45] Find that one at smallbatches.fm/9. I invited Mik on Small Batches to discuss the full framework's origin story. From there, I move onto how the ideas in project product dovetail into the three ways of DevOps. This is one of my favorite aspects of project to product. I happened to read the DevOps handbook before reading project to product.
[00:01:07] So as I was reading the book, I noticed that there's a strong focus on value streams and how to optimize them and start thinking to myself, well, this sure feels a lot like dev ops, but zoomed out to the entire organization. Well, yes, it's true. That DevOps connects engineering to the ideas of business value, but the flow framework takes it one step further by treating the entire business as a value stream with customers on one end and business results on the other.
[00:01:33] We also discuss that a bit in this episode. Our conversation hits the intersection of software architecture, value, stream architecture, and team architecture, all the notes that organizations must conduct for effective software live. And this is also, I think, kind of where the sweet spot of small batches is.
[00:01:52] There's also a detour into structure and dynamics. I suggest listening to a few episodes of Dean Kim's podcast with Dr. Steven Spear to learn more. You may also remember a structure in dynamics from the previous episode on team topologies. Links to all those episodes at smallbatches.fm/21.
[00:02:13] No, I'm overjoyed to have Mick on the show because he spotlights what really matters as to flow time or in other words, optimized for fast flow and the rest comes along for the ride. Anyway, you'll hear it all from him in his own words. Now I give you my conversation with Dr. Mik Kersten.
[00:02:31] Adam Hawkins: Mik, thank you so much for coming on the show. I'm so happy to talk to you.
[00:02:37] Mik Kersten: Great to be here. Thank you for having me.
[00:02:39] Adam Hawkins: Right. So I've already done an episode on the flow framework, introducing the idea through the four types of work. But I think the audience would like to know about the context of the epiphany is that you mentioned in product to product that led to the creation of the flow framework.
[00:02:54] Adam Hawkins: So can you give us some of that back?
[00:02:56] Mik Kersten: Yeah, absolutely. So for the entirety of my career have been studying software value streams initially as a developer working on open source projects. And then I think for me, it got really interesting to study software at scale, and you're going to get a sense and intuitive sense for how to deliver value how to contribute to let's say for me, it was to an open source community by doing more certain kinds of work. But then you also get the sense of, of the things that get in the way of that work, right. Where you've got sort of, you might, it might be a lack of automation might be a problem of software architecture.
[00:03:31] Mik Kersten: And I started doing more and more visualizations actually of the flows of work. I realized also that I wasn't necessarily obsessed with studying code bases to understand software architecture. And then I realized, well, if we actually study, if we assume that software delivery is as this creative process, it's a, it's a design process, involves design thinking and conversations. Then we've got this amazing body of work to study.
[00:04:00] Mik Kersten: There's a lot of the ground truth of software is actually captured in the conversations, that people have, in a software, what we now call a software value stream. And so there, those are poll requests by developers. Those are conversations on specific issues or user stories or tickets or customer information.
[00:04:17] Mik Kersten: And I started studying more and more of the communication, the flow of information on those things and on how they interact with a source code. I started and it created this one visualization actually showed me how, when you had a lot of conversation on it on a specific kind of issue on an open source project that would actually start changing the software architecture around that conversation.
[00:04:38] Mik Kersten: So it was this really interesting interaction and really understand the different types of work, led me to realize, okay, well, if we want to understand what flows and software delivery, we actually need to understand the fundamentals of on first principles, what those flows items are. And from that, I tried to create the simplest possible representation of the different types of work item flow. And that's really where the fourfold came from. So features, defects, risks, and debts.
[00:05:07] Mik Kersten: And then after that, it was really a case of studying if every single tool that we knew, because at Tasktop we have the benefit where we actually understand both the kind of default schema of every single agile DevOps product management tool out there.
[00:05:24] Mik Kersten: And so we actually looked at every single one of them. And say, well, how do they allow you the model work? Right? How do the service desks like a service now or a Zen desk or something about you, the model of work?. And then we had one more piece of data, which was our customers value steers in the book. I built this around, seeing the artifacts of 308 different organizations, value streams, and what flows in them.
[00:05:48] Mik Kersten: So what, what kind of issues or defects and features and risk items that they work on. And of course, then there's been the work of the scaling frameworks, right? Pretty much like the scaled agile framework or scrum frameworks and nexus and so on and seeing how they had worked categorized. And from that I realized, well, it really does boil down when we take the perspective of not this fine grain decomposition that happens when we're trying to plan work and prioritize work with is really important to the agile frameworks. But when we think about the value that we deliver to the customer, cause that's, that's the whole point of the flipped frameworks to think product value, stream centric, customer centric.
[00:06:22] Mik Kersten: There are only these four types of work. And if we actually understand that these, these things are trade-offs that we make against each other, we can make better decisions and we can surface the kinds of decisions that developers make for themselves every day or development team makes for themselves to the business for a better understanding of, of these trade-offs between investment technical debt versus features delivery and so on.
[00:06:43] Mik Kersten: So it really came from a very personal experience of making these trade-offs. Working with teams to saying, okay, there's, we've got to have a way of, of understanding these dynamics of flow and the trade-offs that we make, and then doing this, this broader study.
[00:06:57] Adam Hawkins: And so one of the epiphany, as you mentioned in the book was the realization that the, the value streams are not linear, but they're actually networks. And it seems like on his face, that might be obvious. But if you sort of look at. Say how the work happens, especially in open source where you have like clear boundaries between things that are part of the project and really not part of the project. You know, like if you're working in a bigger company, you might have a team who's, you know, in the same department as you, or definitely the same organization that you can work with.
[00:07:29] Adam Hawkins: Whereas if you're working on a sufficiently complex open-source project, you might have to go over to this repo, these other maintainers and work with them and that kind of fans out into this broader network of things. So like once you had the network. Like the value stream network. Maybe you can just talk a little bit about that as much, or if the listeners are familiar with that concept and how important it id.
[00:07:52] Mik Kersten: Yeah, absolutely. So I think like a lot of people I try to sort of, when you try to envision what flows and software deliveries to better understand how to improve flow, how to deliver more how to have fewer weights states and friction and so on. When you say, when I start to visualize it, I often came back to this picture a lot of us have in our minds, which is of this delivery pipeline. Right. You've got this continuous delivery pipeline and, but I started realizing that we're not really delivering releases. When you're working with continuous delivery, when you're working with a cloud mindset, what you just stop thinking about releases.
[00:08:30] Mik Kersten: Because releases are something that actually can be automated and it really should be automated. Right. It's critical to automate your delivery. So you're not the pipe, this notion of a pipeline where you're delivering releases, it's just felt so antiquated to me. And the notion that it's linear also seemed completely wrong because when I did these initial visualizations of how conversations on issues on pull requests and so on, actually the structure of those conversations, because issues are linked, they're linked the source code that like to build and so on. I realized that what you're really seeing is this network of teams and the dependencies between those teams and sometimes people, right?
[00:09:07] Mik Kersten: Cause you'll have a person on a part of the infrastructure or the SRE team who's really close to in conversation with someone on the feature team who's responsible for operations of this particular product and so on. The underlying structure is this network where the nodes are people on teams. And that's just something, again, as with the flow items, it just something I empirically observed.
[00:09:29] Mik Kersten: So then there was a question I was really helping to simplify that into something that can be meaningful for us to help them to optimize the flow of software delivery. And I think the key thing is that these concepts of value, we need a concept that's bigger than the team, because if we're always optimizing for just the team, we fail to optimize around those dependencies.
[00:09:50] Mik Kersten: And that's a lot of what's happened in my experience in the, in agile and DevOps. Not, not so much intentionally, but there's been such great support in terms of tooling, in terms of practices, in terms of training for making teams work better.
[00:10:03] Mik Kersten: But once we actually dig into an organizations, Value stream flow, we see that as soon as the fixed, some of the easier stuff, like some long dependency on waiting on screens from, from the graphic designer or something of that sword, or some lack of automation for, for some, you know, security testing we actually see that the weights it's come from the dependencies between teams.
[00:10:25] Mik Kersten: So realize that we need a way of conceptualizing and visualizing and understanding a value stream, something that said at the team of teams levels, construct. And once you do that, you actually see that both within a product value stream across them you have this network structure, right? You have this collaboration, these conversations happening. And that's what you really need to understand because that structure, if you've got a mismatch between that structure and what you're trying to deliver to the market, or a mismatch between that structure and your software architecture, that's where all your weights states will be. That's where things get caught up.
[00:10:56] Mik Kersten: So, so the key thing to me was to understand that there is this other structure that we need to think at a level above the team. And then that's, we need to be able to understand flow and to basically measure flow to get the bottlenecks out of the path of our teams.
[00:11:14] Mik Kersten: Right? Because this is the part of the problem of sort of the maturity that there is in the industry around teams and the lack of material that team of teams level is that the bottlenecks tend to be outside of the teams. It's an external dependency, it's an organizational dependency.
[00:11:26] Mik Kersten: It's those things that are wrong. And that's why, that's why the flow framework focuses so much at that team of teams level. We're again. What we see in the structure is is, is not the simple pipeline, but it's actually this, this value stream network.
[00:11:40] Adam Hawkins: So you mentioned, I think maybe like the missteps between agile and dev ops and focusing on some of these dependencies. And I'm curious on your opinion of like, do you think. Maybe that happened because sort of like a bottom up type of approach of maybe taking a more like engineering focused view of like engineering as it relates to the wider organization? Because of course dev ops and those ideas, they are definitely focused on delivering business value, but they're still like largely texting.
[00:12:09] Adam Hawkins: And one thing I think the flow framework does really well is it takes that perspective and takes it completely from one end the business on the other end the customer. And you have the idea of the flow metrics like flow, velocity, efficiency, time and load, and then the business results on the other end.
[00:12:25] Adam Hawkins: So, how does the flow framework sort of relate outside of the value stream network, but the focus on those metrics and the top demo approach, how do you think that that either like surfaces or addresses this dependency problem you mentioned?,
[00:12:41] Mik Kersten: yeah. So I think first of all, in terms of directional goals, I think that was as a set aside by Gene Kim and the others in, in the Phoenix project. The goal of dev ops was kind of end to end flow and feedback and continue learning, right. It was, it was about the intimate delivery of value, right? And those are the three ways of DevOps, which the flow framework pretty much builds on.
[00:13:02] Mik Kersten: The thing that I think happened is that some of these concepts got to get good and they got and got stuck at the team level or the delivery pipeline level. Right, because for a lot of organizations, and this is why DevOps is so important and DevOps movement is important for a lot of organizations that they're continuous integration, continuous delivery practices were so poor that wasn't obvious bottleneck. If you can, you know, you've got dev teams who are getting better for a decade with agile practices and you've got, you know, weeks or sometimes longer in terms of actually getting software into production. That was an obvious problem.
[00:13:35] Mik Kersten: But in terms of principles, the three ways of DevOps were about or about the end-to-end flow of value. And so really my goal with the full finger stick to get unstuck from something a, the teams and developers already understand is that if they've got ups and downs and bottlenecks, they know those are getting in their way.
[00:13:51] Mik Kersten: If they've got. Technical debt. That's making it difficult for them to deliver features at the rate that they would like to, again, they understand that that an architectural investment in APIs needs to be made. And so the goal of four framers to basically expose those dynamics from, from the small, I'm just thinking these things are only important that the CICB pipeline level or the dev team level to say, no, these are important at the end to an organization level, right?
[00:14:16] Mik Kersten: If we have constant wait states on the meeting, that's being rescheduled every two weeks and we still don't have into this particular set of constraints or what the performance of the system should be with the scale should be what the design of this thing should be. Well, that can become our bottleneck. And it's not that these bottlenecks again, I think the interesting ones are the ones that fall outside of the teams because the ones inside the teams we've, we've become better at solving.
[00:14:42] Mik Kersten: So really is the flow framework is as simple as I think what you alluded to there, Adam, which is to take these concepts that, that have worked and we understand within the delivery team and make them bigger and make them the everyone's problem. Right. Make them something that the whole organization is looking at optimizing it's full time to bring value to market faster. It's not that it's just the responsibility they have o just the responsibility of the, of the ops team and so on.
[00:15:07] Adam Hawkins: That's right. I think it's actually so powerful about the four types of work is that it gives a mutually exhaustive categorization of all the things that the business can do. And this fits well between integrating or the mapping between product and engineering, because you can see that, you know, okay. If you had hypothetically a security incident, then working on sort of risk items to mitigate that, or like paying back typical debt as a means to meet like continued flow time.
[00:15:34] Adam Hawkins: I think this is something that you also talked about in, on your podcast with Adrian Cockcroft, which is the focus on flow time. Like if you focus on flow time so many other things come, come out of that. And just for the listener flow time is sort of the measurement of how long it takes the organization to do something that results in business value that you could probably find a more precise definition.
[00:15:59] Adam Hawkins: But the overall concept is how fast is your overall value stream performing. And you also mentioned that the flow framework builds on the ideas of DevOps and in dev ops, like the DevOps handbook, they talk about value streams a lot, and this is also present in project to product and when I read the book, I'm reading it, I'm nodding along.
[00:16:20] Adam Hawkins: I'm like, there's a lot of stuff about value streams. And I'm thinking about dev ops and I'm thinking of sort of the virtuous feedback loop of dev ops, or you have flow, which leads to feedback and if you continually learn, you can instantly optimize that and things start to get going faster. And we can sort of transition the conversation but how in your mind was like, did you see the full framework sort of building on the ideas of DevOps, but applied in a different sort of different context or is it just sort of a continuation of like thinking in this direction?
[00:16:51] Mik Kersten: It's a continuation. So I think again, the, that, and then in, you know, many chats with Gene Kim and others in the DevOps community, it was just a continuation. I think there was an initial success in terms of the impact that DevOps has been able to make. And then the questions I think to me is what's next given it's not sufficient to do this. We need the flow on feedback and an end to end way, we need that to feed back into business planning. We need people doing business strategy to understand the effect of technical debt and to prioritize it because we know that when they don't, and it's only the technical teams who understand these concepts, you end up with just very mismatched understandings of the world and, and dynamics, that don't make sense.
[00:17:36] Mik Kersten: So that was really the, the goal of that flow, famous to say, okay, what's next for DevOps is to basically become part of the way that the business functions, not just the way IT functions. And we need to break through the fact that the business side and the technology side, the IT side have two different operating models and two different ways of measuring things and to create one way of measuring things, that's at a high enough level of obstruction.
[00:18:04] Mik Kersten: To make sense for the business side, right? Because part of the other problem is noticing of this thing is that enlarged organized well and all sizes of organizations, the way that sort of the executives and management and leadership tends to measure things and the words that they use are very different from the words way to Carl just thinks about things.
[00:18:21] Mik Kersten: And so I just want to create a common language because the technology side, when we are, you know, we really care about things like chain success rate and some of these other important metrics. Those need to be upleveled. Because fundamentally all that the business or the customer cares about is the quality of their experience and how many new features they got in the last release. And that's really what gets them excited about continuing to use some, some digital experience that you're creating.
[00:18:49] Mik Kersten: So, so it was really, for me, I guess, taking that, helping take catalyze what DevOps started to do and make it easier for the business to adopt as an operating model because of the fact that.
[00:19:02] Mik Kersten: The whole goal of identifying modeling and measuring these probably value streams and the four or five items was really to expose the dynamics of software delivery in a way that's understandable to the business. And that allows the right kind of decisions to be made.
[00:19:20] Mik Kersten: So just as just a sidebar here. So when you're mentioning dynamics, are you referring to the concept of structure and dynamics or something else?.
[00:19:27] Mik Kersten: So I think that I really liked what the journey that Gene Kim's been on recently on structure and dynamics. Yes. So it's, it's, it's the same concept, right? The dynamics, as in, it's not like you've got sort of a silver bullet for saying, well, do this to make delivery go faster. But if you've got the right way of representing flow in visualizing flow, you can actually see within the dynamics that within the way information is moving in the organization and of course the flow items are one measure of that, right? Your meetings might be another measure of that. What it takes to get an approval might be another measure of that? For something.
[00:20:04] Mik Kersten: So all of those things are, I think, in the broader category of dynamics and the structures, of course, you know what you have organizationally and from a process point of view. And so I wanted to have a easy way to measure and visualize the dynamics of software for the point of view, again, of these kinds of trade-offs that you have to make that... If you want reduce to time to market. Here's what you'll need to change. If you ignore technical debt by over focusing on features, this is what the outcome of that will be.
[00:20:36] Mik Kersten: And so that these are, these are conscious decisions made at a, at a business level. Not those things that are hidden and that, you know, let's say the there's some developers do and they're. In their spare time to make sure that the platform that you're building doesn't, it doesn't fall apart completely.
[00:20:50] Adam Hawkins: That's why I really liked the graph, the flow distribution, because you can imagine sort of like a fader, right? If you're putting all the work into features, then you're not putting any work into say risks or debts.
[00:21:00] Adam Hawkins: And I don't know what your experience has been, but I've been in teams where the bin on features and bugs are so long, but then there's been no work on debts. And then the chickens come home to roost. And then there's some new business requirement that comes in and then we can't make it because we haven't invested in paying down any of these debts.
[00:21:19] Mik Kersten: Yeah, exactly. And that's the whole point is that it's a, it's a conscious, deliberate decision that if you've got a slide that feed or that much the features, you need to understand the effect that's going to happen three, six, and nine months from now and not complain at that point. So there's a consciousness decision.
[00:21:34] Adam Hawkins: Yeah. So now that we're on structure and dynamics, I want to bring the conversation back to some stuff that you were talking about with Adrian Cockcroft again, which was sort of, I think that there is a stipulation that when we're talking about say continuous delivery and modern organizations, that they sort of assume that things are going to be microservices and certainly lay out at a certain scale some sort of microservice architecture makes more sense, but it's like if you scale down the organization size, you scale it down the system size, you know, how, like, do you think that these microservices or that kind of architecture is actually a prerequisite and succeeding? Or is it just more about, cause that's speaks to the technical structure, you know, but if you have say a well-designed monolith where you can apply all these things and work, work quickly, fix bugs and do these things, you know, where is this sort of like, how do you view the spectrum between one side of it being a monolith versus say the other side being a larger distributed system? I guess there are prerequisite that you have to be doing some specific technical architecture to succeed.
[00:22:44] Mik Kersten: Yeah. So my view on that is, and this kind of goes back to a story of modularity, right? Because in the end. I used to think of this very much modularity and architecture first, but now I completely changed my view on software architecture to be values stream flow first. So what I think we all want to optimize for is, is faster product value stream flow. Right. And what I've learned from the data is that product value streams are between two and 10 teams.
[00:23:18] Mik Kersten: Okay. And that if you've got, let's say one team. I've certainly observed this. You can work very successfully on Amazon and you don't have any kind of, you're not making an API that people are building on or something of that sort. It's not extensible, but you're truly have kind of one mobile app or something you generally find with one team having its own model.
[00:23:41] Mik Kersten: Right. And it's probably the way you can move fastest because anytime you're introducing API or services, you've got, that's basically you're introducing a maintenance burden going forward. So you're introducing some kind of versioning and so on. So the challenge of course becomes, as you know, now when you have a second team, so that I think the key thing is as soon as your number of teams grows to be a significant number. And of course it depends on the domain you're working on, you start needing to decouple the work of the teams because the dependencies between the teams work becomes a bottleneck and you can see that in the flow. That you have to go check with too many teams to change this one thing, because you didn't know how they're using that bit of data or pushing it onto a stack or whatever they were doing.
[00:24:24] Mik Kersten: Right. So you have to start hiding some implementation behind an API or a microservice. And as soon as you're doing that, you're able to make the teams move faster independently. So this is really all just about the need for microservices, APIs, and basically component models is, is to allow the teams to move fast autonomously.
[00:24:46] Mik Kersten: And I think that's something that's been fairly well understood for a long time. But I think the really interesting thing is that product value streams need their own autonomy as well, but that team of teams levels, construct also needs to have basically a, a way of hiding implementation so that you've got the set of APIs that can work as dependencies between product value streams. And so I think that is something that absolutely at these microservices architectures are generally a good direction on.
[00:25:15] Mik Kersten: Where I think platform thinking where you're, for example, depending on the API, you treat your platforms as products with their own backlogs and the backlogs are just additional API requests or a functionality requests from a platform.
[00:25:28] Mik Kersten: So I think the key thing is to understand that you want product values. You want teams to be able to, with less tests as they can and have loose coupling between them. And you want the same thing for your probably value streams. And if you look at it from a flow perspective, that means you have to invest heavily in APIs, especially these platform APIs. That means that the teams, depending on that particular parts of the club, I don't need to reinvent these things themselves, right. They can, they can rely on, on a common service and that service will continue to evolve and meet their needs.
[00:25:56] Mik Kersten: So I think it's, it definitely depends on scale, right? So I hear a 50% startup. Now, your chances are, you're fine with a monolith, right. But as soon as you, again, need teams to move independently you're looking at this at this way, the key point that you know, repeatedly make is that you really want, when you want to optimize for, with architecture is just fast flow within the product value streams. And that will give you the right kind of guide of what to invest in a platform API you do that when it's a bottleneck for feature flow and when not to.
[00:26:27] Adam Hawkins: On the other end of the spectrum, you can adopt say an architecture like microservices too early, and then really shoot yourself in the foot by introducing all these dependencies and this sort of stuff that you may not actually be related to your core problem.
[00:26:38] Mik Kersten: Yeah, exactly. Yeah. And that's why I think having Flowbee or guide is so key because I know, you know, myself when I was a developer and a lot of other people who have I've worked with, they will over architect.
[00:26:52] Mik Kersten: So if you're now overdoing it on the micro services on a fairly small code base that's only a couple teams.
[00:26:59] Mik Kersten: You've been easily, again, introduce more burden than benefit.
[00:27:03] Adam Hawkins: Yeah. Well, that's why the importance of focusing on the overall flow time through all layers of decision-making gets you aligned in that direction, right? It's not necessarily about making, say maybe the best technical choice, but what will actually allow me or the team to work as fast as possible to optimize for fast flow. And that has yet totally changes the way that you, that you think. So that speaks to the technical structure of, you know, the software architecture. And then of course you have the relationship between Conway's law and team structure, which is another part of the overall structure of sort of this value stream network.
[00:27:44] Adam Hawkins: So how do you see like to use a book title, not on purpose, but I think it works very well. The idea of team typologies and an organization, like what's the relationship between like team architecture, software architecture, and value stream architecture.
[00:27:59] Mik Kersten: Yeah. And so I think that's a great book and a really important contribution. And I think it gives us kind of a language to have this conversation. Right. So my view on it is the first part of what you said is that you need to base optimize these things for flow. And in the end where we're actually trying to optimize for flow of value that we deal with it delivered to the market, which tends to be more on feature flow, but also, you know, the quality of defect size and for the risks as important.
[00:28:26] Mik Kersten: So. The way that I look at it is that y'all, you always want to have for any kind of architecture work or team structure or restructuring, you always want to have a hypothesis that this will increase flow .And it will do it. Here's the other key part in a sufficiently short time window.
[00:28:45] Mik Kersten: So, you know, I know we used to do spend more time architecting for any kind of future options. Now, when you start thinking about flow, you really want to make architectural decisions for the 6, 9, 12 month window, right? They'll be some new open source component that will be created at that point or some new AWS or Azure service that you can consume and so on. So really the hypothesis should be that my architecture change or my team's structure change, which needs to support flow well, we'll drive faster flow.
[00:29:14] Mik Kersten: And so I think that the great thing with the work-life team topologies was these modern ways of thinking about architecture is that it's not that you have kind of one cookie cutter decision it's that you actually understand the structure of the dynamics and you can say, okay, given what we're delivering, it's really important that we have, you know, this one particular API teams structured this way with these teams depending on it. And this is the size of it. And so on, you start looking at some of those team typology structures, and you say, because you know, this will minimize dependencies here, which will increase our flow. And here's the key thing. And here's why I think that this is where the flow framework really comes in is that you can then measure whether you are right or wrong on that hypothesis.
[00:29:56] Adam Hawkins: Which is the whole point of doing hypothesis.
[00:29:58] Mik Kersten: Yeah, exactly. And that's the, that's the part that it's amazing to me, so is missed so often, right? It's that you have endless discussions on how we should structure things and what's optimal and so on. And that takes weeks. So there's a decision's made and then every week, no one measures the outcome.
[00:30:15] Mik Kersten: Right. Right. And so my whole point of making sure that however that the flow match, the filaments were seem to be a part of your entire journey because you know, you make one hypothesis, you check it, did this team structure increase load. Did it not? If it didn't why? And did we do something wrong? Did we not actually give the teams a chance? Was there not a big enough time window, but, but it's, to me that the key thing is the flow metrics give you a fast feedback loop on whether architecture, team structure, process automation, whether it, all these decisions, whether they increase flow or not, because you're constantly measuring that.
[00:30:51] Adam Hawkins: Yeah. It's funny how this is the two things you brought up. One is how we have the idea of hypotheses. You know, we like to think of ourselves we're engineers. We know how to build things. We conduct experiments and we verify results, but more often than not, we don't actually verify any of these results.
[00:31:07] Adam Hawkins: We have ideas, but we kind of just do a gut check if they work or not. And this comes back to a conversation I had with Dave Farley on why he didn't really consider himself a software engineer, because he wasn't doing actual engineering. You know, he had an idea and maybe he maybe had some data or not, but we don't get into this feedback loop of I have a hypothesis. I will do X and Y should happen. Does it happen or not? Right. And the flow framework gives us the metrics to do like an engineering at sort of an organizational architecture level. But, you know, we think about value streams and, you know, there are so important that we once optimize them. And this comes back to the third way of dev ops, the continuous learning and experimentation is that you have to continuously be doing that.
[00:31:54] Adam Hawkins: And that was one thing that really kind of blew my mind about the first part of the flow framework was the turning point in the age of software is just that we sort of like me, you know, I exist in this bubble where it's sort of assumed that organizations are doing these things, I've work like this, but then you look at some of the numbers and it's like, man, there's only like 1% of companies working like this.
[00:32:17] Adam Hawkins: So how, how do we spread this, this knowledge and the way of working with the wider industry, who's maybe not encountered this kind of philosophy before.
[00:32:28] Mik Kersten: Yeah. So I think that the key thing here is, and again, I think that's whole point of continuous improvement. I think it's, it's basically, it needs to be based on data, right?
[00:32:40] Mik Kersten: Software's complex enough. If you want to thrive in this age, regardless of the size of your company, regardless of your industry, if you're not measuring you don't have that feedback loop to how you're improving on your delivery practices. You're going to fall behind. And if you don't have the right way of collecting and measuring that data or the right way of reasoning about it and using it, not with these proxy metrics, but again, there was with flow metrics, then you have to assume you're going to fall behind.
[00:33:04] Mik Kersten: Are you just going to follow the latest trend or some fat on tooling or process? Improving our methodology or something else. But if you have that guide, that's telling you, okay, when we deployed this, this new methodology or this new team topology, or this new tool flow increased, you actually start that process which to me, I think is just so critical amd Carmen De Ardo with my colleagues came up with this of data-driven continuous improvement, right.
[00:33:29] Mik Kersten: So we know that could use some improvements important. We're seeing that through literature. The improvement of daily work is one of Gene Kim's five ideals, and we need data for it.
[00:33:40] Mik Kersten: Software's too complex to do it without data. So so I think bottom line is I think the way that I think it's it's fairly simple to explain is you need the data to improve. And you need to measure the flow metrics to do it. And that will get you into the path of innovation, because you do have a lot of these organizations who've just been at this for so long.
[00:34:01] Mik Kersten: They're always doing it. They're, they're all, they always know where their bottlenecks are and that's, that's all there that always examining it. And yet, so many organizations, large and small have not done that. Right. And it is purely based on speculation and opinion. And when it comes down to making these really big decisions, If you don't have established this culture of continuous improvement with data again, you can make quite a few missteps on their own.
[00:34:24] Adam Hawkins: Yeah. And it's just funny to me, how much time we spend, like in this whole area as engineers, or thinking about business in relationship between these value streams is just how important it is to get data and act on data.
[00:34:35] Adam Hawkins: Like as a first principle that even in like technological driven fields, we still don't operate that way by default.
[00:34:43] Adam Hawkins: Anyway, I want to ask you one last question to make sure we get you out of here on time. So I think you publish the flow framework in 20... Was it 2018, 2019?
[00:34:54] Mik Kersten: 2018, right.
[00:34:58] Adam Hawkins: Now the book's been out in the wild, the ideas have been in the wild. You've have calm, you know, you've had conversations. You see how people think about this? How they're react. What's kinda your retrospective on this. I mean, what do you think has worked or not work? Like what's clear. Here do people have questions and what do you think.
[00:35:15] Mik Kersten: Yeah, one really interesting thing is I was expecting the, to want to change and evolve more of the flow framework.
[00:35:24] Mik Kersten: I thought it would be a year before I wanted to make some really significant changes, but the, the, you know, or, or someone discovered a fifth flow item, right. Because I was kind of, you know, it's kind of a challenge. I basically said like, no, there's just these four there there's, there's actually just four.
[00:35:39] Mik Kersten: So the interesting thing is it's how well it has stood. The test of time from the point of view is structured. Not, not that it's been that much time and it will evolve over time. And we're learning like with some customers right now, we're actually learning how to apply it to mixed hardware, software systems in IOT.
[00:35:56] Mik Kersten: Right. We got sort of two different types of value students going into parallel. One on the hardware from our side and one of the software and the interesting thing is the flow items still apply the core concepts still apply, but there's some new ways that we're thinking about extending that a little bit.
[00:36:15] Mik Kersten: So I think the interesting thing. It's worked the thing, and the structure is working in terms of helping organizations do this. Right. Which is fundamentally all I care about. So the, the thing I wish I had done a bit more of is that help understand the different kinds of product value streams that organizations have and the importance of these internal platform, value streams, and the thinking of the vice from network itself, your tools, data itself as a product of someone. Cause because that's where a lot of organizations get hung up. So I've definitely done a bit more work on that lately. I think there's some things in it that, you know, it can still be leveraged to help with these journeys like those. Indexes that it has like the alignment index. How aligned are you? Are, are areas where I think there's, there's, there's a lot more organizations can gain from those things. But right now, I think what I'm really happy about in terms of what's the immediate value is delivered to organizations is just highlight those four flow items, modeling them out and just the simple.
[00:37:16] Mik Kersten: And this will go back to that, what you're saying, Adam, about the podcasts, because I thought he's just got some fascinating ideas, unexperienced and just the simple fact of folks come in one flow metric just on flow time, just how transformational that can be, because it has you think the end to end and it gets you started rather than. Thinking you need to be, you know, have a perfect agile and DevOps deployment to get started. Now you start with measuring and then again, using data to drive further improvement.
[00:37:44] Mik Kersten: And just how transformative to a lot of organizations, elevating debts, technical debt and risks has been because. Do you tend to get ignored. Do you tend to cause the development teams a lot of stress because they're always trying to keep up with them and then they're not being properly scheduled they're accounted for or prioritized.
[00:38:05] Mik Kersten: So yeah, I think the, you know, the key thing right now is to take and what I'm focused on is taking the outcomes of these flow diagnostic.
[00:38:13] Mik Kersten: To help provide a better guidelines and have our teams provide better guidelines to how to improve right. To the fact that you know, what the anticodons are, if you're under investing in new platforms, because it's something that we so often see. One of the things that we see most consistently is, is too much flow load. Right. That's because if you're ignoring that and risk by definition, you too much flow load, because you've got all this invisible work. So, yeah, it's that's, that's been some of the cooler.
[00:38:40] Adam Hawkins: So when you said sort of educating around different kinds of product value streams, and you, you mentioned like internal platforms, are you talking about like internal platform teams who are sort of like a, maybe a horizontal team for other teams inside the organization? Can you expand on that a little bit?
[00:38:57] Mik Kersten: I see exactly. I did not do this well enough in the book. It's it's there's we don't have great common definitions of this, but I think it's such an important concept, which is the fact that you've got your business facing product. Right. Those face the customer then you've got the products that those build on those are your platforms, API APIs.
[00:39:15] Mik Kersten: And then below that you've actually got the tool chain itself. So your, your ads on dev ops tooling, which you need to treat each of those as its own product that has its own roadmap and its own backlog and treat those internal things as first-class products, which is what pretty much every tech company knows to do. But a lot of organizations have not come from a technology background don't they, they basically think there's... you've got this. It makes stuff work. And we've got a bunch of business products rather than actually understanding the structure of their product and value stream portfolio.
[00:39:50] Adam Hawkins: And I agree with your point make on why team typologies is so important because at least it gives us a common vernacular to discuss the types of things. How it relates to the structure of organizations and even in team typologies, as the focus of value stream, aligned teams, platform teams, supporting teams, like how they all, how the structure of these teams actually fits into the whole network, the value stream network and the each kind of the role, it plays in the whole dance of delivering all this stuff.
[00:40:16] Mik Kersten: Exactly.
[00:40:17] Adam Hawkins: So Mick, it was my pleasure to talk to you. I'm so happy you came on the show and talk to us about the full framework and project product and value stream networks, all this stuff.
[00:40:25] Adam Hawkins: I think it's so important to the work we do as engineers. And also for those of us who are really focused on business results, which is something that the flow framework really brings to the forefront of the daily work.
[00:40:38] Adam Hawkins: So thank you again for coming on the show. Is there anything you'd like to leave the audience with before go?
[00:40:43] Mik Kersten: No, my pleasure, Adam, thanks for the great work that you've been doing around this and, and helping educate people on it. It's great to see, I think yeah, I think the main thing is, is, you know, just for people to get started with this now it's once you everyone's got sort of the same score card, with, they'll just say, standing with flow time. It's amazing how much, how, how positive as it is from a cultural point of view. Right? Everyone's got the same goal of, of reducing the flow time and delivering more and taking all the impediments out of the way and trusting their teams to then to build off of that and, and thrive.
[00:41:14] Mik Kersten: So. Thank you. And yeah, you can find more on the book and then me on project to product. Other work. Yeah.
[00:41:21] Adam Hawkins: And also Mik, has a podcast, a Mik + one, where he talks about all this kind of stuff with different guests and you had Adrian Cockcroft on recently. And another most recent episode was a kind of developer productivity, some good stuff there. So if you like podcasts, be sure to check out Mik + one. All right. Thank you, buddy.
[00:41:40] Adam Hawkins: Thank you for listening.
[00:41:42] Adam Hawkins: That wraps up this batch. It's a small batch of that FM for the show notes. Also find small batches of fam on Twitter and leave your comments in the thread for this episode. More importantly, subscribe to this podcast for more episodes, just like this one.
[00:41:57] Adam Hawkins: If you enjoyed this episode, then tweeted or posted to your team slack rate this show on iTunes. It also supports the show and helps me produce more small. Well, I hope to have you back again for the next episode. So until then, happy shipping,
[00:42:16] Adam Hawkins: want to learn more about dev ops that wasting your time and sign up for my free email course freedevopscourse.com. My course combines the best from the DevOps handbook, accelerate and years of software delivery experience. You'll learn the three ways of dev ops and the four KPIs of software delivery.
[00:42:33] Adam Hawkins: Perform. More importantly, I'll show you how to put that theory into practice. That means shipping better software faster. Sign up today at freedevopscores.com.
[00:42:48] Adam Hawkins: Like the sound of small batches? This episode was produced by pods worth media. That's pods worth.com.
