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

member. Field notes were made during and immediately after the
sessions, to the extent possible. The team’s supervisor was
interviewed during and after the project, and the team’s customer
was interviewed after the project. The team was interviewed once
during the middle of the project and once after completion of the
project.
Most of the meeting recordings and interviews have been fully
transcribed. Recordings from work sessions have been partly
examined and summarized based on their perceived relevance in the
analysis process. Quotations have been translated into English by
the researcher at need. Analysis of the data started out with some
theoretical concepts being perceived as central (cf. the Principle of
Abstraction and Generalization, [24]). Coding was performed on the
basis of these concepts, by the aid of a computerized qualitative
analysis tool (Atlas.ti). New codes were added as themes developed
during interpretation and writing. For instance, PLENTI was used as
a code to mark and organize data related to the team’s use of the
framework and interaction with the community. Further, the data
have been chronologically structured within selected themes.
The researcher was the coordinator of the project course, grading
the projects, but not supervising any group. In the process of
observing the Anniva team, great care was taken to avoid mixing up
the roles of researcher and course staff and to be aware of the
possible effects of ‘the teacher being present’ (cf. the Principle of
Interaction Between the Researcher and the Subjects, [24]). As part
of the initial agreement between the researcher and the team, it was
decided that another member of course staff set the grade on their
project. Further, it was agreed that the researcher was not to
supervise them, but restrain interaction to being social without
causing too much disturbance. The reason for not supervising was
not mainly that supervision would influence the case. The influence
of the researcher is an inevitable consequence of participant
observation, even if the degree of influence can, and should, be
limited. The team was not, however, to be given advantages as
compared to the other teams in the course, or at least the sum of
advantages and disadvantages of being research subjects should be
perceived as close to zero by the team and by the other teams. These
considerations impacted on the possibility to have the researcher’s
interpretation validated with the research subjects during the study
(cf. the Principle of Multiple Interpretations, [24]). As all teams in
the course were however interviewed about their project work and
viewpoints on the course in the middle of the semester, and on that
occasion it was possible to have some prompted viewpoints from
the Anniva team. Also, the day after the completion of the project, a
three hour interview was conducted with the team to have their
feedback on the researcher’s preliminary interpretation of the
project.
In reflective discussions within the team towards the end of the
project and in the interview conducted after the project, the team
expressed that they had perceived the researcher as non-interfering
and agreeable, and that they had not received project supervision
from her.
To validate findings reported in this paper, a draft version has been
reviewed by two of the team members, Owen and Ethan. Ethan
expressed that he liked the paper. Owen provided more detailed
viewpoints which have been incorporated in the Analysis and
Findings and Discussion sections.
5. ANALYSIS AND FINDINGS
In presenting the findings of our study in terms of the team’s
interaction with the PLENTI community, we have made a
chronological structuring of the material, distinguishing what we see
as four partly overlapping phases.
The first phase is a (dis)orientation phase in which the team strives
to understand what PLENTI is and how to obtain adequate
knowledge about the framework. In the second phase, PLENTI is
regarded by the team as an obstacle, but starts taking on the role of a
tool (albeit not quite mastered by the team). In the third phase, the
team is communicating with PLENTI users and developers through
the listserv of the community, actively making use of the framework
as a tool in the project development task. In the fourth phase signs
of a feeling of identity related to the PLENTI community
participation can be found in the team, and the team is contributing
to the PLENTI development.
In the subsequent discussion (Section 6), we will argue that the
transition to the third phase was essential to the project, and address
how this transition came about in our case. In the present section,
we characterize each phase in more detail, giving some illustrative
excerpts from the data where appropriate.
5.1.1 First phase (January-February): What is
PLENTI?
In the original project description as well as in the initial customer
meeting, it was specified by the customer that PLENTI should be
used as a development framework. The reason was that one of the
two customer representatives had attended a seminar with an
enthusiastic PLENTI developer and thus caught interest in the
framework. During the first customer meeting, the team was offered
the alternative of using another framework, but not PHP, which was
the only alternative with which they were familiar. This left
PLENTI as the de facto option. Adding to the arguments to use
PLENTI, the customer expressed interest in having it tried out to see
how it worked for this type of application development.
None of the students in the team had any advance knowledge about
PLENTI. Further, no one had any experience with the programming
of web applications with servlets. The web pages of the PLENTI
community were the only resource about the framework known to
the team.
The team decided that every team member was to learn PLENTI
and participate in the programming tasks. Two team members, Sam
and Owen, were assigned the task of starting the knowledge
acquisition about PLENTI. Ethan and George, accepted as the lead
programmers in the team, took on the task of developing a prototype
to demonstrate to the customer as a basis for refining the functional
requirements. Ethan worked on the web user interface whereas
George focused on the underlying business logic, none of them
making use of PLENTI for their tasks. Both programmers
participated in team-internal discussions on the role and use of
PLENTI, though. The fifth team member, Morgan, took the role as
project manager, which made him mainly responsible for overall
project planning, generating and handing in bi-weekly status reports
and activity plans to the supervisor, scheduling meetings, and
making sure that work on the project report progressed in
accordance with the deadlines.
794
112