Every time I hear someone state the evils of Big Design Up Front I cringe.
Mockup Provides Early Glimpse of new Space Exploration Vehicle is but one of 100's of examples of how agile, adaptive projects deals with emerging requirements. I work at one of the contractors currently assigned a Phase I Trade Study contract for the emerging requirements for manned space flight to the moon and beyond. This is a very high ceremony environment, complete with CMMI Level 3 IPPD processes.
But no one in their right mind would consider Big Design Up Front as a viable approach for this multi-billion dollar project. It would be simply nuts to approach the problem in that manner. So two questions:
- Why do IT and software development project still consider this viable?
- Why doesn't agile development stop beating a dead horse and move by contributing their "golden" ideas in domains that are receptive to their concepts?
Maybe it's time to remind everyone of the "Dead Horse Management Strategy." Dakota tribal wisdom says that when you discover you are riding a dead horse, the best strategy is to dismount.
However, in business (or software development processes) we often try other strategies with dead horses, including the following:
1. Buying a stronger whip.
2. Changing riders.
3. Say things like, "This is the way we have always ridden this horse."
4. Appointing a committee to study the horse.
5. Arranging to visit other sites to see how they ride dead horses.
6. Increasing the standards to ride dead horses.
7. Appointing a tiger team to revive the dead horse.
8. Creating a training session to increase our riding ability.
9. Comparing the state of dead horses in today's environment.
10. Change the requirements declaring that "This horse is not dead."
11. Hire contractors to ride the dead horse.
12. Harnessing several dead horses together for increased speed.
13. Declaring that "No horse is too dead to beat."
14. Providing additional funding to increase the horse's performance.
15. Do a Cost Analysis study to see if contractors can ride it cheaper.
16. Purchase a product to make dead horses run faster.
17. Declare the horse is "better, faster and cheaper" dead.
18. Form a quality circle to find uses for dead horses.
19. Revisit the performance requirements for horses.
20. Say this horse was procured with cost as an independent variable.
21. Promote the dead horse to a supervisory position.
The Idiom of "beating a dead horse" is flailing at a dead or useless idea. Let's move from the BDUF as the wipping boy for why software development doesn't work, irregardless of how many example of really bad management their are. If you're dong BDUF, you're dead and don't know it.
