Communication in Software Testing: Scrum

Introduction

This post is the third and last in a three part series about communication and natural language in the context of software testing and software development in general. This will be done taking the register approach the way Douglas Biber and Susan Conrad proposed it into account. I will not conduct a full-fledged register analysis, but will rather work out the situational context.

The first part laid the theoretical foundations, while this part will have an exemplary look at the scrum software development process:

Part 1: Communication and register analysis in general

Part 2: Communication and register in software testing (waterfall)

Part 3: Communication and register in software testing (scrum)

Scrum

Scrum is one of several software development processes. I took it as an example as it is a representative of the lightweight, iterative and incremental models around.  Scrum is probably the most common agile development framework nowadays, which makes it a good example to examine.

There are six major acts of communication:

1. Requirements collection
2. Story writing
3. Sprint Planning
4. Daily meeting
5. Sprint Review
6. Sprint Retrospective

There are of course others and I actually thought a lot about including backlog grooming into the list, but finally decided to go with the core elements of scrum (well, at least the way I understand it).

Requirements collection

This act of communication does not differ a lot from the requirements collection in the waterfall model. Of course the roles have different names and most requirements are denoted in the form of user stories, but it pretty much boils down to customers sharing their ideas, visions, requirements with the contractor. In this case represented by the product owner. So the participants, purpose and topic are somewhat defined.

The circumstances, the channel and the settings are not though and will differ. Again, you could argue that there are different registers in place here. I will not go into detail here, because I would have to repeat what I wrote in part2. But be assured that the similarities in communication between waterfall and scrum end here.

Story writing

Story writing is the only act listed here that does not share a common time or place which is due to the medium and circumstances. The topic is probably the main aspect of this act as it is all about a common basis for the sprint planning. Possible refinement activities are not part of this act, so there is no direct feedback integrated here. We are dealing with a rather directional communication here.

Sprint Planning

This act of communication is interesting as it is actually an act of communication about another act of communication (i.e. the user stories). The interactive feedback is an integral part of this act.

Daily Meeting

The participants and channel do not differ from the sprint planning: all developers gather for a spoken meeting. The medium is semi-planned, since the main purpose of the meeting is to inform the participants of the answers to the three questions that define the topic. Often discussions emerge, but this meeting is supposed to be limited to the questions, since most discussions are only valid for a part of the participants.

Sprint Review

Stake holders can be involved as participants here, but it is generally a developer to product owner communication. I included the software as a medium here, as in addition to speaking about what has been done it is shown as well to get an approval. The circumstances are again semi-planned because it is known in advance what will be talked about: the user stories selected in the sprint planning will be the topic for this act of communication.

Sprint Retrospective

The retrospective is again guided by given questions, so the topic is somewhat fixed. It is noteworthy that only developers are among the participants and opinions are more than welcome.

Evaluation of the communication in scrum

Two things really stand out when analyzing the communication in scrum:

1. most acts share a common time and place
2. most acts are oral ones

Both support direct interaction between participants and thus a straight feedback opportunity, something we missed in the waterfall model. Another result of these two things is that there are not as many documents which need to be realized, thus saving time by focusing on just the necessary documents (the definition of these is a totally different story, though). If we take the GateKeeping theory into account, there is only one person as a gate between the customer and the developers (including the testers): the product owner, who has a lot of responsibility as far as communicating the right contents is concerned, thus making the role vital.

You will have noted that I omitted the scrum master from the tables and the situational context. The scrum master is a passive participant in all acts. I would agree with people saying that the sprint planning and the sprint review would be notable exceptions, where a scrum master would take on a more active role. But this really depends on the team and its experience with scrum.

Overall I would argue that communication is generally easier in scrum since direct feedback is an integral part of it. In addition the product owner really needs to be aware of him being the gatekeeper of all communication between the customer and the team.

So much for defining the situational context of communication in two development methods. Within the register framework we would now have to identify the prevalent linguistic features and an analysis of why these features were used in this context. But that was not really the focus of this series, I wanted to work out some general linguistic ideas about communication and especially the situational context within a register analysis with the purpose to show where in software development people communicate in what ways. And I hope some of you got something useful out of this. I did at least while writing and thinking about it.