The idea is to organize multiple teams in accordance to architecture. Each component is very much loosely coupled with other components which makes life easier for a team and they don’t depend too much on progress of other teams.

IMO, this can work most of the times, with one limit that needs to be considered: Do not assume too fast that multiple teams cannot take care of same multiple components simultaneously. Although more difficult to manage, the great advantages is quality improvement when more people are working with the same code and improved interchangeability of team members because so many of them know the code.

Before teams pick up their stories, basic overall architectural decisions are made. These are necessary for correct definition of each component built by separate teams. I like this, except the fact that you should have separate (runway) teams named “Architecture” or “Prototyping team” consisting of architects and/or technical leaders from other teams which don’t deliver direct value.

Although Leffingwell mentions that such teams deliver coded architecture and not some document, there are still two major pitfalls:

1. Functional teams are not familiar and involved in this early development and tend to dislike delivered product because they often do not support to be delivered stories well.
2. Architecture and prototyping teams tend to be technology-driven and the question: “Is this really needed?” is not easily answered. Keeping things as simple as possible is not natural in such teams.

According to Leffingwell, these are activities intended to address design challenges, architectural extensions, and the impact of new technologies or to explore critical problems with the existing solution. Design spikes do not deliver direct value and occur in each iteration.

What I wonder about design spikes is what makes something worth spending time on regular basis discussing, discovering and improving by itself? What kind of design issue is not driven by one or more stories or business requirements and thus not prioritized in product backlog? In other words, I think it is really good to spend time discussing and designing, but always driven by real business / user need. Therefore, it is not needed to plan such meetings on regular basis; let them happen as part of user stories design.

In large enterprise Agile projects and organisations I have worked with, we never needed architectural runway or something similar. In contrary, such undertakings were standing in the way of delivering real architecture and quality.

What we did need is more intensified collaboration between teams and business during delivery of real value. This means, many on-demand cross-functional teams workshops and meetings. This requires creativity in order to make them as effective as possible.