How does design get done on an Agile Project?

Last week I gave a talk at Agile Austin entitled “How does design get done on an Agile Project?”  The slide deck can be downloaded here, and, thanks to Chad Myers, you can watch the video feed on Viddler.  (There is content in there after I get done being hamhanded with the A/V stuff).

Major points and questions:


What do you mean there isn’t an Architecture Phase?  When does design get done?  All the time.  Continuously.  Design is too important for the success of your project to be restricted to a brief “architecture phase” anyway.  Design is all around us.  Design surrounds us, penetrates us, and binds the system together.  No seriously, design is happening.


Can this work?  Yes, it can, if you have good people with solid design skills who can also communicate their ideas and thoughts to others.  People are still the most important factor in a project. 


Who does the design?  Every single coder on the project.  Oh, your senior guys are going to make most of the decisions, but every single developer should be participating in the design and be able to explain the design.  Developers do much better with a design if they understand how it came about.  The best way to understand how it came about was to be there at its creation.  At a bare minimum, the worst developer on the project team should at least be a source of feedback for the design.  “This is hard to code this way” or “I don’t understand what I’m supposed to do here” from your junior most developer is still a sign that something might not be right with your design. 


Anyway, enjoy Chad’s camera work, and here’s some relevant links.



Is Design Dead? – Martin Fowler in one of the most quoted papers of all time

A Microcosm of Agile Design – but, but, but Web Services are easier than they used to be.  I don’t care if it’s easy to build a web service.  It’s still more mechanical work to build a Web Service than a library that runs in process with the rest of your code.  The automated tests run slower if there’s SOAP in there anywhere, the deployment is a bit more work, and it’s just more friction all the way around. 

First Causes:  Reversibility.  But it’ll be cheaper if we do it now!  We should just build the web service/caching infrastructure/generalization now while we’re in the code!  It’ll be harder later!  We have to get it right upfront, or all hell is going to happen.  All those fears are valid, but we can eliminate the cause for concern by paying attention to the reversibility of our design decisions.

“Code Complete” is a lie!  Done, done, done is the truth

The Last Responsible Moment – Make decisions at the right time.  Sometimes delaying a commitment to a design until you have more information is the best course of action.

Ordering Code Construction Tasks – Work vertically by feature!  Don’t schedule your development in terms of infrastructure or technical layer.  Everything follows from a business goal.

About Jeremy Miller

Jeremy is the Chief Software Architect at Dovetail Software, the coolest ISV in Austin. Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy is the author of the open source StructureMap tool for Dependency Injection with .Net, StoryTeller for supercharged acceptance testing in .Net, and one of the principal developers behind FubuMVC. Jeremy's thoughts on all things software can be found at The Shade Tree Developer at
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • The Question Guy

    Another question for your list:

    How do you maintain and document your design?

  • SteveJ

    First time I’ve gotten to see you speak. Pretty good, I enjoyed it. I’m working on internalizing the Last Responsible Moment right now. Currently I’ve got 12 or so decisions that need to be made but haven’t yet. I feel like I ping pong around on them, Can’t do A yet so work on B, can’t do B, so work on C, can’t do C, so work on A, oh wait, not ready for that either. Crap. Somehow I work all day, but I’m certainly not getting to done, done, done :)

  • Jeremy D. Miller


    Everything you said seems fine to me. I’ve found that doing Domain Modeling is a great way to learn about the business domain. I don’t really think that It’s that much of a design aid per se, but the learning is invaluable.

    As far as the exploratory design phase from RDD, I’d say that my preference is for a little bit of whiteboarding before starting any new type of user story. I wouldn’t call it a phase because it happens at any time.

  • Web Design Services

    Hi!! I have got some valuable information through your site.Thanks for some wonderful info.

  • Ian Cooper

    I agree with what you are saying.

    On a point of detail however.

    How do you feel about domain modeling at the moment.

    Crystal, especially on Orange and above, has a domain model as a requirement before coding begins. Of course the requirement is to do just enough to enable the next phase, to provide some insight into the domain that both development and customer can agree on. Eric Evans has made a similar comment around Domain Driven Design that sometimes to understand what the simplest thing is we have to do some up-front modeling of the domain.

    We regard this as Rebecca Wirfs-Brock’s exploratory design phase from Responsibility Driven Design. We tend to do some whole-team CRC modeling to try and create a shared understanding of the model before we begin coding. We don’t delve to attributes and methods. We don’t regard this as fixed in stone, but we do model. We drive from user stories, sampling them to understand what the domain should look like to meet these requirements.

    Looking at the slides (I’ll try to make time for the video later) is this your reference to modeling, but only whilst you are still learning?

  • Jeremy D. Miller

    😉 I knocked over a lamp at DevTeach Montreal from pacing back and forth

  • Chad Myers

    It was a great talk, Jeremy. Next time, I’m going to consider nailing your foot to the floor, though :) or getting a better tripod with a fluid mount