Do complex projects need design up front?

“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.

7 thoughts on “Do complex projects need design up front?

  1. Pingback: Do complex projects need design up front?

  2. Ryan Cromwell

    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.

    Reply
  3. Angela Post author

    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

    Reply
  4. Ryan Cromwell

    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.

    Reply
  5. Saranya Sasidaran

    Hi Ryan,

    Please help to understand that whether up front can be used for desiging an entire agile project…?

    Reply
  6. Akinyemi

    3.17Awe;r; yjbqy;3q j54;jtlqkwu kwya’erak ;wkly ;kae’ykt’;raj yq’;lrk akh’ar;tky ra;ky’aky’ ;akyh’akry’ ;k’r;kt’ rk’ kty’q;k’ra k’;aktWill you recommend?: yesDid you find this rievew helpful?

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>