Aug 31, 2021
Servant Architecture
Can ‘agile’ and ‘architecture’ even be used in the same sentence?
The other day I had an interesting discussion with our architects around agile and architecture. I was invited to their weekly architecture guild meeting, to present my thoughts on architecture from an agile perspective.
To be honest, I was a bit anxious going in. As a coach, preaching agile in a traditional and hierarchical organization, I’m kind of used to the strange looks and sometimes even hostile body language, but architects are on a whole different level — they are generally experienced, knowledgeable, and not at all afraid to share their point of view.
The weeks before the meeting I did a lot of reading up on architecture in order to prepare myself for the coming architectural tribunal — or so my anxiety told me this was going to be. I didn’t stumble upon a plethora of articles on agile architecture, to be honest. Nevertheless, also through some in-depth talks with a fellow agile coach, I did form a strong opinion on what I think agile architecture should be like.
After taking a sip of water, I cleared my throat and presented my simple slides to the stern-looking architects. At times I would scan the room for responses to my bold statements, looking for body language and lifting eyebrows. As I said, they weren’t afraid to share their opinions, so they regularly interrupted my talk, which was perfectly fine, because it gave me a good gauge of their train of thought at that particular moment.
Here’s what I had to say about Agile & Architecture…
Can we even use the words ‘agile’ and ‘architecture’ in the same sentence? The short answer is yes, and the longer answer is, yes we can and we should, with some adjustments.
Yes we can and we should, with some adjustments
With the business, the architecture will have to change — or be left behind. In an agile framework like Scrum, there is no particular role for an architect. As a matter of fact, one of the principles behind the Agile Manifesto states that “The best architectures, requirements, and designs emerge from self-organizing teams.” See the http://agilemanifesto.org/principles.html
That being said, I believe relying solely on the dev teams to conjure up the architecture, is taking the risk of having an architecture that is not thought through to the levels it might need to be in large enterprises. When, for instance, you’re dealing with a large software product that is comprised of multiple smaller products, or when you’re dealing with multiple teams working on a multi-faceted platform, your architecture is going to be exponentially complex and team-ascending. Individual teams are not going to oversee the much-needed bigger picture.
With the business, the architecture will have to
change — or be left behind.
Once the architects are convinced they need and want to be part of the agile transition, they need to know what is expected of them.
A question that often arises swiftly is, should architects be part of the teams, or should they be outside the teams? Should they perhaps form their own team, with their own separate backlog? Giving away a bit of my end-conclusion here, I think the architects should be heavily involved and work together closely with the teams. Ideally, an architect is part of a dev team and at the same time — together with fellow architects — in something akin to what we call a guild.
Besides deciding on their place within the organization, first and foremost, architects need to have a vision. Not unlike the business, they need to paint a dot on the horizon that serves as a beacon for the development teams. We know from the business what we need to achieve, and now the architects need to provide a technical direction. No details please — let those come from the dev teams — but do provide overarching, cross-team technical guidance.
Should architects be part of the teams?
In order to be able to keep up with the dev teams, the architects will need to adopt an agile mindset. They don’t need to have all the answers. And they don’t need to create architectures for pyramids. And they most certainly don’t need to create elaborate documents.
Better alternatives are working within the dev teams to co-create the architecture. Also, deliver just enough, just in time architecture. And please only write documents if people really need to read them.
Working in the dev teams will make sure the architect makes a true connection with the people in the team. That will definitely help in getting the (architectural) point across. It will also make the architect feel the team’s daily pains and needs, which enables the architect to design to help them, instead of restricting them.
Feel the team’s daily pains and needs.
An agile mindset asks of the architect to empower people of the dev teams — foster their autonomy, mastery and help them see the purpose. Think iteratively, tolerate small mistakes, and work on continuous improvement through short feedback loops. Focus on the value the whole is delivering, to which the architecture contributes. And embrace transparency. Don’t be the traditional architect in the ivory tower, telling the minions how to program, but engage with the other team members to deliver the best architecture possible. Trust the team members to be knowledgeable, make good use of their combined knowledge.
One of the ways to ensure the best architecture possible is to drive a culture of quality. Connect with the other team members and convince them of the needs around quality and how architecture can help in that respect.
Ask tough questions on why certain things are done by the team. Try to help them eliminate waste, think lean, and connect the dots.
Last but not least, help the team out by removing future roadblocks, help them to keep moving at full speed.
Don’t be the traditional architect in the ivory tower.
One of the consequences of adopting agile as architects is, they will have to be bold, because traditional management is going to ask for pyramids — and the architects will have to sell another story.
Since the team is going to go fast, architects will need to go steady, be the rock that gives the team stability. This will occasionally clash with the rest of the team, but so be it, the discussion will only strengthen the team in general.
The most difficult consequence of agile thinking for architects is, that they will have to come to terms with the fact that some of their work will be (knowingly) temporary. They have to be willing to create adaptive architecture.
Please note that adaptive is used instead of emergent, the latter being a more common agile preference.
In practice, it also means that architects will have to work ahead of the dev team, together with the Product Owner, Business Analyst, and Graphic Designer.
Speaking more in general, the message for the architects is, be involved. Get down from your ivory tower and be part of the teams, help them be good and fast, help them deliver tangible business value for the company, be a servant architect.
Be a servant architect.
With this last phrase, I hoped to trigger some thoughts in my audience about their own personal role in the various projects. The good news is that I already received an invite to one of their next guild meetings, to further discuss this agile thing they want to know more about…
