I originally went to the QA team with the intention to do so but realised I didn’t need to and it worked out well. The popular idea at the time when I joined the QA team was to break up the centralised QA teams. That is, the testers should be embedded into the development teams. I was OK with that though I remember thinking to myself that if you say everyone has ownership of something, you typically wind up with nobody owning it. Also how would you do an E2E test for large integrated systems? Regardless, I figured I’d just get started and figure out that problem later.

After Team Topologies came out I could express what I had in mind better. I was going to divide up my QA teams into 3 types. My QA team was onboard since we were evolving in that direction anyways.

  1. Generalist full-stack testers on stream aligned teams. These were folks who like to learn new things and have breadth of knowledge.
  2. Testers whose depth of knowledge couldn’t be confined to one team. They’d be in the central complex subsystem team. They’d learn to use MBT tools to support the stream aligned teams.
  3. Test automation developers part of a central platform and enabling team updating the test automation platform or going around helping folks improve.

Later on I came across Team of Teams when I was listening to Matthew Skelton on the Engineering Room. What really mattered was the culture, the relationships between the COBOL developers and testers. Their managers weren’t helpful or supportive and in fact were against the change in practice (on paper they were all for it). I remember one of the Java development teams manager actually said that COBOL had a technological advantage over Java which is why this earlier testing was possible. What the COBOL folks did have as an advantage was this great relationship of trust and respect between developers and testers which is why we make it that far.