The very first time I used anything resembling an agile method was in the early 1990s. Our team of ten decided to attempt staged delivery on our next medical instrument project. We were motivated not by changing requirements (which were pretty rare), or a need for speed, but by a desire for higher quality and predictability. We thought the “smaller bites” of staged delivery would encourage adequate time for design while making it easier to predict what we could finish by the next trade show.
Staged delivery breaks the features into several groups and builds each group one at a time. This was a radical change from waterfall, but it wasn’t anywhere near today’s Scrum or XP. We didn’t have standup meetings, the stages were different lengths, the product was not shippable until close to the end, we didn’t accept new feature requests in each stage, and we kept right on writing all our usual documentation. Our “continuous integration” consisted of simply building the software from source code once a day.
Despite all these missing pieces, our staged delivery was a resounding success. There was adequate time for design, and we accurately predicted the true end date about halfway through the eighteen-month project. On our previous projects, we didn’t have a clue about the end date until the project was more than three-quarters finished. The upper management was very impressed, and staged delivery was adopted by other groups in that organization over the next couple of years.
In my next workplace, waterfall still reigned supreme—until 1999 and the “dotcom” boom. Waterfall simply couldn’t cope with this new, fast-moving market. We explored adaptive methods and evolutionary delivery and XP, trying out various combinations on our many short projects. I was puzzled to find that according to the books I was reading, our staged delivery at my last job years before shouldn’t have worked. We had left out practices that were labeled as absolutely necessary—yet I’d seen very positive results. I couldn’t explain this. Were we just lucky? As time went by, I grew more and more dissatisfied with the explanations of why agile worked, not to mention the ever-growing lists of necessary practices. I watched teams adopt all the practices and still struggle, and I couldn’t explain that, either.
In 2009, I was introduced to a different way to look at the flow of work in a project, one borrowed from mechanical engineering and known as “Second-Generation Lean." Suddenly, a light went on. This view explained why our staged delivery had worked! Not only that, but I could also see why some of the other agile projects weren’t working—and what could be done to fix them. It was like getting my first pair of glasses, when I saw individual leaves on the trees across the street instead of a green, fuzzy blur.
So what are these magic glasses? Start by taking a systems view: seeing the whole development system at once.
Imagine your development organization as a machine turning ideas into saleable stuff. The ideas move through a series of activities, with waiting areas, or queues, between them. I think of the work as little boxes or chunks moving through the activities and the queues. (See Figure 1.)