One of the most influential books in my career was Peopleware by Tom DeMarco and Tim Lister. One concept in the book was the concept of flow state, being fully in the zone so that a problem or piece of work can be focused on and delivered. Flow maximizes the amount of value delivered. Demarco and Lister’s introduction to flow paved the way for my interest in The Flow Framework. Chapter 3 of Project to Product introduces the Flow Framework.
There are several critical concepts in this chapter. The first is the concept of value streams and value stream networks. Value stream decomposes the departmental view of a value chain into an activity-level view of the flow of work required to deliver a product. (Note: While Kersten does not conflate value chains, streams, and process maps, many people do, please read https://bit.ly/3aoTOfu as a primer). Kersten states “The role of the Flow Framework is to ensure that the business-level frameworks and transformation initiatives are connected to the technical ones.” Value streams map the flow of value through an organization. Knowing the path required to deliver value creates the environment for focusing on what really matters: delivering value in an integrated and consistent state. Identifying and mapping value streams is not always easy, yet failure leads to a failure to see and address bottlenecks, local optimization, and waste. Very early in my career, I worked in a firm that was sales-driven. We invested in the best technology for our salespeople and in marketing analytics. This worked well until we took our eyes off the ball of the logistics of picking, packing, and shipping. We could sell it but we couldn’t deliver. No one had an understanding of the value stream and each manager ran their department like a little highly optimized fiefdom. The end was not pretty. Everyone in the organization needs to understand the big picture so they can focus on end-to-end results. Before you “go agile” or transform, figure out your value streams.
The second critical takeaway for me in this chapter is the focus on measuring the flow of value from an end-to-end perspective. Kertsen’s flow framework measures the ultimate output rather than individual activities. For example, measuring (or counting) the number of releases or epics delivered may be important telemetry for dev-ops or a software development team; they are not reflections of the end-to-end flow of value. Measuring the flow of value for a whole value stream provides a framework for aligning everyone team in a value chain. Think about being able to understand whether the work you are doing is delivering real value rather than the vague impression you are moving in the right direction based on the pursuit of a common mission statement. As I have noted several times in the past, just because we are committed to the same set of words does not mean we have a common goal. Table 3.1 in the text provides an excellent breakdown of the four flow items and who pulls these units of value through the value stream. This is an excellent place to begin a discussion of what gets delivered and how it gets to that point.
A third concept is MECE (mutually exclusive and collectively exhaustive). While the idea has been around since the 1960’s, I was introduced to the idea during my first reading. Further reinforcement came from Kevin Goff during an exercise of classifying the types of work done in an organization. Classifications that are MECE reduce the possibility of double-counting observations and more importantly arguing over gray areas. The four flow items proposed by Kersten are MECE.
Chapter three could be summarized as “focus on the big picture and measure the end-to-end flow of value.” While it can be stated simply, we need to understand the nuances of those words.
Previous Entries:
Week 1: Foreword and Introduction – https://bit.ly/39gIt0A
Week 2: Age of Software – https://bit.ly/2XYvqyI
