“Agile purists”, Bob Customer says, “don’t understand my reality. Nobody ever tells me how agile says we’re supposed to manage the overall architecture.” Without an orchestrated design process resulting in thorough design docs, how could we keep all the disparate pieces together?
What does Agile tell us about big projects with lots of little parts?
Bob, the best way to manage a large project is by continuous interaction between teams and between teammates while coding proceeds according to a work-in-progress-limiting scheme.
Skilled rhetoricians constantly invoke “painting yourself into a corner”, or “the local optima problem”, or they just sometimes jump out and say “BOO-GA BOO-GA BOO_GA!”
This scare-mongering is effective because we all know large complex software is risky, and we all wish we knew some way to make it safe. Architected projects are no more likely to succeed than un-architected ones. Two thirds of all large projects (>1 year), ship 6 months to a year late. The other third never ship at all.
Sometimes you just have to live with your fear for a while. Certainly, utilizing mechanisms that have never succeeded will cost you a lot without helping.
Don’t worry, though. Once you’ve nailed that first big project using agile technique, you won’t have to be scared of them ever again.