Communication channels

I attended a meeting of the Software Test User Group Hamburg last week, which was an open discussion on how testing and the role of testers have changed in agile contexts. I won’t go into detail here on the “Quo vadis, QA?” part, but there was a statement during the discussion that I would like to have closer look on: “Of course there are differences in processes and methodology between waterfall and scrum, but the main difference are communication and accountability.” While I don’t think that these two are the only differences, I would agree on those two being important ones.
This blog post will deal with the differences in communication. I have described communication in waterfall and scrum already before, but more in terms of register in general, less in terms of actual usage. Accountability certainly warrants a post of its own and won’t be discussed here.
Let’s have a look at a tweet first that I had to think about when the discussion turned towards communication:

Question about preferred size of a #Scrum team made me visualize this today: “Why BIG teams fail!!1!” 🙂 #agile pic.twitter.com/gyJrGpaIpw

— Jordann Gross (@JordannGross) 8. April 2016

You may know the underlying concept as two pizza team size. So what is it about? If teams grow too big, there are too many potential communication channels providing overwhelming information which will inevitably lead to stalling a team. So would it be better to limit possible communication channels to one or two? I don’t think so (and judging from the colors used in the sketch note the author seems to agree).
Let’s have a look at this:

The sketch depicts a situation where communication channels are closely aligned to hierarchy. So if I am tester and need some information about the requirement, I’d ask the test manager, who then might go and ask the project manager who would ask the business analyst, who would ask the requirements engineer. All in all four communication acts would be involved and that’s just for getting the question to someone who is supposed to know the answer. Getting the answer to the question asker will double that. Chinese whispers, anyone? I know that this sounds rather constructed, but unfortunately it is not. I experienced similar settings not too long ago.
While I have reduced my possible communication channels as far as it gets in this example (well, not communicating not taken into consideration that is), the total number of communication acts (8) and thus the number of additional communication gateways (6) has increased when compared to the communication acts needed when all persons were on the same team as shown in the tweet above.
In scrum, while I may have more possible communication channels, the actual number of communication acts is reduced. In my opinion the number of possible communication channels needs to be as high as possible and as low as can be managed without managing cutting into other activities.

A thing we have to keep in mind is that only in rare occasions are the other team members the only persons I need to communicate with. As a tester on a team I may be on a testing community of practice, I may need to talk to the company secretary, the janitor, the CEO from time to time, so we might even have to differentiate between primary and secondary communication channels.  On the positive side as well you will that limiting primary communication channels, i.e. limiting the number of people on a team, will make it easier for teams to make decisions. On the other hand you need to make sure that all necessary skills and information for the team to be successful are within reach. So it is not about tipping the balance, but about keeping the balance between possible communication channels and managing the number of communication channel without needing extra effort. Scrum provides a great framework for this in my opinion by already narrowing down the possible primary communication channels to a manageable number, while keeping the number of potential communication gateways down as well. But regardless of the chosen methodology, this is something to be taken into consideration when talking about teams, team size and communication.

And comparing the tweet and my sketch, I really need to work on my sketch note skills…