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.
What then?
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?
Interesting post and fully agree, so much that I managed – on a one year project 5 developerd agile team – to convince that myself alone would need 1 full month (2 sprints) to reverse engineering all production etl code, tables on top of views on top of temp tables + frontend java accessing databases in different ways .. a mess.
Scrum master, product owner + all developers were as almost so what shall we demo in 2 weeks from now, and i managed evangelize mu peer dev colleagues and then step up in private call with both scrum master and product owner suggesting i needed 2 weeks to propose solution architectures old vs new, plus 2 more weeks to build full data mapping down to data field level + business rules used in etl and search function into 1 single excel.
Product owner (+scrum master) understood the complexity and delayed the agile for 4 weeks and we created epic “foundation” with stories mostly for me to reverse engineering everything.
And it was a perfect smooth project in remaining 11 months, high performance, good logging, flexible way to implement business rules concept.. all as result of my foundation architecture and very much needed global reverse engineering of production code.. all this was possible because both product owner and scrum master were americans.
Cultural differences really impact how smooth projects go. American and the best management to work with, in all most all European countries i worked the few times i couldn’t drive with this initial approach of reverse engineering+foundation architecture on enterprise level environment driven by messy politics of respecting more the agile ceremonies and “is it done?” vs really trust developers in whats needed high level. In our case there wasn’t need to learn nee technologied but if it that was the case then couple more weeks should also be part of foundation epic stories, instead of forcing and stressing developers with no knowledge of production system neither underline technologies to just learn on the fly both.. and then all becomes a mess.
Again thanks for broadcasting the importance of a foundation work high level architecture and/or data mapping and reverse engineering as START OF THINGS 😊