It’s fair to say that most organisations I’ve worked for recently have adopted the Spotify model. Usually in a way that manages to reorganise their development and operations teams. Leaving other shared services (infrastructure) at the mercy of shared budgets and project funding models.
Matthew Skelton and Manuel Pais had created a set of DevOps Topologies from years of consulting for organisations. I found myself recommending these as a way of visualising where you are now in a transformation. Where you want to be and identifying transition states between. As a consultant I often feel that most organisations stated that they were doing one thing. But their organisation design was more like another. Thus making transformation much more difficult.
Also, with testing and testers in mind, I have been party to similar transformations. Let’s call all the testers ‘Quality Specialists.’ All the testers will be a central quality consulting team. Or we won’t have any testers at all. Without a way of expressing what that journey looks like, usually testers carried on doing what they did before. How they would interact with other teams, what capability they will enable, success indicators all neglected.
It is great to see Matthew and Manuel have extended DevOps Topologies into Team Topologies. I do recommend the training and don’t want to spoil it too much! So I thought I would share a few thoughts around the training work and its significance for testing.
- Conways Law – If we are likely to replicate our communication structures within the systems we build then how and where testers communicate the information they find is important. If the information discovered while testing is only communicated within that team, will the system that team builds be less transparent? Lack of diversity in testing skills and techniques might mean that testers focus on user interfaces. Rather than testing business logic and lower as well. This could lead to ‘thicker’ user interfaces, but unreliable back end services.
- Cognitive Load – during the training we looked at different types of cognitive load and how that impacts delivery, team size and wellbeing. Trying to build whole team testing cultures within organisations has the potential to increase cognitive load. Especially in teams that relied on a separate testing function. Good software testing is an intellectually challenging activity. So challenging that we may well be increasing the cognitive load on a team beyond a tipping point.
- Team Types – the course talks about 4 core team types. Stream aligned teams working on a service or set of features. Enabling teams which bridge capability gaps. Platform teams which build services to assist flow in stream teams. Finally complex subsystem teams for parts of the product which need specialist skills. Testers could be part of any of these teams. Testers as enablers for certain capabilities. Or testing hard problems within a complex subsystem entered my head as options.
- Interaction Types – I’ve worked in a lot of places where collaboration is a goal. Collaboration does have extra cognitive load. If this collaboration goes on forever and never ‘normalises’ in a common service, then that cognitive load goes on forever. What does that mean for flow of valuable work? I admit I’d never thought of it like this, it felt a little jarring at first as I’ve spent a career encouraging lots of collaboration.
There is a lot more I could add. I would encourage you to buy the book and if you get chance attend the training with either Matthew or Manuel.
How we design our organisations has a profound impact on testing and those who identify as testers. Team Topologies is a great set of heuristics for thinking about how to test our organisation design.
Diagram Industries 