Received: 30 October 2017 Revised: 28 June 2019 Accepted: 8 July 2019

DOI: 10.1111/isj.12261

RESEARCH ARTICLE

The use of prototypes to bridge knowledge

boundaries in agile software development

Thomas L. Huber1 | Maike A.E. Winkler2 | Jens Dibbern3 |

Carol V. Brown4

1
ESSEC Business School, Paris, France
2
Competence Center Learning and
Abstract
Development, Die Mobiliar, Bern, Switzerland Bridging knowledge boundaries among project team mem-
3
Institute of Information Systems, University bers is essential to prevent delays or complete failure of
of Bern, Bern, Switzerland
4
software development projects. Prior researchers have
School of Business, Stevens Institute of
Technology, USA - retired reported that software prototypes can be used to help
bridge knowledge boundaries between team members in
Correspondence
Thomas L. Huber, ESSEC Business School, traditional software development settings, yet their use in
Cergy & Paris, France.
an agile development setting remains unexplored. Agile
Email: huber@essec.edu
development centers the interactions between team mem-
bers on emerging representations of the prototype whose
properties are prone to change over time. Therefore, we
conducted an in-depth study of an agile development pro-
ject to enhance our understanding on how software proto-
types are used as boundary objects in a distributed team
setting. Our analyses of team member interactions during
46 virtual meetings that took place over a period of 6
months revealed four different prototype use practices
(exemplifying, contrasting, relating, framing) that were
effective in bridging syntactic, semantic, or pragmatic
knowledge boundaries. We also provide empirically
grounded evidence of how variations in object properties
can afford different use practices, how the use practices
take advantage of these properties, and how object proper-
ties are reshaped through these use practices as different
types of knowledge boundaries are bridged. These findings
bear important implications for research on prototypes as
boundary objects in software development in particular and
boundary object use in general.

Info Systems J. 2019;1–25. wileyonlinelibrary.com/journal/isj © 2019 John Wiley & Sons Ltd 1
2 HUBER ET AL.

KEYWORDS
agile software development, boundary objects, object properties,
observational study, software prototype, use practices

1 | I N T RO D UC T I O N

Bridging knowledge boundaries among project members is essential for the success of software development pro-
jects (Guinan, Cooprider, & Faraj, 1998; Rosenkranz, Vranesic, & Holten, 2014). Such projects often suffer from large
asymmetries of knowledge between the software product owners who formulate the requirements to achieve
desired benefits from the software and the technical experts who are responsible for the technical design and imple-
mentation (Tiwana & Mclean, 2005). The bridging of knowledge boundaries is particularly challenging in distributed
team settings because team members are separated not only in terms of knowledge domains, but also linguistically
and geographically, which complicates communication among team members (Kotlarsky, Scarbrough, & Oshri, 2014).
If during the course of a project the knowledge boundaries are not successfully bridged by inter-personal interac-
tions between team members, this can lead to project delays or complete project failure (Levina & Vaast, 2008;
Tiwana, 2004).
Prior research in traditional systems development settings has reported that software prototypes can be used as
boundary objects, ie, objects that help bridge knowledge boundaries (Doolin & McLeod, 2012; Rosenkranz et al.,
2014). In recent years, however, systems development projects have increasingly shifted from traditional to agile
development approaches (Stavru, 2014). Despite this shift, the use of prototypes as boundary objects in an agile
development setting has remained unexplored. This is an important research gap because agile approaches break
down development work into short iterations (Ghobadi & Mathiassen, 2016; Ramesh, Cao, & Baskerville, 2010) and
software prototypes are at the center of these iterations (Marshall & Bruno, 2009), ie, prototypes become dedicated
boundary objects. Specifically, throughout each iteration, prototypes are used to evaluate, validate, adjust, and refine
requirements (Marshall & Bruno, 2009; Ramesh et al., 2010). Because iterations are so short, prototypes entail not
only functional pieces of software but also intermediate work products such as paper prototypes, click dummies, or
UML models (Marshall & Bruno, 2009; Ramesh et al., 2010). Team members may use these different prototype vari-
ants in different ways and to convey different types of knowledge. We therefore seek to expand our understanding
of how to use prototypes in ways that facilitate the effective bridging of knowledge boundaries, by examining the
following research question:

RQ1 How do different ways of using software prototypes as boundary objects help to bridge different knowledge
boundaries in agile software development?

Further, recent research has begun to indicate that a deeper understanding of how objects facilitate the bridging
of knowledge boundaries requires in-depth investigations of the “mutually constitutive” nature of object properties
and object use practices, ie, how object properties afford use practices and how the way an object is used shapes
object properties (Doolin & McLeod, 2012, p. 573). In agile software development, the dedicated boundary object—
the prototype—is emergent throughout the development process, prototypes exist as a series of variants of the
desired product (Dingsøyr, Nerur, Balijepally, & Moe, 2012; Ramesh et al., 2010), and these different variants can
have a completely different form than the final product (Marshall & Bruno, 2009). At the same time, in the process
of using a software prototype as a boundary object to bridge a knowledge barrier, the properties of the boundary
object are also likely to change. The specific role that such differences in object properties play in boundary bridging
is yet to be explored. Thus, studying the mutually constitutive nature of object properties and object use practices
HUBER ET AL. 3

with software prototypes in an agile development setting is likely to yield novel theoretical insights on object use.
This leads to the following second research question:

RQ2 What role do the properties of prototypes as boundary objects play in the bridging of knowledge boundaries?

To answer our research questions, we conducted an in-depth case study of an agile software development pro-
ject in a distributed team setting. We use observational and archival data to inductively build a theory that explains
how software prototypes in agile development become recognized as boundary objects that can achieve varying
boundary bridging consequences. Our key finding is that the effectiveness of a software prototype as a boundary
object depends on use practices as well as the variation and change in object properties of the prototype(s) used.
Specifically, we show which practices of using a prototype result in team members bridging different types of knowl-
edge boundaries. Moreover, we empirically unpack the dual role of object properties for the effectiveness of these
practices by showing (a) how variations in object properties can afford different use practices that take advantage of
these differences and (b) how object properties are reshaped through these use practices as different types of
knowledge boundaries are bridged. Our objective is to provide answers to new questions for information systems
theory and practice concerning the ability of systems development team members to bridge knowledge boundaries
in agile development projects. These findings bear important implications for research on prototypes as boundary
objects in software development and on boundary objects use in general.
In the next section, we briefly review the literature on knowledge boundaries and boundary objects in general to
identify important research gaps. Then, we position the use of prototypes in agile development as a fruitful systems
development context to address these gaps. In the section that follows, we present our a priori definitions for the
key concepts from this prior literature that we use as scaffolding for our study. Then, the study's research design is
described, including our justification for selecting a project in a distributed team setting, and our findings are pres-
ented and discussed.

2 | K N O W L E D G E BO U N D A RI E S A N D B O U N D A R Y O B J E C T S

A major problem in knowledge-intensive IT settings—such as software development—is the bridging of knowledge

boundaries (Guinan et al., 1998; Rosenkranz et al., 2014). Carlile (2002) has established three different types of
knowledge boundaries. First, the syntactic boundary refers to a lack of shared syntax between different team mem-
bers and the ensuing language differences (Carlile, 2002). For example, in order to express the novel ideas incorpo-
rated in a new software product, the client might have developed a new vocabulary that is difficult to convey to the
software development team. Second, the semantic boundary refers to interpretive differences among different team
members (Carlile, 2002). For example, the client and software developers often hold inconsistent interpretations of
desired product qualities (eg, Dibbern, Winkler, & Heinzl, 2008). Third, the pragmatic boundary refers to different
viewpoints of team members rooted in different interests (Carlile, 2002). For example, the client and technical
experts may have different viewpoints on how to best implement a feature because the client is interested in low
development costs and the developers are interested in technical elegance.
One approach to tackling knowledge boundaries is the use of objects (Star, 2010; Star & Griesemer, 1989). The
classic theory to explain why objects help to address boundaries is boundary object theory (Star & Griesemer, 1989).
This theory holds that the ability of an object to promote the bridging of knowledge boundaries is associated with
the properties of that object. Specifically, an object is abstract if it represents ideas in ambiguous, rudimentary, or
generic terms, but concrete if it represents ideas in unambiguous or specific terms. An object is plastic if it is adapt-
able to situational demands, and an object is robust if it is not adaptable to situational demands (Star, 2010).
Empirical research has explored the role of many different objects, including software specifications and project
management tools (Barrett & Oborn, 2010), architectures (Bergman, Lyytinen, & Mark, 2007), drawings and models
4 HUBER ET AL.

(Yoo, Boland, & Lyytinen, 2006), work products such as graphical presentations or documents (Kellogg, Orlikowski, &
Yates, 2006; Newell & Edelman, 2008), timelines (Yakura, 2002), and social media (Tim, Pan, Ractham, &
Kaewkitipong, 2017). While early research had a strong focus on objects and their properties (Bergman et al., 2007;
Carlile, 2002), other studies have shifted attention towards what people do with objects, ie, use practices (e.g.,
Ewenstein & Whyte, 2009; Levina & Vaast, 2005; Nicolini, Mengis, & Swan, 2012). The latter studies have
established that objects only become useful in the bridging of boundaries if they are meaningfully incorporated into
work practices. Thus, objects do not automatically enable the transfer, translation, or creation of knowledge; they
need to be appropriated in the situated actions of team members (Levina & Vaast, 2005). In addition, boundary
object use can have a number of desirable effects. For example, objects can facilitate the transfer and translation of
knowledge (Carlile, 2004), the alignment of interests (Levina & Vaast, 2005), the coordination of expertise (Barrett &
Oborn, 2010; sterlund, 2008), the overcoming of cultural differences (Barrett & Oborn, 2010), the realization of a
vision (Boland, Lyytinen, & Yoo, 2007; Gal, Lyytinen, & Yoo, 2008; Yoo et al., 2006), the communication of design
ideas (Boland et al., 2007), and joint problem solving (Ewenstein & Whyte, 2009).
This new empirical research has led to theoretical advances, which we collectively refer to as contemporary
boundary object theory. Star (2010)—one of the originators of boundary object theory—recently clarified her stance
on the ontological status of boundary objects by suggesting that the original concept of object properties (published
in Star & Griesemer, 1989) is not in opposition to, but instead closely linked to, the more recent concept of use prac-
tices; while objects do have important material properties that shape the range of possible ways in which they can
be used, objects derive these properties “from action, not from a sense of prefabricated stuff or ‘thing’-ness” (Star,
2010, p. 603).
In their recent contribution to the software development research stream, Doolin and McLeod (2012) argue that
Star's revised conceptualization is compatible with the ontological foundations of sociomateriality and they
reformulate the use of prototypes as a sociomaterial practice. Two implications of their study are particularly rele-
vant for our own. First, object use practices are highly sensitive to context, ie, “a boundary object may be performed
differently across multiple sites, times, practices and participants, with varying effects” (Doolin & McLeod, 2012, p.
571). This calls for research in novel contexts with unique and even extreme characteristics to more fully understand
the nature of object use. Second, the usefulness of a boundary object in bridging different knowledge boundaries is
neither fully determined by its material properties nor by the intentions of the humans using the object, but arises
from “the constitutive entanglement of the two” (Doolin & McLeod, 2012, p. 573). This calls for research that explic-
itly acknowledges two roles of object properties, ie, how different object properties afford1 different use practices
and how these use practices in turn shape object properties (Doolin & McLeod, 2012). Below, we argue why an agile
systems development setting provides an excellent opportunity to answer these calls by providing new context-spe-
cific explanations (Hong, Chan, Thong, Chasalow, & Dhillon, 2013; Lee & Baskerville, 2003).

3 | T H E SO F T W A R E P R O T O T Y P E A S B O U N D A R Y O B J E C T I N A G I L E
D E V E L O P M E NT

With the rise of agile software development, the practices through which software has traditionally been developed
have changed considerably (Ghobadi & Mathiassen, 2016). Agile software development places a strong emphasis on
close interpersonal interaction between team members (Ramesh, Mohan, & Cao, 2012). In co-located settings, this
involves frequent face-to-face meetings; in distributed settings, the geographically separated team members use
information and communications technology such as groupware, with a shared desktop feature (Sarker & Sarker,
2009). Irrespective of whether teams are co-located or distributed, agile software development systematically cen-
ters team member interaction around an object—ie, the software prototype in various representations (Marshall &

1
In this paper, we use the terms “afford” and “affordances” as found in prior boundary objects research, ie, objects provide possibilities for actions (eg,
Doolin & McLeod, 2012). It is not our intent to tap into the debates surrounding this concept in the wider research on technology adoption and use.
HUBER ET AL. 5

Bruno, 2009). Specifically, agile teams work in short iterations in which they jointly and continuously formulate,
model, and revise software requirements with the goal of developing a running and testable piece of software at the
end of each iteration (Dingsøyr et al., 2012; Ramesh et al., 2010). Software prototypes are not only present at the
end of each iteration, but instead are omnipresent throughout the iteration as a series of different representations of
the software product. For example, at the beginning of an agile “sprint,” a software requirement may be represented
as a brief formulation in the form of a user story or a rough graphical sketch in the form of a paper prototype or a
mock-up design. As the sprint progresses, the representation of the requirement may be elaborated in the form of a
UML diagram and, finally, evolves into a testable software prototype. Thus, prototypes as boundary objects in agile
development entail not only functional pieces of software, but also objects that can have a completely different form
than the final product (such as a paper prototype or a UML model) (Marshall & Bruno, 2009).
Moreover, software prototypes in agile development are different from prototypes in more traditional develop-
ment contexts in that their properties are intentionally indeterminate in the sense that they are not definitively fixed.
This is because in agile development, the various representations of the software prototype are emerging—ie, their
properties are expected to be continuously changed and refined (Dingsøyr et al., 2012; Ramesh et al., 2010). Given
that the use of prototypes as boundary objects depends on the properties of the object and that object use shapes
object properties (Doolin & McLeod, 2012), studying prototype use in agile development promises novel insights on
the role of variation and change in object properties for overcoming different knowledge boundaries.
In the next section, we will conceptualize and define the key concepts that together form our theoretical pre-
understanding.

4 | C O NC E P T D E V E LO P M E N T

The goals of this study are to explore how different ways of using software prototypes help to bridge different
knowledge boundaries in agile development (RQ1) and to understand the role of prototype properties for boundary
bridging (RQ2). To achieve these goals, we draw on and integrate concepts from the two literature streams intro-
duced above. From the boundary objects, literature we build on the concepts of knowledge boundaries and object
properties and from the systems development literature we build on the concepts of software prototypes as bound-
ary objects and prototype use.
For knowledge boundaries, we adopt the well-established distinctions for syntactic, semantic, and pragmatic
boundaries (Carlile, 2002). To understand how an object may or may not be helpful in bridging a knowledge bound-
ary, both classic and contemporary boundary object theory points to the importance of four object properties2: con-
crete vs abstract and plastic vs robust (Star, 2010). In part A of Table 1, we provide formal definitions and examples
for these concepts.
Our conceptualization of the software prototype as a boundary object adopts the broader notion of software
prototypes in an agile development setting and acknowledges the omnipresence of prototypes in this context: the
prototype is not one single object, but a multiplicity of co-existing, related objects (Doolin & McLeod, 2012; Lyytinen
& Newman, 2008). To categorize the many different representational forms of prototypes that are used in agile
development, we adopt the notion of different prototype dimensions (Lyytinen & Newman, 2008). Specifically, we
refer to representations of plans of the desired system such as textual descriptions of a functional requirement (eg, a
user story), a graphical sketch of the user interface (eg, a paper prototype or a mock-up design), or models of the
desired architecture (such as a UML component diagram) as building prototypes (BP) (adapted from Lyytinen & New-
man, 2008). Once pieces of software are coded and executable but not yet deployed in the operational system they
become part of the working prototype (WP) (adapted from Lyytinen & Newman, 2008)—eg, those prototypes
deployed in a dedicated testing environment at the end of a sprint (Marshall & Bruno, 2009).

2
We chose to adopt the properties proposed in classic boundary object theory (rather than Carlile's, 2002 more recent typology of boundary object
characteristics) to be fully consistent with the idea of mutual shaping.
6 HUBER ET AL.

TABLE 1 Definitions of key concepts from prior literature

Concept Definition Examples

A: Concepts from boundary objects literature

Knowledge boundaries
Syntactic Team members do not share a common syntax or
terminology (adapted from Carlile, 2002)
Semantic Team members do not share the same
interpretations (adapted from Carlile, 2002)
Pragmatic Team members have different goals, points of
view, or preferences (adapted from Carlile,
2002)
Object properties
Abstract An object represents ideas in ambiguous,
rudimentary, or generic terms (based on Star,
2010)
Concrete An object represents ideas in unambiguous,
comprehensive, and specific terms (based on
Star, 2010)
Plastic An object is adaptable to situational demands
(based on Star, 2010)
Robust An object is not adaptable to situational demands
(based on Star, 2010)
B: Concepts from systems development literature
Prototype dimensions
Building prototype The building prototype refers to the not yet
(BP) developed hypothetical prototype that is
embodied through written or visual
representations of software requirements
(adapted from Lyytinen & Newman, 2008)
Working prototype
Team members …
▪ … use mutually unintelligible terminology.
▪ … pronounce words in mutually
unintelligible accents.
Team members have different
understandings about …
▪ … desired product characteristics.
▪ … the nature of relationships between
different components of the product.
▪ … how product characteristics relate to
the product vision.
Team members have …
▪ … conflicting views on roles and
responsibilities.
▪ … conflicting expectations regarding the
activities expected by each side.
An object …
▪ … conveys several meanings (ambiguous).
▪ … represents incomplete or partial
information (rudimentary).
▪ … represents an idea in a stylized way
(generic).
An object …
▪ … conveys one single meaning
(unambiguous).
▪ … represents exhaustive/extensive
information (comprehensive).
▪ … represents an idea in detail (specific).
An object …
▪ … is perceived as flexibly adaptable to
novel situations.
▪ … is perceived as alterable to novel plans
and ideas.
An object …
▪ … is considered as stable to changing
demands.
▪ … is acknowledged as unalterable to
changing ideas and plans.
▪ Paper prototype
▪ Mock-up designs
▪ User stories
▪ UML diagrams
(Continues)
HUBER ET AL. 7

TABLE 1 (Continued)

Concept Definition Examples

(WP) The working prototype refers to the already
developed prototype that is embodied through
a functioning piece of software (adapted from
Lyytinen & Newman, 2008)
▪ An executable piece of software
running in a dedicated test
environment.
▪ An executable piece of software
running in a sandbox that is isolated
from the production environment.

Practices of using prototypes

Use practices The recurrent, materially bounded, and situated
actions in which team members interact with
prototypes that are shaped by the properties of
the prototype and that subsequently reshape
these properties (based on Doolin & McLeod,
2012)
A team member …
▪ … uses a paper prototype to clarify his
ideas to another team member.
▪ … contrasts a use case diagram with the
executable and testable implementation
of that specific use case.
▪ … uses a piece of software running in a
test environment to clarify problems
with that implementation.

Use practices refer to how team members use an object in specific situations (Levina & Vaast, 2005), ie, in our
context, the different activities and actions through which team members interact with an object. Further, according
to recent research on prototype use in systems development contexts, prototype use and prototype properties are
mutually constitutive (Doolin & McLeod, 2012). This implies that building and working prototypes have object prop-
erties (ie, abstract/concrete and plastic/robust) that afford certain actions (and constrain others); at the same time,
the way a prototype is used, shapes and gives meanings to these properties (Doolin & McLeod, 2012). Moreover, in
agile development, prototypes are emergent objects, ie, as the development project progresses iteratively, proto-
types are frequently modified (Dingsøyr et al., 2012; Ramesh et al., 2010). This is likely to result in a change to the
properties of a prototype. For example, when a written requirement from the building prototype is too abstract,
developers may point to a running piece of software (WP) and use this more concrete representation to close this
gap in understanding. After having looked together at a BP element and the current WP, project members may arrive
at a better understanding of the meaning of the original requirement formulated in the user story—ie, the building
prototype is no longer considered as too abstract (a perceived change) or the written user story in the building proto-
type is enriched with additional information, making it more concrete (an actual change). In Part B of Table 1, we pro-
vide formal definitions and examples for building prototype, working prototype, and use practices.

5 | METHODS

Building on the conceptual foundations summarized in Table 1, our research objective was to build theory on how
different ways of using software prototypes (ie, building prototype and working prototype) as boundary objects help
to bridge different knowledge boundaries (ie, syntactic, semantic, and pragmatic boundaries) in agile software devel-
opment. As part of our study, we also explored the role that object properties of prototypes as boundary objects (ie,
abstract/concrete and plastic/robust) play in the bridging of knowledge boundaries. To achieve these theory-building
goals, we conducted a single case study (Eisenhardt & Graebner, 2007) of a software project called “Neo.” Con-
ducting a single case study was an appropriate research design given that our data collection was longitudinal (Yin,
2009). A single case research design was also appropriate because the specific case provided a unique opportunity
for direct observations of team member interactions in meetings conducted over a 6-month period.
8 HUBER ET AL.

We purposefully selected the Neo project for our single case study on theoretical grounds (Eisenhardt &
Graebner, 2007; Yin, 2009). First, the Neo project was an agile software development project in which the work was
centered on the emerging building and working prototypes in their various representations, which increased the
likeliness of discovering novel use practices. Moreover, the Neo project was an offshore, outsourced agile develop-
ment project, which ensured that knowledge boundaries would be particularly frequent because in this systems
development context, the client and vendor often possess highly different knowledge bases (Tiwana, 2004). Specifi-
cally, in the Neo project, the client was an entrepreneur based in Switzerland with an idea for a novel software prod-
uct but without any prior software development experience. The development team, consisting of three developers,
one designer, and two scrum masters3 based in Vietnam, were experienced software professionals but without any
prior knowledge about the client's idea. The bridging of knowledge boundaries was particularly difficult in the Neo
project because the client and the vendor were not only geographically separated, but also encountered linguistic
barriers (ie, although both parties spoke English, they found it difficult to understand one another's accents) (Dibbern
et al., 2008; Kotlarsky et al., 2014). Thus, this case study choice meant that the client and vendor would likely use
digital objects as facilitating devices.
The ultimate goal of the Neo project was to develop a new software product (Neo) which enables each user to
store and organize a large variety of different media (eg, links, videos, and photos) according to her needs. Each user
can share this personally-structured media with other users, enabling those other users to experience the world
through the eyes of the sharing user. Because the team tasked with developing the Neo project was geographically
distributed, all synchronous meetings between the client and vendor took place in virtual settings using collaboration
tools. To make software prototypes visible to each other, they relied on the screen-sharing tool WebEx. For example,
this tool allowed the client to demonstrate a digitized photo of a paper prototype to the offshore team or the off-
shore team to display and illustrate an implemented4 requirement running in a remote test environment.

5.1 | Data collection

Our data collection included two types of qualitative data. First, we gathered observational data of all (virtual) meet-
ings that took place between client and vendor over the initial 6 months of the project: we started with the project
kick-off and ended with the deployment of the first “feature-freezed” version (alpha version) of the Neo software.
The first and the second authors of this paper attended 46 virtual meetings, all of which were conducted in English,
as nonparticipant observers and took field notes during every meeting (Miles & Huberman, 1994). Because all meet-
ings were virtual, we could record audio and video data during these meetings for refined analysis. This resulted in a
total of 20.4 hours of recorded observations and 204 pages of notes. The research notes described what the devel-
opers and the client discussed in each meeting and how they made use of software prototypes when facing a knowl-
edge boundary. All direct quotes provided in Section 6 are taken from the virtual meeting recordings.
The second data source is archival and entails the content exchanged via a task management tool used by all
team members. We had ongoing access to this tool, in which all software requirements were stored and represented
through certain attributes such as a status, a priority, verbal descriptions, and possibly some discussion threads,
mock-up designs, use case diagrams, etc. The content of this task management tool was helpful as a repository for
us to acquire a deeper understanding of the context of encountered knowledge boundaries. During the recorded
synchronous meetings, the team members often screen-shared the asynchronous task management tool to display
and work collaboratively on the prototypes.
These two data sources enabled us to ensure internal validity (Yin, 2009). First, if the observers of the meetings
arrived at discrepant interpretations or were unsure about the validity of their insights, we could go back to the

3
The Neo project adopted the agile development approach “Scrumban.” This approach is a hybrid that has all of the characteristics of classic scrum but in
addition, proposes techniques to continuously improve work.
4
Please note that in line with our focus on prototypes, the term “implemented” is used to refer to pieces of software deployed in a dedicated test
environment.
HUBER ET AL. 9

recording of the original meeting for clarification. Second, if we were not able to understand what exactly the team
members were discussing or what their problem was, we could resolve such ambiguities by looking up additional
information in the task management tool after the conclusion of a meeting. Third, we systematically used the data
stored in the task management tool to triangulate the insights we derived through observation. Specifically, if our
observations suggested that a knowledge boundary had been bridged, we triangulated this by examining whether
the status of the affected task was changed shortly thereafter (eg, from “in-progress” to “done”).

5.2 | Data analysis

As suggested by Eisenhardt and Graebner (2007), our theory-building effort combined multiple analytic approaches.
We followed an iterative approach that involved moving back and forth between data and theory (Corbin & Strauss,
1990; Eisenhardt, 1989). Our theory-building efforts included open, axial, and selective coding espoused by
grounded theorists (Corbin & Strauss, 1990), (soft) positivist methods (Madill, Jordan, & Shirley, 2000), as well as
other state-of-the-art techniques to analyze qualitative data (Lyytinen & Newman, 2008; Miles & Huberman, 1994).

5.2.1 | Identifying episodes

In a first step, all field notes were carefully reviewed to identify episodes (Lyytinen & Newman, 2008). For this study,
an episode is an ordered sequence of events where the project members used building and working prototypes to
bridge a knowledge boundary. Thus, an episode always begins with the occurrence of a knowledge boundary (syn-
tactic, semantic, or pragmatic) between the client and the software developers. Then, to bridge the knowledge
boundary, team members engage in different practices of using prototypes. An episode ends when the client and
vendor stop using prototypes, or shift attention to another boundary. This step resulted in the identification of 44
such episodes.

5.2.2 | Coding of a prioridefined concepts

Using open coding (Corbin & Strauss, 1990), we analytically broke down our data guided by the concepts defined a
priori from the literature (see Table 1). Our coding of knowledge boundaries was informed by Carlile's (2002) distinc-
tions between syntactic, semantic, and pragmatic boundaries. However, we also looked for subtle differences within
these categories (Corbin & Strauss, 1990) and discovered three types of semantic boundaries (see Section 6 for
details).
Then, we analyzed whether or not the knowledge boundary was bridged over the course of the episode. We
coded boundaries as bridged if either or both of the following conditions were met: (a) we directly observed behav-
iors implying a successful bridging (ie, the correct use of previously unfamiliar terms for syntactic boundaries, the
converging of previously diverging interpretations for semantic boundary, or the settlement of goal conflicts for
pragmatic boundaries), and/or (b) team members made verbal statements that directly indicated that a boundary was
bridged (eg, “I understand now”).
Afterwards, we turned our attention to the practices of using a prototype in each episode. We identified which
prototype dimension was referred to (ie, building or working prototype) and how each prototype was used. Our sys-
tematic comparisons resulted in four higher-level practices of using a prototype (Corbin & Strauss, 1990). We also
examined how different use practices were associated with object properties (ie, abstract vs concrete and plastic vs
robust). This involved two steps. First, we analyzed how object properties afforded different use practices. Second,
we traced how changes in object properties emerged through different use practices. These changes could be per-
ceptual (eg, the prototype was no longer considered as too abstract) or actual (eg, information was added to a mock-
up design). Together, these two steps allowed us to arrive at robust interpretations of the ways in which object prop-
erties and use practices mutually constitute each other (Doolin & McLeod, 2012).
10 HUBER ET AL.

At the end of this analysis stage, for each of our 44 episodes, we had coded and triangulated data on the type of
knowledge boundary, whether it was bridged, how different practices of using prototypes facilitated bridging, and
the role of object properties in this process. We then eliminated three episodes in which use practices failed to facili-
tate bridging, and continued to analyze only the 41 episodes in which they facilitated bridging.

5.2.3 | Identifying patterns

In this stage, we explored relationships between our core concepts via axial coding, ie, we related concepts to each
other and tested these relationships against the data (Charmaz, 2006; Corbin & Strauss, 1990). For this purpose, we
relied on comparative analysis techniques, including replication logic, memo writing, tables, and visual maps (Char-
maz, 2006; Miles & Huberman, 1994). In this process, we systematically compared all 41 episodes to understand
which use practices facilitated the bridging of different boundaries. These analyses resulted in four different prac-
tice-outcome relationships. For each of these practice-outcome relations, we then identified how object properties
afforded the respective use practice and how this practice affected the object properties (ie, abstract vs concrete
and plastic vs robust). In a final step, we used selective coding to synthesize and unify our findings (Corbin & Strauss,
1990) to develop a theoretical model of using software prototypes as boundary objects.

6 | FINDINGS

This section is structured as follows. In Section 6.1, we introduce our inductively developed groupings of prototype
use activities into four higher-level use practices to bridge knowledge boundaries. In Section 6.2, we explicate the
relationships between these use practices and the types of knowledge boundaries they bridged, as well as the role of
object properties. We then describe in detail each of these practice-outcome relationships and provide rich vignettes
of specific knowledge-bridging episodes from our case study data. In Section 6.3, we synthesize and integrate these
findings into a theoretical model.

6.1 | Use practices to bridge knowledge boundaries

Our cross-episode analysis led to the identification of four prototype use practices: exemplifying, contrasting, relat-
ing, and framing. Table 2 provides a formal description and an illustrative example for each of these use practices.

6.2 | Relationships between use practices and types of knowledge boundaries

Next, we focused on which practices were used to bridge which type of knowledge boundary. Across the 41 epi-
sodes in which a knowledge boundary was bridged, we initially identified the type of knowledge boundary using the
definitions for syntactic, semantic, and pragmatic boundaries in Table 1 adapted from Carlile (2002). However, the
semantic boundaries that were bridged revealed systematic variations related to their points of reference, resulting
in a more fine-grained distinction. Specifically, semantic boundaries could relate to the behavior of an individual soft-
ware feature (which we refer to as simple semantic boundary), the connections between different elements of the
software such as features, classes, and objects (complex semantic boundary), or the broader product vision behind
different elements (systemic semantic boundary).
Our analyses of how one or more of the use practices were systematically used to resolve a specific type of
knowledge boundary resulted in the identification of four practice-outcome relations. In 38 of the 41 episodes, pro-
ject participants faced a syntactic or semantic boundary. As shown in Table 3, three of the four use practices facili-
tated the bridging of those types of boundaries using one or both software prototype dimensions (BP, WP). The
practice of exemplifying alone facilitated the bridging of syntactic and simple semantic boundaries. The combination
HUBER ET AL.
TABLE 2 Practices of how prototypes are used
Practices Description
Exemplifying Highlighting a particular aspect of the prototype
by pointing to or clicking through the prototype
to focus the dialogue around this aspect.
Contrasting Comparing aspects in different prototype
dimensions by switching between them.
Relating Contextualizing a specific aspect of a prototype in
the broader product vision by referring to that
aspect and elaborating on reasons and
intentions behind it.
11
Illustrative Examples
When client and vendor shared their screen, the
developer displayed the visual design that
represented requirements related to so-called
user profiles. Pointing to the prototype using
his mouse cursor, the developer started to
query the client about specific behaviors
desired for user profiles: “So what should
happen if I click one of them [the user profiles]
here?” Client: “They will move to the center
position in the middle column ….” The developer
then pointed to another user profile depicted in
the visual design to ask if this behavior applied
there as well: “And when we click here … is it the
same behavior?” Referring to the visual design,
the client confirmed that “this will center the
user profile …. It's like a quick navigation ….”
As client and vendor shared their screen, the
developer opened a diagram that the client had
added earlier to the verbal description of a
requirement. The diagram illustrated that the
client expected that there would be linkages
between user profiles and Neos. Referring to
the diagram, the client pointed to the
importance of “two different types of user
profiles” with different linkages to Neos. The
developer then realized that this was very
similar to a requirement implemented earlier.
Therefore, he switched to the respective
feature in the working prototype and used it to
compare and inquire about similarities and
differences between the implemented
requirement and the one he was currently
working on: “Here, the user A has a private
profile A. And when he switches to a follower
mode … in the first column you see Neos selected
by himself.” Then, he switched back to the
diagram to ask “… and [what about] here?” The
client and vendor continued to switch back and
forth between the requirement and already
running part of the prototype until similarities
and differences had become clear.
When client and vendor shared their screen, the
scrum master displayed the user story of the
new requirement called “Neogroups” to ask: “…
what can users do with Neogroups?” What was
particularly unclear to the Scrum Master was
why there needed to be different types of
groups (ie, public and private groups). Referring
to the written requirement, the client
elaborated that “Neogroups are very important in
our system, because if you want to meet [other
users] … it's very helpful to create Neogroups,” He
(Continues)
12 HUBER ET AL.

TABLE 2 (Continued)

Practices Description Illustrative Examples

Framing Signaling verbally that certain elements in a
software prototype are open to change while
referring to other elements in that prototype to
prohibit change.
continued elaborating that he envisioned
groups focused on different domains of interest
such as “cakes,” “football,” or “wine.” Still
referring to the written requirement, the client
then explained his intentions behind the need
for public and private groups: “There is also a
business use for it [groups], because we will have
Neogroups, where you can rule how to join
[private groups].” He made clear that whereas
public groups would be open to join for
everybody, companies would be able to “buy”
private groups to create closed communities.
When client and vendor shared their screen, the
developer referred to a certain, already
deployed functionality in the executable piece
of software and invited the client to suggest
changes to that functionality: “You can now try
and test the newly implemented functionality …
to give us some feedback [on what should be
changed].” Then, the client referred to already
implemented icons to point out that they did
not comply with the envisaged color scheme.
He emphasized that this color scheme was not
up for discussion and that it was imperative
that the team implemented the “requirements
correctly,” ie, exactly as specified.

of contrasting with the practice of exemplifying facilitated the bridging of complex semantic boundaries. Relating com-
bined with exemplifying facilitated the bridging of systemic semantic boundaries. Pragmatic boundaries were bridged
in three of the 41 episodes by enacting the framing practice. This use practice involved the verbal signaling that cer-
tain elements in the software prototype would be open to change, whereas other elements were not. Table 3 also
summarizes our evidence on which software prototype dimensions (BP, WP) were used for each use practice and
the dual role of object properties—ie, how they afford use practices and are also reshaped by them.
In the next paragraphs, we further elaborate on the practice-outcome relations shown in Table 3 and the role of
object properties in each of these relationships.

6.2.1 | Exemplifying facilitates bridging of syntactic and simple semantic boundaries

The practice of exemplifying encompasses activities that highlight, ie, draw special attention to, particular elements
in either the building or the working prototype by selecting texts, pointing to graphical elements, or clicking through
an implemented feature. The developers or the client moved the mouse cursor to visually locate a particular unclear
(ambiguous) aspect in tables, diagrams, drawings, and texts (building prototype) or in already implemented functional-
ities and designs (working prototype). This centered the ensuing discussion on the highlighted aspect. For example,
developers pointed to a specific term in a written user story (ie, the building prototype) that they did not understand
by selecting the term with the mouse (eg, the term “Neo”). The client then gave a verbal explanation of this term.
Similarly, developers clicked through already developed features (ie, the working prototype) and asked the client to
verbally verify if the demonstrated functionality met his needs.
HUBER ET AL. 13

TABLE 3 Practices facilitating the bridging of syntactic and semantic boundaries

Object Software Object Bridged

Properties Prototype Properties Knowledge Number of
Practice(s) (Affording) Dimension(s) (Reshaped) Boundary Observations
Exemplifying Abstract element WP WP more Syntactic 7
in WP concrete
Abstract element BP BP more Syntactic 5
in BP concrete
Abstract element WP WP more Simple 6
in WP concrete semantic
Abstract element BP BP more Simple 4
in BP concrete semantic
Subtotal: 22
Contrasting ΔAbstract- BP&WP BP more Complex 8
combined with concrete concrete semantic
Exemplifying ΔAbstract- BP&WP BP & WP more Complex 2
concrete concrete semantic
Subtotal: 10
Relating combined ΔConcrete- WP&BP WP more Systemic 5
with abstract abstract semantic
Exemplifying ΔConcrete- BP & BP BP more Systemic 1
abstract abstract semantic
Subtotal: 6
Framing Indeterminate WP WP more plastic Pragmatic 2
plasticity/ and robust
robustness
Indeterminate WP & BP WP & BP more Pragmatic 1
plasticity/ plastic and
robustness robust
Subtotal: 3
Total: 41

Abbreviations: Δ = differences in properties of juxtaposed prototypes; BP, building prototype; WP, working prototype.

The practice of exemplifying supported client and vendor bridging of syntactic boundaries related to single ele-
ments (such as special terms). The client had created his own vocabulary for various desired features and design ele-
ments in Neoproduct, which the software developers were not familiar with. We observed that attempts to clarify
terms purely verbally—ie, without using a prototype—often failed; there were severe differences in vocabulary and
the mutually unintelligible accents made it difficult to communicate effectively. Thus, exemplifying was critical for
bridging syntactic boundaries; this practice enabled the team members to precisely show unclear aspects in a proto-
type when they were lacking the syntax to articulate problems without such a visual aid. This helped them to become
familiar with each other's differences in language.
Exemplifying was also instrumental when the client and developers were faced with simple semantic boundaries,
ie, boundaries related to the behavior of an individual feature. Often, solely relying on verbal dialogue was insuffi-
cient to gain understanding of an exact behavior of an individual feature; when the client and vendor used a proto-
type to exemplify particular elements, a better understanding of the behaviors of individual elements such as
features, buttons, and fields for data entry was achieved. Thus, the practice of exemplifying is used to visually
14 HUBER ET AL.

highlight those particular elements of a prototype that are ambiguous or only rudimentarily understood and this
visual aid helps to establish a common context that makes the element more concrete.
Below, we illustrate an episode in which the client and vendor engaged in exemplifying with a working prototype
to bridge a syntactic knowledge boundary.

Vignette: Exemplifying to Bridge a Syntactic Boundary

Knowledge boundary. The developers were not familiar with the particular term “Neo.” A Neo is an element consisting of
three standardized fields to enter information and share it with other users (i.e., title, description, and photo). The
client often referred to Neos as a “combination of title and page.” The client and the developers used different
language for the same element (ie, syntactic boundary).
Practice and object properties. The developer used the already developed functionality in the executable prototype
deployed in the test environment (WP) to display one concrete Neo. Then, the developer highlighted those aspects
of the Neo that were ambiguous to him; he visually moved the mouse cursor to the “title,” the “description,” and the
“photo” of that Neo. In parallel, the client explained that he commonly refers to these three elements as
“combinations of title and a page,” and that every newly created Neo represents a unique combination of a title and a
page.
Consequences. This syntactic boundary was bridged since the developers became familiar with the client's terminology,
ie, they understood that each Neo represents a combination of title, description, and photo to which the client refers
to as a “combination of title and page.”
Analytical summary. Exemplifying helped to bridge the syntactic boundary related to the term “Neo.” To achieve this,
the WP was used as a visual aid to make visible those aspects that were ambiguous to software developers. This
enabled the client to provide an explanation with targeted precision. The pinpointed and previously ambiguous
aspects became more specific—ie, the building prototype became more concrete.

6.2.2 | Contrasting combined with exemplifying facilitates bridging of complex semantic

boundaries
When the practice of contrasting was enacted, it was always combined with the practice of exemplifying. Contra-
sting encompassed comparing aspects in both software prototypes with each other to look for similarities and differ-
ences between the two. The team members switched back and forth between the building prototype (eg, tables,
user stories, and diagrams) and the working prototype to visually highlight particular elements (ie, exemplifying). This
allowed the team members to precisely express a lack of understanding regarding the building prototype in relation
to the working prototype. For example, first the developers selected a user story (ie, the building prototype) that
they did not understand; then they elaborated on what exactly they did not understand by switching to the working
prototype and clicking through partly implemented functionality.
The combined use of contrasting and exemplifying enabled the client and vendor to bridge complex semantic
boundaries, i.e., those related to the connections between elements. The ultimate goal of Neoproduct was to repre-
sent the worldview of its users by depicting a complex, interconnected web of different user-generated content ele-
ments (eg, profiles, Neos, cards, videos, pictures, and events). Thus, consistent interpretations between client and
vendor about the nature of connections between elements were of major importance. However, given the novelty
of Neoproduct, the parties lacked shared interpretations. Contrasting combined with exemplifying was critical to
bridge this type of semantic boundary because it enabled them to precisely identify similarities and differences
between the building and the working prototype. The parties highlighted those elements in the building prototype
for which they had only rudimentary understanding or that were ambiguous to them, and then compared these
abstract elements of the building prototype with more concrete features in the working prototype. This allowed the
client to give highly specific guidance to help the developers arrive at a more sophisticated and unambiguous under-
standing of the building prototype, and to implement this in the working prototype—ie, the building prototype (and
HUBER ET AL. 15

sometimes the working prototype) became more concrete. Below, we illustrate an episode in which the client and
vendor engaged in contrasting and exemplifying.

Vignette: Contrasting Combined with Exemplifying to Bridge a Complex Semantic Boundary

Knowledge boundary. In Neoproduct, different elements such as Neos and user profiles should be linked to each other in
various ways. Depending on these linkages, particular users could see certain Neos. However, the developers did not
understand the different ways through which multiple users could be linked to each other, and how such differences
should affect which Neos they could see. Accordingly, the developers and the client had different understandings of
the relationships between elements (ie, complex semantic boundary).
Practices and object properties. A developer displayed a written requirement (BP) and highlighted a specific example of
three interconnected users in this written requirement that he did not understand (exemplifying). The developer then
switched to the executable prototype in the test environment (WP) to display similar linkages that were already
implemented and thus perceived as more concrete. He started comparing the already implemented linkages with the
description of linkages as formulated in the written requirement. They then switched back and forth between the
example in the written requirement and the running, clickable functionality of the WP to reach agreement on how
the written requirement was to be implemented (contrasting).
Consequences. The complex semantic boundary was bridged since the developers came to understand how the different
relationships between users expressed in the example would affect which Neo each user should be able to see.
Specifically, they learned that if user A was a “follower” of user B, then user A should be able to see all of the Neos of
user B.
Analytical summary. Contrasting combined with exemplifying enabled the bridging of a complex semantic boundary
related to the linkages between different Neos. To achieve this, the developer contrasted the unclear example in the
written requirement (BP) with a similar functionality in the executable prototype deployed in the test environment
(WP), ie, a more abstract element from the building prototype was compared with the more concrete functionality of
the working prototype. This systematic contrasting between more abstract elements of the building prototype with
more concrete elements of the working prototype eliminated ambiguities related to the building prototype, which
was then revised to be more concrete by adding information.

6.2.3 | Relating combined with exemplifying facilitates bridging of systemic semantic

boundaries
When the practice of relating was enacted, it was always combined with the practice of exemplifying. The cli-
ent used a software prototype to refer to a specific aspect in that prototype, such as the behavior of running
functionality or a particular design element (exemplifying). Then, the client contextualized this specific aspect, ie,
he placed the specific aspect into the appropriate context of the broader product vision by articulating its wider
purpose such as the intentions behind that functionality or design element (relating). For example, the client
explained why a highlighted functionality should operate in a certain way and why different Neo types should
have distinct recognizable design features, and then elaborated on the broader product vision that was previ-
ously unknown to the developers.
The combined use of relating and exemplifying enabled the client and vendor to bridge systemic semantic bound-
aries, ie, those related to the broader product vision behind individual elements. Because of the novelty of Neo-
product, vendor employees lacked an understanding of its broader vision. Relating combined with exemplifying was
critical for gaining such understanding because it enabled the client to highlight specific functionality or a design that
he knew was affected by the broader product vision and contextualize it in the broader product vision for the devel-
opers. In five of the six examples, the more concrete elements of the working prototype were related to more
abstract elements of the building prototype such as product vision statements or long-term plans. This allowed the
client to elaborate on how specific aspects in the working prototype were affected by the more general product
vision such that developers achieved a more abstract understanding—ie, the working prototype became more
16 HUBER ET AL.

abstract. Below, we illustrate an episode in which the client and vendor employees engaged in exemplifying and
relating.

Vignette: Relating Combined With Exemplifying to Bridge a Systemic Semantic Boundary

Knowledge boundary. The developers did not understand why users who wanted to create new Neos should instantly
receive recommendations of existing, related Neos. For example, when a user wanted to create a new Neo called
“wine” the system should recommend related Neos such as “vineyard” or “wine merchant.” The source of this lack of
understanding was that the client had not yet fully shared his product vision (systemic semantic boundary).
Practices and object properties. The client used the executable prototype deployed in the test environment (WP) to refer
to a specific, already implemented field on a form called “title.” The client entered a title into the form field and began
to explain that as soon as this text is entered, the system should recommend titles of related Neos. He then
expanded on his product vision (BP) by elaborating on the general idea and intentions behind this recommendation
feature: “[My intention is to] push users to use existing Neos” in order to establish “new relations between users and
information.”
Consequences. The systemic semantic boundary was bridged because the developers had arrived at an understanding as
to why users who created new Neos should receive instant recommendations of related Neos. The goal was to push
users to create a complex web of connections between Neos rather than a large number of fairly unconnected Neos.
Analytical summary. Relating combined with exemplifying enabled the bridging of a systemic semantic boundary related
to the recommendation feature. To achieve this, the client contextualized the already implemented functionality for
creating new Neos (WP) within the more abstract vision of connecting users with similar interests (BP). The
systematic contextualization of relatively concrete elements of the working prototype within relatively abstract
elements of the building prototype helped the developers arrive at a more abstract understanding of the role of the
recommendation feature—ie, as part of the whole system; thus, the working prototype became more abstract.

6.2.4 | Framing facilitates bridging of pragmatic boundaries

The use practice of framing encompassed activities in which the client and vendor verbally expressed their general
openness to change certain elements of prototypes as well as their unwillingness to change certain other elements.
For example, the client first referred to an already developed functionality or design in the working prototype, or to
tables, designs, and user stories in the building prototype, and then invited changes, critical feedback, and input for
further improvements and asked developers to consider alternative solutions. Subsequently, the client again referred
to an already developed functionality or design in the working prototype, or to tables, designs, and user stories in
the building prototype, and restricted the opportunity to change a particular aspect by ignoring alternative sugges-
tions and inputs from developers and by emphasizing that he would not be willing to accept any changes to that par-
ticular aspect.
The practice of framing facilitated the bridging of pragmatic boundaries. Framing enabled the parties to reach
mutual agreement from different viewpoints rooted in the diverse backgrounds of the client and vendor. The client
had a strong interest in ensuring that the features of Neoproduct would be implemented as he had envisioned them,
but he was a novice to software development. The developers had a strong interest in technical elegance, but they
were novices to Neoproduct (pragmatic boundary). The use practice of framing made already agreed-upon or already
implemented functionalities and designs appear alterable to the other party's interests. However, it complemented
such openness to change with a signal that such changes would only be restricted to certain aspects, while other
aspects were framed as stable and unalterable. As a consequence, discussions about how to change prototypes
became more focused. This practice was critical for resolving pragmatic boundaries, it enabled middle-ground solu-
tions between diverse viewpoints, while simultaneously enabling the client to enforce his views on aspects where he
was not willing to compromise. Below, we illustrate the episode in which the client and vendor engaged in the prac-
tice of framing with both the WP and BP prototypes.
HUBER ET AL. 17

Vignette: Framing to Bridge a Pragmatic Boundary

Knowledge boundary. A developer informed the client that arranging the order of Neos in the way determined by the
client would not be possible to implement from a technical point-of-view. However, the client was convinced that
the envisioned ordering feature would be an essential strength of Neoproduct (ie, pragmatic boundary).
Practices and object properties. The developer displayed an already deployed functionality (WP) to demonstrate the
technical infeasibility of ordering Neos in the specified way: “I can say that it's impossible to do that.” The developer
then opened the user story in the backlog (BP) and began proposing alternative ways of ordering Neos. The client
and vendor then jointly explored alternatives and came to agree on a feasible technical solution. However, when the
developer suggested additional changes, the client signaled unwillingness to make further adaptations: “Oh my … I
have to get used to this thought [the already agreed-upon changes] first.” Referring to the already developed
functionality (WP), the agreed-upon changes, and the original user story (BP), he then argued that the additional
suggested changes would be too strong a deviation from his original idea. The developer realized that the client's
openness to change this feature was depleted and promised to “think more about” how the ordering feature could be
implemented without deviating too far from the client's initial idea.
Consequences. The pragmatic boundary was bridged. The client agreed to modify his initial idea in response to some of
the developers' concerns on technical feasibility, but he also clearly expressed where he was not willing to
compromise.
Analytical Summary. The framing practice helped bridge the pragmatic boundary related to the technical feasibility of
the ordering feature. To achieve this, client and vendor demonstrated openness to change by exploring the feasibility
of alternatives—ie, the working prototype and building prototype became more plastic. However, as the client
expressed his unwillingness to make further adaptations to his original idea, the client made other aspects
unalterable—ie, more robust.

6.3 | Towards a theoretical model

Our study documents how team members in an agile software project setting resolved syntactic, semantic, and prag-
matic boundaries by enacting and combining four different practices of using software prototypes as boundary
objects. Our study also explicates the important role of variation in and changes in object properties as different
types of knowledge boundaries are bridged through use practices. On the one hand, object properties afford differ-
ent use practices and the use practices take advantage of these properties through activities such as highlighting,
comparing, contextualizing, and utilizing. On the other hand, these use practices reshape (perceived or actual) object
properties. A summary of our findings can be found in Figure 1 and in the text that follows.
First, for bridging syntactic boundaries and simple semantic boundaries, prototypes need to be used in a way that
highlights what exactly was ambiguous to a team member. The information gained from the exemplifying use practice
makes the prototype more concrete. Thus, this practice is afforded by a specific element in the prototype being
abstract. Second, to bridge complex semantic boundaries, prototypes need to be used in ways that systematically
compares more concrete with more abstract prototype representations in order to make the abstract prototype more
concrete (ie, combined use of contrasting and exemplifying). Thus, the contrasting practice is afforded by relative dif-
ferences in the properties of the building and the working prototype. Third, the bridging of systemic semantic bound-
aries was also afforded by relative differences in prototype properties. Here, prototype representations are used in
ways that systematically contextualize concrete elements of the prototype with the more abstract vision expressed in
a building prototype to make the concrete properties more abstract (ie, combined use of relating and exemplifying).
Fourth, to bridge pragmatic boundaries, prototypes are purposefully utilized to verbally reframe perceptions of the
plasticity and robustness of different elements (ie, framing). Thus, this practice was afforded by the fact that, because
of its emergent nature, the plasticity or robustness of different elements of a prototype is more indeterminate—ie,
not definitively fixed. Team members can utilize this indeterminacy to frame some elements as more alterable and
18 HUBER ET AL.

FIGURE 1 Summary of findings

other elements as more robust and thereby establish a common ground between the parties of what is subject to
change and what is not.
In Figure 2, we offer a theoretical model that reflects our findings on how software prototypes are used as
boundary objects to bridge the three different types of knowledge boundaries (based on Carlile, 2002) that can
emerge during an agile software development project. In the center of the model, we show how the four object
properties (based on Star, 2010) of building prototypes and working prototypes afford different use practices (exem-
plifying, contrasting, relating, and framing) by members of a software development team for bridging an emergent
knowledge boundary. The use practices in turn reshape the relevant object properties of the building and/or working
prototype, which results in a knowledge boundary being bridged.

FIGURE 2 Theoretical model: Software prototypes as objects to bridge different knowledge boundaries
HUBER ET AL. 19

7 | DISCUSSION

The goal of this study was to expand our understanding of how prototypes are used to facilitate the effective bridg-
ing of knowledge boundaries in an agile development setting and to clarify the role that object properties play in
such bridging. To reach this goal, our study was guided by contemporary boundary object theory, which sensitized
us to the need to better understand the mutually constitutive nature of object properties and use practices (Doolin
& McLeod, 2012; Star, 2010). An in-depth study of an agile development project in which various building and work-
ing prototypes played a key role in the interactions between the client and vendor served as the empirical context
for our exploration.
Our first research question asked how different ways of using software prototypes as boundary objects help to
bridge different knowledge boundaries in agile software development (RQ1). In response to this question, we identi-
fied four relationships between use practices and the bridging of knowledge boundaries related to differences in lan-
guage (syntactic boundaries), differences in interpretations (semantic boundaries), and differences in goals (pragmatic
boundaries)—including three different types of semantic boundaries.
Our second research question asked what role the properties of prototypes as boundary objects play in the
bridging of knowledge boundaries (RQ2). In response to this question, our findings show how the object properties
of software prototypes afford different use practices and how the use practices take advantage of these properties.
Moreover, we show how the use practices change the (perceived or actual) properties of a prototype, which is essen-
tial for bridging different knowledge boundaries. Thus, our overall finding is that the effectiveness of software proto-
types as boundary objects depends on use practices as well as the variation and change in object properties of the
used prototypes. Hence, to bridge different knowledge boundaries, team members need to use software prototypes
in appropriate ways. On the one hand, the use practices need to purposefully exploit affordances associated with dif-
ferent prototype properties. On the other hand, the prototype properties need to be actually changed or team mem-
bers need to adopt new perceptions of these properties.

7.1 | Theoretical implications

Our study bears important implications for two literature streams: research on prototypes as boundary objects in
software development and boundary object use in general. To our knowledge, prior software development
researchers have studied the use of prototypes in more traditional settings (Doolin & McLeod, 2012; Rosenkranz et
al., 2014), but not in an agile development context. Since object use practices are highly sensitive to the context
(Doolin & McLeod, 2012), our study acknowledges and builds on two key characteristics of agile systems develop-
ment projects to increase our understanding about how prototypes can be effectively used as boundary objects.
First, in each iteration of an agile development project, prototypes exist as a series of multiple, highly diverse repre-
sentations. By drawing on the distinction between building and working prototypes (Lyytinen & Newman, 2008), we
were able to categorize these different kinds of prototypes—ranging from intermediate work products such as writ-
ten requirements or rough drawings to functional pieces of software—in a systematic and simple way. The value of
this distinction is twofold. On the one hand, it allowed us to unveil how these highly diverse prototypes are com-
bined through their use and to develop more fine-grained knowledge on the effects of such combinatorial object use
(Barrett & Oborn, 2010; Scarbrough, Panourgias, & Nandhakumar, 2015). That is, we found that the practices of con-
trasting and relating purposefully combine building (eg, drawings) and working prototypes (eg, functional pieces of
software) and that such combinatorial use enabled the bridging of semantic boundaries that are more intricate, ie,
complex and systemic boundaries. Moreover, the distinction between building and working prototype allowed us to
highlight that the effectiveness of combinatorial object use can be traced back to its ability to juxtapose building and
working prototypes with divergent properties. Specifically, use practices that juxtapose a more abstract prototype
(eg, a drawing) with a more concrete prototype (eg, a functional piece of software) enable team members to highlight,
20 HUBER ET AL.

compare, and contextualize differences between these representations, which is key to overcoming complex and
systemic semantic boundaries. These findings therefore extend prior research that has investigated the effects of
combinatorial object use on work outcomes such as coordination (Scarbrough et al., 2015) or overcoming cultural
boundaries (Barrett & Oborn, 2010), but not investigated the effects on the three types of knowledge boundaries
(syntactic, semantic, pragmatic) identified by Carlile (2002).
Second, the emergent nature of prototypes in agile development (Dingsøyr et al., 2012; Ramesh et al., 2010)
enabled us to unveil the role that a change in object properties plays in the bridging of different types of knowledge
boundaries. Specifically, we show that prototype properties are emergent in the sense that the way prototypes are
used reshapes their abstract vs concrete and plastic vs robust properties and that differences in this emergent pro-
cess have different bridging effects. Practices that make object properties more concrete (exemplifying and the com-
bined use of contrasting and exemplifying) are vital in bridging syntactic, simple semantic and complex semantic
boundaries. Practices that make object properties more abstract (combined use of relating and exemplifying) are vital
in bridging systemic semantic boundaries. Finally, the practice of framing creates simultaneous changes from plastic
to robust and from robust to plastic, which is vital in bridging pragmatic boundaries. That is, the practice of framing
can be used to pinpoint which elements of a prototype are open to change (and therefore plastic) and which ele-
ments are not (and therefore robust). We provide evidence that this practice facilitates finding suitable compromises
when client and vendor interests differ. We thereby extend prior research that has focused on how boundary objects
can help bridge cognitive boundaries (ie, syntactic and semantic) but not on how they can help bridge pragmatic
boundaries (Boland et al., 2007; Gal et al., 2008; Yoo et al., 2006).
In addition to these contributions to our understanding of software prototypes as boundary objects in an agile
setting, our findings have implications for object use in software development projects in general. Our data revealed
that semantic boundaries vary in intricacy and we acknowledged this variation by breaking down semantic bound-
aries into three fine-grained subtypes (ie, simple, complex, and systemic). Recognizing this variation enabled us to
discern the effectiveness of different use practices in the bridging of a semantic boundary. Specifically, our distinc-
tion between different types of semantic boundaries provides an explanation for why one single use practice or the
combination of multiple practices may be required for effective bridging of a semantic boundary. This fine-grained
distinction of different types of semantic boundaries reveals the distinct challenges related to independence (simple
semantic boundaries) vs interdependence of features (complex semantic boundaries), as well as the embeddedness
of features in a broader product vision (systemic semantic boundaries). Since these challenges are highly likely to
occur in software projects, we believe that categorizing semantic boundaries into these subtypes will prove useful
beyond the specific context of agile projects.
Our findings also hold implications for research on boundary object use in general. In recent years, the idea that
an object can only serve as a boundary object if it is both “plastic … and … robust” (Star, 2010, p. 393) and if it is
(simultaneously) “concrete and abstract” (Star, 2010, p. 408) has caused some confusion as to how something can be
both plastic and robust, as well as abstract and concrete. By adopting the novel ideas of both object affordances and
the reshaping of object properties offered by contemporary boundary object theory (Doolin & McLeod, 2012; Star,
2010), our study provides some empirically grounded clarifications. First, boundary objects as a whole can be simul-
taneously abstract and concrete because use practices can juxtapose different dimensions of objects that have dif-
ferent properties. In our case study, we show that the multiple objects categorized under the dimensions of building
and working prototype often exhibit differences with regard to the properties of abstract vs concrete. Use practices
can purposefully exploit these relative differences through activities such as contrasting, which juxtaposes relatively
more abstract with relatively more concrete elements. Second, boundary objects can be abstract and concrete at dif-
ferent points in time because use practices can change the seemingly fixed properties of an object. In our case study,
the properties of a prototype changed from abstract to more concrete when team members engaged in exemplifying
or the combined use of contrasting and exemplifying, and changed from concrete to abstract when they engaged in
the combined use of relating and exemplifying. Third, boundary objects can be simultaneously plastic and robust
because team members can frame some aspects of the object as robust and others as plastic. In our case study, we
HUBER ET AL. 21

show that by engaging in the practice of framing, a distinct element of a prototype (such as a requirement in a build-
ing prototype) that has already been agreed upon can be verbally reframed as more plastic, while another require-
ment can be reframed as more robust.
In addition, our inductively developed theoretical model addresses how the software prototype in agile develop-
ment becomes recognized and delineated as a boundary object that can achieve various boundary bridging conse-
quences. While it is nowadays well-established that objects only become useful in the bridging of knowledge
boundaries if they are meaningfully incorporated in work practices (eg, Ewenstein & Whyte, 2009, Levina & Vaast,
2005, Nicolini et al., 2012), our study addresses what has heretofore been a black box; the role of the object proper-
ties proposed by Star and Griesemer (1989) for the effective bridging of different knowledge boundaries. Specifically,
our study provides empirically grounded knowledge on variations in and changes of object properties associated with
use practices that help bridge knowledge boundaries. Our study thus significantly extends prior research that built on
arguments related to object properties but did not specifically examine the role of these properties (eg, Bechky,
2003, Bergman et al., 2007, Carlile, 2002, Newell & Edelman, 2008, Patnayakuni, Rai, & Tiwana, 2007, Rosenkranz et
al., 2014) for bridging different types of boundaries (Ewenstein & Whyte, 2009). By tracing in detail how object prop-
erties and use practices are inextricably linked, we were able to show that distinct object properties afford distinct
use practices, but that these object properties are not materially fixed; they are shaped by use practices. This implies
that a given boundary object such as the software prototype is not per se abstract or concrete, plastic or robust, but
that it has the inherent potential to be any of these—and the use practices help actualize and shape this potential.

7.2 | Practical implications

Our findings provide some meaningful guidance for practitioners on how to bridge knowledge boundaries through
the use of a software prototype. The use practices identified in this study that transform software prototypes into
boundary objects can be purposefully enacted by professionals who deal with problems in language syntax, under-
standing and viewpoints across team members. For agile contexts in particular, the developers or scrum masters can
intervene in meetings to ensure that team members engage in these types of practices to bridge different kinds of
knowledge boundaries. Practitioners can combine different practices purposefully to take advantage of specific pro-
totype properties to master these problems.
Further, our study suggests that agile systems development projects may succeed without the need to engage in
extensive knowledge sharing—even if the team members possess highly heterogeneous knowledge. Recognizing that
building or working software prototypes are more than just an intermediary work outcome, and invoking them for
supporting communication and overcoming knowledge boundaries, can be key to making continuous progress.

7.3 | Limitations and future work

We recognize that our specific findings summarized in Figure 1 are based on a single case study, and should not be
generalized to a wider population (Lee & Baskerville, 2003). Hence, it should not be assumed that the same use prac-
tices would have the same boundary spanning effects in other project contexts. However, the inductively developed
concepts and the relationships shown in our theoretical model in Figure 2 can be used to develop testable hypothe-
ses. Such hypotheses can be tested under varying contextual conditions. For example, they can be tested in other
offshore agile projects of varying size, complexity, or task novelty. Alternatively, hypothesized practice-outcome rela-
tionships can be systematically tested with a sample of projects where team members are distributed vs co-located
and which follow different development methodologies (ie, agile vs waterfall).
Another limitation of this study is the timeframe of the project that was studied: our focus was on the first pro-
ject phase (ie, the initial 6-month development phase) of an offshore-outsourced agile software project. While we
believe that the theoretical insights that have been generated by this project scope justify this focus, future studies
that extend the observation period could yield additional important insights. First, there might be differences in
22 HUBER ET AL.

object use over time due to learning. For example, team members may learn to more effectively apply a use practice
to address a type of knowledge boundary or they may refine the use practices themselves. Second, object use may
change over time due to the introduction of new prototyping technologies as the project proceeds (Boland et al.,
2007; Yoo et al., 2006). For example, a new prototyping tool may offer advanced collaboration features and there-
fore enable entirely new use practices. Third, different use practices may have different short-term vs long-term
effects that were not revealed in this study. For example, a use practice that enabled a type of knowledge boundary
to be bridged during a particular project stage may or may not enable team members to bridge the same type of
knowledge gap at a different project stage. An extended observation period would enable the disentangling of the
short- and long-term effects of different practices.

ACKNOWLEDGEMEN TS

The authors thank the senior editor, associate editor, and two anonymous reviewers for their extremely valuable,
supportive, and constructive guidance. The authors also acknowledge helpful feedback from Rudy Hirschheim, Nat-
alia Levina, Greetje Corporaal, and Wanda Orlikowski on early drafts and ideas of this paper.

ORCID

Thomas L. Huber https://orcid.org/0000-0001-6230-1579

RE FE R ENC E S

Barrett, M., & Oborn, E. (2010). Boundary object use in cross-cultural software development teams. Human Relations, 63(8),
1199–1221. https://doi.org/10.1177/0018726709355657
Bechky, B. A. (2003). Sharing meaning across occupational communities: The transformation of understanding on a
production floor. Organization Science, 14(3), 312–330. https://doi.org/10.1287/orsc.14.3.312.15162
Bergman, M., Lyytinen, K., & Mark, G. (2007). Boundary objects in design: An ecological view of design artifacts. Journal of
the Association for Information Systems, 8(11), 547–568.
Boland, R. J., Lyytinen, K., & Yoo, Y. (2007). Wakes of innovation in project networks: The case of digital 3-D
representations in architecture, engineering, and construction. Organization Science, 18(4), 631–647. https://doi.org/10.
1287/orsc.1070.0304
Carlile, P. R. (2002). A pragmatic view of knowledge and boundaries: Boundary objects in new product development.
Organization Science, 13(4), 442–455. https://doi.org/10.1287/orsc.13.4.442.2953
Carlile, P. R. (2004). Transferring, translating, and transforming: An integrative framework for managing knowledge across
boundaries. Organization Science, 15(5), 555–568. https://doi.org/10.1287/orsc.1040.0094
Carlile, P. R., Dutton, J. E., & Feldman, M. S. (1997). Understanding knowledge transformation in product development: Making
knowledge manifest through boundary objects. n/a: University of Michigan.
Charmaz, K. (2006). Constructing grounded theory: A practical guide through qualitative research. London: Sage.
Corbin, J. M., & Strauss, A. (1990). Grounded theory research: Procedures, canons, and evaluative criteria. Qualitative
Sociology, 13(1), 3–21. https://doi.org/10.1007/BF00988593
Dibbern, J., Winkler, J., & Heinzl, A. (2008). Explaining variations in client extra costs between software projects offshored
to India. MIS Quarterly, 32(2), 333–366. https://doi.org/10.2307/25148843
Dingsøyr, T., Nerur, S., Balijepally, V., & Moe, N. B. (2012). A decade of agile methodologies: Towards explaining agile
software development. Journal of Systems and Software, 85(6), 1213–1221. https://doi.org/10.1016/j.jss.2012.02.033
Doolin, B., & McLeod, L. (2012). Sociomateriality and boundary objects in information systems development. European
Journal of Information Systems, 21(5), 570–586. https://doi.org/10.1057/ejis.2012.20
Eisenhardt, K. M. (1989). Building theories from case study research. Academy of Management Review, 14(4), 532–550.
https://doi.org/10.5465/amr.1989.4308385
Eisenhardt, K. M., & Graebner, M. E. (2007). Theory building from cases: Opportunities and challenges. The Academy of
Management Journal, 50(1), 25–32. https://doi.org/10.5465/amj.2007.24160888
Ewenstein, B., & Whyte, J. (2009). Knowledge practices in design: The role of visual representations as epistemic objects.
Organization Studies, 30(1), 7–30. https://doi.org/10.1177/0170840608083014
HUBER ET AL. 23

Gal, U., Lyytinen, K., & Yoo, Y. (2008). The dynamics of IT boundary objects, information infrastructures, and organisational
identities: The introduction of 3D modelling technologies into the architecture, engineering, and construction industry.
European Journal of Information Systems, 17(3), 290–304. https://doi.org/10.1057/ejis.2008.13
Ghobadi, S., & Mathiassen, L. (2016). Perceived barriers to effective knowledge sharing in agile software teams. Information
Systems Journal, 26(2), 95–125. https://doi.org/10.1111/isj.12053
Guinan, P. J., Cooprider, J. G., & Faraj, S. (1998). Enabling software development team performance during requirements
definition: A behavioral versus technical approach. Information Systems Research, 9(2), 101–125. https://doi.org/10.
1287/isre.9.2.101
Hong, W., Chan, F. K., Thong, J. Y., Chasalow, L. C., & Dhillon, G. (2013). A framework and guidelines for context-specific
theorizing in information systems research. Information Systems Research, 25(1), 111–136.
Kellogg, K. C., Orlikowski, W. J., & Yates, J. (2006). Life in the trading zone: Structuring coordination across boundaries in
postbureaucratic organizations. Organization Science, 17(1), 22–44. https://doi.org/10.1287/orsc.1050.0157
Kotlarsky, J., Scarbrough, H., & Oshri, I. (2014). Coordinating expertise across knowledge boundaries in offshore-outsourcing
projects: The role of codification. MIS Quarterly, 38(2), 607–627. https://doi.org/10.25300/MISQ/2014/38.2.13
Lee, A. S., & Baskerville, R. L. (2003). Generalizing generalizability in information systems research. Information Systems
Research, 14(3), 221–243. https://doi.org/10.1287/isre.14.3.221.16560
Levina, N., & Vaast, E. (2005). The emergence of boundary spanning competence in practice: Implications for
implementation and use of information systems. MIS Quarterly, 29(2), 335–363. https://doi.org/10.2307/25148682
Levina, N., & Vaast, E. (2008). Innovating or doing as told? Status differences and overlapping boundaries in offshore
collaboration. MIS Quarterly, 32(2), 307–332. https://doi.org/10.2307/25148842
Lyytinen, K., & Newman, M. (2008). Explaining information systems change: A punctuated socio-technical change model.
European Journal of Information Systems, 17(6), 589–613. https://doi.org/10.1057/ejis.2008.50
Madill, A., Jordan, A., & Shirley, C. (2000). Objectivity and reliability in qualitative analysis: Realist, contextualist and radical
constructionist epistemologies. British Journal of Psychology, 91(1), 1–20. https://doi.org/10.1348/000712600161646
Marshall, D., & Bruno, J. (2009). Solid code. Redmond, WS: Microsoft Press.
Miles, M. B., & Huberman, A. M. (1994). Qualitative data analysis: An expanded sourcebook. Thousand Oaks, CA: Sage
Publications.
Newell, S., & Edelman, L. F. (2008). Developing a dynamic project learning and cross-project learning capability: Synthesizing
two perspectives. Information Systems Journal, 18(6), 567–591. https://doi.org/10.1111/j.1365-2575.2007.00242.x
Nicolini, D., Mengis, J., & Swan, J. (2012). Understanding the role of objects in cross-disciplinary collaboration. Organization
Science, 23(3), 612–629. https://doi.org/10.1287/orsc.1110.0664
sterlund, C. (2008). The materiality of communicative practices. Scandinavian Journal of Information Systems, 20(1), 4–20.
Patnayakuni, R., Rai, A., & Tiwana, A. (2007). Systems development process improvement: A knowledge integration
perspective. IEEE Transactions on Engineering Management, 54(2), 286–300. https://doi.org/10.1109/TEM.2007.893997
Ramesh, B., Cao, L., & Baskerville, R. (2010). Agile requirements engineering practices and challenges: An empirical study.
Information Systems Journal, 20(5), 449–480.
Ramesh, B., Mohan, K., & Cao, L. (2012). Ambidexterity in agile distributed development: An empirical investigation. Informa-
tion Systems Research, 23(2), 323–339. https://doi.org/10.1287/isre.1110.0351
Rosenkranz, C., Vranesic, H., & Holten, R. (2014). Boundary interactions and motors of change in requirements elicitation: A
dynamic perspective on knowledge sharing. Journal of the Association for Information Systems, 15(6), 306–345.
Sarker, S., & Sarker, S. (2009). Exploring agility in distributed information systems development teams: An interpretive study
in an offshoring context. Information Systems Research, 20(3), 440–461. https://doi.org/10.1287/isre.1090.0241
Scarbrough, H., Panourgias, N. S., & Nandhakumar, J. (2015). Developing a relational view of the organizing role of objects:
A study of the innovation process in computer games. Organization Studies, 36(2), 197–220. https://doi.org/10.1177/
0170840614557213
Star, S. L. (2010). This is not a boundary object: Reflections on the origin of a concept. Science, Technology & Human Values,
35(5), 601–617. https://doi.org/10.1177/0162243910377624
Star, S. L., & Griesemer, J. R. (1989). Institutional ecology, translations and boundary objects: Amateurs and professionals in
Berkeley's museum of vertebrate zoology, 1907-1939. Social Studies of Science, 19(3), 387–420. https://doi.org/10.
1177/030631289019003001
Stavru, S. (2014). A Critical Examination of Recent Industrial Surveys on Agile Method Usage. Journal of Systems and
Software, 94, 87–97.
Tim, Y., Pan, S. L., Ractham, P., & Kaewkitipong, L. (2017). Digitally enabled disaster response: The emergence of social media
as boundary objects in a flooding disaster. Information Systems Journal, 27(2), 197–232. https://doi.org/10.1111/isj.
12114
Tiwana, A. (2004). Beyond the black box: Knowledge overlaps in software outsourcing. IEEE Software, 21(5), 51–58. https://
doi.org/10.1109/MS.2004.1331302
24 HUBER ET AL.

Tiwana, A., & Mclean, E. R. (2005). Expertise integration and creativity in information systems development. Journal of Man-
agement Information Systems, 22(1), 13–43. https://doi.org/10.1080/07421222.2003.11045836
Yakura, E. K. (2002). Charting time: Timelines as temporal boundary objects. Academy of Management Journal, 45(5),
956–970.
Yin, R. K. (2009). Case study research: Design and methods. Thousand Oaks, CA: Sage Publications.
Yoo, Y., Boland, R. J. Jr., & Lyytinen, K. (2006). From organization design to organization designing. Organization Science,
17(2), 215–229. https://doi.org/10.1287/orsc.1050.0168

AUTHOR BIOGRAPHI ES

Thomas Huber is an assistant professor of Information Systems at ESSEC Business School, France. He received
his PhD in Information Systems from the University of Bern. His research focuses on the dynamics of gover-
nance and control in inter-organizational software development, software platform ecosystems, digital collabora-
tion, and the management of digital transformation projects. His research has been published in the Journal of
Management Information Systems (JMIS), Information Systems Research (ISR), IEEE Software, and in proceed-
ings of the field's leading conferences.

Maike Winkler is a team leader at the Competence Center Learning and Development and responsible for fos-
tering agility, leadership, professional training, and human development programs across Die Mobiliar. She led
digital transformation projects in the HR field for a wide range of large international companies in the DACH
region as Project Manager and Consultant at John Wiley & Sons. She received her PhD in Information Systems
at the University of Bern, Switzerland. Her research focuses on cross-border collaboration and innovation in
software development and the use of Information Systems as boundary objects. Her work has been published in
the proceedings of the field's leading conferences including the International Conference of Information Systems
(ICIS), European Conference of Information Systems (ECIS), and Hawaii International Conference on System Sci-
ences (HICSS).

Jens Dibbern is a professor and co-director of the Institute of Information Systems at the University of Bern,
Switzerland. He received his PhD in information systems from the University of Bayreuth and was assistant pro-
fessor at the University of Mannheim, Germany. His research focuses on various aspects of the division of work
in information systems provision and through information systems, such as outsourcing, offshoring, platform
ecosystems, enterprise systems use, and IT-supported collaboration. He has previously published in Manage-
ment Information Systems Quarterly (MISQ), Information Systems Research (ISR), Journal of Management Infor-
mation Systems (JMIS), Journal of the Association of Information Systems (JAIS), and others. He has been
associate editor of MISQ and currently serves as senior editor of JAIS and MIS Quarterly Executive (MISQE); he
is also department editor of Business and Information Systems Engineering.

Carol V. Brown has retired from her position as distinguished service professor of Management Information Sys-
tems in the School of Business at the Stevens Institute of Technology (USA). Previously, she served on the fac-
ulty of Indiana University's Kelley School of Business and Purdue University, and was a visiting scholar at MIT.
She received her PhD in management information systems from Indiana University. Her research on IT manage-
ment topics has been published in leading scholarly journals such as MIS Quarterly (MISQ), Information Systems
Research (ISR), Journal of Management Information Systems (JMIS), and Organization Science. She is a former
editor-in-chief of Information Systems Management (ISM) and MIS Quarterly Executive (MISQE).
HUBER ET AL. 25

How to cite this article: Huber TL, Winkler MAE, Dibbern J, Brown CV. The use of prototypes to bridge
knowledge boundaries in agile software development. Info Systems J. 2019;1–25. https://doi.org/10.1111/
isj.12261