Key Takeaways
- Many organizations face a transformation crisis as they adopt new ways of working without seeing the promised benefits
- Technologists and business leaders continue to speak different languages and are failing to bridge the communication gaps
- Agile and DevOps are approaches which point in the right direction, but they don't go far enough - more is needed
- Project approaches are not applicable in the rapidly moving world of product development
- Project to Product introduces the Flow Framework™ as a means of addressing this problem by bringing the three ways of DevOps, flow, feedback and continual learning, to the organization as a whole
Dr Mik Kersten has published a book titled Project to Product in which he describes a framework for delivering products in the age of software. Drawing on research and experience with many organisations across a wide range of industries he presents the Flow Framework™ as a way for organisations to adapt their product delivery at the speed of the market and adapt to rapidly evolving customer, market, legislative and societal change.
The book can be purchased here and InfoQ readers can access a sample chapter here.
Mik spoke to InfoQ about his ideas.
InfoQ: Why did you write this book - what is the problem you are addressing?
Mik: Many organizations are facing a transformation crisis. Directionally, everyone knows that the ways of Agile and DevOps are the right path. But the business is not seeing results other than in small pockets, culture keeps getting blamed, all while technologists and business leaders speak very different incompatible languages. Project to Product takes the point of view that both sides want to succeed. They each want their organizations to thrive and remain relevant through the disruption that has more and of the world economy going to the tech giants. The problem is not the willingness. The problem is that these organizations are using the wrong approach. Project to Product introduces the Flow Framework™ as a means of addressing this problem by bringing the three ways of DevOps, flow, feedback and continual learning, to the organization as a whole. To do that, we need a new language that spans the gap between business and technology.
InfoQ: Who is the book for - who should read it?
Mik: : The primary audience for the book is business and technology leaders in large organizations whose success is dependent on their software delivery. If you are already satisfied with the speed, quality and visibility of your how you build software, this book is not for you. But if you see a better path for your organization, and feel that existing approaches are not moving you forward fast enough, the Flow Framework™ in Project to Product is something that you should look at.
Note that by leaders, I am not referring to managers alone. Project to Product is meant to be just as relevant to an individual contributor who sees a better path for their organization’s approach to software delivery, and is frustrated by the inability of the organization to support those efforts. If you fall into that category, I hope that the book reinvigorates you and provides you with a new approach for seeking support for your efforts and vision.
InfoQ: You weave a story of visiting a BMW plant through the book. How is it that a motor vehicle manufacturer can provide inspiration for changing the approach to building software products?
Mik: The BMW Group story came from my visit to their Leipzig plant. I witnessed the focus on flow and product value streams which connected the business and production with an incredible efficiency and elegance. I realized then that if enterprise IT organizations could exhibit even a fraction of this kind of product and flow, they could double the productivity of their software delivery. The BMW group takes an end-to-end and business value centric perspective on flow, and that’s exactly what every software and IT organization needs.
InfoQ: You say that many of the metrics that organisations use to show the progress of work and delivery of product are not useful - why and what are some alternate measurements teams should use?
Mik: Project to Product specifically calls out measure of activities as “proxy metrics”, ie, metrics that are not focused on outcomes. For example, the number of teams doing Agile, or the number of deploys per day are both proxy metrics. This is not to say that they are not useful to track. But they tell you nothing about whether or not you are delivering more value to your customers through the software you’re building. Worse yet, the theory of constraints tells us that if you are investing effort somewhere other than the bottleneck, you are most likely wasting your time. For example, it may be that your Agile teams are constantly waiting on wireframes, but you are failing to notice that you need to quickly staff up on UX designers. Project to Product introduces four end-to-end Flow Metrics to augment Agile and DevOps metrics and ensure that you have end-to-end visibility of what is impeding flow across your various value streams.
InfoQ: How can “flow” be a framework - what are the key elements of the approach and how do they link together?
Mik: It is a framework because it provides a prescriptive way of organizing and measuring your software delivery organization. The framework provides three layers, and a new organizing principle called the Value Stream Network which enables you to connect the technical tools, such as Jira, ServiceNow, Azure DevOps, and measure the flow of artifacts across the corresponding people, processes and tools.
InfoQ: How is this different from the ideas of Agile and DevOps which it seems to be building on top of?
Mik: The Flow Framework™ builds on the learnings of Agile and DevOps, and in no way replaces them. It dovetails over approaches such as Scrum and SAFe, which you can use to structure your approach to Agile delivery. It relies on DevOps and automation practices and tools being in place. But it is at a higher level of granularity, and intended to bring the gap between those practices and business planning and budgeting. One way it does that is by displacing the practice of Project Management as a way of managing software delivery. While its goal is to provide a new kind of visibility of software delivery, it does this in a way that is meant to put the power in the hands of the people doing the work on the product value streams.
InfoQ: You make a particular point that value stream mapping is not a particularly useful technique for identifying the sequence of handoffs in a software development environment, why is this the case and what is an alternative?
Mik: I actually think that the practice of value stream mapping can be applied to architecture. However, I do point out that attempting to create a linear value stream map of software delivery is futile. Software delivery is a collaborative and creative activity that is best represented by a network, not by the kind of batch handoffs that we see in an assembly line. Our product value streams look a lot more like an airline network, one that is resilient to interruptions at one node, but much more susceptible to problems with queuing and backlogs. That’s why I emphasize the need to focus on Value Stream Architecture to enable the optimization of flow and dependencies through this network.
InfoQ: Do these ideas apply outside of software product deliver?
Mik: Theoretically, some of these ideas could be applied to other highly complex and collaborative knowledge work activities. But I haven’t put much thought to that, my entire focus will continue to be helping the industry apply them to transform how software is built.
InfoQ: How dependant on tooling is this approach - do organisations need to have specific toolsets in place?
Mik: The Flow Framework™ is completely tool agnostic. You could use any of the dozens of popular Agile and DevOps tools out there to implement your Tool Network. You could use any Value Stream Management product, such as Tasktop or in-house teams to connect and inspect that network. The whole point of the Flow Framework™ and its concepts is that it has you thinking about a layer that is more abstract than the tool chain, and focusing on how you deliver the flow and feedback needed to enable your teams build great software.
About the Book Author
Dr. Mik Kersten spent a decade creating open source developer tools before realizing that programing was not the bottleneck of large-scale software delivery. Since that time, he has been working on creating a model and tools for connecting the end-to-end software value stream. He has been named a JavaOne Rock Star speaker and one of the IBM developerWorks Java top 10 writers of the decade. He was selected as one of the 2012 Business in Vancouver 40 under 40 and has been a World Technology Awards finalist in the IT Software category. Kersten is the editor of the new IEEE Software Department on DevOps. In 2018, Mik launched his book, Project to Product, introducing the Flow Framework™, with concepts to help drive software at the pace of organization's business.