The work-reflection-learning cycle - Department of Computer and ...

project trajectory and involves facts as well as feelings. Anselm Strauss [3] uses the term
‘trajectory’ to describe: “(1) the course of any experienced phenomenon as it evolves over
time” (e.g. an engineering project) and “(2) the actions and interactions contributing to its
evolution” (pp.53-54). Events in a SE project can be understood in terms of the action and
interaction taking place within the team and between the team and other stakeholders. While
Strauss uses the concept ‘arc of action’ to describe a trajectory as retrospectively understood,
we apply the term ‘reconstructed trajectory’ to the retrospective understanding of the process.
From a social constructivist perspective [4, 5], project reality is interpreted through the
individual’s unique history of social interactions. Team members assign different meaning
and significance to events based on their previous experience and can be expected to
remember different facts as significant to the project. Making a shared, reconstructed
trajectory can be seen creating common ground [6] for communicating about the project
process. Possible disputes over facts may be settled by checking available evidence. In the
case of the interpretation of events, completely shared understanding among team members is
unattainable in principle, but participants may get a richer understanding of the process
through the encounter with others’ perspectives. Contradictions or discrepancies between
interpretations may serve as a source of reflective thinking [7]. To support reconstruction of
the shared trajectory and its use in reflection, it may be given a visual representation
containing elements that are considered shared and agreed-upon as well as elements
representing individual and possibly conflicting interpretations.
Boud and colleagues present a model of reflection outlining three major components:
experience(s), reflective process, and outcome [8]. Experience involves behavior, ideas and
feelings. In the reflective process addressing the experience, there are three steps: 1)
Returning to experience, 2) attending to feelings, and 3) re-evaluating experience. Essentially,
this means reconstructing the trajectory of the experience. Boud et al.’s model is adequate for
guiding the reconstruction of a project trajectory in a postmortem review. In particular, the
process of reconstruction can be approached by decomposing it into the steps of returning to
experience, attending to feelings and re-evaluating experience. As Boud et al. stress, the steps
should not be understood as a fixed template. Reflection is situated and creative, moving back
and forth between steps and sometimes omitting them.
Among the many SE postmortem techniques [1] there is an approach which reflects well
the idea of reconstructing a project trajectory: the timeline exercise as outlined by Derby et al.
[9]. An example of its use in industry can be found in [10]. The exercise is based on industry
best practice for postmortems. While the context of [9] and [10] is agile development, the
timeline technique is not bound to any particular software lifecycle model. Derby et al.
outline a basic exercise with some possible variations. The purpose of the exercise is to
stimulate memories, make a picture from many perspectives, examine assumptions about who
did what when, and see patterns. The exercise may be used for ’just the facts’, or facts and
feelings.
In the next section, we show how we have adapted and detailed the timeline exercise in
line with the previously presented theory.
3. Design of a postmortem workshop in a SE project course
The case of our study is an undergraduate project course taking up 50% of students’
workload in the last (6 th ) semester of the Bachelor program. The teams develop software for
genuine customers. Each team receives one grade and has a supervisor from course staff.
Deliveries include a software product, a project report in several versions and an oral
86
Authorized licensed use limited to: Norges Teknisk-Naturvitenskapelige Universitet. Downloaded on February 5, 2010 at 09:01 from IEEE Xplore. Restrictions apply.
164