“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?
GeePaw sez…
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.
4 Comments on “Do complex projects need design up front?”
You can track this conversation through its atom feed.
I'm Angela, by the way. There are lots of wonderful reasons for these studies; my favorite is because collaboration actually works better than coercion. If you'd like to know more about Agile, I'd encourage you to read 
This guy is an 
Do complex projects need design up front? says:
[...] the overall architecture.” Without an orchestrated design process resulting in thorough… [full post] Angela My Agile Education design 0 0 0 0 0 [...]
Posted on February 2, 2011 at 1:19 pm.
Architecture is a development task executed during your delivery process through collaboration with the rest of the team. Through refactoring and clean code we are able to evolve an architecture which meets the needs of each iteration.
This process certainly is, in a sense, an orchestrated design process that occurs in the context of delivery.
If your team decides design documents are a necessary deliverable for one reason or another so be it. Deliver them with the increment. Inspect on their usefulness as you otherwise would any activity in your process.
Posted on February 2, 2011 at 5:03 pm.
Hi, Ryan,
Thanks for answering my question. As usual, I’ve made assumptions in how I expressed it. Sorry about that.
By “big project”, I meant a project where the work of lots of different teams has to tie together. Does that change how you’d answer?
Angela
Posted on February 10, 2011 at 8:18 pm.
No I don’t believe it would change my comments. I would simply add that projects demanding cooperation between multiple teams require even more open and honest communication.
Collaboration and discussion is a form of orchestration. I believe teams should use the most effective form of design collaboration (UML, whiteboard, samples, entity diagrams, stickynotes, etc) for them to vet out the most appropriate solution to shared architecture. Implement, evaluate, adjust, and deliver. Focus on code clean and that collaborative architecture can bend and flow over time.
The smell I get from Bob’s comment is that the term “Orchestration” and “thorough” come with the baggage of dictation. The baggage of a one way conversation from an isolated entity often dubbed the Architecture Team.
Productive inter-team collaboration is very difficult. Mix in egocentric, opinionated, passionate developers (I fight these traits daily) and it gets that much more difficult. That said, the results of a well coordinated team can be awesome.
Posted on February 10, 2011 at 9:23 pm.