Agile and architecture – lessons from the trenches

When talking with architects about their contribution to agile, you get some interesting reactions. Most architects see agile as if it is just the SCRUM teams where they don’t have influence. Some architects recognize the scaling Agile opportunity but don’t know to deal with it. Almost all architects struggle with their role in agile context.

There is an increasing need for scaling agile teams that is implicitly driven by uncontrolled autonomy of SCRUM teams. Although uncontrolled autonomous teams will become more and more high performing, their value for business will decrease. Scaling agile teams is a necessity to stay agile and keeping up business value. The agile architect has an important role in achieving this.

Stories from the front line

Let’s discuss some observations in more detail and address the challenges for the architect in order to explain the importance and added value of the architect role in Agile context.

On the many role definitions for architects…

“The Agile architect role is not recognized”

Architect roles are mainly defined as functions within a common domain, such as business architect, information architect, application architect, infrastructure architect. In agile, only three architect roles are distinguished: the system architect, the solution architect and the enterprise architect. It is not self descriptive which role an architect has to play in agile context. This leads to different interpretations of the roles and responsibilities of an architect in agile context. Also in many organizations the enterprise architect is seen as part of the IT organization and is not situated on business level.

On the way Agile is implemented…

“Architecture is not implemented conform Lean / Agile principles, but from IT perspective or just partly”

Most organizations approaching Agile as the next IT delivery model by setting up many individual and autonomous SCRUM teams or DevOps teams with the aim to deliver IT value more efficiently. The architect role is not defined in SCRUM teams, so the architects will stay in their traditional role. Also, for architects it becomes very hard to contribute to the teams’ effort and guide the teams to work under the designated and defined architecture. When involvement of architects in teams is not stimulated, teams will show resistance to architects because they think that architects are impediments in reaching the sprint-goals. This maintains the situation that architects are involved relatively late in the process and just validate changes that are already implemented.

On Agile being seen in the traditional management context…

“Architects are still organized as of traditional / legacy way of working”

Because agile is often seen as the next development method – as a successor of the traditional iterative way of working (such as RUP or DSDM) – many traditional project management principles remain in place. With that, traditional architectural controls (design authorities, architecture control boards, building permits) will also stay in place. This hinders architects to change their mindset and their work patterns to agile. They will stay implicitely in their comfort zone, and thus will be ineffective in agile.

On focus on the SCRUM process instead of the Agile product value…

“Architects are not involved in SCRUM teams”

The focus on only SCRUM (or DevOps) teams inhibits the focus on business value and properly defined product value for middle and long term designed solutions. This enforces doing waterfall projects with scrum teams which delivers the defined and specified building blocks from IT only. It is difficult for architects to change this approach because architects don’t have enough influence and perceived added value. Architects mostly don’t have full attention from business value perspective, and scrum teams are purely focusing on short term business value defined in user stories. They don’t have insights and focus on longer term integrated business solutions (including enabling value from architectural perspective).

On what architects encounter…

“There is too much work pressure – Agile is additional to our traditional architecture work”

Since Agile is almost always seen as additional to the traditional architecture work (which is already time consuming), there is a real danger of too much work pressure. It is quite a challenge for architects to make the right choices to guide the SCRUM teams. That causes architects to be disconnected and not part of the solution which the SCRUM teams are creating.

“I’m feeling like I’m a rush goalie, I’ll have to switch constantly between a lot of subjects and problems”

Architects sometimes feel like “rush goalies”, to have to switch between too much topics & teams with too little time to handle things properly. This, of course, distracts them from adding real value in an Agile context.

“Architects are not adding value enough, but management does not see this as a problem”

From management’s point of view, the essence of a changing architecture role does not get enough attention. It seems that management doesn’t know and doesn’t care about the necessity to optimize the effectiveness of architecture in an Agile context. A sense of urgency for becoming an Agile organization as a whole is often lacking. Instead the traditional steering and control on projects and programs is maintained. This kind of hybrid situation (f.e. “Agifall”) is often contra productive.

What can you do yourself to become an Agile architect?

To become a real Agile architect you must focus on some guiding principles, take small steps, look for low hanging fruit and celebrate success. Stimulate and sustain a mindset change from being prescriptive to a servant leader as architect and show your added value daily.

Respect the troika: “content – structure – process”

As Agile architect you are an important link in the collaborative structure between content (Product owners and product management), organization (System and Solution Architect) and process (scrum master, Release Train Engineer and Solution Train Engineer). These three aspects and according roles are main drivers to deliver the value as defined by retaining structure and preventing and handling impediments. These troika must be respected at each level of abstraction in your organization (SCRUM teams, incremental releases, solutions and enterprise portfolio). As an architect, you will form teams and stimulate collaboration of architects to sustain the chosen structures and architecture on all these levels.

Step consciously into the agile architect role

Ask yourself in which agile architect role you really can make the difference and step into this role. As agile architect you will span all common domains to design and guide the system or solution for the business value stream. It’s okay that you don’t have all of the skills for the common domains. Collaborate and form cross-functional teams to fill in the gaps. Take your mandate as responsible agile architect to craft the solution which is needed. This model is similar to full stack developers and T-shaped individuals in scrum teams.

Organize around business value – bring structure with increments and solutions

Reduce autonomy of SCRUM teams by addressing scaling from business value perspective, so called vertical scaling. Just to close the gap between autonomous SCRUM teams and needed value from IT for business value streams (or value chains). As an architect you have the responsibility to bring structure in solutions and how these should come to live via increments. Just to shorten the feedback loops with end users and to be able to adjust frequently when necessary.

Collaborate with other architects own enablers and non functional requirements

As an architect you are the product owner of non functional requirements, features and user stories. By paving the right architectural runway, which consists of working components and infrastructure that enable continuous delivery of business features and functionality.

Use the Agile architecture values

For Agile architects it is helpful to address some additional Agile architecture values, such as:

Simplicity over elaboration

Create Minimum Viable Architecture for MVP’s and describe this in Agile start architectures. Maintain Solution Intent, a common gallery of architectural views as single point of knowledge.

Concise guidance over comprehensive documentation

Deliver the architecture just-in-time, just-enough, in sprint-size chunks

Platform Concierge over Design Authority

Acts as daily chief assistance and join when necessary, as part time member, multiple Agile teams in parallel. Those teams are working on designed solutions and increments. Design and update solution architectures owing enterprise architecture, principles and guidelines

Continuous transformation over phased change

Continuous transformation in small batches to enable delivery speed. Continuous architecture refinements-driven through shortened feedback loops.

So…

If you use your common sense and apply the agile principles then you will travel far on the road to agility. As agile architect you can be the guiding coach and leading change agent in the transformation to agile. Overcome the struggle, learn from failures and celebrate success. When addressing scaling and build on small successes you will be able to take full advantage of architecture in agile context. And above all: enjoy the journey!

This article is co-authored by Hans Van Rijs