How do you do architecture with SCRUM?

This is a hard one let me tell you. Before becoming a full time scrum master, I was a software architect full time. So when we had to work with user stories and translate them into code, architecture seems to have taken a back sit. However this is not true, architecture does not take a back sit in SCRUM in fact it is always there non-stop. Its not that architecture is not important - its need to fulfill the needs of the business and on its own its useless. So the business comes first, defines what we want and architecture is built all the time to meet the business needs - its on going and it never stops. I call it “just in time architecture”.  This is how it works:

The business drives architecture

everything needs a reason, you don’t just code it because you think its important. These can be looked as constraints of your system. For example you might have a constraint that you need to handle 1000 concurrent connections to your website, now this might affect how we build the site. There is a reason. We are not going to create a design that supports concurrency for fun. We are doing it because it is defined in a user story or constraint of a user story. Product owners don’t always think of constraints, so its your job to ask the questions. Do we need security? do we need concurrency? What kind of error handling do we want? A product owner that doesn’t really understand that will look at you funny and not understand. So make him or her understand. Give examples and give possible solutions. Provide choice so the product owner can make a decision.

But it still take a long time to code, so how do you present it in the backlog?

True. Even if the business gives you a good reason to do a framework that handles the needs, it takes time. It can even take more than a sprint. The solution I like to do is build it behind the scenes and build it by supporting real user stories. This way I get to validate my framework against real features. For this to work the stories need to be very very thin across the layers. For example, “add a user to the system”, might take a larger cost due to the infrastructure work behind it. Still, I only build the framework to add a user, not to delete a user and not to get a list of users. I keep my functionality limited to what I need and not beyond that. I expand my framework only based on new features that are required. This way I don’t build code that might never get used.

OK, but my kind of framework takes a long time to build  just to meet one story.

I would challenge that. You should be able to make stories small enough so some framework elements can be coded, and then add more framework elements when doing another story. If you still can’t around this idea - then lets have a use story that is a technical user story covering a technical feature. However technical user stories are bad and I only used them as a last resort. The reason they are bad is because product owners normally don’t understand them and therefore can’t properly prioritize them. So before you go the easy way out and get your product owner all confused with technical terms, see if you build your framework on the backbone of business need (or a user story).

Architecture never ends

You build your framework and design every sprint, every story. You make it better and better all the time. Its not just the first 3 months of development - its continuous and iterative. Within the development of every user story you might have tasks to improve the framework, and add features to it. Avoid at all cost big design up front, you will probably get it wrong because you don’t know everything yet. You will most likely not use half the stuff you build when doing big design up front. Design as you go, improve as you go. Think of building framework elements as tasks items to every story but not stories on their own.

Use patterns

Lots of pattern improve code and architecture - use them. Here are some of them:

IOC, AOP, DI, TDD patterns, BDD patterns and DDD patterns, (if you don’t know what this means start googling).

Use framework that are already done and tested

don’t reinvent the wheel and focus on the business needs and not the technologies. Unless you are a company that builds development frameworks, you should use what’s there and not re-build it.