We often discuss where the “testing people” fit into the organisation – are they part of a delivery team or an enablement team independently of the delivery teams? The Team Topologies model enables a discussion about this challenge and a guidance on what goes where and why.
I can see the benefits of having a central Test Center of all the testing people – and, on the other hand, having them spread out in the delivery units. I work in an IT services company, sometimes a project does not require full-time test attention. So we work on a range of customers, at the same time. On the other hand, sometimes projects lasts for years and years – and the testing people become dedicated towards a specific company IT stack and delivery team.
Notice that I use the term “testing people” to cover testing specialists, test analysts, automation specialists, test engineers and test managers like myself. Besides the moniker “testers” in the blog title, I try to avoid calling us “testers”. First of all, “testing people” do more than testing and secondly other people do testing too.
The Test Center I’m in is an organisational unit of “test consultants” of various of the mentioned roles working for various of projects. But considering the “whole team approach to quality“, the Test Center unit sounds a bit .. off. Would it be better to assign everyone to a delivery unit? – What would be the reasoning behind what goes where where and why?
I have found the Team Topologies model, which identifies these teams:
- Stream-aligned team: aligned to a flow of work from (usually) a segment of the business domain [yellow]
- Enabling team: helps a Stream-aligned team to overcome obstacles. Also detects missing capabilities [cyan]
- Complicated Subsystem team: where significant mathematics/calculation/technical expertise is needed [red]
- Platform team: a grouping of other team types that provide a compelling internal product to accelerate delivery by Stream-aligned teams [purple]
The model identifies three modes of interaction during the flow of change:
- Collaboration: working together for a defined period of time to discover new things (APIs, practices, technologies, etc.)
- X-as-a-Service: one team provides and one team consumes something “as a Service”
- Facilitation: one team helps and mentors another team
Based on this model the dedicated testing staff should be part of the stream-aligned delivery unit. While everyone working ideally to enable the team – testing coaches etc – should be part of an enablement team, aka. a center/unit/group/staff team for enablement (Accelerate the Achievement of Shippable Quality). I read into it, that the enablement team’s primary focus would be to build self-reliance in the team and get out of dodge. A key principle in Modern Testing.
How “testing people” could fit into the other two teams (Subsystem & Platform), I would have to consider a bit more. The testing activity is in both, and the Enablement team also facilitate (testing) into those two team modes/units. So perhaps it’s not that different. What do you think?
The findings of the model also aligns with the “Product Team” and “Competence Team” of this article (in Danish): Hvilke karakteristika og udfordringer har dit team?
Reality, though, is a bit more complex. Even the Team Topology Model – is just a model, and wrong a some point. It is though still useful in enabling a discussion on where the testing people fit it, and why.
Complexity is a Matter of Perspective 