The Magical Number 30
In agile processes, especially Scrum, 30 is a magical number. A working product increment should never take more than 30 days to produce. The reasoning, which is sound, is that you’ll know exactly what state the evolving product is in quicker than you normally would under a “traditional” process. You can then decide what to do next before expending more resources.
The trouble I have with this 30 day “law” is that not all requirements/user-stories/function-points/”shalls” are created equal. Getting from a requirement to tested, reviewed, integrated, working code may take much longer – especially for big, distributed systems or algorithmically dense components.
Arbitrarily capping delivery dates to a maximum of 30 days and mandating deliveries to be rigidly periodic is simply a marketing ploy and an executive attention grabber. When managers and executives accustomed to many man-months between deliveries get a whiff of the “30 day” guarantee, they: make a beeline to the nearest agile cathedral; gleefully kneel at the altar; and line up their dixie cups for the next round of kool-aid.
Leave a Reply
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 
I have finally gotten it through my thick head that most people don’t know what the hell they are talking about or they would keep their collective and individual traps shut.
What they want in 30 days and what you think they want in 30 days can never ever be the same thing as hey don’t have a clue while you have been beaten senseless multiple time by the clue stick.
Give them what they really want. Anything! Quickly! So you can sit back and work on the product they need. Most people want a frontend and they don’t care if it’s hooked up to a hamster on a wheel on the back end much less if it works or not. Give them something pretty to look at and mumble at best and be vague and deflective at worse when they ask questions about anything but the pretty picture.
This may sound like madness but it is in fact a recipe for everything that doesn’t work (or was that implemented?) to be called a bug. So that the simpleminded can let you work on those bugs (proper SD) now that they have their pretty picture.
Nice strategy – give ’em something to chew on to get ’em off your back for awhile.