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

Getting from the second to the third phase can be seen mostly as a
result of the team’s realization that progress was too slow and that
something must be done. The means for the transition to take place,
was the interaction with the OSS community, the only place where
the necessary knowledge could be found. In what follows, we will
focus on an important mechanism enabling this interaction: the
brokering performed by one team member.
In our case, Ethan took on the role of broker between the team and
the OSS community. In the community, he presented the team’s
challenges in a way which was meaningful to the OSS developers.
Back in the SE student team, Ethan explained what Bernhard’s
feedback meant to their work and translated it into Java code in
collaboration with the other programmers.
In the brokering process, there were artifacts that can be seen as
boundary objects [15] enabling meaning-making across
communities. The auctioning system, from the outset unknown to
Bernhard, gradually became more useful in mediating interaction as
specific modules were discussed and changed. Pieces of code were
described but also submitted in ‘raw’ format, explored, and perhaps
modified and returned. Further, the PLENTI framework itself
mediated the interaction: From the start, PLENTI was well known
to Bernhard but not sufficiently mastered by Ethan and the team. As
the interaction proceeded, the team’s knowledge improved to the
point that it became meaningful to discuss changes to PLENTI
itself. The roles of the boundary objects in each of the communities
were of course different: For the SE team, PLENTI was a means to
develop a working auctioning system. To Bernhard, having
someone doing development by the use of PLENTI was a means to
improve PLENTI itself.
We leave the elaboration on boundary objects at this point, noting
that they should be seen as integral to the brokering and enriching
our understanding of the process. Having argued that Ethan was in
fact a broker, we turn the discussion to how the brokering empowers
the broker, with possible effects on the SE project.
6.1 The power of the broker
We suggest that the broker between a SE team and an OSS
community gains increased power in the team in three ways: 1)
through his position as gatekeeper of knowledge needed by the
team, 2) through strengthening his existing authority as a
programmer, and 3) through increased credibility in both
communities through the feedback provided in the OSS community
In what follows, we pursue these arguments referring to our case.
6.1.1 The power of the gatekeeper
As the broker translates knowledge from one community to the
other, he simultaneously controls which information flows between
the communities. It is the broker’s interpretation which will reach
each community, even if he faithfully aims to represent the
community’s interests and not his own vested ones. When the
receiving community depends on the information to succeed with
their core activities, controlling the information is a great source of
power and an opportunity to control the agenda. Some
characteristics of our case point to the gatekeeping role of the
broker.
First, it is only Ethan in the team that interacts with the PLENTI
community. Thus, no one else actually passes the only gate towards
the PLENTI community, namely the listserv, apart from reading the
resulting threads there and taking part in the interpretation of the
new knowledge in the context of the team’s work. Nothing would
have prevented the other team members from communicating with
Bernhard if they wanted to. However, the division of labour letting
Ethan take on the role as broker and gatekeeper seems to be
generally agreed-upon in the team, perhaps because they
acknowledged his abilities to attend to the interests of the team.
Second, Ethan is fairly active in taking and keeping the role as
broker, thus in a sense defending it as his domain. For instance, in
meetings, when unresolved, PLENTI-related issues arise, he is
quick at suggesting that he pose a request to the community.
Third, Ethan’s communication with the PLENTI community is done
through postings partly sent outside the hours of collocated work in
the SE team. The questions asked and the interpretations made in
the OSS community are therefore withheld from, or at least
distanced from the collaborative activity of the team. No one in the
team ever expressed any dissatisfaction over this. This might point
to the team’s general appreciation of members’ flexibility of work
(time and place), but may also indicate satisfaction with the way
Ethan reflected their discussions and represented their interests in
the OSS community.
6.1.2 The programmer increasing his power
The role as broker towards a developer community must be held by
an individual having enough knowledge about development to be
able to effectively communicate over issues important to the
community. In practice, this means a programmer. As argued in
section 2, programming skills give authority in the SE teams. The
programmer brokering towards a developer community gets more
programming skills and thus more power.
The following points from our case serve to illustrate how being a
programmer is highly central to the broker:
First, in the OSS community, the language of interaction is largely
source code as well as considerations on aspects of source code, on
the level of single lines of code and on the level of modules and
versions of the entire system. Ethan makes his requests
understandable to Bernhard by giving excerpts from their source
code, and receives answers directly addressing aspects of the code
or even containing modifications of the code itself. In addition to
being able to ‘speak code’, there is a need to follow the implicit
rules of communication in the forum. It is an open question whether
programmers generally have a better starting point for
communicating in virtual developer forums, but it is not unlikely
that many programmers are experienced in gathering information
from this type of site. In all his contributions to the PLENTI users’
forum, Ethan demonstrates a high degree of literacy in terms of this
communication channel. His contributions appear friendly, polite,
concise and goal-directed, and always appropriate to the context.
Second, being a broker, you need to represent your community.
Representing a SE team in the context of a developer community
means being accountable for the software produced by the team. It
is difficult to see how team members other than Ethan and George,
who had the hands-on experience with the current version of the
code and its unresolved bugs as well as the overview of the current
version of the system, could have communicated with PLENTI
developers over development issues. In face-to-face meetings with
project stakeholders, e.g. the customer, Ethan frequently took on the
task of articulating the status of work and the current issues and
priorities of the team. This worked only partially, as Ethan’s role
and conduct was not quite accepted by the customer. In the OSS
797
115