Do-it, Try-it, Fix-it Cycles of Learning
/Another aspect of successful teams is their use of the "do-it, try-it, fix-it" cycle.
Slow teams typically spend long periods of time trying to "get it right" for fear of failing. Some corporate cultures tend to punish for failure rather than reward for success. They don't make the trade-off between long duration and that last 10% to make something "perfect." They default to getting it right over getting it done (soon). This model means that you had better be right at the end of the cycle. If you have to rework then this will take even more time.
This manifests itself in long product development cycles where products have to be right many years after they were first conceived, then (when released) fail to meet current customer or market needs since so much has changed. We call this the big-bang approach to product development. This is further explained in the "roughly right"post.
Fast teams on the other hand know that they need to generate multiple cycles of learning as fast as possible. This also has a foundation in the concept of early-prototyping where you try and get customer samples or engineering prototypes into the customers hands as soon as possible and use this feedback to incrementally refine the design while understanding customer needs. They know that the only way to continuously improve is to get through the "try-it, fix-it" cycle as soon as possible.
In the example above, the fast team gets three cycles of learning during the same time frame as the slow team who gets through one-cycle at best. Rapid incremental cycles only work in corporate cultures that reward experimentation and encourage a rapid failure/learning cycle. Is this not what good engineering is all about?
More on this subject as it is applied to scheduling in Best Practice 3.3..."They recognize that scrubbing replaces the 'mistake, fail, punish' cycle with a 'try it, fix it, recycle' learn cycle." This is a concept though that extends beyond scheduling and can be used as a general principle for how a good organization should behave.
Also see: