When thinking about applying "lean" approaches to delivery of software projects, one easy but flawed analogy is to think of a manufacturing plant churning out s

When thinking about applying "lean" approaches to delivery of software projects, one easy but flawed analogy is to think of a manufacturing plant churning out some kind of widget. Say, we're manufacturing zippers. In the case of the software project, instead of delivering increments that consist of batches of partly assembled zippers, and handing them off to the next stage for bending or finishing or whatever, we deliver project increments brimming with new features, defect fixes, etc. In the case of the widget factory, you get many attempts at building exactly the same thing. In a typical software project, there's only ever one thing, and with each change in each increment, you're constantly changing the design and construction of that single, increasingly complicated thing. From this perspective, both the case studies of the Empire state building and the Polaris missile system are much better approximations of how incremental design and delivery work in software projects than the mental model of a factory churning out indistinguishable widgets. One can argue most floors in the empire state building are pretty similar, so experience gained while designing and building the 3rd floor can apply to the 53rd, and to some degree that's true. But if we mistake our floor building for zipper manufacturing and conclude this means we will be able to keep adding another 25 floors per quarter and extending the height of the building indefinitely, as we gain more and more experience at building floors, boy are we are in for a big surprise. The floors aren't independent, the project is to design and deliver a single system - the building - each increment during the project modifies that single thing. We'd better have some people involved who are thinking really hard about how the entire system is going to come together, what constraints the whole system is under, and testing our design and build assumptions.