A lot of software development teams these days are pretty well-versed in the ways of Agile. They understand its principles and they’re adept at knowing what to do in order to create an Agile environment.

But for software architects, the challenge is different, since on the surface, the values that guide their role are seemingly at odds with the values presented by the Agile Manifesto. They are faced with finding ways to do their job without crushing the Agile constructs put into place by the team — the processes, the mindset, and the goals — that bring better usable products to life faster and so much more efficiently.

It’s not impossible for software architects to accomplish their goals in an Agile world, however, and with the right model, the two worlds can integrate naturally, in a way that works for everyone on the team.

Here’s what software architects can keep in mind when working on a development team that’s guided by the hand of the Agile Manifesto.

1. The architect eliminates bureaucratic processes, paving the way for team consensus

The larger an organization, the more layers of management there are likely to be. But as a software development team, those layers can mean a heavy burden of bureaucratic processes they have to follow. These processes can stem from a dogmatic approach to generally-accepted industry guidelines put into place by management to consolidate visions and strategy, or to increase uniformity across departments.

That can slow down any Agile-minded initiatives they’re trying to put into place, such as team consensus. Building team consensus means having each member actively contribute to the assessment process, whereby you’re making sure that what you’re all doing is actually contributing to business success. Extra layers of bureaucratic procedures essentially dissolves any attempt at building consensus, where teams own their code, their decisions, and the product they’re working on together.

By shielding the team from those layers of bureaucratic processes, the software architect can guide them through code reviews and code quality gates to improve the quality of the software. Then, top-down rules shouldn’t even be necessary!

2. The software architect writes code

Having control over an architecture likely influences the decision for most other development work, so it is important that the Software Architect has leadership skills akin to a TL, even if they aren’t part of the continuous day to day of the project.

So, as a software architect, you’re also a technical leader. Your decisions are informed by your knowledge of the code inside and out, and they impact the quality and overall success of the product. With a heavy load of responsibility like that, it’s easy to devalue the benefits you get from actually writing code yourself.

As a leader, you’re there to guide the team by reviewing team members’ code, serving as technical point of contact, coordinating technical aspects across projects, and acting as a reference for architecture and application design. As such, it helps to have empathy for everyone’s problems. As you write code yourself, you’ll gain empathy by finding out for yourself exactly what types of technical problems your team faces. You’ll see first-hand the details that present obstacles and you’ll be better able to help the team resolve them.

Furthermore, by coding, an SA can see whether the standards they set are truly in line with achieving the goals of the team. Do they help productivity? Do they really help at all? Is the team working so hard to follow your guidelines that they’re spending more time than they should? 

Finally, in keeping with the non-hierarchical values of Agile development, having a SA write code is a great way to engender trust and connection with the rest of the team. Code review can also go both ways, with the team reviewing the code of the SA instead of exclusively the other way around.

3. The software architect fosters a close relationship with developers

Peer code review is good, but the software architect is also a leader, acting as a protector of the development team. Staying actively involved, constantly making it clear that you’re there to provide what developers need, and generally getting down in the trenches with the team are all not-unheard of techniques for fostering better collaboration. By providing those reminders that you’re there to “serve” them, you’re acting as a true leader.

And the protection part? Think about the pressures the team faces from stakeholders like the client, the scrum master, or even fulfilling the business goals. The SA protects the team’s morale by keeping these pressures at bay and providing a work atmosphere that’s stable, and relatively predictable while also answering to the demands of those stakeholders.

The key is striking a balance between decision making and pressure-tolerance. The SA creates the proper “filter” for what the team needs to hear so that they can make decisions, without the pressure that stakeholders will apply.

4. The SA negotiates with stakeholders to reach goals and protect the team

Speaking of negotiating with stakeholders, a software architect should also have great communication skills. It’s how they’ll be able to assist with the negotiation process with stakeholders on various technical solutions — good solutions that preserve the quality of the product without, for example, loading too many technical tasks into one sprint.

It’s important to note that although they may not serve as the chief negotiator, they can, with the general architectural plan in mind, provide valuable feedback to avoid miscommunication and failure.

5. The SA strikes the right balance between responding to change and following a plan

Agile development offers guidance principles that value flexibility. Strict adherence to a set plan is a mindset that’s derailed by feedback, rather than fueled by it. But planning is what software architects do, so there’s some negotiating they need to make in their own internal thought process before they can find the right balance.

Bad decisions made in the name of the Agile value, “just make it work for now, worry about the rest later” can potentially become very difficult to roll back later on. There has to be a vision and expectations have to be realistic, too. The balance to be struck has to be one of accepting changes while maintaining internal quality.

So it’s the experience of the SA that helps them form a vision of foreseen problems or the project’s general direction. It’s a long-term plan that they have in mind, and they may need to make adjustments along the way, but they need to be able to envision it all in their mind’s eye.

A final word

Since there is no one methodology that completely dictates how a Software Architect should think and plan, it’s key to be flexible with your approach. Being a good Agile architect means having values that are rooted in the dictates of the Agile Manifesto and also translate into real-world solutions to the problems your team will face.

Being involved in the process at the granular and high level keeps you grounded with your team and ensures that you’re applying an Agile mindset in ways that address stakeholders’ concerns, business goals, the company, and the technical aspect all at once.