Principles Of Product Development Flow Summary
Algernon Alcala
This chapter focuses on understanding product development from an economic perspective. It emphasizes the importance of making decisions based on their overall economic impact rather than solely on proxy objectives like innovation or efficiency. The chapter introduces key principles and frameworks for quantifying the economic impact of product development decisions, highlighting the necessity of viewing these decisions through an economic lens for better profitability and efficiency.
This chapter delves into queueing theory and its application in product development. It explains how queues, often invisible in product development processes, significantly impact cycle time, costs, and overall efficiency. The chapter presents key principles to better understand and manage queues, highlighting the importance of balancing capacity utilization with queue size to optimize productivity and minimize economic waste.
This chapter challenges the conventional wisdom that variability in product development is inherently negative. It explores the economics of variability, demonstrating that while excessive variability can be detrimental, a certain level of variability is essential for innovation and value creation. The chapter offers a nuanced view, distinguishing between beneficial and harmful variability and providing strategies for managing and exploiting it effectively.
This chapter delves into the concept of batch size in product development, emphasizing its critical role in improving process efficiency and overall product quality. The focus is on understanding how reducing batch size can bring about significant improvements in various aspects of product development.
This chapter focuses on the application of Work-In-Progress (WIP) constraints in product development processes, drawing insights from both manufacturing systems like the Toyota Production System and data communication networks like the Internet.
In this chapter, the author delves into strategies for managing product development under conditions of uncertainty and variability, drawing parallels from traffic flow, telecommunications, and computer operating systems. The chapter explores concepts such as congestion, cadence, synchronization, sequencing work, and managing a development network, offering 30 principles for optimizing flow in product development processes.
This chapter focuses on the role of feedback loops and control systems in product development, drawing from concepts in economics and control systems engineering. It emphasizes the dynamic nature of product development goals and the asymmetric payoff functions, differentiating it from the more static and predictable world of manufacturing. The chapter is structured into five subsections, discussing feedback from an economic perspective, the benefits of fast feedback, control system design, the human factor in control systems, and practical metrics for product development.
This chapter delves into the concept of decentralized control in product development, drawing lessons from military doctrine, particularly the U.S. Marine Corps. It discusses the balance between centralization and decentralization, emphasizing the need for a blend of both to effectively manage uncertainty and rapidly changing conditions in product development.
Ready to elevate your product management game? Join our community of passionate professionals and be the first to receive exclusive insights, tips, and strategies directly in your inbox. Subscribe now to our newsletter and ensure you're always in the loop with the latest product management trends and wisdom bombs!
If you were looking into learning more about kanban and lean as it relates to software development projects, I would probably suggest you read them in the order I have listed above, with Principles of Product Development Flow following these. It is certainly the most advanced of the books. It also has the most to offer to any product-oriented business, and does a good job of debunking certain myths about lean as it relates to software development. Unsurprisingly, writing custom software without a script is not entirely analogous to manufacturing known goods using known techniques as quickly as possible. Reinertsen does a good job of demonstrating where and how lean manufacturing principles do not directly apply to software product development, and provides models and principles that can be applied with confidence.
Reinertsen suggests that when considering the optimal batch size, one should consider the U-Shaped Total Cost, as opposed to blindly believing that small batches are always better or striving for One Piece Flow (a nirvana of some lean approaches). Note too that these curves are merely examples, and that in order to apply this principle you must first understand the nature of the holding and transaction costs that apply to your process. You can also then work on changing the shape of these curves in order to lower your total cost, perhaps reducing transaction costs through automation.
Queue size multiplies the cost of delays. When we have 20 jobs in a queue, a 5 minute delay generates 100 minutes of delay time. When there are only two jobs in line, a 5 minute delay generates 10 minutes of delay time. You can apply this same logic to overloaded web servers, for which queued HTTP requests immediately result in massive performance degradation.
A key point in the variability chapter and the book as a whole is that small batch sizes and low variability are not universally desirable. Rather, there are economic payoff functions for each and cases where reducing batch size or variability can actually be the wrong decision, economically (which of course should be our basis for decision-making). When we do wish to reduce variability, one way to do so is by using principle V5, Variability Pooling: Overall variation decreases when uncorrelated random tasks are combined.
The Scaled Agile Framework (SAFe) is a set of organizational and workflow patterns for implementing agile practices at an enterprise scale. The framework is a body of knowledge that includes structured guidance on roles and responsibilities, how to plan and manage the work, and values to uphold.
SAFe promotes alignment, collaboration, and delivery across large numbers of agile teams. It was formed around three primary bodies of knowledge: agile software development, lean product development, and systems thinking.
As businesses grow in size, SAFe provides a structured approach for scaling agile. There are four configurations in SAFe to accommodate various levels of scale: Essential SAFe, Large Solution SAFe, Portfolio SAFe, and Full SAFe.
SAFe requires that companies put planning and reflection cadences in place at all levels of the organization. With these in place, everyone understands the current state of the business, the goals, and how everyone should move together to achieve those goals. By synchronizing people and activities regularly, all levels of the portfolio stay in alignment. Information flows both upward and downward in a timely fashion, unlike traditional top-down, command and control structures.
SAFe encourages trust-building behavior, including planning work in smaller batch sizes so problems can be surfaced sooner, providing real-time visibility into backlog progress across levels, and inspect and adapt rituals.
SAFe encourages people using the framework to apply systems thinking to three key areas: the solution itself, the enterprise building the system, and the value streams. Solutions can refer to products, services, or systems delivered to the Customer, whether they are internal or external to the Enterprise.
By default, designing systems and software is an uncertain exercise. This principle addresses uncertainty by bringing in the concept of set-based design, which calls for retaining multiple requirements and design options for a longer period in the development cycle. The set-based design also relies on empirical data to narrow the focus on the final design option further in the process.
Demonstration of an actual working system provides a better basis for decision making than a requirements document or some other superficial evaluation of success. Including stakeholders in those feasibility decisions early on supports trust-building and systems thinking.
When you apply this to software development, this means limiting the amount of overlapping work , the complexity of each item of work, and the total amount of work tackled at a given time. Small batch sizes allow for constant validation that work is headed in the right direction. And managing queue lengths ...
Agile teams naturally apply cadence through sprints or iterations. Creating a cadence for all possible matters reduces complexity, addresses uncertainty, builds muscle memory, enforces quality, and instills collaboration. Synchronizing these cadences enables the people and the activities to move like cogs in the wheel where learned information informs decisions and incremental planning.
Inspired by influential management consultant Peter Drucker and author Daniel Pink, this principle is one of our favorites! It's about unleashing the potential of teams and helping leadership take the perspective of coaching and serving their teams over a command-and-control mindset.
Reducing queue lengths and taking an economic approach by decentralizing decision making, gives teams the autonomy they need to get work done. Leaders should preserve their decision-making authority for topics of strategic importance and enable teams to make informed choices on everything else.
Scaled Agile, Inc. provides a SAFe implementation roadmap that contains detailed steps on how to get started and set up the organization for widespread adoption across portfolios. The 12 steps for implementing SAFe include:
Large-Scale Scrum (LeSS) takes a minimalist approach to roles, structure, and artifacts. Where SAFe offers four configurations to accommodate teams of greater and greater size and with increasingly complex solutions, LeSS offers two configurations: LeSS for two to eight teams and LeSS Huge for more than eight teams. LeSS also differs in its stance that product owners should have complete content authority and strategic influence, where SAFe encourages a more democratic approach. And while in SAFe many factors inform strategy, LeSS places an emphasis on a customer-centric approach focused on paying customers.
c80f0f1006