When should the architecture of an enterprise level project be created in Scrum?

Question

First of all, I know, that there is no such entity as Sprint 0 in Scrum. Also, I know, that architecture should not be nailed down during the first Sprint.

Well, all these principles work fine for us. We start from the prototype in the first Sprint, then gather feedback and in the second or third Sprint we understand the general customer's requirement well and the architecture becomes stable. But all projects were small (max duration is a little bigger then a year with 12 involved persons).

But what should I do with architecture in a large (enterprise level) projects, in which several teams are participating? I believe, that they can't start work together without preliminary coordination. For that coordination a basic architecture should be done first. And for a basic architecture we need to do general requirement gathering and a rough analysis of them.

So:

• First of all, Scrum didn't provide any special events for these activities (like Sprint 0).

• Second, the flow, that I described below looks like a waterfall, not agile.

What we shall do with a complex projects, which demands that we gather general requirements and create an architecture before its implementation? Are there any best practices for this? How do we solve this problem within Scrum?

Answer 1

thank you for this hard question. My answer is two-fold. First about your belief ("I believe, that they can't start work together without preliminary coordination."):

Remember principle 11 behind the agile manifesto. Those amazingly senior guys who had worked on huge projects for large enterprises agreeing on: "The best architectures, requirements, and designs emerge from self-organizing teams." Architectures EMERGE. I know it's not a simple thing to believe in.

I believe the best link with detailed information on how to actually do it: http://less.works/less/technical-excellence/architecture-design.html

Some important things from there: Don’t let architects hand off to ‘coders’. Very early, develop a walking skeleton with tracer code. Do customer-centric features with major architectural impact first.

Hope it helps.

Answer 2

The answer is simple: architecture should be defined BEFORE build, regardless if it is scrum, waterfall, etc. doesn't really matter if you define just a portion of architecture to support only the first sprint.

Simple fact of life: Architecture comes BEFORE build.

In future sprints you can scrap/adjust/enhance/redefine/whatever the bare minimum architecture defined, but it doesn't change the order of what comes first.

Answer 3

How much work should you do up front? Well, as much as you need and no more of course.

What I find works well on large teams is to just get started. You should get enough backlog ready for the teams to start their first Sprint. Bare in mind that they will not deliver a lot as the basic infrastructure and understanding is not in place.

The hardest part will be dealing with dependencies between teams, and that includes architectural issues. I would create an Integration Team that can help coach and mentor the individual teams in DevOps, Architecture, Contracts, and other dependant issues that crop up. Kind of like a Scrum Master, but for the Product instead of the Process.

https://www.scrum.org/Resources/The-Nexus-Guide

While the Integration Team should try to avoid doing the work, and may be part time representatives of the Development Teams, you need someone that is accountable and responsible for delivering the Done increment.

This group will help coordinate the types of emergent architectural decisions that need to be made.

Answer 4

One suggestion: Create a scrum team, give the output you require to them as their product to create. Run sprints in the usual manner until you have what you need. At that point the team can continue working on the core shared infrastructure used by other teams, or could be disbanded and (ideally) the members moved onto various other teams which will use the shared architecture. If the latter, I'd suggest the original team still meet every few weeks to share knowledge on how the architecture is evolving for each of their teams.

Answer 5

You should consider impact of change here. If it is small (it can be reduced), Scrum is a good option. However, it can possibly be better if you nail down a few things in advance - interfaces and data exchange format between systems (developed by parallel teams), general requirements for scalability, maintainability (standard format of log files used by enterprise, mandatory authentication and auditing formats, etc.).

When refining those requirements, you should consider schedule of the entire program (connected projects), not only yours, because if you don't do so, it can cause significant delay and rework in other projects, that depend on your input. In this case a more waterfall-like approach is needed, and somehow, Scrum rules will be crossed.

• You may choose the approach where an architecture team agrees upon those decisions in front. In this case, there will be decisions made outside of the Scrum process.
• You may choose to introduce design tasks into a product backlog and dedicate a sprint or two for creating them as the first activity of the project, in this case those sprints will not produce a potentially shippable product increment.
• You may choose to do a regular sprint and grow those architectural decisions. If other projects can wait until those work items are stable, this could be fine approach, they can take your result and build upon them. However, if they need the results earlier, at some point, product management will raise an issue in your project for causing a lot of rework / delay in other delivery streams.

I can accept the statement that the best architectures are grown instead of designed (although I don't see such great examples of it in building bridges or making cars - and even in software industry, solutions tend to be more "beautiful" if they are designed in a coherent way, which is easier if the overall architecture is decided at the beginning). However, at enterprise scale, architectural perfection (or pm methodology purity) is usually not the most important success criteria of the project.