7.7 Practical application to professional practice
7.7.4 How would I go about using it?
Participants found facilitation useful (§7.3.1). In theory the workshop could be conducted following the same procedure without the need for a third party, but this has not yet been tried. There is a risk that without one, prompts to get quieter people to contribute might be missed and the discussion get off track. A third party is desirable not only to manage the workshop but to create a tangible outcome for follow-up as the research participants suggested. The proposals in section §7.3.1, for example, require someone to record the decisions about follow-up actions. It appears from a participant’s comment about having someone with “the ability to make improvements” that they considered some improvements possible, but not within their own capability to make. This does not mean, though, that the facilitator needs to be a person with authority to make certain changes. Indeed such a person may have too much of a stake in the discussion to be an effective facilitator. The important thing is perhaps not so much who facilitates as that conclusions about viable actions are captured and taken forward with appropriate support for acting upon them.
outcome that is beyond the powers of an external facilitator to fulfil. While features can be incorporated into the procedure to prompt and facilitate it, there is nothing to prevent participants from making notes and resolving to exercise their own “ability to make improvements”. At one company there seemed to be an air of resignation about changing a characteristic of the work which appeared to be beyond their control, but this was unusual. Having owned the discussion to address local issues in detail, it is not clear why this did not necessarily extend to owning potential solutions. Perhaps it was simply an issue of having a written record as a reminder (as suggested by the comment “take notes for us”), but there is something troubling about the phrase concerning someone “with ability to make improvements”. The appropriate ways to address this will be local according to the make-up of the group and the way that the business is run, but a clear message about expectations, responsibilities and support for participants to enact change would be a useful addition to the workshop. The material concerns programmers’ decisions and actions, so unless constrained by the weight of past decisions it should be within the power of programmers themselves to change these.
The procedure itself (§7.3.1) is straightforward and requires only an uninterrupted meeting room with a large table, simple materials and an hour of people’s time. In the research workshops, participants spent the hour focused entirely on this activity with no interruptions or use of laptops or mobile phones. This is considered essential; listening to others’ explanations is a fundamental part of the workshop objectives and engaging fully only when speaking would undermine the purpose of holding the workshop.
In the research workshops the agreed time was one hour and the procedure was for everyone to choose one card each. When there was time to spare one or two additional cards were allowed, but this was a mistake; the workshop should focus on each person’s top priority. Sometimes a further card enabled people who had found it a hard choice to include the one that came a close second, but a more appropriate step would be to take that forward for future action (such as a another workshop session in a series of regular reviews).
The desired outcome should be considered when setting up a workshop, and the follow up planned accordingly. As suggested in §7.7.3 the materials and discussion procedure might be adapted according to local needs. Similarly any follow-up procedure adopted should reflect these needs; whatever form the follow-up may take, there should be one if the workshop is to be more than a one-off, “so what?” talking shop.
The focus here has been on the workshop format, designed as it is to use the findings of the Exploratory Study by helping developers to discuss aspects of practice which have been shown to exercise their peers. However the materials of the Exploratory Study have also proved useful. One company involved in both the Exploratory and Evaluation Studies reported that staff participation in the former had generated a lot of discussion for some time afterwards. They requested a copy of the interview cards and envisage continuing to use these to reflect on their practice, perhaps annually or to initiate similar discussion with programmers who join the company. Taking time to reflect, as in agile retrospectives (Derby & Larsen, 2006), can be a valuable process for a team to solve its problems and build on its strengths. The materials used in this research can act as a catalyst to focus attention more widely than the confines of the current most urgent problem or the conduct of the most recent sprint, encouraging a holistic review of the whole software development environment created by the team.
7.8 Conclusion
The response to the workshops was resoundingly positive, with 96% of participants happy to recommend the workshop to others and many of them suggesting ways they would like to use it themselves in future. Their suggestions invite further developments of the workshop itself and also raise the possibility of doing more with this kind of socio-technical approach to helping software developers. These are discussed in Chapter 8.
Chapter 8
Summary
8.1 Introduction
This research looked at good practice from a novel perspective, focusing solely on the impact software developers’ practices have on their peers’ day to day working life. Which practices commonly present a particular help, making them “team- friendly”, and which are a hindrance? The reasoning for this perspective was set out in Chapter 1 and placed in the context of other research into the practices of software development in Chapter 2.
The research sprang from personal experience and the desire to create a practical
outcome of real use to software developers. This background underpins the
pragmatic approach to the research set out in Chapter 3 and the emphasis on designing a technique that would meet the need of the target audience.
To ground the research on a broader foundation than personal experience alone, an Exploratory Study (Chapter 4) was conducted to identify common themes in experienced developers’ accounts of what is, and is not, team-friendly practice. The findings (Chapter 5) represent a distillation of over 400 years’ experience in the industry from 28 developers working in different software domains. It is unlikely to overlap perfectly with the picture that would be produced by talking to novices; the practices identified are those which continue to affect developers for good or ill long after their novice days are behind them.
Practices were not included unless they had peer impact. For example, practices affecting such factors as the speed or reliability of software were not appraised on these criteria so made an appearance only if reported by software developers as something that affects their Developer eXperience (DX). This is not to say that the scope was narrow. In focusing on the developer’s perspective, the research took care to include not just coding but the full breadth of tasks including software architecture, builds, testing, bug reports, version control and direct interactions and experiences with peers. This phase of the work answered Research Question 1, as summarised in §8.2 below.
Identifying peer behaviours that are team-friendly or otherwise was not the end in itself but the prelude to designing a practical application to help teams reflect on their own practices and identify changes they would like to make. This took the form of a workshop design in which team members selected their own choice of topics from themes which interviews with experienced software developers had shown to be important (Chapter 6). This approach not only used an engaging format but was calculated to minimise any sense of personal criticism by presenting only topics
validated by people from outside the company.
The teams involved in the testing of this innovative workshop evidently enjoyed the experience and found it useful (Chapter 7); after taking part, 96% said they would recommend it to others. This gives a very positive answer to Research Question 2, as summarised in §8.3.
The success of the research in its stated objectives suggests potential avenues for further investigation, as well as wider dissemination of the approach so that it can be of use to other teams. This is discussed in §8.4.