[The Turning Point of the Age of Software] is when businesses either master the new means of production or decline and become relics of the last age
Few notes and take away from this book:
- no formalized notion of value streams or measurement of how business value is delivered
- software value streams are not linear manufacturing processes but complex collaboration networks that need to be aligned to products
- the more staff, the more tools, and the more software scale and complexity, the worse this problem became
- moving from project-oriented management to product-oriented management is critical for connecting software delivery to the business
- importance of decentralized decision making and autonomy
- technical debt reduction if not done will result in the reduced ability to modify or maintain that code in the future
- features are positive and visible, whereas architecture improvements are positive and invisible
- ITIL defines the important differences between these problems, incidents, and changes
- the four flow items aka features, defects, risks, and debts provide the simplest and most generic way to unlock the black box of IT
- value stream is the way to connecting technology investment to business outcomes
- Moore’s zone management make explicit to each manager and teams working on the corresponding product allowed them to set the flow distribution and the talent and processes supporting the value streams, matching the business goals of the horizon or zone
- feedback gives the capability of connecting software production results back to business
- at its core, the end to end software life cycle is a business process that delivers value to end users
- if we put too much WIP on our value streams, queues build-up and the rate of delivery decreases
- the flow framework enables a data driven business case for lowering flow load in order to achieve higher flow velocity by surfacing those metrics for each value stream
- DeGrandis identifies three kinds of dependencies: architecture, expertise and activity based
- DeGrandis points to items such as technical debt and “zombie projects” as wasteful sources of neglected work
- cumulative flow diagrams also called CFDs
- We need to elevate the practice of software delivery by connecting today’s business leaders and technologists, and reducing that chasm, not broadening it. To do that, we need a common language that empowers both the technologists and the business stakeholders with the right kind of information to drive good decision-making for the business.
- The vast majority of enterprise IT organizations have no formalized notion of value streams or measurement of how business value is delivered.
- Productivity declines and waste increases as software scales due to disconnects between the architecture and the value stream.
- Software value streams are not linear manufacturing processes but complex collaboration networks that need to be aligned to products.
- We fail when we measure activities, not results. An IT team could be deploying a hundred times per day, but if their work intake is not connected to the needs of the business, the results will not materialize for the business.
- An important aspect of measuring revenue per value stream are the systems for tracking revenue, such as accounting and CRM. These systems need to be set up in a way to connect revenue results back to a single product’s value stream.
Value Stream Metrics
Thinking in terms of flow distribution trade-offs elevates the understanding of software-delivery trade-offs to the business.
If pressure from the business to deliver new features while fixing defects does not abate for several quarters, debt backlogs could get to the point where new-feature delivery will no longer be feasible.
Value Stream Networks
Either we undertake the kind of billion-dollar investments that the tech giants have undertaken into creating a unified tool suite or we need to connect off-the-shelf tools produced by vendors and open-source projects into a Value Stream Network.