Gene Kim (00:00:00): Gene Kim (00:04):You're listening to the Ideal Cast with Gene Kim, brought to you by IT Revolution.Gene Kim (00:15):This is Gene Kim. If you haven't yet listened to episode one, where I talked with Dr. Mik Kersten and Peter Moore, go listen to it now. If you have listened to it, up next is the talk that I promised you. And by the way, in that episode, I told you that Mik's talk was from the 2019 DevOps Enterprise Summit. That was a mistake as it's actually from 2018. This is the entirety of Dr. Mik Kersten's presentation, where he talks about his 20 year journey studying developer productivity, which led him to writing his amazing book, Project To Product. Join me as we listen to his presentation. I'll break in periodically, adding my own running commentary on points that I found particularly impactful, both when I watched this talk initially and now over a year and a half later. Here's Mik's talk.Mik Kersten (01:02):Hello, everyone. I am just thrilled to be here today with all of you and sharing the story behind this book, Project To Product. So my name is Mik Kersten. for my entire career, I've been on this journey to help transform how software is built. And the first 10 years of that journey I spent as a developer and just writing a ton of code because I thought the problem was actually with the code, with the way that the code was disconnected from the value stream. And so I actually ended up writing over a million lines of opensource Java code that's still in use today in frameworks such as aspect oriented programming that you might know from spring, tools like the eclipse [inaudible 00:01:35] project that influenced how developer tools work and so on. And as Gene said, what I realized is that if we do remove those impediments from developers and connect them to the users that they're supporting, to basically the flow of business value, we do get the sense of focus and flow and even joy.Mik Kersten (01:52):And I actually got my PhD in software engineering on exactly that topic. So when my supervisor and I realized this, we decided, okay, let's try to scale this. Let's try to make this work for the very large scales. And we thought where better to look for those very large scales than enterprise IT? So we started a company called Tasktop to do just that. And I learned some very different lessons about what it's like to work in enterprise IT, and those kinds of scales, than it was like in open source. I actually noticed a 100 fold productivity difference between how quickly open source developers, and I was managing the community of hundreds of open source contributors, could create value compared to what I was seeing in these very large scales enterprise IT organizations. And I realized the problem is actually much deeper. And I think this morning, Gene gave us the inspiration that we can no longer target just improving the lives of 10 million developers.Mik Kersten (02:41):We now have to think of 40 million IT specialists. And so I can quantify this past decade of my life not with lines of code, but with traveling over a million air miles, which I can assure you is nowhere near as fun or rewarding as writing a million lines of code. But it did teach me a whole lot of valuable lessons by allowing me to meet with hundreds of IT leaders who are struggling with this problem, struggling with this weird and broken layer that we've put between technology and the business. And to try to bridge that layer, bridge those gaps, I created this thing called the flow framework that I'll share with you today. And that flow framework is what's featured in Project To Product. And the goal is to give us a common language between the things that we've learned over the past 10 years of agile and of dev ops, and bridge that gap between the way that the business looks at technology and looks at surviving and thriving in the stage of digital disruption.Mik Kersten (03:34):So for me, the journey started at Xerox Park. It's 1999. I just got my undergrad degree from the University of British Columbia in computer science and in anthropology. And I had this opportunity to work at Xerox Park, which is amazing to me. This is the computer science lab where they invented things like the graphical user interface, little things like the mouse and [inaudible 00:03:56] programming was pioneered there as well. And I was just having the time of my life because I was getting to work on these super cool new programming tools that were supposed to bring business requirements actually closer to developers and express them in the code. And I was actually working, started working basically 80 hour weeks and trying to do this because we have a thriving user community. And I loved what I was doing.Mik Kersten (04:20):And then after some time, the RSI started. So, I got this really bad tendonitis, and then that progressed into some nerve issues in my arms. And I tried mousing with my other hand and so on, but at one point my boss told me that she'd seen several careers end this way, and she suggested some paid time off. And this was the absolute last thing I wanted to hear. I was having the time of my life building these tools and coding, and I was far from burnout. It was just my body was not holding up. And I really then at that point decided to figure out why this was happening. Why was it that I couldn't keep coding these longer hours with us having so much fun doing it? So I started analyzing my own work, and the most surprising thing to me was that it wasn't the coding that was giving me the RSI.Mik Kersten (05:08):It was actually all this thrashing I was doing with all these windows, which were invented at park, so it felt a little ironic. But the windows, and those windows had stack traces, they had tickets, they had instant messaging. There was email because we were tracking user stories in email at that point. And by the way, we'd done all our continuous integration, continuous delivery automation. I wasn't even thrashing that way. It was actually all the communication in terms of what we were supposed to be doing and how misaligned our software architecture was to that flow of value stream artifacts. And so I though, okay, if that's a misalignment, well, we can make a software tool to solve that. So that's why I did this experiment of creating Mylyn. It actually did fix my RSI because it bridged this gap between what I was working on and the structure in the code. Other people seemed to have this problem as well. So I started seeing millions of monthly downloads, and that was kind of the foundation for my PhD thesis.Gene Kim (06:01):Gene here. Mik's 2009 PhD dissertation that he'd just referred to eventually turned into the eclipse Mylyn project, which pioneered bringing a broad set of tools to developers, which we now expect from any modern development environment.Mik Kersten (06:15):And so I realized there was something really fundamental around this weird disconnect between the software architecture and the value stream. And that was my first epiphany that's featured in the book, that these fragmented value streams kill personal productivity. In my case, that actually caused me physical bodily injury because I just kept wanting to code. In other cases, of course, you'll end up with burnout, with people who are unmotivated because they just can't get work done the way that they want to. So now fast forward a little bit. It is now 2007, and that's what my phone looks like. I thought it was a beautiful phone. And it turned out that Nokia had started their agile transformation. So just like you've heard Jeffrey Stover say earlier this morning, they had realized that they were about to get disrupted. They knew about [inaudible 00:07:02] touch screen, the large screen of the iPhone a year ahead of time.Mik Kersten (07:06):And so they realized that they better get better at software. Clearly this company was incredible at manufacturing physical devices, but the screen was going to get so much bigger and going to involve so much software that they realized that software delivery would be their bottleneck. And they realized this in time. They started adopting agile practices. They started hiring more developers. They did all the things that you hear companies doing today, and it appeared like they were doing it the right way. And I was invited to speak at the agile conference in 2009 about how to connect agile and open source. And I was amazed because every room I went into, there was a consultant on stage saying how Nokia was the poster child for enterprise agile. But then I started working with Nokia, and I realized that the truth was very different from the way that they were being described because what Nokia was doing was basically just the way that the business was looking at the agile transformation was how many teams were agile, how many teams were trained on scrum?Mik Kersten (08:03):So the measurement of the success of the agile transformation was this proxy metric. If you've seen Jeff Bezos' letter to shareholders in 2016, he talks about proxy metrics, metrics of activities, not metrics of result. Now you've heard John Smart talk about this as well. And this Nokia test for agility basically tested whether they had optimized the very narrow segment of the value stream development. You may have heard Kevin Fisher mention this morning that when Nationwide looked at their end to end value stream, only two and a half percent of the time was spent actually in development. So now imagine, Nokia could have hired 20 times that developers, could have hired 20 Ken Schwabers to help them on scrum, and it would not have helped this problem.Gene Kim (08:48):Gene here. Mik just referred to Ken Schwaber, who co-invented the scrum framework with Jeff Sutherland in the 1990s, who for so many of us was the way that we entered the world of agile and this new way of working.Mik Kersten (09:00):And as a result of this, that in the business not realizing this, Nokia actually completely lost the market, the mobile market that it created. And this was really my second epiphany that the silos, that looking at the value stream, this end to end value stream of bringing business value to your customers and measuring proxy metrics, some of those proxy metrics are very important. Chain successor is important. Development cycle time is important. But it's not enough to make a transformation successful. We cannot measure these proxy metrics and these silos. These are the things that destroy and derail transformations, as we saw with Nokia.Mik Kersten (09:34):So now it's 2016, and we should have learned all these lessons, but I'm at this bank. This is a top 25 bank by revenue, and they're in their third transformation. So the first two failed in very similar ways to Nokia. The third one was not just an agile transformation, it was an agile and DevOps transformation. So I thought, okay, this must have a better chance of success. And they actually were taking the approach of automation as well, so there was some fundamental positive differences. And the amazing thing was that it was such an important transformation-Mik Kersten (10:02):And the amazing thing was that it was such an important transformation that there was a billion dollar budget for this particular transformation. Everyone was pushing for making this thing work. Everyone wanted this thing to succeed.Mik Kersten (10:13):And then I realized that there was some, that it was going to fail. And this was two years ago, it's now happened. And I noticed that there was another very big silo. IT was doing the transformation basically within IT. And there was a chief digital officers and those kind of people who were brought in, of course, they were creating these amazing dashboards for this bank. So you imagine like this amazing car dashboards, because it was separated, those dashboards would never work in any of the regions that they were planned for. The software architecture was never going to support it. And the silo that was separating the business side, who was wanting to do the transformation and IT was completely getting in their way of this. So the transformation was being managed to of course costs because it was a project management transformation. And so, yes, of course the costs were reduced at the end of the two years.Mik Kersten (11:05):In addition, after interviewing the people that next time, everyone said the same thing, our ability to deliver value was also significantly reduced, of course, because it was just managed to cost alone.Mik Kersten (11:18):So this layer that was put between the transformation, the technology side and the business side completely got in the way. It was the wrong lens, it's the wrong layer for this thing to succeed. And that led to my third epiphany, that project management and cost centers are completely the wrong model if you want to become a software innovator. There are these things that completely derail these transformations, and we have to replace them with something better, and we have to do that quickly because other companies already have.Mik Kersten (11:48):So this is the stock price change between 2006 and 2016 of some retailers that you might know.Mik Kersten (11:55):Now, the retailer that's got that big bar, that 1910% stock price increase, that retailer, Amazon, has completely aligned its business strategy to it's software products, to its software architecture with microservices, to its organizational structure with [inaudible 00:12:12] teams. And they've completely out innovated everyone else in the process, of course, some of that stock price is AWS, and there's more to the story. In addition, it's great to see that some of the companies like who are speaking here at this conference are actually making steps in the right direction, for example, Target's price is near its all time high. But this is not just retail-Gene Kim (12:31):Gene here. Let me describe the amazing graph that make a showing right now. It's a graph of stock price changes from 2006 to 2016. On the left, you have Amazon with a 20X increase in stock price where all the other retailers are decimated or at best flat growth. Sears, JC Penny's, Kohl's Best Buy, Macy's, Nordstrom, Target and then Walmart up 2%. What a great graph. It will be shown in the show notesMik Kersten (13:04):We've got at this point, this world where some organizations have done this, they do not have this project management layer that's assuming a high degree of certainty of what will happen for the next two years of the market. They've become software innovators and the change is now so rapid between those who've managed software delivery at scale and other organizations that at today's turn rate, half of the S&P 500 will be replaced in the next 10 years. So this is happening and it's happening quickly.Mik Kersten (13:33):And as I was wondering about this, I was wondering, has this ever happened before, because I think for all our careers, we've been used to all this crazy change, then JavaScript framers coming out every two weeks and so on. But have we seen this rate of change? And Jean introduced me to the work of an economic historian by the name of Carlota Perez. So she has studied technological revolutions and she studied the last five technological revolutions, starting with the industrial revolution, the age of steam and railways, age of steel and heavy engineering, age of formal mass production and where we are today, the age of software and digital. And a really fascinating thing that she discovered was that these revolutions have two phases. There's an installation period, and there's a deployment period and between them, there's a turning point.Mik Kersten (14:17):So in the installation period, there's a big frenzy because some new means of production becomes very cheap. So you might have mass production, and this is the period in Detroit over a hundred years ago, where there were 300 car startups, over 300 car startups in Detroit, and this is fueled by financial capital. So today that's venture capital. And there's another example of that. There's a conference on FinTech in Las Vegas today, there are over 2000 FinTech startups today.Mik Kersten (14:45):So these companies are mastering the new means of production. And what's interesting is that this causes a tremendous amount of creative destruction, which has happened in every one of these technological revolutions. And then some masters of the new means of production emerge. So we can now call those the fangs, so Facebook, Amazon, Netflix, Google can include Microsoft Alibaba, fd.com and so on. These companies have mastered the new means of production, and they're amassing great amounts of wealth. And I think the key thing right now is to help all the other companies in the world economy move into this wealth generation that happens when we have the dissemination of this new means of production. So it really becomes a question, how do our companies survive this turning point? What do we learn from all those tech startups? What do we learn from the tech giants? What are they doing differently than enterprise IT organizations are still responsible for the majority of the world economy are doing today. And how do we have our companies survive this mass extinction event that happens in a turning point? Because we are currently in the middle of that turning point.Mik Kersten (15:50):So if we look at those revolutions, each of them has brought with it, a new managerial discipline. So there've been new financial systems discovered, but things like factories have some subcontracting than Taylorism and then Fordism. So what's so fascinating, and from conversations with Carlota Perez, this became clear is that Taylorism is actually where we learn how to do really interesting, amazing projects, the Hoover dam, not far from here that was created with Gantt charts, which is an amazing thing. But you could not create an economy of mass production that way, where mass production actually manage lean methods and products and value streams.Mik Kersten (16:27):And so what I've noticed is happening to these companies, that a lot of them were actually founded and established before the start of the age of software before the 70s, were still using management techniques from two ages ago to run our businesses and our strategies.Gene Kim (16:43):Gene here, again, this talk was recorded in 2018 when digital disruption was on the agenda of board directors everywhere. I'm recording this in May, 2020, in the middle of the COVID-19 global pandemic, where most of the world has been sheltering in place for nearly two months, working from home in order to maintain physical separation, to slow the spread of the virus.Gene Kim (17:06):Last month, Mick posted a blog with Dr. Carlota Perez with the title COVID-19 Triggered the Turning Point, which I'll link to in the show notes. It is a breathtaking post where he explains that the economic downturn that the global pandemic is causing is forcing a massive fiscal response and changes to public policy, actions that are always associated with the turning point. The actions being taken recently in the United States by the fed and by Congress are so much larger than those associated with the.com crash in 2001, and the great recession in 2007.Gene Kim (17:38):There's a meme going around on Twitter. It's a poll that asked which executive was most responsible for your digital transformation, the CEO, the CFO, the CIO, or COVID-19.Gene Kim (17:49):I love the work of Dr. Carlota Perez and her analysis of what we're going through right now is so interesting and even inspirational and hopeful. If you're interested in this, check out mixed blog posts and the interview that he did with Dr. Perez on his podcast, all the links of course will be in the show notes.Mik Kersten (18:04):So I wanted to look at with this is how did this happen? How did companies, mass production companies survive the last turning point? And I actually looked at a company that we've worked with very closely, so BMW, they're clearly one of the masters of mass production and they made it through, that last turning point. What did they do? How was their business connected to production? And could we learn anything from that? So we had this amazing opportunity to visit the BMW Leipzig plant, where this is Renee Strata on the right. He likes to be speaking with Common Diardo tomorrow and can tell you more of the story and more of what BMW is doing in their agile transformation. But the thing that was so amazing to me about this plant is that it's got the complexity, not only the architectural elegance, but the complexity of this plant is tremendous. So there's a new car delivered off the end of the production line, every 70 seconds, one or two series model. And those cars are actually delivered in the same sequence they were ordered, it's called Justin's sequence delivery, with an ecosystem of 12,000 suppliers putting in parts into those cars. And of course, many suppliers providing the different robots and parts on the production line.Mik Kersten (19:15):So this actually, we don't have an excuse of complexity enterprise IT. This is somewhere near that same scale of complexity. But no one there is talking about project management, they're living the lean principles that are listed from lean thinking. So those principles precisely specify value by product, identify the value stream for each product, make value flow without interruptions and let the customer pull value from the producer because in the end products are about customer polls. That's what we're meant to deliver.Mik Kersten (19:48):And so in this plant, for example, everybody knows where the bottleneck is. The CEO knows what the bottleneck with the limiting factor of the plant Is. Meanwhile, in all those meetings I did traveling. I asked many, many times what is the bottleneck of yourself for production. And IT...Mik Kersten (20:03):..Many times, what is the bottleneck of your software production? And IT executives or business leaders will just give vague answers or a blank stare because we're not even sure about what the units of production are in software, in terms of the way that the language of the technology side and the business side. And BMW is so amazing with architecting everything around these value streams, you can actually see the value stream architecture from space. So, this over here is the one and two series building. So, this is a very long high automation line because it's, again, delivering those cars every 70 seconds, no manufacturing step can take more than 70 seconds. The cars weave in there, and this is extensible. They can add new manufacturing steps by extending those buildings. BMW did not know how much demand there would be for their electric series, or I8. [inaudible 00:20:49] that very configurable line, the I8, the time to create an I8 is actually for each step of production, is 30 minutes.Mik Kersten (20:55):There's much less automation than in the one or two series. So, everything is configurable as these value streams and the business understands the product lines and the value streams. And let's compare this to what we're doing today with an enterprise IT. In car production, we've got these beautifully integrated production lines, not these disconnected tool chains. Everything is meant as products, not as projects. Everything's architected around flow, not technology layers, front ends, back ends and so on. Everything's architected on these product lines. Everything's optimized end to end, not optimized in silos and everything of course is managed by business results, not these proxy metrics of one aspect of the silo. So, if we look at business value flow, because fundamentally I think that's the problem, we've not agreed upon what production, what productivity is in software delivery. We don't have a common definition. If we look at business flow at the BMW plant, it's about quality cars that deliver sheer driving pleasure.Mik Kersten (21:52):Interestingly, those cars are designed in yearly cycles, even though they're delivered every 70 seconds. So, there's a difference between what they're doing and what we're doing, but the creative and the manufacturing processes are decoupled. They're actually in separate buildings. And of course, all of this flows across a linear line. The line stops, everything stops. That's a little bit different than what we see. In IT and technology and software, we delight our customers not with releases, because those should happen continuously now, but with new features. They're pulling new features, they're pulling new value, our customers are. Those things are designed sometimes on a weekly or daily basis and the creative and the manufacturing processor wants. So, that's a pretty fundamental difference, and the flow is not linear. It's not a batch process of delivering a feature. It's a flow across a complex value stream network that includes all the specialists, designers, developers, support staff, and operations involved.Mik Kersten (22:43):So, the flow framework aims to answer this core question, that what flows and software delivery, we need a common definition of productivity and of flow. And it's these four units. Features, that's new business value that's pulled by the customer. Defects, quality improvements also pulled by the customer. Risks, so the reduction of risk, security, availability, compliance, and so on pulls by people like risk officers. That's technical debt improvements, and these are built by architects, by developer and so on. And these four flow items are mutually exclusive and comprehensively exhaustive, which means they represent all work that's being done. You can have these very specific taxonomies, for example, in the scaled agile framework, which has a very nice taxonomy that we use. All of those types of work items map in to these four flow items. And so, I'll give you an example of how we can use these to express a common language between the business leaders and the technologists.Gene Kim (23:37):Gene here. Mik is going to describe the story of where technical debt comes from and how we can eliminate it using only up and down arrows. Mik and I created these series of graphs designed to convey the story of technical debt to even senior business leaders. I love it and I use it all the time. I'll post a link to the YouTube video where Mik walks through the graphs. I find these graphs to be an extremely effective communication tool and recommend showing it to anyone who you want to convince of the importance of managing technical debt as you go, before it kills you. Also include links to his slides in GitHub. back to Mik.Mik Kersten (24:13):So, imagine your last big push to market. Of course, with a big push to market, it's features, it's your ability to deliver great features to your market, to your users that's probably going to define the success of that product. As you do that, with that push to features, there's a cost because it's a zero sum game between those four flow items, which means that you take on additional debt and risks. And the result? Quality of course goes down as you do that, and defect work goes up and up to the point where you can easily get into this death spiral, been there more than I care to admit. Where the defect works keeps rising, this is where we can actually get the burnout. Developers want to be delivering features, they want to see the impact of their work on your customers. But of course they don't get to do that. And that's where we actually measure, as you'll see, things like employee net promoter scores drop as less work is done.Mik Kersten (25:08):And this is exactly the situation that Nokia got itself into. And just as a case in point, this is by John Cutler. This is the things that of course we've all experienced. In 2015, a reference feature took 15 to 30 days. In 2018, company's probably now bigger, 150 to 300 days. And of course the technologists understand why this is happening, they know they need to invest in technical debt reduction. The problem is the company, the organization, the business is not understanding that. So, now contrast that to the security stand down that Microsoft witnessed in 2003 with SQL Slammer. So, what Bill Gates did is sent this fascinating memo back in 2003, before security's front page news, and said, "Across our value streams, we're going to basically drop the feature work, we're going to reduce our debts." And then, the debts were reduced and this was of course the Trustworthy Computing Initiative. So, as a result of that, Microsoft assured its place in the future and the way it's been able to do things like move to cloud, where in the end they're going faster than ever and more securely than ever. So, this is exactly what Nokia at the business level failed to do.Mik Kersten (26:19):And the whole goal of the float framework is to provide this common language. The thing that, of course, the tech giants who have CEOs who were previously software developers already innately understand, but to make this more accessible to our business leaders and to come up with a common language and framework between the technologists and the business leaders. And so, I'll just give you a really quick overview of that. This idea of the flow framework is that you've got this flow distribution and you're measuring for flow metrics. How many of each of those flow items you delivered for a sprint, a release, a year and so on. The efficiency of that delivery, because we can measure that in the value stream network. The time, how long it took for feature or a fix to get to market. And flow load. If you're familiar with [inaudible 00:27:03] book or Donald Reinertsen's work, we know that putting too much load on the value stream causes things like burnout and actually decreases productivity. So, we've got a measure for that.Mik Kersten (27:12):And the key thing is you do this for each value stream. You don't do this for operations, you don't do this for one feature team, you don't do this just for a scrum team. You do this for a value stream, which tends to be bigger than feature teams. And you correlate that to business results that have to be specified for that value stream. So, those business results can be revenue. If it's an internal product that you're doing that, the internal product value stream such as an internal developer platform or API, that can be an adoption metric. You measure cost, but you measure cost for the value stream across all the different specialists involved in building up the value stream. You measure quality and you measure happiness, but you measure happiness with measures like employee net promoter score for all the people working on that value stream. Because then, you'll have an early warning indicator that if you put too much load on one set of teams, you could cause them to burn out and cause developers to start leaving because they're so miserable or you didn't give them the chance to reduce technical debt. So, this is just a high level sense of the flow framework, and this is how you'll get to end of life all those products, project management, things go on forever. If you see business results dropping while you're adding more features, maybe it's time for that thing to die.Gene Kim (28:21):Gene here again. In our careers, we have all run into these zombie projects or zombie services that just keep going despite no one actually wanting them, no one actually wants to pay for them and it just saps the time and energy of our most precious and most talented people. Mik describes how project management processes, portfolio management processes, especially for shared services in a cost center, are often what props these things up, keeping them from dying a natural death. I think Mik's point here about how everything needs to be measured towards a business result, whether it's revenue or it's productivity that enables across the organization, it must be measured. Mik will talk later about the zone management metrics, which he and Peter Moore discussed in episode one. These metrics, from the book A Zone to Win, provide awesome metrics from value streams, depending on which zone they're in.Mik Kersten (29:08):And on top of this, we can layer on these metrics that are covered in the books such as flow efficiency. So, for example, we measure end to end flow time, rather than again, just looking at development cycle time, where code commit to code deploy. We really need to take the customer's perspective of flow, which has to do, of course, with the end to end activity ever since that feature was submitted, that defect fix was submitted, we measure there. And we can create these dashboards using those flow metrics. The key thing being, those dashboards are all for each value stream, so you've got this level of visibility. This won't tell you if you bring the right features to market, but it'll actually show you when you've got a bottleneck, when you've got one of your time thieves, such as too many dependencies between a value stream slowing a single one of the value streams down. So, the question becomes how can we do this? And how can we really go from silos and proxy metrics to this connected value stream network that we can measure, that we can optimize-Mik Kersten (30:03):Through this connected value stream network that we can measure, that we can optimize, that we can manage and that we can see. And the idea here is that you basically take all these different tools and create a tool network out of them. You stop thinking about individual tools. You create this abstract model on top of that, that you can actually measure and you can measure cross to form on that model. We call this the artifact network that sits on top of your tool network. You can then measure flows across that network and you can measure those flows and map them into your product value streams, and measure those product flows and those product value streams.Mik Kersten (30:36):So you can go from this waterfall world of projects, where again, you're assuming that you know exactly what you should be living for years on end, to this flow orientation, but measure the results of that flow orientation. You can go from this world where everything has to be specified upfront to what some very innovative companies, including tech giants are things like what we're doing at Tasktop, which is you do create a product development budget, but you allow the reallocation of budgets between product value streams on a much shorter timeframe than a year so that you can adapt to your market for wherever you are getting those business results.Mik Kersten (31:11):And of course, this key thing is that you stop bringing people to the work, you bring work to the people. So you allow those teams to form stable value streams that are bigger than just feature teams. Feature teams are a great start, but you give the entire value stream, the ability to have autonomy, mastery and purpose, and you allow them to set the flow distribution. Those teams, the product value stream teams will know when they should reduce more tech debt, for example, to reach your North star, whereas where they should run faster on feature delivery.Mik Kersten (31:40):So just as a really quick example of how we do this at Tasktop because the flow framework has absolutely changed how I look at managing software delivery. Of course, we just connect our valleys from network. We've got all our customer requests, similar to BMW, where they're coming in from customer orders. Ours are coming into Salesforce, going into product management tool with target process then to Jira, which is connected to contractors Jira, then to our service desk and so on.Mik Kersten (32:03):But we've got this abstract model on top of that, and we can measure that model. So here's an example of a live dashboard they look at on a weekly basis. And what you can see here across these different product value streams, have got almost a dozen of these is that you've actually seen something I did wrong. And I blame Dominica [Degrande 00:32:24] for joining Tasktop too late.Mik Kersten (32:25):I set a North star a year ago of feature delivery because I knew the more features we delivered, the more successful this new product would be. So I actually put this on the strategic plan for the company, which means that some people in management were bonused on this. But I did that deliberately. I knew we would pick up some more technical debt and that we would then pay off that debt once the product had succeeded in the market.Mik Kersten (32:51):You can actually see that green bar just above this red box. There was a lot of flow load on this team, and there's a predictable rise in debts and defects, of course, and we had to do more defect work and it took more time. So I understood that was going to happen. I did not quite predict how much that flow load would affect the happiness of this team and the fact that I'm not even sure we communicated to them, that they'd be able to reduce it at some point in the future, even though we were thinking it, and this actually, this became a real problem, but now I can now see the problem.Gene Kim (33:23):That story that Mick just told, shows us how they deliberately pushed on features. But as a result, the team happiness level dropped significantly. I asked Mick about this and what he told me was that upon reflection, his mistake was not communicating clearly to the team that there would be time later to clean up all the technical debt that had been created. I love this example because it shows us the cause and effect relationships of decisions we make and the outcomes that we get in return. Back to Mick for his second story.Mik Kersten (33:54):I could also see that the team who was unhappiest the year before, who actually were given the time to rearchitect their continuous delivering and their entire test infrastructure is now the happiest team. And so being able to see this, this is fine when you're like us, and I'm looking usually at six of these, imagine this across the portfolio of hundreds of internal and external products, this becomes a really big deal and a really important tool.Mik Kersten (34:18):So my advice to people kind of more on the business side is ensure that you're defining this product portfolios and these product value streams, and that the metrics are being tracked and empower the delivery teams themselves to allocate flow distribution. They're the ones who know when they need to reduce tech debt. You just need to listen when they need to be given that chance. And again, this is why we need a common language. This is why the leaders of the tech giants, no one to listen to their delivery teams.Mik Kersten (34:46):Sometimes you'll actually need to do things definitely to hit a North star. For example, you might need to do a major risk reduction, a major investment and things like GDPR. And you need to accept that's going to take away from the flow of say, feature delivery. To technologists, create your value stream network by connecting all those tools. Again, abstract over that tool network, define your value stream architecture. This is as important as your software architecture. That's probably one of the main things I've learned.Mik Kersten (35:13):And then use those flow metrics to identify bottlenecks. You can then dig in and see, okay, is the problem that this team is actually ... Their testing pyramid is inverted, is the problem that they haven't ... They've said they've done it, but actually not done, their CIC pipeline properly. This will be your early warning signals or you'll look at where to extract the platform because everyone's got dependencies on this one internal component or team.Mik Kersten (35:37):So quickly, the idea is that we go from project and cost centers to these product value streams, from silos and proxy metrics to flow metrics and business results, fragmented value streams, this integrated value stream network. And so the book will launch on November 20th, I'll be signing some copies of the book tomorrow. We're trying to document some more best practices around this at flowframework.org, or you can follow the book on projectproduct.org. And then the main ask I have is that Jean and I have been trying to understand how best to present this to CEOs, to our boards, to our executive teams so they can understand where to invest in helping make us all successful in bringing our companies through the turning point. So Jean had that cool idea of those system dynamic diagrams that you saw. If you have any ideas how we can better presenters to your organizations, please get in touch and let us know. And thank you very much. I hope you enjoy the book.Gene Kim (36:33):In our next episode of the IdealCast, is my extraordinary interview with Elizabeth Henderson, who has profoundly influenced my thinking on so many different topics over the years. It's difficult to overstate how much DevOps handbook was influenced by her, as well as the Unicorn Project, among many other things. She is a software engineering leader and she's the author of the book, Explore It: Reduce Risk and Increase Confidence with Exploratory Testing, which is really a book about technical excellence and mastery in creating effective feedback loops for everyone. Most recently, she served as the VP of R&D in charge of all of Pivotal's big data products.Gene Kim (37:10):This podcast was brought to you by IT Revolution, and here is their latest news from publishing the terrific Agile Conversations book by Douglas Squirrel and Jeffrey Fredrick was launched on May 12th, available wherever fine books are sold. And from events, the DevOps enterprise summit London is going virtual, same dates, same times, same great people and same great speakers with the format changing to take advantage of the virtual format.Gene Kim (37:35):And by the way, I wrote an article called A Love Letter to Conferences, where I wrote about my most meaningful conference experiences, trying to understand what made them great and what are universal and which ones can be changed in a virtual format. In the show notes you can find a link to that article as well as the link to 700 pictures I took over 10 years with my favorite conference memories. Thank you so much.