When does design happen in agile?

Someone at work, new to agile approaches, asked me
about when agile projects do design. I thought I would share my answer in case others were still wondering, and to try and explain where experience may have lead to us activities that are not textbook.

The short answer is ‘all the time’ and
‘just-in-time’. The long version is ‘all the time’ in that we are always
thinking about design during story gathering, planning etc. which is why you
want as many people on the team involved as possible. When we say ‘just in time’
we mean that we leave it to the ‘last responsible moment’. Of course the hard part is figuring
out when the ‘last responsible’ moment is. I like Alistair Cockburn’s model that the objective of any activity ins software development is to provide just enough for the next activity to take place. So we would tend to do just enough design to let us being development.

Being more concrete: 

  • Agile projects do
    design through TDD, so called emergent design or incremental re-architecture.
  • XP supplements TDD with
    pair programming, so at least two people design everything.
  • XP recognizes that some
    design needs to be all team, and has an optional CRC path, in each iteration,
    for contentious design choices or complex problems.
  • Crystal does not mandate pair-programming,
    and scales to larger teams, so it has more ceremony. It’s not uncommon for a
    crystal project to model the core domain model up front.
  • Most agile teams
    recognize that there is a nebulous conception or inception phase when you gather
    user stories, organize and understand them, do just-enough modelling,  set up
    build servers etc. It is the great unspoken step of many agile
    methodologies.
  • We care more about the
    domain model when modeling than about the
    infrastructure. Early on I would never tend to model the infrastructure.
  • Any ‘up-front’ modeling, before coding, is high-level, not low i.e. we care about classes, roles,
    responsibilities, and collaborators, but not attributes, methods etc. I tend to
    favour Rebecca Whirfs-Brock’s Responsibility Driven Design for this, and would
    consider this her Exploratory Design phase.
  • The conversation is
    more important than the artifacts the conversation produces. This is why CRC cards are great because the
    artefact is less important than the design discussion among the team and running
    the scenarios. You may produce a UML sketch of the system at the end, but it’s
    just an aide-memoir to the discussions, not a blueprint. It is also why design
    needs to be ‘all-play’. We don’t want to punt documents over the wall to
    developers, we want them to be involved in the activity of design from the
    beginning. That way the documents don’t inform, they just record the discussion.
    That’s what a document is after all.
  • CRC cards also work well because they have feedback – running through scenarios. We tend to divide up the cards and throw a ball between participants as the system calls their classes act. That means you get some testing around your design as you do it.
  • Remember that you are
    looking for ENUF, just enough design to make the next step, development,
    possible. If you end up throwing away too much of your initial design when you
    get to coding you have created waste, which we are trying to avoid, so don’t
    push this exploratory design step too far. Just do enough to answer the key
    questions
  • Be proportional. If you
    have ten user stories you may not need much of a conception phase. If you have
    two hundred you may need more.

The N-Tier with LINQ posts almost finished so should be out in the next few days. There is really only one post in the series after that, then we will move on to looking at hard-to-test areas in TDD.

About Ian Cooper

Ian Cooper has over 18 years of experience delivering Microsoft platform solutions in government, healthcare, and finance. During that time he has worked for the DTi, Reuters, Sungard, Misys and Beazley delivering everything from bespoke enterpise solutions to 'shrink-wrapped' products to thousands of customers. Ian is a passionate exponent of the benefits of OO and Agile. He is test-infected and contagious. When he is not writing C# code he is also the and founder of the London .NET user group. http://www.dnug.org.uk
This entry was posted in Agile, Architecture, Object-Orientation. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Alex Worden

    I think more fundamentally this is where we see a difference in human beings. The frontal lobe of the cerebral cortex is responsible for planning and is recognized as one of the latter developments of evolution. It is what separates us from many animals and I believe a majority of humans among us do not have these developed planning capabilities. Agile methodology is a reflection of this. It’s all they (agile coaches especially) understand, and their majority consensus is forced upon the rest of us. They make a career of telling people how to build software, when they’re never actually done it themselves – or they tried, failed, and became an agile coach. Hell, you’ve got to pay the mortgage right? They’re definitely the ‘chickens’ in the ‘pig and chicken’ agile fable, and they should be encouraged to ‘get out of the room’.

    It’s fine if you want to build lowest-common denominator products, but agile makes no provisions for the creation of true quality products, let alone revolutionary innovations. I like to use Google Search as an example. “As a user, I want to type a search query into a box, hit Search, and get search results”. Now go implement that story… do you think you’re going to get Google quality search results from that? It gets worse when you have many complex user-needs resulting in many stories that are implemented by 10’s of developers independently. Imagine building a house without a blueprint and just letting everyone build their ‘feature’ as quickly as possible.

    Sure, your user-needs will be met, but you’ll end up with a slow, inefficient, sub-standard product that will involve a lot of virtual duct-tape and will not stand up over time… unless you have a few genius developers on the team that will do design DESPITE the agile process. This sadly is often the case. They’re not recognized, and not rewarded, and move on from project to project, leaving a mysterious trail of successes that make upper management scratch their heads wondering why some agile projects succeeded while others failed.

    There is no replacement for a plan, and for that, you need to acknowledge and make room for up-front design. Even a badly formed plan is better than no plan at all.

  • http://elrypvkx.com/ Wgrwlcrs

    xgFKi3

  • http://jordanbortz.wordpress.com Jordan Bortz

    @Ian

    Possibly — however, using the “Do the Simplest thing that could possibly work” and YAGNI principles, both hallowed ground among the agile crowd, practically guarantees one will do much more refactoring than necessary.

    Sometimes requirements change, sometimes they do not. Sometimes they change subtly, sometimes they change drastically.

    I believe there should be mechanisms in place to allow for changes, but I also believe that developers should do more design and requirements gathering up front, which will prevent many needless refactorings from occurring…

    Jordan

  • Ian Cooper

    @Jordan Well emergent design is a part of what is overall known as incremental re-architecture. Experience should tell us that we don’t tend to get the design right first time around, often because we did not get the requirements right initially, but sometimes because the technology does not behave as expected. While we can mitigate, by using user stories for requirements gathering so that we keep asking, by spiking technologies, by running CRC card sessions to walk through a potential design, there will always be surprises and revelations.

    TDD helps us get to many of those ‘revelations’ early by putting the stress that usually causes them to appear, satisfying test criteria up front, so that we hit issues early. This is particularly good at making sure our code meets requirements.

    Being pragmatic we need embrace the fact that even that may not be enough, but fortunately our tests allow us to refactor easily, so that we can be amenable to changing our architecture.

    The point that your application will change for new requirements post its first release, coupled with the fact that you cannot predict what those changes will be (many will be unanticipated domain changes) and that a system spends 90% of its life in maintenance mean that you need to accept that your architecture will change, and you should be in a place that lets you do something about it.

  • http://jordanbortz.wordpress.com Jordan Bortz

    This “emergent” design stuff that has been bandied about for so long is horribly inefficient.

    Now people should be in acceptance of refactoring their SQL Schema, Stored Procs, Entity Models, and Domain Layers just because they wanted to start coding right away?

    Doesn’t make a lot of sense to me; design a little more up front and you’ll have a lot less refactorings to deal with….

    Jordan

  • http://blog.troyd.net Troy DeMonbreun

    Love this article! Thanks for addressing a nebulous subject that is very rarely addressed by Agile practioners.