Here’s What a Software Architect Does in an Agile Team

So, you’re an architect. With AI twisting industry roles yet again, the question still gets asked: what do you do on an agile team? I don’t want to pretend this is a new debate; there was even a fairly recent article on The New Stack about the same issue.

The problem with the term architect is that it has a very specific meaning when building a house. This is where most people experience the idea first. It is a more splintered term in software production. In some cases it is just used as an honorific — not quite as vague as “thought leader”, but a way to give respect to a senior person without giving them any headcount. But let’s move past that and assume you are the real deal.

For one team running a simple web app, most people can see the technology without the architecture. The devs have their favourite frontend frameworks. AWS is always supplying different solutions, but they will show you how to host a web site, if that is all you need. No one needs to be persuaded to use git anymore. We all know what a web site can do, so communication between customer and site maker is likely to be smooth. Who needs an architect here? Of course, in this limited case the architecture has walked backwards into the hedge; web sites were standardised sometime ago, they work, and we don’t look at the cogs much anymore. But as soon as you need a bit more, it all comes back out. Is Tailwind still suitable, or do the components of Bootstrap provide a safer route? Do we need to run those extra methods in Lambda to keep costs down? Has the customer got an appetite for getting more business from their site? So we hit your first responsibility as an architect: managing complexity to reduce risk and costs.

When an organisation deals with multiple teams or multiple products, it is much easier for you to plough a steady furrow. Sometimes making sure a common API is in use across teams. Maintaining the pipeline, and defining the different stages. Some existing cloud solutions imply a design, so that needs to be a constraint. Either way, the architects ward off chaos by providing structure, alignment and certainty.

Agile is About the Now

It may have started as a dirty little secret, but it has become an accepted truth. An architect is probably not a valid role on an agile team. I admit I have at times been overzealous with non-coding members of a dev team. The less militant version of this is to be aware of ‘pigs’ and ‘chickens’ in the agile sense. When making breakfast, chickens lay eggs but pigs literally have skin in the game. So only pigs should attend daily agile stand ups.

There are three problems with the role of architect in classic agile. Think of these as Lutheran protestant theses nailed to the door — or more likely to the planning wall.

• There are no upfront design phases in agile.
• “The best architectures, requirements, and designs emerge from self-organizing teams”.
• An architect cannot be an approver and cause of delay.

This leads to the idea that architectural know-how should be spread out amongst the other team members. This is often the case — however it elides the fact that architectural responsibility doesn’t fall to anyone, even if people feel they may be accountable. Remember your RACI matrix.

Should all agile developers be architects in a project? This makes little sense, since architecture describes a singular plan. It is not an ongoing argument, in the way that software implementation can be.

The biggest reason for architectural competence is when one internal system has to work with another one. But it is unreasonable to assume that the whole team has purview over both systems.

Smuggling in a Design

I don’t quite believe in emergent design; in fact I’ve often seen a design smuggled into day 0 sprint planning, even if it is just a ‘straw man’. Or a suggested architecture receives no push back, because a senior member suggested it.

This leads to the idea that if the architect is also a hands-on dev, their intentional design can be smuggled in without any questions. While this is a practical solution, it does mean that the team’s operation becomes opaque.

Governance is also something that must be done, but often goes unmentioned. The agile rituals would appear to help with self governance; but when retrospectives don’t get done properly, one cost is the feedback needed for any “evolving” architecture.

Just Enough in Time Architecture

So with “big design upfront” out of the question, architecture has to try to be more about tramlines than a big roadmap. Setting boundaries, using technical constraints in existing systems to maintain a vision, and keeping alignment with other teams and projects.

I wouldn’t normally bring up SAFE, or the “scaled agile framework”, but it is fairly bullish in facing the contradiction with the idea of an Architectural Runway. This is literally the idea of “Wile E. Coyote” building a road under his feet, in that physics-defying manner normal only in Roadrunner cartoons.

But one understands what they mean. Produce plans that work from ‘here’ to a little bit more than ‘there’. This might be enough APIs, constraints on new tools use, or a reorganisation of the CI pipeline to suit an upcoming epic. It might also be mentoring developers to help them see the advantages of working with existing systems, not rolling their own.

Bringing Down the Agile System From Within

I think there is perfectly effective room for someone to work against strict agile methodology, while giving wholehearted support to a team or project. In fact, to recognise agile’s nearsightedness is partly to help fix it.

Developing an intentional design (although perhaps not revealing it all at once, but in chunks) and not running too far in front of customer requirements — these are the main skills of the agile architect.

Handling technical debt is another place where by inference we have already accepted that agile effectively leaks productivity. This is maybe the best place to guide the development towards a plan. This is perfectly reasonable in an agile context — let some code appear, then after it has proved out the system to the stakeholders, write it with more intention.

Keeping an eye on data formats and APIs that are being used by other groups in the same organisation, and adding stories to nudge these into alignment, can also work perfectly well in any agile framework. Instead of repeated squabbles over json vs yaml, use a Community of Practice to focus skills across the organisation on the best format.

So there should be no need to actually bring down the agile system, even if you work against the flow a little. While I would admit that this still makes the architect a chicken not a pig, it is the architect that may be keeping the farm from sinking into the mud — and keeping the teams and projects delivering strongly over time.