Grow And Fix
The figure below shows a series of “Grow And Fix” (GAF) cycles that models a software development effort. The gaps between each cycle represent external (to the team) deployment/usage/feedback periods. In practice, there usually are no gaps. After all, any upstanding org filled with managers who are paid to obsess over efficiency can’t allow for any idle machines between incremental releases.
Note that in the GAF way of doing things, the duration for producing a stand-alone increment varies from increment to increment. That’s because the GAF community thinks the act of arbitrarily setting T1 == T2 == T3 == T4 == T (like, say, T == 30 days) for every major increment is a pretty much stupid and dogmatic policy. As stated in the 16 page GAF user guide, the duration for each release is proportional to the breadth and depth of the functionality (f1, f2…. fx) allocated to the release.
In addition to the effort required for defining, creating and integrating new functionality into the growing system, the GAF method takes into account the effort required to “unbreak” existing functionality and to handle emergent, unexpected, behaviors that arise from function-to-function interactions (fix(f1,f2), fix(f1,f3)…).
For more detailed information on the groundbreaking new GAF methodology, including real success stories, endorsements, certification costs, books, T-shirts, hoodies, mugs, and upcoming community conferences, visit the GAF website. Enter the code BD00 at checkout to receive a 10% discount and free shipping on your first purchase.
Ha ha, Tony love your work. The photo hooked me in to read if you can believe that. Idle time between iterations, time to think and plan?! No way that will happen. AND one size does fit all. For the record that was sarcasm.
Thanks Jon. I like to have fun.:)
I’m sure someone out there has figured out a way to apply network theory to estimate or perhaps minimize function/module interaction complexity. Wonder what wonderfully catchy buzzword they gave the method?