This year I had to work with a colleague for multiple internal poc’s that we could use to show customers. Together we started thinking about the approach and where to start. We planned to approach it in a Scrum way, but soon landed upon the question where architecture would fit in. If we planned out the architecture up front, what would remain of the whole agile approach? Then again, we needed something.
We knew what the products were supposed to do in general, so we knew what the architecture would look like on the edges of the input and output. What would happen in between, the ETL process, hot and/or cold storage, and other processes, would remain more open. The main takeaway about this that I personally had was that architecture can function as a bordering tool, it gives a frame in which to build.
Where does it fit?
This go-between process made me think about the role and place of architecture (and the role of ‘architect’) in the agile process. And as I asked other knowledgeable persons about this, and scoured the internet for answers, I found that this ‘issue’ has hit more people. The founders of the Agile methodology seem to have been very knowledgeable people, who, in their manifesto, suppose that each agile team-member is equal in his or her capabilities. Roles such as analyst or architect are not available in the agile world, and architecture is not spoken about in the agile methodology; but is this realistic? Are we supposing that each team member can equally contribute to architectural design decisions and guarding mid to long term technical decision making? And if not, how could we combine this facet of architecture into the agile methodology?
Imagine a city
The larger a project, the more desire for standardization there will be to reduce risk and uncertainty in complexity. Take the metaphor of a city. If you’d build a city, leaving everything open for a sudden agile pivot here and there would leave too much room for uncertainty. So you’d want to standardize and lay out the grand scheme for infrastructure like plumbing and the electricity net beforehand. This gives a canvas for building the city, what is left over is the building process itself, which would remain agile. If for example, a type of apartment building is suddenly not suitable anymore, you can change it out, but the connection to the plumbing and electricity will remain the same. The same with architecture, there’s no escape, even in an agile project, that the business side, together with eventual architects and other non-agile or non-scrum roles, will have the desire to plan the project ahead in advance.
In practice it seems that architecture, or the architect, borders between a role of guarding long-term complexity sided with the business, and at the same time guaranteeing flexibility for the developers, giving them a canvas to work in. I think we have to come to a point where we say that agile theory is unrealistic in practice, whilst the company has legacy of non-agile work methods. We have to think of ways to incorporate it in a more official way, where the position of architecture is not awkwardly ‘glued’ to agile teams. A couple of ideas might be:
- Incorporate technical decisions in the retro; taking a step back as a team and reviewing previous technical decisions.
- Possibly reserving a certain % of the sprint capacity to technical debt, architecture design, etc.
- Giving the architect part ownership of the backlog for necessary technical issues
- Incorporate architectural ‘backing’ in to the Definition of Ready
I would like to encourage the debate around the shortcomings of agile when it comes to the ‘real’ world.
To the person reading this article: what are your views and opinions about this matter?