Team Alignment: "Architecturally Focused" Teams

Last post 11:43 am September 17, 2019
by Sander Dur
5 replies
03:15 pm August 3, 2019

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?

05:13 pm August 3, 2019

What is the expected evidence-based outcome of this architectural focus?

03:23 am August 22, 2019

A shorter lead time from user request to working software released to users and higher quality software are the goals.

06:22 am August 22, 2019

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?

08:36 pm September 16, 2019

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.

11:43 am September 17, 2019

Would said customer-facing team than not be your customer in itself?