So you are an architect. With AI once again upending industry roles, the question remains: what do you do on an agile team? I will not pretend that this is a new debate; there was even a fairly recent article on The New Stack about the same problem.
The problem with the expression architect is that it has a very specific meaning when you build a house. This is where most people first experience the idea. It is a more fragmented term in software production. In some cases, it’s just used as an honorific – not quite as vague as “thought leader”, but a way of paying respect to a senior person without giving them any authority. But let’s move past that and assume you’re the real thing.
For a team running a simple web app, most people can see the technology without the architecture. Developers have their preferred frontend frameworks. AWS always provides different solutions, but they will show you how to host a website if that’s all you need. No one needs to be persuaded to use git anymore. We all know what a website can do, so communication between customer and website builder is likely to be smooth. Who needs an architect here? Naturally, in this limited case, architecture has gone backwards into the hedge; sites were standardized some time ago, they work, and we don’t look at the cogs as much anymore. But as soon as you need a little more, it all comes out again. Is Tailwind still suitable, or do the components in Bootstrap provide a safer route? Should we run the extra methods in Lambda to keep costs down? Has the customer developed an appetite for more business from them? So we hit on your first responsibility as an architect: managing complexity to reduce risk and cost.
When an organization deals with multiple teams or multiple products, it is much easier for you to plow a steady furrow. Sometimes ensuring that a common API is in use across teams. Maintaining the pipeline and defining the different stages. Some existing cloud solutions imply a design so it must be a limitation. Either way, the architects stave off chaos by providing structure, adaptation and security.
Agile is about the present
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 that I have been overzealous at times with non-coding members of a development 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 participate in 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 pre-design phases in agile.
- “The best architectures, requirements and designs come 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 among the other team members. This is often the case – but it avoids the fact that architectural responsibility belongs to no one, even if people feel they can be responsible. Remember your RACI matrix.
Should all agile developers be architects in a project? This does not make much sense as 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 must work together with another. But it is unreasonable to assume that the entire team has power over both systems.
Smuggling 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’s just a ‘straw man’. Or a proposed architecture gets no push back because a senior member suggested it.
This leads to the idea that if the architect is also a hands-on developer, their intended design can be smuggled in without question. While this is a practical solution, it means that the team’s operations become opaque.
Governance is also something that needs to be done but is often not mentioned. The agile rituals seem to help with self-management; but when retrospectives are not done properly, a cost is the feedback necessary for any “evolving” architecture.
Just Enough in Time Architecture
So with “grand design in advance” out of the question, architecture must try to be more about trams than a grand timetable. Setting boundaries, using technical limitations in existing systems to maintain a vision and keep alignment with other teams and projects.
I wouldn’t normally bring up SAFE or the “scaled agile framework”, but that’s pretty bullish about 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 the physics-defying fashion only normal in Roadrunner cartoons.
But you understand what they mean. Make plans that work from ‘here’ to a little bit more than ‘there’. This could be enough APIs, restrictions on using new tools, or a reorganization of the CI pipeline to fit an upcoming epic. It can also be mentoring developers to help them see the benefits of working with existing systems, not rolling their own.
Get the agile system down from within
I think there is a perfect place for someone to work against a strict agile methodology while also giving wholehearted support to a team or project. In fact, recognizing agile’s myopia is in part helping to solve it.
Developing a conscious design (although it may not reveal it all at once, but in bits and pieces) and not running too far ahead of customer requirements – these are the most important skills of the agile architect.
Managing technical debt is another place where we have already accepted by derivation that agile effectively leaks productivity. This is perhaps the best place to direct the development towards a plan. This is perfectly reasonable in an agile context – let some code emerge, then after it proves the system to the stakeholders, write it with more intent.
Keeping an eye on data formats and APIs being used by other groups in the same organization and adding stories to align these can also work perfectly in any agile framework. Instead of repeated arguments about json vs yaml, use a community of practice to focus skills across the organization on the best format.
So there should be no need to actually break down the agile system, even if you work a little against the flow. While I will admit that this still makes the architect a chicken and not a pig, it is the architect who can keep the farm from sinking into the mud – and keep the teams and projects delivering strongly over time.