I was reading a white paper over at Realization.com and a thought hit me regarding lean vs. conventional development.
Backing up a moment, perhaps I need to explain some of my reservations toward conventional waterfall development. I've always felt that projects driven by the waterfall approach are fear-driven - fear of the developer and fear of the development team producing something the business doesn't want. However, waterfall often times doesn't even protect you from that fear - market pressures exerted during the development phase are forcibly ignored by the project manager who is guarding against scope creep for fear of jeopardizing the previously committed schedule. This makes me believe my fear theory is wrong. Waterfall is also capable of driving specifications to the nth degree before development begins and many are outdated by the time they are saved in some godforsaken repository. Worse yet, waterfall taken to the extreme is capable of distilling context out of the specifications which can lead to developers making poor implementation decisions.
After reading the white-paper titled "What should multi-project operations focus on: Resource Utilization or Cycle-Time?" my entire attitude toward waterfall completely changed. (The link currently requires registration, but I'm asking the company to provide me a direct link.) The article states that the primary operating assumption in traditional, waterfall development is "not enough resources." That deserves repeating...
The primary operating assumption in traditional, waterfall development is "not enough resources".
Take a moment and consider the waterfall project. The entire process is usually driven by a master Microsoft Project template (or some other tool from that software category) where tasks are broken down, dependencies stated and ultimately resources are assigned - everything drives to assigning resources. The project manager's primary focus is getting and holding onto resources with every grasp of energy. Good project managers will protect their people from outside interruptions and getting time taken up by other projects - they are protecting their project. But what if their greatest battle is actually fighting the schedule they've created? I contend this happens all the time.
Going back to the Realization whitepaper, they state the traditional operating assumption is "not enough resources". They contrast this with a lean approach that states "reducing the cycle time of projects will increase overall throughput". They further contrast the differences by stating that traditional operations set aggressive resource utilization targets for the resource while lean operations set aggressive cycle time reduction targets to ensure that there is no room for Parkinson's Law in the project. This becomes clearer on how lean differentiates when you read Darrell's LSD principles. When you drill down on the approach you can see that waterfall projects are push-based while lean is pull-based. Pull based is fundamentally different and merits some discussion.
If you look at lean from a manufacturing standpoint and compare it to software - I see a couple of concepts that are critical. This whitepaper from Synchrono is particularly useful in this discussion from the first three pages by introducing the following concepts: the pacemaker and takt time. The pacemaker is the constraining resource (development) and all focus is directed on delivering continuous flow to the pacemaker. This continuous flow includes inputs such as specification writing, sample data generation and anything else that feeds into the development process. This continuous flow also includes the output - which is testing. Meanwhile, we also have the concept of takt time. Takt comes from the German language and means meter - as in musical meter. Takt time is the rate at which the market consumes the product coming from our pacemaker. In development terms, takt time is driven by testing. For this process to be effective, testing is continuously building the product, testing it and providing feedback to development with a 24 hour turnaround which is referred to as the heartbeat in lean terms. Now developers are receiving feedback immediately after coding and not waiting 3-4 months before testing gets involved. This takes the whole process a step beyond Test Driven Development - not replacing it, but further enhancing the quality of feedback to development.
Since we are no longer driving off of a static schedule and development is pulling tasks to be completed based on triaging the highest priority issues we can see a number of capabilities that play to Darrell's points mentioned earlier. We can now "decide as late as possible" since specifications can be written at the last possible moment provided they don't violate the continuous feed to development. The longer we wait on specifications, the better those specifications will be by adjusting to realities such as market shifts during the development process. Here's the best part, I can now respond mid-cycle to a new requirement! New specifications can be driven to completion and prioritized on development's "to-do" list and handled in the normal process - it's simply a question of evaluating the size of the task and deciding when it needs to be released. As opposed to waterfall, the entire process and schedule doesn't need to be rebooted to accomodate what was formerly considered a major interruption. Finally, if I need to push the project out sooner based on customer requirements, I can choose an arbitrary cut-point at any time and deliver the product with minimal interruption. In reality, the concept of "three-month cycles" or "six-month cycles" are now truly arbitrary and have no meaning/value beyond the marketing/planning benefits because development is now focused on a 24-hour cycle.
I previously posed the question "is Lean just a rehash of Agile?" I believe the answer is a resounding 'no'. While Agile&XP focus on making changes starting with the programmer, lean focuses on the management process and drives down to the programmer. Lean cannot exist without Agile/XP approaches while Agile/XP can become much more effective with Lean.
There are a number of traits you have to consider in a product used to drive this project such as managing sequential processes (called gating). A gating capability can even allow you to coordinate multiple projects under one plan (try doing that on a complex project set using MS Project!). There are also architectural issues that must be addressed along with programmer skills. I'll leave those discussions for another blog entry.
Previous Topic
