Get certified - Transform your world of work today


Where Does the Architect's Role Fit on a Scrum Team?

10 February 2016

Amit Maheshwari
The Agilist Pvt Ltd

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.

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 2.7 (3 ratings)


Amber Haley, CSM,CSPO, 2/10/2016 6:41:08 AM
I have another question in relation to this - as you say (and it's totally my experience too) that a defined Architect role has limited time to devote to teams; how can look to empower teams to be able to confidently add to architecture? how can organisations open-source their models and practises to allow teams to only lever the knowledge of the Architect as a subject matter expert, and not as someone who is responsible for the whole Big Picture, but more like the caretaker of the community that contributes to it?

I know these are pretty conceptual but I'd be keen for any discussion around this
Amit Maheshwari, CSP,CSD,CSM,CSPO, 2/12/2016 2:51:39 AM
Yes, these are valid questions and from experience I always try to strike a balance between decision making and delivery of the team. In other words, I encourage the team to come up with design decisions (in-line with architecture blueprint), and present it to the architect(s). This usually leads to a 10 minute conversation rather than weeks for an architect to come up with a design. Obviously, if the team is coming up with design it does impacts the velocity, but I think its a good trade-off considering the team owns the design and are fully bought into it. At the end of the day we don't want the design decisions to start impeding the progress of the team.
Coming on to the second question, I guess its more of an organisational mindset to open up architecture for contribution from teams. I always mention this in my courses that "Multiple brains are more likely to come up with a better solution than a single brain".

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up