Where and when do design, architecture activities take place in Scrum

Question

The traditional Waterfall lifecycle includes a specific phase for design and planning. In Scrum there is no big up front design. A small amount of design to conducted when breaking down features into stories, during the sprint planning meeting and during the sprint.

Since sprint planning is time boxed to a few hours, there isn't enough time for the team to decide on technology choices, which responsibilities belong different components deployment and release considerations etc.

Where does design work belong? Should it be conducted prior to sprint planning with details added to stories or tasks? Or should there be an additional design meeting post sprint planning?

Answer 1

Design should be planned for, either as enough extra story points per story or as a separate story. And you should still have designers on your team who own and monitor the design.

The trouble is that design represents "no business value" and pure user stories will typically be dumped onto "the team" which is this blob of developers that focusses on workable software rather than maintainable software. So with the introduction of scrum, conscious design often ceases to exist. For larger, long running products this is a desaster waiting to happen of course. It will be a silent one though, development time and the number of bugs coming back will just gradually go up. And no one will regard this as worrying, we will just do more testing and feel good about it. It is not a coincidence that testing has grown into a big thing lately, also in run-off-the-mill software projects.

Fortunately, today we also have a fancy name for this: "technical debt". It is a great name because it does not sound like a problem to anyone but the development team. It implies it is their fault too, the techies should pay for it, not the business. It is their problem.

And in all fairness, it really is. The development team must make sure they do design. They are self organising and must be strong enough to reserve the resourses to do what is necessary. They commit to a planning they make themselves. There will be pressure to move ahead with features but it remains their responsibility to think things through and to have people who are responsible and accountable for this. Scrum does make it harder to maintain these basics.

Answer 2

Where does design work belong?

Either before the first sprint, or on the first sprint, and possibly in every subsequent sprint. Some teams will have a period of time before the first sprint where some of these decisions are made. If the decisions aren't made before the first sprint, then you must do at least some of the design and archtecture work in the first sprint. As the project progresses through the sprints there will come opportunities for additional design and architecture tasks. The extent depends on the scope and complexity of the product being built.

I think it's perfectly valid during any sprint planning session to say something like "we don't have enough information about how we are going to architect this, so our first story (or task) needs to be to come up with the architecture."

The whole point of scrum is to have teams that are empowered to make decisions on how to build a product. If part of the process of building the product involves deciding on architecture, that is a perfectly fine activity for any sprint.

Answer 3

Robert C. Martin had a talk about that you can find on youtube:

The land Scrum forgot

There he adresses this common issue that in Scrum architecture and design is never mentioned so it is up to the team to identify what architecture and desiogn should mean within the project.

My personal opinion is that you should have one instance in the team to be responsible for architecture and design. The contract should be: The architect decides how these subjects are adressed. On the other side he should not be able to escape resulting questions that came out of his decisions.

In my current project we are currently facing several issues, that can mainly be broken down to concept diversification and disharmozied code base beside implementions that completely ignores the architecture instead of extending it in a useful way.

The point is: If you cannot find a consense about the best architecture to the given requirements within the team, you cannot expect the team doing a good job. This also true for issues of code quality. A democratic way of solving this problem may be a way if the understanding only differs in some little points. But if you have essential discussions that do not lead to a solution you better put someone in the position to decide.

Answer 4

there isn't enough time for the team to decide on technology choices, which responsibilities belong different components deployment and release considerations etc

Most of this is dealt with in a 'Sprint 0' or is just inherent to the team. You expect build servers and environments to be in place before the project starts.

Just as if you are a team of c# web developers, you known you will be writing a asp.net web site backed by MSSQL

Scrum is focused on getting results quickly. So which javascript framework, or database is the best isn't important. Don't waste time thinking about them.

Choose the thing that is quickest to implement every. single. time.

If the product is a success, then in a few years you will maybe have another project to change one of the technologies to a cheaper version.

Answer 5

There are activities that need to be performed before the teams actually goes Sprinting. Team is assembled, tools are procured, budget is secured, estimation is done, draft vision is created, architecture is decide.

The idea is to prepare just enough and to not go for weeks and month before actually test your hypothesis.

Therefore, take time to setup and ask the very first questions then work out the unknowns alliteratively in Sprints.

I suggest to avoid calling the preparation period Sprint Zero, or Hardening Sprint etc.

Answer 6

Design work prior to planning meeting is not preferable as the team won't have sufficient inputs because the story hasn't been broken down. The planning meeting can be used for breaking down the features and estimation. Later the team should be given time for analysis and re-estimating the story after which a meeting should be scheduled for design work.