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 document 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 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 code that is handed to resting. 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 or 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.