The Retrospective Practice as a Vehicle for Leading Conceptual Change

Introduction

This paper tells the story of how we coached the adaption process of agile software development in a company, with a focus on one specific project. It delivers the message that as soon as software engineers grasp the need for change in the software development process, they can accomplish it; the challenge, however, is to guide them towards the realization of the needed change and let them lead it. Such a realization requires a conceptual change, and it is our role to lead this change in the initial stages of adopting agility. One mechanism we employ to guide this process is one-hour retrospective sessions that take place at the end of each iteration. As soon as team members start facilitating the retrospective sessions by themselves, it signals that a) the team is ready to lead both the conceptual change needed for agility and the change in the development process, and b) we have completed our coaching role with this team. From our perspective, reaching this stage is a landmark of success.

Retrospectives as a mechanism for enhancing a conceptual change

The importance of introducing reflective processes into software development processes in general, and into agile software development in particular, is largely based on Schön's Reflective Practitioner perspective (Schön, 1983).

From a team perspective, the aim of a retrospective process is to examine the development process and find ways to improve it. From the coachers' perspective, retrospectives also serve as tools for the enhancement of a conceptual change. To exhaust their potential, retrospective sessions take place at the end of each two-week iteration and are limited to one hour to ensure productivity. Further, other activities do not take place at this time, and at the end of each retrospective session at least one action item is decided upon with a specification of who is in charge of its implementation.[1]

Figure 1 describes how retrospective session targets can be achieved. The implementation of the specific action item decided upon at the end of each retrospective session creates a change in the development process that can lead to a conceptual change about the process itself. This change, especially in gradual agile implementations, creates a new need-for-improvement in the development process that eventually becomes the topic of one of the future retrospectives. In this manner, and in the spirit of the conceptual change established through this process, this cycle continues when each small conceptual change leads to the next one. Gradually, these small conceptual changes accumulate to a meaningful change in the team's conception of software development. As illustrated below, our experience has shown that at some point, this change is significant enough to enable the team members to start facilitating the retrospective sessions and leading the conceptual change themselves.

Figure 1. The retrospective cycle: Retrospectives as a vehicle for a conceptual change

The story

The project environment

This story focuses on the application of agility in a complex, one-of-a-kind project, tailored for specific customer needs. The specific project was a system development, i.e., disciplines other than software, such as hardware, firmware, and mechanics were also part of the project development. Such projects have relatively long development periods, taking several years and sometimes even several generations.

Due to several major problems, such as frequent requirement changes, expensive overheads (mainly due to inter-disciplinary coordination and integrations), and a lack of communication within the team, the project leadership decided to start the examination of agility with the software team, which consisted of 15 members, organized in four sub-teams. Most team members were skilled, embedded real-time software engineers, specializing in networking and communication. Some were team leaders.

Agility was adopted in two stages. In the first stage, the following agile practices were applied within a Scrum framework: Sprints of eight weeks each, daily standing meetings in sub-teams, maintaining a sprint backlog, sprint summaries (presentations), and sprint retrospectives. This stage was a big step towards improvement in many aspects: planning, communication, and customer (system engineer) collaboration.

However, it seems that more substantial and courageous action must be taken to make the best of this methodology. Furthermore, the sprint reviews did not include any measurements, so there was no objective data about process achievements, no way to measure improvements, and no way to improve the process systematically.

In the second stage, which we guided starting five months later, the process was tightened up. Specifically, the software team adopted the following agile practices: short two-week iterations, customer involvement, measurements, role assignments, and bi-weekly retrospective sessions.

Illustrations of the retrospective cycle by retrospectives on knowledge sharing

To initiate the conceptual change associated with agility, at the beginning of the second stage, retrospective sessions were facilitated by us, built on the software practitioners' expertise in software engineering.

Table 1 describes the first 15 retrospective sessions that took place with the team. As can be seen, knowledge sharing was the subject of several retrospectives. According to the retrospective cycle (Figure 1), this focus of the retrospectives was not determined at the beginning of the coaching process; rather, the topics of the retrospective sessions emerged during the transition process to agility. The fact that several retrospectives focused on knowledge sharing should not be surprising; after all, software engineering is knowledge work and therefore, it makes sense that knowledge sharing was elicited as a topic that should be addressed in the adoption process of agility.

Table 1. Retrospective sessions (#1-#15)

Figure 2 illustrates the retrospective cycle in the case of knowledge sharing, showing how retrospective sessions can foster a conceptual change with respect to knowledge sharing.

Figure 2. The retrospective cycle in the case of knowledge sharing

We now describe two retrospectives on knowledge sharing and explain how they can foster conceptual change.

Second retrospective (one month after starting the coaching process): Team members were asked to indicate three positive things and three things to be improved in the current development process. Lack of knowledge of the different parts of the project was identified as something to be improved, and was selected for focus from all topics suggested by team members. The action items decided upon at the end of this retrospective were a) mapping the expertise areas of each team member (the team leader took the responsibility of the accomplishment of this task) and b) in consecutive iterations, assigning team members who are not experts in specific domains to be in charge of tasks belonging in these domains.

The implementation of these action items initiated a process of knowledge sharing in two ways. First, team members had to indicate their expertise in the different parts of the projects. For this purpose, they had to a) evaluate their knowledge level with respect to the different parts of the project and b) share this evaluation with other team members. Second, the assignment of tasks in specific domains to people who are not experts in these domains a) expanded their knowledge about the different parts of the project and b) encouraged team members, who are experts in these domains, to share their knowledge to support the accomplishment of these task successfully. It is reasonable to assume that each of these four actions contributed to knowledge sharing and changed the team's conception of development processes in a way that closed knowledge gaps with respect to the different parts of the project.

Seventh retrospective: Following our visit to one of the stand-up meetings, we realized that a knowledge gap existed with respect to concepts mentioned by team members at the stand-up meeting. After confirming that these gaps indeed existed, we decided to focus in the seventh retrospective session on closing these knowledge gaps (at least partially).

The retrospective started by asking each team member to write down three concepts mentioned in the stand-up meetings that he or she did not understand. All these concepts were then written anonymously on a white board, and team members voted on each concept to indicate whether they understood it or not. This process took 10 minutes. The team was then divided into five groups and each group was asked to choose one of the concepts and take twenty minutes to prepare a short presentation about it. The five groups then presented their five-minute presentations, each followed by one minute of short questions and answers. The action item decided upon in this session was to organize the presentations in the team repository.

This retrospective had several outcomes connected with knowledge sharing. First, team members had to scrutinize their knowledge of concepts mentioned in the stand-up meetings and define their familiarity with various unclear concepts, either suggested by themselves or by other team members. Second, during the work in groups, team members had to share their knowledge once again to prepare the short presentations. Those familiar with a concept had to share their knowledge for the sake of the presentation, while those unfamiliar with that concept had to ask questions and indicate what was unclear. Third, during the group presentations, all that knowledge was shared.

As a result, in one hour, five unclear concepts were identified, short presentations about them were prepared and shared with all team members, all team members were involved, and each team member had to share his or her knowledge. Clearly, a shift towards knowledge sharing culture was achieved.

Team members start leading the conceptual change

Eight months after we started the coaching process, during which time agile software development principles were gradually introduced and applied, a retrospective session was dedicated to summarizing what had been accomplished so far. We asked team members to indicate three positive things that had happened during the process and three things that still needed improvement. As a result of this retrospective, two topics emerged as issues to be addressed: a) the time dedicated to knowledge sharing in the team; and b) avoiding time pressure. In the consecutive retrospectives, we further investigated these outcomes.

One of the next retrospectives took place about a year after we started the coaching process and addressed the topic of avoiding time pressure. At one point during this session, one of the team members interrupted the discussion and said: "We're missing the point. In the past several retrospective sessions, we have looked at measures that we didn't understand, but it is actually more important to analyze problematic tasks." We recognized that this was a suitable moment to let the team members themselves start leading the retrospective sessions, so we stopped the retrospective and told that team member: "Please go ahead and continue facilitating the session". That team member took the lead very naturally and continued with the facilitation of the retrospective. The action item at the end of that retrospective was the identification of a list of problematic tasks.[2] Several team members, it was planned, would each select a task and facilitate a retrospective about it.

From that point forward, one year after we started the coaching process, the retrospective sessions were facilitated by the team members themselves. In a very natural process, the topic for each retrospective was identified either by the team or by one team member who suggested a topic that was important for him or her to address (time estimation and personal responsibility are only two examples).

Summary

This story illustrates how a conceptual change is tied with a technical change, and suggests one mechanism – retrospective sessions – that connects these two processes. From our perspective, as coaches of agile adoption, success is achieved when the development team, who are experts in the engineering aspect of the development process, can carry out these two change processes simultaneously.

References

• Hazzan, O. and Dubinsky, Y. (2008). Agile Software Engineering, Springer.
• Kerth, N. (2001). Project Retrospective, Dorest House Publishing.
• Schön, D. A. (1983). The Reflective Practitioner, BasicBooks.

About the Authors

Dr. Orit Hazzan is an Associate Professor and Head of the Department of Education in Technology and Science of the Technion – Israel Institute of Technology.  She earned her B.Sc. (1989), M.Sc. (1991) and Ph.D. (1995) from the Technion's Department of Education in Technology and Science. After a post-doctorate fellowship at EDC (Educational Development Center), Boston, MA, USA (1995-1996), she pursued an MBA from the Technion's Faculty of Industrial Engineering and Management (2000).  Her research deals with computer science and software engineering education, and specifically, with teaching human aspects of software engineering. Her research has been conducted in different research arenas: high schools computer science classes, undergraduate computer science and software engineering programs, the hi-tech industry, and the public sector. Hazzan published about 100 papers in professional journals and conference proceedings and co-authored three books: Human Aspects of Software Engineering (Charles River Media, 2004), Agile Software Engineering (Springer, 2008), and Guide to Teaching Computer Science: An Activity Based Approach (Springer, 2011). Additional details about her activities can be found in her homepage.  

Dr. Yael Dubinsky is affiliated with the Software and Services group in IBM Haifa  Research  Lab  (HRL).  She has published her work at conferences and journals  related  to  software  engineering  and  information systems, and organized  workshops  and  tutorials  in  leading  conferences.  Yael has a significant  experience  with guiding agile implementation processes in the industry  and  academia.  Her book on Agile Software Engineering, which she co-authored with Orit Hazzan, was published by Springer in 2008.

[1] For additional guidelines concerning how to facilitate retrospective sessions, see our book (Hazzan and Dubinsky, 2008) and other books about the facilitation of retrospectives (e.g, Kerth, 2001).

[2] A problematic task was defined as one for which a significant gap existed between its estimated implementation time and the actual time it took to accomplish it.