Let's discuss only bigger projects where multiple teams work on the product.
Should they be part of the (Scrum) team?
Should they be outside of the team? What is their relationship to the team? Are they superior? Or should they act as a service/consultants/servant-leaders?
What's your experience? Can you recommend it? What's your opinion?
Top comments (4)
An architect is generally a highly experienced person who can design into the product qualities to match its goals. E.g. reliability, scaleability, operational cost, dev speed, etc. This person is usually responsible for some foundational choices which result in setting these qualities for the product, and evolving those qualities as the business changes. The specific teams will do what's best for their area, but the architect is supposed to organize the whole.
Whether an architect should be part of the Scrum team and their relationship there is subjective to the situation. Personally, I hate working for dictatorial types of people. ("Hey guy, I am reasonably intelligent. Tell me what problem you are trying to solve instead of just dictating a solution.") In as much as I have leadership at work (where I have the title of Software Architect, but am not "a superior" to anyone on the org chart), I aim for the servant-leader paradigm and am just part of the team. (The team is agile, loosely based on Scrum.) I end up doing most of the infrastructure parts, devising ways to push the legacy stuff forward, and 'canarying' new tech and integration with services. And giving lots of implementation advice. That suits our particular team and org pretty well, but may not work everywhere.
Hi Kasey, thank you for your response. I see your point and I would like to know more. You said that you are part of the team, do all your teams have dedicated architect? Do you co-operate together? How do you have your responsibilities/areas split?
For transparency, this is the first titled architect position I have held, and it is a relatively small organization. My career path has led in this direction. (I've been responsible for all aspects of most products I've worked on. But it has taken some time to learn and recognize the best choices for various scenarios.)
There are two small teams and I am on both of them, and everybody is all in the same room together. In addition to working out the plumbing code, I implement normal features on both teams -- especially first-of-its-kind features that might need infrastructure support. We have ~5 different service/product software offerings, and nearly double that many individual applications. I imagine if we were larger, I would be on a separate team for providing infrastructure services to the other teams. And the teams individually would have tech leads or senior devs who trail-blaze unfamiliar techs.
I spend a bit of time doing whiteboarding sessions and code review. This is on request, not a required process. I find that most of the time the value I bring to these discussions is focusing in on the business factors and less on the technical details. Although sometimes tactics are needed for the details as well. Another major thing I advise on is UX (user experience), which has been a problem in our products.
I don't dictate implementations. When asked I explain, share experiences, suggest, etc. My advice is frequently taken. But ultimately the person working on the feature has the best information, so it is their choice. I like to use tools (like Functional Programming) that make change easier. So there's no need for me to micro manage every implementation. It's far more important to give the teams an accurate understanding of the business concepts.
The teams trusts me to pick tools (languages, IDEs) and infrastructure designs that will help them and not get in the way. I try to analyze infrastructure from many angles, but especially: dev surface area, ops complexity, and cost. Since we are small, solutions with high ops requirements (e.g. 5 different kinds of databases, micro-services, etc) are less desirable. Of course we have legacy systems too, where yesterday's choices have bitten us. So I'm also responsible for devising ways (and doing some of the core work) to push our legacy systems in the right direction.
I guess you could say I am the maintainer of the technical vision of our products. I talk with the customers, our internal staff (who are customers for some products), and anyone else I need to in order to understand the value proposition of backlog items. Then I help teams work out what that could look like in the software. I prioritize the backlog for one of the teams.
This all sounds like too much (and sometimes it feels that way), but I don't do all of these things every day. I'm basically an "old" dev who gets asked to help with various things at any given time. We are all just trying to do our best for the customer.
I had very bad experiences with architects being "implanted" from outside. I don't think they should be superior. Apart from that, based on my experience, an architect in a coaching/supporting role may work.