What could I use it for?

Participants found the workshop a welcome opportunity to stop and reflect about local issues and practices in a way that does not seem to happen within the normal work routine (§7.3.1). Those taking part were already in quite open and communicative teams but although their workshop discussions were not necessarily raising anything entirely unknown to the team they were nonetheless relating and addressing systemic issues that had not received attention when competing with the immediate demands of specific tasks. For some participants it was an opportunity to reflect and articulate ideas for the first time.

The workshops were not merely a theoretical discussion of abstract examples of the possible impact software development behaviours. Participants rapidly recognised their own concrete local issues in the generic quotation cards. These were issues which appeared to be well-known to all present but had not been addressed. The workshop prompted teams to address together the reasons, consequences and solutions for them in a way that had not happened in their day-to-day conversation. This discussion included what was, and what was not, realistic to solve the problem. In some cases this simply led to everyone understanding why an issue was intractable and just something to be lived with. In others, examining it together revealed viable solutions.

Turner and Boehm (2003) noted that Agile methods “cultivate the development and use of tacit knowledge, depending on the understanding and experience of the people doing the work and their willingness to share it.” This reliance is also illustrated by the “Social” element in the model of software developer tasks that emerged from the Exploratory Study (Figure 4). This research suggests that sharing of understanding and experience is an aspect of software development that needs improvement. The workshop could therefore be useful as a framework for retrospectives that facilitate

a broader overview than might otherwise be the case. As Highsmith and Cockburn (2001) observed, face to face communication is faster than writing and reading

documents. And indeed no participant called for more traditional documents,

preferring the documentation inherent in the artefacts of software development that is characterised in Chapter 5 as ”chronicling”. But having fewer written documents means that it is all the more crucial to talk face to face.

Derby and Larsen (2006, p. xv) described Agile retrospectives as “a special meeting where the team gathers after completing an increment of work to adapt and inspect their methods and teamwork”, and presented practical and creative ways to elicit

information using tangible tools such as sticky notes and coloured dots. The

retrospective approach focuses, though, on events during the iteration (increment of work, also known as a sprint) — which is its valuable purpose, but one that does not necessarily prompt a wider holistic perspective on the team’s practices. A wider perspective seems more in keeping with one of the principles underpinning the Agile Manifesto: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly” (Agile Alliance, 2001b). This principle is listed independently of “Deliver working software frequently.” and the Agile Manifesto does not contain any suggestion that retrospectives should be tied to iterations.

Pikkarainen’s (2008) case study of communication within agile projects suggests that practices centred around iterations, whether prior planning or subsequent retrospectives, promote useful communication about the features in that iteration but can have negative effects on the longer-term overall goals. The study examined just two teams, but methods under the Agile umbrella vary widely and are not always clearly specified (Jalali & Wohlin, 2012); it would be difficult to generalise even from a much larger sample when there are so many variables in their practices. It is perhaps more helpful to consider individual practices regardless of the local interpretation of the Agile Manifesto: Vallon, da Silva Estácio, Prikladnicki, and Grechenig (2018) show that retrospectives come fifth in the frequency of agile practices employed in the many case studies they reviewed (44 cases compared to 70 for the most widely adopted practice, standup meetings).

Both Jalali and Wohlin (2012) and Vallon et al. (2018) concern geographically distributed teams, unlike the teams in the workshops. Enquiries about participating companies’ processes revealed that retrospectives are not universally or consistently

practiced as described by Derby and Larsen (2006). One admitted “We do

‘retrospectives’ but only at the end of projects”, which would appear to have more in common with a project wash-up meeting than an agile retrospective, and too

late to help the project. Another said they had “tried a retrospective — but we don’t really have very well defined sprints at the moment.” (note the singular, “retrospective”). Both would describe their process as agile. Exploring the breadth of practices followed under the “Agile” label is beyond the scope of this research but presumably these companies have not seen sufficient value, whether through experience or expectation, to warrant regular retrospectives.

The workshop seems to have given them something that their retrospectives have not. It might, with the refinements discussed below, be a viable alternative that allows them to discuss and address their practices at intervals; another participant evidently also saw room for improvement in retrospectives and explicitly suggested a future use of the format to take a similar approach in coding retrospectives (see §7.4.5). It also has potential as an occasional supplement for teams which do conduct regular retrospectives but want to step back to take a broader view; one participant suggested doing this annually or when new staff join the team. Their feedback about the workshop makes it clear that participants found the workshop experience useful. Participants also had suggestions for using the workshop that went beyond discussions with their existing team (see §7.4.5), as a potential means of facilitating dialogue between teams. There is scope too to use the materials as a tool for assessment. The cards illustrate points that are of significance to others working in a team, so some participants thought the materials would be useful as a point of focus for appraisals, where they could be used to discuss how well the developer measures up on desired team-friendly behaviours. Similarly they could be used as a discussion point in interviews, this time not to ask someone how they fare on any given criterion but to form an impression of their attitude as a developer by asking them to select cards that resonate with them and explain why. This could be done either in an interview panel using just the cards, or in a workshop scenario where they can have a discussion with the team they would be joining so that both sides can assess whether they would “fit in”. The latter could also be useful as an onboarding exercise to help introduce the norms of the team and ongoing issues they are facing.

An approach to using the cards in interviews has already been discussed in detail with an independent experienced developer who did not participate in the research; he has received the materials but at the time of writing had not yet had the opportunity to try them. His analysis (reproduced in full in Appendix S) is that the cards offer a conversation starter to get candidates to talk about the issues they run into and how they tackle them. Giving them choice from a selection of issues raised by experienced people could help to structure the interview around the candidate’s

own experience rather than the interviewer’s and thus avoid wrong-footing them.