7 Do-or-Die Situations Where a Technical Architect is Indispensable in Your Agile Team

The importance of a technical architect in software projects is well known and documented. It is normal – in fact, right – to see a project team build to the guidance of an architect.

Traditionally, enterprise, system and solution architects provided up front guidance about system design, functionality, system interfaces, technology. Architecture is one of the first steps in the design process, establishing protocols and guidance that the project team need to adhere to during delivery. It is now common for architects to stay hands on through the build phase of a project, and increasingly, even stay involved through testing and implementation.

And, traditionally, there has also been some stigma about an architect’s role in a project – that they tend not to be pragmatic, that their views of ideal system design are too idealistic, expensive, impractical etc. Still, the architect survives as a role in the software project – and with good reason.

With the advent of Agile, project roles and responsibilities have aligned to work with the new ways of working. The role of the technical architect is no different.

How architects work with and guide a team has changed with Agile. While the engagement has changed, it hasn’t disappeared – and with good reason. In this piece, we look at 7 critical situations where the technical architect guides and aids an Agile project team’s success.

#1 – Transform requirements into a logical functional map

In an Agile world, requirements gathering is a collaborative exercise – involving the Product Owner/Manager, BA, Architect and Technical SMEs. As it should be.

Agile way of working mandates that requirements are assessed as soon as they come out the door, at least at a high level. This then allows your team to review the feasibility and short-/long-term benefits of proposed requirements, assess solution options, and their impact and alignment to the enterprise and supporting systems.

The architect is beginning to play an increasingly central role in these endeavours.

A case in point is the Functional Decomposition exercise that teams (must) undertake during the Project Initiation phase. The architect picks up each requirement as it is raised, and maps it to a logical functional component of the proposed system, or its support systems, that would fulfil the requirement.

For instance, if you’re discussing the requirements for a messaging engine that generates messages for customers based on triggers and rules, one of the components will be a business rules repository. The Functional Decomposition exercise will draw out the need for, and characteristics of, the rules repository, and identify how it interacts with other components like the decision engine, message template repository, customer preferences database etc., and other systems external to the messaging engine.

The architect’s expertise and experience will shine through this exercise, as they steer the requirements discussion towards an achievable end-product design. To see why the architect is best placed to lead this exercise, look at #3 below.

#2 – Guide in-sprint technical discussions

By nature, Agile projects tend to think only one or two sprints ahead. Agile team members face the risk of building too tactically or towards incorrect system design, at times ending up with a messy solution that, while meeting objectives of the sprint or scrum, doesn’t scale or integrate well over time.

This is because, Agile teams don’t have (and at times, want) to think their sprint deliverables through in relation to the system, and its impact to its extended ecosystem. The architect can direct sprint-level technical discussions, and steer the team closer to the enterprise and system architecture. This includes updating and revising the solution architecture document regularly to act as a reference point for the team.

#3 – Provide enterprise context to any conversation

Architects usually work across a number of projects or system areas, and therefore possess a bird’s eye view of what’s happening across your organisation. The value of this knowledge is unlocked when they’re able to guide project discussions and provide the team some context for why a particular approach is right or wrong from the point of view of the enterprise.

This ability to guide individual projects towards the larger enterprise goal will benefit your team and your organisation as a whole, by increasing harmony and reducing wastage.

#4 – Participate in pre-sprint planning sessions

A best practice for Agile projects is to conduct some advance planning for the next few sprints. This allows architects to review in advance, the work necessary to deliver the next sprint’s objectives. Reviewing a future sprint’s scope now helps them identify any issues and misalignment between the solution under development and its source architecture.

Any such issues, when identified early on, are easier to resolve or plan for before the sprint begins, than after.

#5 – Participate in backlog grooming sessions

Another Agile practice is to groom the product and release backlog regularly – i.e., the BA, product owner, scrum master, lead engineer, test manager and the architect get together to take a critical look at the work completed so far, and what remains on the release backlog or product backlog. Ideally conducted every other sprint, or slightly less frequently, grooming will help re-align the scrum team to current priorities, as well as allow the core team to take a critical look at project progress.

Any grooming sessions need the architect to guide the conversation towards a feasible solution architecture – because all that we have discussed so far will come into play to make the exercise productive.

#6 – Lead Architecture spikes

A spike is where a small group of experts on a topic, work behind the scenes during a sprint to figure out a solution to any burning issues. And as with any issue or concern that needs a spike, Agile projects can schedule Architecture spikes. There could be many reasons for a project to need one.

For example, your mobile app project could decide mid-way through delivery to shift away from separate apps for iOS and Android, and towards cross-platform app development. Technical architects are ideally placed to lead this effort, given such conversations involve a lot of re-thinking about the current and new architecture of the app, and how the work completed so far needs to be re-directed towards achieving cross-platform compatibility.

#7 – Mentoring/disseminating architecture skills to your team

Building effective Agile teams is a massive challenge for any project or organization. Add to that training your team to practice critical thinking skills when reviewing functional and technical scope. Architects, by nature of being a guiding role, provide a scrum team implicit training in approaching requirements and solution conversations, and over time, help imbibe some of their own architecture skills in the team.

While this doesn’t make the architects themselves dispensable, it does help the team in learning to think about how every decision they make will move the project towards or away from success.

In summary

Whether you’re leading an Agile project or any other, I have now given you seven more compelling reasons for why you need an architect to support your team on a day-to-day basis. Architects, by nature ever-smiling and gentle (I know I’m creating a stereotype!), provide the calm but firm guidance that is necessary to steer your project away from choppy waters and on to calmer surrounds.

When you hear one of them clear their throat and politely disagree with you the next time you’re leading a project discussion, hear them out patiently. They might just help your project avert disaster or court success.

Share your views below on why and how the Architect is an indispensable asset to your project.