I got my book as a "new" copy from Amazon.com, so I am not sure what's up with the annotation? It's not my handwriting. In a previous blog article, I mentioned how I was getting back to my programming roots and reading The Principles of Product Development FLOW: Second Generation Lean Product Development by Donald G. Reinertsen. My plan is to review each chapter. Here is my review of Chapter 1, The Principles of Flow. The first chapter identifies the problems typically associated with traditional approaches to software development. Although many software developers can accurately estimate and measure the cost associated with developing software, few can do the same for the cost of delay. Having tax software ready for April 16 is very different from being late on something that has an arbitrary ship date. Development processes really need to include an understanding of the economics associated with not releasing on time. Having lots of designs in progress can lead to poor productivity. It is important to focus and drive tasks to completion. Customers do not benefit from 99 features that are almost done. They can only use what is completed, tested, and released. In an attempt to be as efficient as possible and avoid underusing their programmers, some managers make sure that developers have more to do than possible. This leaves no breathing room to respond to unexpected circumstances. Even though most programming situations are unique, many software development managers are hostile to variability and mandate software development methodologies that may not always be suited to the tasks at hand. Many software development managers value conformance to original plans and spend huge amounts of effort to get back to those plans, instead of leveraging the new information that has become available and devising new plans. Software development releases typically include a large number of new and improved features to leverage the economics of costs associated with the release process. Large releases take more time to develop, test, and release which reduces an organization's ability to be responsive to customers. To maximize organizational efficiency, things are done in batches rather than as they are completed. Here's the example from the book. In many companies, manufacturing wants to receive a fully completed design from engineering. They tell engineering that they don't want to see any engineering drawings until engineering has stopped changing the design. Once all drawings are ready, they are reviewed in one large batch. All 200 drawings are reviewed on a single day. Companies assume this makes reviewers more efficient because they can see the entire design at once. But these drawings were not completed in a single day. They may have been completed over a 10-week period. The first 20 drawings to be completed may have waited 9 weeks to be reviewed. What happened during those 9 weeks? If an engineer makes a bad assumption in one of the first 20 drawings, then that assumption will go unchallenged until the final review. Without feedback from a review, this bad assumption will be incorporated into 180 more drawings. [Page 10] Software development projects are typically managed by timeline milestones instead of managing the queues of work in progress of the software developers. One of the most effective ways to manage a software development project is to apply work in progress constraints; however, the nature of software development makes this harder to do than lean manufacturing projects. Telecommunication networks employ adaptive approaches that adjust to congestion to maintain phone call throughout even at peak demand, yet this approach is not often applied to resources, processes, and people when it comes to developing software. Although some software development projects control flow using first-in-first-out queues or individual feature profitability measures like a return-on-investment analysis, the best approach is to delay projects with the overall lowest cost associated with delay. Though many organizations rely on centralized project management control out of fear of "not doing so" leading to chaos, the operating principles of the United States Marines for dealing with the uncertainty of warfare (define the goal but not the means) are very applicable to software development. Based on these problems, Chapter 1 also foreshadows the major themes that will appear in the remaining chapters. Economics Queues Variability Batch Size Work In Progress Constraints Cadence, Synchronization, and Flow Control Fast Feedback Decentralized Control In theory, I guess I could take what I have learned so far and apply it; however, I want to see where the remaining chapters take me. This book is a very easy and enjoyable read. Anticipation regarding the principles of flow is alive in the lab.Go to the original post...