From User Stories to Architecture

This is the slide deck of a presentation I gave for bbv Software Services AG at two events in 2009 along with some comments .

If you are interested in seeing this presentation live (either in German or English) then please contact me.

In an agile project, the architecture has to evolve together with the requirements and the code. In this presentation, I’ll show you our agile architecture lifecycle.

But what is software architecture anyway? A bunch of UML diagrams? The structure of the software? How components interact?

Add your definition here!

From an agile perspective, architecture is the structure of working code. The architecture describes which systems the product is built of and how the system’s internals communicate with each other.

The important part is working. Architecture is always a model of reality (working code). Only working code gives us the feedback whether our great architectural ideas can be implemented.

I oppose this to…

… documentation.

Documentation describes what we think we have or what we would like to have. Therefore, never mistake the architecture description for the real architecture of your project. The real architecture is built from methods, classes, components and systems; not words, paragraphs and chapters.

Documentation is important to provide someone information about the architecture (for example the new one on your team). But the driver is always code, not paper.

Now, what is so special about agile architecture?

In agile projects, we do not have a big up-front analysis and design. Therefore the architecture underlies two main constraints: …

… incompleteness and change.

Incompleteness because the requirements are never complete and will change due to feedback provided by your customer on your progress.

The team will learn while developing. The team members will get better at using the technology used in the project and they will get a deeper understanding of the problem domain solved.

We always have an incomplete picture because we cannot anticipate every change that will happen during the project lifetime.

Change happens because requirements get clearer. During development, the team will ask questions to the customer to get a better understanding of the problem to solve. These discussions result in requirements that are more precise as the project goes forward.

Plans may change due to a changed business situation. If your customer’s competitor made a move then your customer may have to react and change the scope of your project.

In projects that take more than a year to develop, or during maintenance, technology will probably change. Take the .NET framework for example. There is a major update about every 2 years. Or the operating system changes (from 32bit Windows XP to 64bit Windows 7). Your architecture will have to take this steps, too.

Finally, people change. Either because they learn new things, simply change their minds, or they change teams. Your architecture has to take this into account, too. The architecture is no good if the team does not understand it or thinks it’s bad.

This presentation is not about how to get an architecture that can cope with all of this. There are principles you can follow, like…

… the SOLID principles by Robert C. Martin.

These principles help you to get an architecture that can technically cope with changes very well.

In this presentation, I focus on the process related things supporting the architecture.

We use Scrum as our development process. Scrum looks basically like this:

Red: Meetings, Green: Artifacts

The project starts with a Kick-off meeting of some sort. Before the first Sprint (an iteration in Scrum), an initial product backlog is built to get a rough understanding of what is to be built.

Development happens in Sprints. Each Sprint starts with the Planning Meeting to plan the current Sprint (detailed discussion of what is to be built). The result is the Sprint Backlog.

Each day, the team stands together for the Daily Scrum Meeting to get a picture of the current status of the project.

To get feedback from any stakeholders, the newly built parts of the project are demonstrated in the Review.

Finally, each Sprint ends with the Retrospective, which the team uses to find improvements in the process as well as in the way they work (for example tools).

Now, let me add our activities regarding the lifecycle of the architecture:

Let’s have a detailed look at the different actions.

After the initial product backlog is created, it’s time to start thinking about the architecture:

The granularity of the initial architecture depends a lot on the type of the project. It has to be clear enough to get the development team running, but it should not be too specific either.

Firstly, because we want to start producing working code as fast as possible to get real feedback as soon as possible.

Secondly, architectural design decisions at this early stage may be difficult due to lack of know-how on the problem domain. If something does not yet have to be defined, then I’ll defer the decision to build up more knowledge first.

Therefore, the initial architecture is “only” a guideline for the team, describing the project in a very coarse way.

The architecture will gradually be refined during the project as you will see.

Every Sprint, my team holds an architecture workshop. Normally, on the first or second day of the Sprint.

The main topic is to build team-wide common knowledge needed to implement the User Stories (and other Backlog Items) of the current Sprint. Note that the team will come up with questions in the Sprint planning meeting while discussing the break-down of stories into tasks.

This meeting also helps to have equally distributed know-how of the architecture; resulting in better designs in each developer’s daily work.

Finally, the team may come up with architectural problems that were identified in previous Sprints. Either the team can solve them in this meeting or a team member takes responsibility for actions during the Sprint (normally the architect, but can be anyone on the team.).

While the developers are working on the code, they gather feedback about the architecture: Can the new feature easily be integrated? Are there new insights that lead to changes of the architecture?

It is important that the team keeps track of architectural issues. We write these on cards and hang them on our Scrum Board.

With every new feature in the software, the architecture is evolved further – always changing together with the code that it supports.

This leads to an architecture that really solves the problems at hand without far reaching assumptions that may never become valid.

Due to the fact that every developer drives the architecture, it becomes a team responsibility. Everyone can and should influence the architecture. That is important because the primary function of the architecture is to support the developers to solve the problem. Therefore, the responsibility lies with the ones who benefit.

When everyone is changing the architecture just in the scope of their current problem, the design decisions taken may not be optimal from a broader point of view. These local decisions have to be transformed into global decisions. For example, the same problem should be solved in the same way throughout the whole project; otherwise understandability of the code suffers.

Therefore, the team should review the current state of the architecture at the end of a Sprint to be ready for the future and refactor where necessary.

This leads me to the main responsibility of the …

… software architect.

The software architect is responsible to drive the architecture: Provide input to the team when asked and take the lead in the review of the architecture.

As I said earlier, every developer makes design decisions every day. Therefore, the software architect has to coach the team to help them take the right decisions.

Finally, whenever the team is not able to decide for itself which way to go then its the responsibility of the software architect to decide. The reason for this is that it is still better to decide wrongly (and hopefully correct it later) than not taking a decision at all and probably stalling parts of the development.

We have seen that agile architecture is not a “do it once forever”. Architecture is a process starting after the initial product backlog is written and ending when the project ends.

There is only a valid architecture if there is working code to proof it. Code to get feedback whether the architecture holds or has to be changed.

Architecture is a team effort. Every team member is responsible that the architecture is evolved to support the currently needed features.

Requirements and plans change and so will the architecture. Inspect and adapt continuously to keep up with the changed environment.

Finally, if the architecture is continuously evolved, it will help you to keep up your development speed throughout the whole project lifecycle.

If you have any comments then I’d be glad to read them in the comments section below.