Sadly there is a misconception that performing any up front design in an agile project is a bad thing… pretty much forbidden because the opposite of agile is waterfall.
This misconception misses the whole point of building great software… use all the tools you have at your disposal in the most appropriate way and if something is not working fix it. Agile is not meant to be a rigid process… it’s meant to be an attitude of continuous improvement. (Caveat, when you are first learning anything, stick to the proven process as you don’t know enough yet to know what is important.)
Right from the beginning of a project you are making major architecture and design decisions. You typically decide whether it will be a web application or a desktop application and you pick a programming language, you might pick an object relational mapping tool such as NHibernate or Entity Framework, you might even have a corporate standard for a database engine.
When you are making so many architecture and design decisions up front already, why on earth would you choose to ignore all the other information readily available at your fingertips in your design?
The premise of good design is to continuously strive to incorporate all you know into the application design while making the software as flexible to changing future requirements as possible. Six months into a project, you would not pretend you don’t know anything about the prior six months and only design the current story… the current story adds to the overall design.
The goal is to deliver as much business value as possible, as soon as possible, and then to continue to do so throughout the life of the project.
The key is how much time you spend on design and architecture up front and how far you go in documenting the results before you start building the application. Adam Kahtava covers this pretty well in “Big Design Up Front is Good“.
There are two situations in a new project:
- The entire project is fairly well defined.
- The project is very loosely defined or only the first part is well defined.
Let’s be clear… what I mean by well defined is that enough user stories exist to define the business functionality that is intended to be included in the initial scope as well as any major constraints on design or architecture. This does not mean fully architected, fully designed and fully documented (i.e. I don’t mean Waterfall), it’s more of a roadmap.
If the entire project is well fairly well defined then you can use the information available to you to whiteboard or rough in an initial architecture and identify any high level design issues, especially the ones that involve other applications. You don’t necessarily have to solve them up front. Create only enough artifacts (documentation) to meet your needs for communication or preservation of the thoughts. If your initial design is flawed, you may still need to redesign, but at least you did the best you could with the information you had. This is all anyone can ask.
If the project is loosely defined, then less up front design is possible and in fact, much of the early work will likely be more of a prototype in reality… it is used to flesh out the requirements and overall design. You will likely have to redesign extensively as requirements and the application evolve. Hopefully your code has lots of automated tests so you can facilitate major refactoring.
Make no mistake, design starts at the beginning of the project and continues throughout.
Great software comes from those who can do good design from the start, improve it as they go and are willing to change things when necessary.
