Whenever I present Scrum courses or coach new Scrum teams, one question keeps popping up: when do we develop the architecture? That's not an easy question actually and there are a few different strategies you can employ. Here are the four approaches I generally propose:Big Architecture: This approach requires that the architecture is fully developed up front before any development starts. This “big-up-front-design” approach is what's generally done in the waterfall method where the architecture is agreed upon before any coding starts. The actual coding of the requirements is still done in iterations, but in accordance with the architecture designed up front.Planned Architecture: Instead of creating the entire architecture up front Scrum teams often just build a strawman architecture in one of the first few sprints once they have a good enough idea what will work. So, while the entire architecture is not planned up front it is still laid out in broad strokes for the team to realize during the actual iterations.Organic Architecture: This is the most fluid approach where the architecture is "grown" as the team goes along. This is particularly valuable when there's no real way to know what architecture will work and it has to be discovered along the way. This may lead to false starts and often result in architecture changes with code being discarded. Most flexible, most "agile", but perhaps the most expensive. This will likely not work when the solution has to integrate in an large enterprise with other systems.Separate Architecture: In this approach, the architecture is designed by a separate team before the project starts and the Scrum team simply follows it. Large-scale enterprise systems often use this approach. It's the most controlled and least agile but often necessary to keep architectural integrity across an enterprise.

For small projects, I prefer the organic architecture approach, but even then I spend a few hours or even a couple of days mapping out the architecture in my first sprint -- I consider that to be part of good planning. Remember, agile and Scrum doesn't mean "no planning" -- instead it's about planning enough to know where you are going without wasting time planning things that you can't plan and making plans that you know are meaningless. It's all about meaningful activities.

If you haven't joined my exclusive (and free) Membership Circle you are missing out on getting access to premium content only available to members. So, join now...

And, as always, please share this article with your friend and colleagues.