Scaling Agile Architecting is NOT rocket science

What about Enterprise Architecture? Can it also be Agile and how does Agile mindset affects Enterprise Architecture? The book “Scaling Software Agility” from Dean Leffingwell elaborates on Agile scaling challenges in general. One of the aspects is architecture.

My general opinion about this book is that most of the book is basic Agile knowledge, but it does have a few practices related to Agile Architecting on which I’d like to elaborate:

Component based Agile teams

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.

Architectural Runway

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.
I find it much better to have same functional teams who deliver direct value also collaborate and make these decisions themselves. Also, term: “architectural runway” sounds like something special, while in practice it is just team members from different teams getting together and making decisions.

Design spikes

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.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.