Talk: Project to Product: Measuring digital transformation with the Flow Framework - Mik Kersten, Tasktop

Lauri (00:03): This is where we get the actual conference going and introduce Mik Kersten, who'll talk about how to track digital transformation, prioritize product development and how to set measurable metrics. Please welcome Mik.

Mik (00:23): My name is Dr. Mik Kersten, I should be forthcoming but I'm actually not a real doctor. But I will be giving you some prescriptions today for some very common DevOps pathologies. So what's happened is, a couple years ago, I wrote this book called Project to Product. And since that time, I've been working with some very large organizations and discovering exactly what Lauri said, where the chasm between the desire for DevOps and the promise of DevOps and the reality that a lot of developers, a lot of teams with day to day seems to be very wide.

Mik (00:59): And myself and my team of advisers have actually uncovered some common patterns that we see in organizations who really want to push towards DevOps, want to move towards getting this kind of business agility, fast, flow, and feedback and learning, but are running up into some common mistakes. So I'll actually identify some of those for you today, the ones that we found to be most common, most problematic and the most tricky in terms of actually succeeding in DevOps transformations and succeeding in making an organization more innovative, and really in bridging this chasm between what the business needs, what customer needs and how we deliver technology.

Mik (01:31): So all of this has actually been grounded in over two years of data that we've collected from large organizations, in some cases, midsize organizations, software value streams and product value streams. So it'll build on some of the concepts of the full framework. I'll introduce those to you today, and try to share with you some of the, to me, were the most profound, and thought-provoking discoveries that I've had in the past couple of years since publishing the book.

Mik (01:55): So the journey for me around DevOps, around spending a decade as a developer, a decade working in Agile, and then getting closer to the DevOps community has really been understanding how value flows, what we deliver, and how we measure that delivery. And it really struck me as I started working several years ago with some of the largest DevOps transformations, that one of the core principles of flow and feedback is, which is understanding your constraint. If we didn't go back two decades, Beck was talking about the Theory of Constraints in XP. It tells us that we should always be investing at the constraint.

Mik (02:28): And I realized that so much of what I was seeing was really not about the constraints, is applying these different metrics that were at one point of the value stream or another point of the value stream, but not really understanding the systemic constraints. So whenever I met with an executive, a CEO, a CIO, who is working with a large organization, I ask him or her, well, given that you're investing so much in this transformation, what is your bottleneck? Where's your main constraint?

Mik (02:54): And what really surprised me, by the way, this is before I wrote the book, and I've kept asking this question, but what really surprised me is I never got a common answer. There's never really a systemic understanding of what the constraint was in delivering value to the customer. And I thought this is very problematic because it made me realize that, as technologists, we tend to understand constraints, if we're having a lot of trouble having our changes approved or having trouble deploying software in a safe or reliable way, we feel that as a constraint, but why was it that when we started to look across different development teams, these constraints were not well understood?

Mik (03:28): Why was it that no one in the C-suite that I talked to could consistently answer the question of where is the bottleneck? And so I just started realizing that so much of the perspective that we've had around agile, around DevOps has been very narrowly focused. If you look at the end-to-end value stream of what it takes to deliver value to a customer, so often, we're only looking at a small slice of it. And I realized that a lot of the work that myself and my colleagues were doing, things like the, Lauri mentioned the State of DevOps report, identified some very common problems, such as organizations that were not able to deploy software frequently, probably had a constraint somewhere in the delivery pipeline.

Mik (04:03): But what was happening is I was seeing executives who were very excited about applying DevOps, saying, "Okay, our number one goal, the only goal that we have is to increase how many times we deploy per day." Which to me sounded profoundly wrong, because in the end, your goal should be around delivering value, around making your developers lives easier, your team's life easier, you're delivering more value to your customers, not really around counting how many times you deploy per day, it's really about extending that feedback and learning loop.

Mik (04:29): So I realized we don't really have a consistent way that was being applied in large transformations of measuring value. So I started writing more about this, myself and Nicole Forsgren, one of the authors of Accelerate, we were working on DevOps metrics, put our thoughts together in this paper in ACM queue and realized, okay, we really need to up our game in how we measure DevOps, how we measure agility, how we measure a transformation from a software perspective. And the set of metrics that we have are really insufficient and are not sufficiently applied. And if we misapply the wrong metrics, we can really mislead our organizations and our transformations.

Mik (05:05): And that's exactly what's happening over and over and over again, that these proxy metrics that didn't speak about value, they were speaking only about a single part of the value stream, how quickly it took to close user story or how frequently we deploy software, we're really not a proper measure of value. So with that, I started really asking myself the question, as I examined with my team, over 308 organizations value streams, so I started asking what actually flows in software delivery?

Mik (05:35): If we were to imagine and envision DevOps and the process of delivering software as an assembly line, and by way, it's not an assembly line, it's a creative process, it's more like a network that turns out, as I learned throughout this. But what would be envisioned flowing along this network, this value stream network of delivering software by building great things and shipping them to our customers in a reliable and safe way?

Mik (05:58): And this is really what the Flow Framework came from, is analyzing those value streams and then recently applying them. And the Flow Framework, I'll just introduce it really quickly, you can learn more on flowframework.org. But it says there are really four units of value if we think of value being pulled by the customer, and the value being pulled along these product value streams. And those are features that net new business value that we provide to our customers, defects, those are the quality improvements that we make.

Mik (06:26): For our customers, risks. That's how we make our software safer. And then debts, things like improvements in technical debt. And those are actually pulled as part of the architecture activities that we do. So these are the four flow items in the Flow Framework. And the Flow Framework really challenged us to think, to layer over those DevOps practices, the Agile practices, the real rich taxonomies that we have in Agile tools, and all the different work item initiatives, and really take the customers and the businesses perspective, to say, at this higher level, at this level that we're both the business side, and the technology side can have the same language, we can all agree that this is how we deliver value. By delighting our customers with new features, by having software that's higher quality, making sure that software is safe and secure and respects privacy, and making sure that we actually invest as we try to bring the software to market more and more quickly, we're actually paying down the debts that we incur by taking all the shortcuts that we do as when we build it.

Mik (07:20): And so in the Flow Framework, these four flow items are mutually exclusive and comprehensive exhaustive. And they describe which, by the way, that just means that if you do more of one, you're doing less of another. If you really have a big feature push, you're going to incur more technical debt, you'll do fewer risks. If you're doing a lot of compliance work, guess what? You'll do fewer features.

Mik (07:39): And so the whole goal is to actually expose the dynamics of software delivery at scale, by measuring the flow of these four flow items, measuring all end to end, and making sure that the business and the technology side have the same way of expressing these things, things like technical debt are no longer hidden from the business and that they're actually worked on technically and celebrated, rather than being done on weekends.

Mik (08:02): So the whole goal here and the whole goal of the Flow Framework we're describing a Project to Product is to give us a way of measuring this and again, give us a common language to bridge that chasm that we just heard about by providing these flow metrics. So the same way that we have metrics to understand our vital signals in our body, these flow metrics, these four simple metrics and flow distribution, which is actually the distribution of those four flow items can actually have us understand how value flows through our software value streams, how well we're doing and applying the principles of business agility and DevOps.

Mik (08:37): So I'll quickly go over these four flow metrics, and then show you some examples of some case studies, some patients, who exhibit some interesting pathologies around this chasm and applying DevOps. So the first one is flow velocity. And remember, each of these flow metrics are all end to end, they're not how long, one silo, one team, one set of individuals did the work. This is all the flow metrics from the customers from the business's point of view.

Mik (09:03): So flow velocity is the number of items completed over a period of time, that period of time can be a sprint, or release, a year. Flow efficiency is a really key one, flow efficiency is this bottleneck detector, because, for each of those flow items, it examines how much, what proportion of time it's been actively being worked on versus waiting. We know that wait states are the kiss of death in productivity and efficiency. But what frustrates us day to day as developers in flow efficiency actually tells us for this value stream, how much were these items being actively worked on versus waiting?

Mik (09:39): There's flow time, flow time is the end-to-end time from when work entered the value stream to when it was completed and when you had running software. And flow time again, is the customers the business's perspective, and it's simply the wall clock time. And one of the most amazing things that we see is the ratio of time spent in development to the ratio of the end-to-end time is completely skewed, it might take a dev team only two weeks to complete some work, but take another six weeks for that work to actually pass through security and other reviews. So that's flow time. The Flow Framework only measures that end to end.

Mik (10:12): And then finally, there's flow load. So flow load is a work in progress metric. It's your WIP metric. And it really tells you how much work has been put into a value stream. Keep in mind, these value streams, the whole goal here is again, to give business and technology the same language at a higher level. So the value streams are a team of teams level construct. So you're really measuring the flow across multiple teams that are creating value for a portion of your software portfolio that some customer's consuming, internal or external customer.

Mik (10:42): And so your flow load is actually telling you how much work has been pushed on to those teams delivering that value. And then finally, flow distribution, and flow distribution is simply the ratio of the different flow items, for this particular release, for this particular sprint, how much debt work that we do versus how much feature work that we do, because, of course, we're always trying to do more and more feature work for our customers. But we have to balance these because we have a complex dynamic system that we need to understand. And again, these flow metrics are a simple way of understanding that for the entire organization, not just for the technologists.

Mik (11:13): So the Flow Framework, I'm actually not going to cover all of it, we're going to focus on how these flow metrics work. These flow metrics, of course, have to be connected up into the top right of the Flow Framework into business results versus value, cost, quality, and the happiness of your teams. And the way that we actually implement this is by layering over your existing toolchain, right. All of this data, all of this flow, all of this information, it's simply there in your agile tools and your project, your product management tools, your service desks, and the like.

Mik (11:42): So now with just this really brief overview, I'm actually going to show you some specific cases of common pitfalls that we've seen in applying DevOps. So the first and sadly the most common one that we see is the technical debt death spiral. This is something we've encountered frequently in many organizations. And let me show you one patient's case and charts right here.

Mik (12:07): So this patient in this case that we're examining is a financial services company. And the interesting thing is that this organization has actually had a successful Agile rollout. So they're actually doing Agile practices, and they have a very mature continuous integration and continuous delivery pipeline. So from a lot of DevOps automation. However, those executives who are very excited about the promise of DevOps have not quite seen the value that they expected to see.

Mik (12:32): So I was working closely with a CIO, who was complaining that feature delivery to his business partners still seemed painfully slow. And that the business as a whole was concerned about a lack of innovation. So what we're able to do is use the lens of these flow metrics, actually look at the data of this value stream. So what we did is we examined, in this case, it's their core banking application, and some of the applications and platform I should say, and some of the applications built on top of that, the mobile and web applications, where they really care deeply about providing innovation to their customers, especially given that the financial technology space has so many startups and so much disruption happening here.

Mik (13:09): So if we actually look at the charts of their flow, and again, this is just using the lens of those flow metrics that you can apply to your own organization, you don't have to understand all these charts, these are just the ones that we get from our tool. But what you see over here is that we've got the flow distribution chart, where we see the distribution of those features, defects, risks, and that's showing something really interesting with this patient, which we see in quite a few organizations, where there's just not enough green, right? Green is the features, it's that net new business value.

Mik (13:41): And we see some yellow in the test of this tool, that's risk works. So the good thing is that the risk work is visible. Oftentimes, when we examine value streams, risk work is not visible because it's not been as prominent in the Agile tools that we use today. This organization is actually doing a good job on tracking that risk with privacy, security, compliance, and so on. However, there's no purple, and purple in this coloring scheme is the tech network. So that's a real problem.

Mik (14:08): Because if we don't see technical debt work being done across these teams, this is multiple agile teams and feature teams doing this work, it means that technical debt work is not being prioritized, it's not being valued by the organization, that's not visible. The whole goal, of course, around managing your value streams is making all that work visible so that you know where to apply your resources, where to apply your efforts.

Mik (14:32): Now, if we look a little bit closer, there's another even deeper problem over here. So if you look at the flow load, so this is the WIP chart, we see something really disconcerting. And I was again looking at this with the CIO and this virtual Gemba Walk over the value streams. And what we see here is that we've got the dark green is the current load that the teams are working on. And this now we've just zoomed into features, by the way. So they're doing a whole lot of feature work.

Mik (14:56): But what's even worse over here is that the light green we see is actually the backlogs and the backlogs are growing and growing and growing. And if we look at the flow velocity of this team, they have no hope of taking down that backlogs given how quickly these backlogs are growing. And this is, of course, a real problem because the teams are frustrated, the business side is frustrated, the executive's championing the transformation. And the DevOps initiatives are frustrated. They're not getting enough value in time.

Mik (15:22): And yet more and more work is being pushed onto the teams. And so this is that kind of unsustainable state that we see so many transformations get into, where there's a lot of promise, there's a lot of desire for things to improve. But for some reason, things are not moving any faster. Now, I should mention the gate that work in progress, this too higher flow load is something that we see in almost all large organizations, too much work has been put on the teams and simply reducing the flow load, simply reducing how much work is being done, will actually increase flow velocity, it'll allow the teams to deliver more and have them thrashed less.

Mik (15:55): But in this case, let's dig a little bit deeper and look at what's really going on in this particular value stream. So what we see here, if we actually analyze the load, we say, okay, well, let's look at the flow efficiency, where's work really being stuck? And what we see in the load, and this is a bit of an eye chart, but there's something if you squint hard, you see actually that there's something here in JIRA. And there's some project in JIRA called core back end services. And this thing has over 73 users already stuck in it.

Mik (16:25): So core backend services turn out to be this painful legacy component that the teams who work on it have been complaining about for ages, but that was never quite visible. And when we started having these discussions, we saw this data saying, look, everything is getting stuck on core backend services, what's going on here? The teams are saying, well, we keep moving contractors in and out of it, all of the talent we're putting on to the mobile and the web applications. And yet, everything's being stuck on core backend services.

Mik (16:50): And so what's so clear from this data, from analyzing the flow is that the bottleneck is core backend services, and you should not add a single developer to the mobile application, to the web applications, until you actually fix the bottleneck and the core backend service and start adding the API's that those teams need. And such a common thing that we see is that the software architecture and the investment that's being done is actually not properly aligned to the value streams and investment's going into the wrong places.

Mik (17:19): So once you actually look at this systematically, and this is exactly what happened. Finally, the data was there, the executive sponsored the Slay The Monolith initiative, which by the way, the team who works on core backend services want to see for over two years, right, they wanted to break this thing apart into microservices, but never really had the organizational support to do that. So finally, again, using the data, it was very, all of a sudden, easy to cross that chasm between sort of the promise of DevOps and how to deliver on it. And how to deliver in this case, was a need to invest in actually the platform components, not the business and customer-facing components over here.

Mik (17:56): So what we learned from this is that when you've got these kinds of pathologies, like the tech debt death spiral, you have these interesting symptoms, right, we can actually see these flow symptoms, and we see them repeatedly in different organizations, we see that full time was increasing, that flow velocity was decreasing and actually the flow distribution of defects was going up as well. The business and then those are the flow symptoms that we see in the value streams, the business symptoms or that time to market is too low. The cost of delay of getting these features out is growing, growing and team happiness, the Flow Framework, one of its main metrics is actually the happiness of the people working in the value stream, it's decreasing.

Mik (18:32): The mistreatments are just more unsustainable and worse, telling the team's look, you should be able to fix these problems while taking down the backlog, while delivering those features. And that just doesn't work. The data shows that it doesn't work. Adding developer headcount to the business applications, again, complete anti-pattern in this case, because that's not where the constraint is, and putting the lowest down to the backend.

Mik (18:53): Again, completely unproductive, even though that's what the organization was doing with the best of intentions. So the treatment plan here, of course, is first makes all technical debt work visible, celebrate it, when you're actually adding those API's, when you're moving off that legacy system, celebrate that, allow the teams to plan for it and make the business understand the value of that delivery, then it will increase feature flow.

Mik (19:13): To do that, we actually need to measure the benefit of tech debt because of course, it's not visible, the benefit is not visible to the customer or to the executives, right? But actually by showing that we're reducing our flow time. So time to value, time to market by investing in tech debt, all the sudden the benefit of tech debt does become visible to the organization.

Mik (19:32): And of course, in this case, this particular organization had to put more of the talent onto the platform and onto the back end to actually make those kinds of improvements, which they finally did. Now, it's important that we actually create this constructive feedback loop of visibility, of improvement. Because in the end, DevOps is about flow feedback and learning. And so we actually need to institutionalize this, not only the review of the features that we've delivered, but the review of how we've improved the flow, how we've made the day-to-day work of our teams better.

Mik (20:02): And so the way to do that is actually to measure a continuous flow time improvement, it's possible to cut flow time in half in many organizations just over the course of months. Once you're focusing on this and fixing those technical debt issues, you'll actually see fewer defects. And we could actually measure the increase in happiness across teams, as we've done with our customers, right? When you move these impediments out of the way, teams are happier, because they're delivering more value, they have fewer frustrations and fewer points of friction.

Mik (20:31): So the next study, I'll go through quickly, and this patient is actually showing the result of neglected WIP. So we saw this technical debt death spiral, we started neglected work in progress was one of the problems. But here, we're going to take a closer look of what that actually looks like. This patient is a healthcare company. They've been rolling out the Scaled Agile Framework. And the interesting thing about them is that they actually have been putting a lot of emphasis on technical debt.

Mik (21:01): However, there's still this ailment that IT can't keep up with the business, the IT teams are moving too slowly. So let's take a look at this patient's charts. And we see something quite interesting here. First of all, there's a bunch of purple. So in this value stream, this set of teams actually is championing tech debt, this is always great to see.

Mik (21:19): However, we see another problem here, which is when we look at the velocity and the load, there's just a big mismatch if we use and we can actually get down to the details here, but you can actually use Little's Law in queuing theory to realize that there is no hope for this team to ever take down their backlog and to do this tech debt work, right, because what's happened, of course, is this teams have been asked to improve their work.

Mik (21:42): And in the meantime, all the work that was on the backlog has not been removed, right? So none of that pressure is, and this happens frequently, unfortunately, in transformations, where the teams are asked to improve their work practices, to apply a lot of the great learnings you'll get from this conference. But none of the pressure of the feature delivery, the requirements that need to be delivered, the customer deadlines that need to be delivered, is actually removed.

Mik (22:04): And when that happens, when you're told you're going to now remove all this tech debt work, but you don't have the capacity, additional capacity to actually do it, load goes up and up and up. And we're seeing this everywhere. And this is an unfortunate symptom of this transformation is that the teams are being asked to do too much at once. When that happens, work slows down even further, flow efficiency starts tanking. So flow efficiency is how efficient it is to get that work out. And we've seen flow efficiencies of two, three, five percent in teams are transforming at the same time they're trying to deliver. And this is very frustrating, of course, to the entire organization, to the teams, to the business, to the executives.

Mik (22:38): So the key thing here is that the flow load must be brought under control. Once you bring flow load under control, you will get more done. And it's just a question: what the priorities are, how much feature work versus how much tech debt work, what the priority of this is, what the priority of the next release is? So in terms of these symptoms, when we see this kind of too high a flow load, which again is just extremely common, unfortunately, across the entire industry, flow load is just increasing, flow efficiency is dropping, and the business symptoms are severe because future work starts waiting indefinitely, you start losing credibility with customers, frustrating business partners.

Mik (23:12): And then there's this other big problem, which is because of this, unplanned work is chronically fast-tracked. So that feature needs to be made, something needs to make in to release, frequent scope changes, then exacerbate even further the flow load on the teams, making things even more difficult. The mistreatments are to push even more work to teams and to suggest that the dev teams get better multitasking and those kinds of things, which simply don't work here, this is too high flow load means you get less out, not more out.

Mik (23:41): The treatment plan is to stop starting, start finishing. Allow the teams to finish their work before you take on that next initiative, and stop changing scope frequently. And again, give that room for improvement, capacity will increase if you do that. Of course, enforcing some kind of WIP on the model can be extremely helpful here, the key thing is to find that bottleneck and to add capacity to the most under resource constraint.

Mik (24:05): The checkups on this are of course, always looking for improved flow velocity. Once you're doing the right things here, you'll actually start seeing more capacity. And over time, when you see more capacity, you'll actually be able to increase the flow load, the team will be able to actually productively take on more work, you'll see improved flow efficiency. And of course, the better predictability in releases and fewer scope changes which in the end makes everyone happy.

Mik (24:26): All right. And I'll just quickly run through one last of these full diagnostics. And this is just an interesting one that we're seeing really frequently as well. And this goes back to how we actually measure and what this chasm is because of the fact that technical teams and business teams and customers see things slightly differently. The goal of the Flow Framework and the flow metrics is to give us one way of measuring that actually makes sense for all of these different stakeholders.

Mik (24:50): So this patient is a healthcare insurance company, very much Agile deployment. They've actually shifted from project to product which is great to see, but still the same on the dev does not seem to be moving fast enough. And the business results are too slow to show up. So when we look at this patient's charts, we see something really interesting.

Mik (25:08): And by the way, each of these, I was actually, this was done with myself and the executive teams and the technology teams. So this was just a super interesting experience for me, because we're seeing over 1000 things in the flow load chart, right. So there's a whole lot of stuff that's in progress here. And it's mostly features. So this looked a little odd when I was first looking at it, I was like, really, are you really working on 1000 things concurrently in this value stream?

Mik (25:31): And if we then analyze the load, again, what we see is something really odd, it looks like all of these things say that they're done, but they're not done. And so if we actually dig into how flow has been modeled here because it's really important to model flow across all your tools to get your customers' perspective. What we see is that all this work that's being done is actually in a wait state. So what's happened is that the dev teams are saying that the work is waiting, the work is actually done, but that none of it's been shipped to the customer.

Mik (26:05): So once you actually simply change this, once you take the customer's perspective on what "done" means, instead of the team's perspective of what "done" means, change the map, and we did it live when we were doing the meeting, you get a completely different picture. So there's only actually 260 things that are active. The dev team has been completely done with those features. And they were all stuck on operations. Right. So the dev team was calling things done, the operations teams had, they were doing additional security review, additional deployment testing and integration testing, and those kinds of things.

Mik (26:35): And so the customer was not seeing the results, because there was this massive bottleneck. So really, this is just the case for DevOps, right? You need to take the customer's perspective on what's being done, not one team's perspective on what's being done. And actually, the big challenge here is because this was not visible, it looked like the dev team was actually being blamed for it. But really, this was just simply a lack of DevOps, and fixing that and making sure that you model your value streams, from your customers' perspective, is critical to actually getting the right kind of visibility and knowing where that effort needs to go.

Mik (27:08): This full diagnostic, we're seeing all this effort, but things are not improving from the customer's point of view, there's a perceived lack of innovations, the bottlenecks are not visible. And of course, the mistreatments to keep optimizing around silos, what you really want to do is you need to shift to that customer focus, you need to identify all those handoffs, and then, of course, you need to include all the cross-silo handoffs to have that whole picture of your value stream so that you know where to place that effort.

Mik (27:32): Again, hiring more developers or blaming the dev team there would have been completely counterproductive. There's just more automation and more investment in the CI/CD pipeline that was needed on this front. And again, once you do this properly, you get the right view of the data flowing through value streams, flow time should get dramatically reduced once you automate those handoffs, once you invest for the DevOps strategy, and of course, customers are seeing those results so much more quickly once you do this.

Mik (27:57): So just to start wrapping up quickly, the whole goal here, of course, is that for our entire organization, all of this is visible, it's as visible as on your Google maps, seeing where your traffic jams are, we're in that last organization, of course, there's wasn't the CI/CD pipeline. And other times it's from too much load because it's simply there's been too much work to put on teams. And there's a whole series of pathologies that we're documenting further, that you can access from flowframework.org.

Mik (28:26): Really, the whole point here is that we actually need to wait to measure the way that we deliver, the way our teams deliver, the way we do agile and DevOps practices, that's bigger than just any single team. The way we really think about the customers' perspective. And we measure from outside the system rather than measuring within any system. And of course, that principle comes from Deming.

Mik (28:47): The key thing is that there's complex dynamics here as well, we need to actually understand what's happening with value streams and try and experiment and create changes and see if those changes produce results, rather than saying, okay, well, we need to spend 30% on tech debt reduction across all our value streams, do we? Let's try to reduce tech debt over here and see if our flow time improves. Or maybe the hypothesis is wrong, and maybe we need to put, the constraints actually somewhere else. And that's the whole point of making these dynamics visible so that the teams, the organization can make these decisions.

Mik (29:16): And of course, the other key thing, this is really back to what was the point of bridging that chasm is we need to basically start measuring things in terms of outcomes and results, not activities, right? If we're investing in things like tech debt, we need to say, okay, that's going to improve our flow velocity or reduce our flow time, our time to market because that, in the end, will help the organization champion these initiatives, those technologies realize are important. Actually changes the language to be the language of the business.

Mik (29:42): So I'll wrap up for now and we've got some time for questions. You can learn more about the Flow Framework and about Tasktop at the Tasktop booth, and you can actually look like you can win a Nintendo Switch as well. And you can get the book from projecttoproduct.org, see flowframework.org as well for more materials, we've got a lot of free materials out there to help you understand how to apply and really think about these concepts of flow. I've got a podcast every couple of weeks where I'm talking about applying this concept of product value streams and flow. And then you can learn more on our website tasktop.com as well. So I will pause there and take some questions.

Linda (30:19): Thank you so much, Mik. Now is your golden opportunity to ask questions from Mik. And the way we're going to do this is you type into the chatbox. And as I mentioned, one of my favorite parts of this conference has always been the active audience. And we are not disappointed because there are a ton of questions for you to answer. But since we're a little bit greedy, I'm going to let Lapa ask the first question to get us going.

Lauri (30:42): Yeah, Mik, I was equating your background from the Eclipse Mylyn project and the task-focus interfaces. And I was curious as to how do you see that approach from an individual developer than lining up with the business objectives? So how do they support each other looking at task orientation versus the big picture?

Mik (31:06): Yeah, Lauri, for me this entire journey started as a developer, right, it started when I realized when I was making developer tools like Eclipse Mylyn, like some programming languages, that basically the more connected that I was to the value stream. So when I knew exactly that, basically, exactly all of the context of this particular defect issue that came in and so on.

Mik (31:30): And when all of the conversation was connected, and I saw my slice of the value stream connected to everyone else, I felt like my productivity was 10 times higher than when I had all these manual handoffs between all these steps in the value stream. So I started realizing, okay, we need to, because my background is in software architecture and programming languages. So I started thinking, well, we need just the same way that we have a formalizing how we think about the code and of our type hierarchies and our call hierarchies and functions and so on, we need a way, a formal way to think about value streams, right?

Mik (32:00): Because we understand where our architecture constraints are, we understand when that microservice gets flooded with too many messages and so on, we need the same kind of thinking to apply to our value streams to how we actually deliver value all the way from work coming in, be that an incident or a feature request or something, all the way to get into the customer. So for me, it starts a personal journey. But then I realized, okay, well, this really applies to at a team level as well. And then what became really interesting to me is it really applies to the whole organizational level, right? At that team of team level, where if we can actually find these systemic bottlenecks and have these simple metrics to reason about where those constraints are, well, we can apply some architectural thinking to the entire flow of value in our organization. So it absolutely came from that journey long, long ago.

Linda (32:49): As someone who has a history all the way back to the Xerox PARC, you've referenced concepts like the Mythical Man-Month and so forth, how much do you think history is repeating itself? How many things are unique to our times? And our software culture? And how much is it all something that we've seen before?

Mik (33:14): So there is a fair amount of this, the Mythical Man-Month, I mean, I basically just retold the story of the Mythical Man-Month in one of those flow diagnostics. Right. And that was one of the first sitting right here. That was one of the first books that I read that really was shocking to me, right. But the interesting thing is that over these past two years, I've been as surprised multiple times as I was by theMythical Man-Month,, right?

Mik (33:35): I had no idea when I wrote Project to Product that I knew flow load was important. And that WIP was important. And Donald Reinertsen, the author of Product Development Flow explains all of that conceptually and theoretically. I had no idea that basically nine out of 10 of the organizations I would work with would have had massive flow load problems, had massive flow load problems. So I think what's happened is because the history is rhyming, right? It often doesn't repeat, but it does rhyme.

Mik (34:06): But what organizations are dealing with right now is just so much more complexity, right, that system 360 Mythical Man-Month was complex, what most of you will come back to after this great conference is going to be so much worse than when Fred Brooks was dealing with Mythical Man-Month. So we need to take these concepts and really think about this systemically and just understand that we have a lot of legacy, we have very complex tech stacks. So as an entire organization, we need to know how to tackle that.

Mik (34:33): And if we have a platform problem, we need to understand that that's what's impeding our flow and stop pretending that we'll just keep working on the front ends without solving the platform problems. So I think for those of you who are familiar with those concepts, I would just go back and read those books. All of those things make sense. But we're now dealing with it in such large complexity, we need a really systematic way to measure this. And again, back to your point at the start, one that makes sense, not just for the technologists, but also for the executives.

Linda (35:01): While Lapa will pull up a question from the audience, I wanted to mention Jacqueline De Goedes, sorry for butchering the name, a question where she asks a very specific question from you and she's told to go to the expo later on. And that's a wonderful way for that audience also to keep engaging with these topics. And the second most asked question over here is about the book. And you all already got the name, Project to Product. So Lapa, any questions from the audience you want to pick up?

Lauri (35:34): I did. But I also want to start with a comment. Because we know that we have a lot of people in the audience who are also fans of Martin Fowler. I want to point out that during the first speech, Martin Fowler's talk of making architecture matter was already mentioned. So the game is open there. But there were two questions, one is probably a meta question, but the one is a real question. The first one is how do you measure happiness for the team? And then the second question, and probably we don't need to dwell in too deep to that is, how do we measure overhead of the measuring itself and find a good balance of what and how much to measure?

Mik (36:13): I mean, those are both great questions. So the parts I didn't cover as much today, the top right parts of the Flow Framework, we've got the value, the cost, the happiness, what the Flow Framework says, you just have to have those metrics, you choose how you measure them. So the way that we measure happiness at Tasktop was with quarterly employee Net Promoter Score surveys. So how happier our employees are through that one metric. There are other employee engagement metrics that you can measure, but the key thing is that you measure them, so that you actually see, again, a dynamic system, right?

Mik (36:41): You see, well, when we invested in DevOps automation and we actually, when we created a team of SREs, all of a sudden, our developer engagement went way up, right? But the key thing about this is what the Flow Framework says is measured for the value stream itself, right? Because it's not just about developers, it's about the developers and the testers and the support staff and so on. And what we want to see is, when we invest in removing some impediments over here, when we make security review easier, we should see that happiness for the entire value stream go up.

Mik (37:13): Whereas when we have an architectural problem on this other value stream, we might actually have declining happiness and developers quitting, we've actually seen that, that the frustration that you end up, again not just developers, it's architects, it's product managers, as well. The frustrations you get from overly tangled architectures actually cause people to leave companies.

Mik (37:30): So the key thing is figure out a way that's right for your organization to measure happiness and make it one of those metrics because you'll see, as you improve flow, the happiness of the people working on the advice from an increase as well, which of course gets everyone more motivated to keep investing in those things that make the staff happier, because happy staff deliver much better things to customers and make for healthy organizations.

Mik (37:52): So that's the key thing. Now the overhead question, that's a really interesting one. I think it's just about minimizing overhead, let the teams work the way they work, right? In the end, I think the measurement layer has to be above the team's work, you don't want to make people use their agile tool in a completely different way tomorrow, that's too much work, that's too much overhead. So basically, allow the teams to work the way they work today for their specific functions.

Mik (38:15): The support that they need, their SLAs, that won't change, right? The site reliability engineers, the SREs, probably need to work more than Kanban flow rather than a very strict Scrum flow. So let the teams work the way they work. And then kind of measuring the flow across the teams is the key thing. So don't alter things because that's a pretty profound question that also incurs more overhead and more frustration to the teams.

Linda (38:38): Beautiful. Thank you so much, Mik.