Team Alignment: "Architecturally Focused" Teams
In the SPS with Nexus training we discussed the "architecturally focused team" in the team alignment section. We spent a fair bit of time on this topic as a training group parsing the differences between these, component teams and feature teams. Two Scrum teams I work with are looking to broaden their product knowledge and responsibilities and evolve from a component team into an architecturally focused team.
I am having challenges communicating this change to management. Education and messaging in various forums are underway however the term "architecturally focused team" is a mouthful and the inclusion of the "architecture" term creates confusion for some mainly because the term itself is misused and flies under a diverse set of (maybe more often than not) inaccurate definitions in people's minds.
Has anyone else experienced a similar situation?
I have considered trying to rebrand "architecturally focused team" to something else but haven't come up with any viable alternatives. What guidance might you have to message this evolution?
What is the expected evidence-based outcome of this architectural focus?
A shorter lead time from user request to working software released to users and higher quality software are the goals.
Would an "architecturally focused team" -- however they are branded -- be able to deliver or help integrate a usable piece of that software in one Sprint, no matter how small the feature might be?
Usable working software every Sprint, yes, however typically that software is not being delivering directly to an end-user but rather to a customer-facing team.
Would said customer-facing team than not be your customer in itself?
Not in the truest sense of the word customer, no. The pain in terms of not being able to eliminate external dependencies will be most felt by the customer-facing team when a feature request forces them to rely on an architecturally focused team.