In Scrum, as we know, the design is always emerging. It's the responsibility of the development team to ensure that it while it's emerging, it adheres to the architecture blueprint.
Generally, people who come up with the organizational architectural blueprint tend to be seated outside the Scrum team. We all agree with the importance of architects for coming up with logical, physical, and application architecture. However, I have yet to see a team that has a fully committed architect. Quite a few organizations have "architecture" as a separate function/department; it generally is not embedded within the development teams.
Almost all of the teams I've worked with, however, yearn for an architect's time to unblock some of the technical design challenges. Architects sometimes are helpful, but often they are snowed under because of other commitments and hence are unable to provide valuable input at the right time. One of the side effects of not having technical guidance at the right time is that the development team will make a decision that may or may not fit with the blueprint.
Therefore, quite often the feedback from development teams working on Agile projects is that they feel there is too much technical debt left. Because the project is over now, i.e., gone to production and the product owner and stakeholders are happy, there isn't anyone to help fix it. In other words, there isn't anyone to fund any fixes.
There are various reasons teams find themselves in this situation, but I will mention a few of the main ones I've faced:
- Stakeholders/product owner are very demanding, and if something is not of business value, it goes at the bottom of the backlog. It is usually tough to come up with a high business value for a technical debt story.
- Project timelines are such that a team can barely fit in the MVP in the given time frame, let alone take time to address any technical debt generated.
- The architect's time is not usually committed to the team from the outset, hence the chosen solution comes with higher technical debt.
Over years, I have managed to devise my own strategy to work from the outset to address the first point given above. I usually allocate about 10% of the sprint capacity to address technical debt. I do understand that, as a development team, we should be practicing TDD and other XP practices; however, there are nonetheless instances wherein some sort of technical debt will be generated. Therefore, by following this approach, I do try and address it as much as possible as a ScrumMaster.
Regarding the second point, I generally use release burn-down/project burn-up as the most effective tools to address the issue.
However, for the final point I am still searching for a solution -- a scenario in which architects sit under a separate function and their time is not fully committed to the team. As ScrumMaster, whenever I have tried to negotiate their time, I get a percentage allocated that I am sure is just a number. Whenever you need them the most in a sprint, they are either busy with other "important" work or they have prior commitments. To alleviate the problem to some extent, I have always tried to ensure they attend sprint refinements, so that team can get maximum output from them, but that hasn't proved enough.
Therefore, coming back to original question, "Where does this role sit?" as per Scrum, I suspect that the simple answer is "Within the development team." However, most of us will agree that we always don't have full-time work for them within our sprints.
Are we at a stage where we should expect senior developers to perform the dual role of developer and architect for the team? This too has its pros and cons -- which I hope to address in a future article.