Three Types of Boundary Objects

The case study findings reveal that three types of boundary objects are critical in facilitating collaboration in Agile software development: (1) infrastructural, (2) projective and (3) process boundary objects (Zaitsev et al. 2016). The three categories are created to theorise on the boundary object application and address the second research question: How are boundary objects used in collaboration between these stakeholders? By mapping the objects together in these three categories, we can analyse how the objects are applied to support the collaboration effort, but also why the objects were applied in these cases.

The three object types – infrastructural, projective and process boundary objects – are categorised by their application and function. First, infrastructural objects facilitate collaboration before the commencement of the project, and its articulation forms the basis of the project’s existence (Nicolini et al. 2012). Without an established and mutually recognised infrastructure, a project would simply not exist. Infrastructural objects provide a foundation that enables the emergence of other object types in the latter phases of the project lifecycle. As the development progresses, some infrastructural objects such as contracts or environment recede into the background when a common understanding between the organisations has been established and the development work is being enabled. However, if breakdowns occur, the objects are brought back to foreground (Star & Ruhleder 1996).

Second, the projective objects – wireframes or prototypes and visual designs in the project studied – are used to establish a common understanding of the end goals of the project. Poppendieck and Poppendieck (2003, pp.27) assert that “a prototype synchronises the efforts toward a well-understood short-term goal” and that they “provide a focal point around which cross functional communication can and must occur”. This is in line with my findings, which suggest that projective objects may undergo several rapid and significant changes to accommodate ongoing shifts in the discussion about the project requirements.

Process objects, on the other hand, are used to capture the information discussed between the collaborating parties in a process informed by projective objects. The information stored in the process objects reflects the information in the projective objects and influence how the projective objects evolve over time. Customers and vendors are able to use projective objects as a sounding board for new ideas and customer feedback (Ciriello et al. 2014). The requirements elicited by the application of projective objects are then recorded as user stories in the process objects (Cohn 2004).

7.4.1. Functions of Boundary Objects

There are several reasons why organisations have to apply the different boundary object categories. Literature shows that different Agile methods focus on different artefacts (Kuhrmann et al. 2013); however, the differences between the methods are not the only reasons why I observed differences in the application of artefacts, boundary objects.

Infrastructural objects are typically crafted at the beginning of the project in order to inform project participants’ shared understanding of what the project will encompass, shape their interactions and guide their practices throughout the project (Koskinen & Mäkinen 2009). In the three case studies, there were several examples that fall into this category. Contracts, regulatory guidelines and software development environments were applied in different organisations in different ways, but they share the same rationale for the application: enabling the foundations for the work and enabling the application of the other objects that supported other collaboration activities.

Despite their foundational role, infrastructural objects are not necessarily static. More specifically, my study suggests that the creation of infrastructural objects should be a collaborative effort so as to create flexible and suitable objects that would best suit the needs of an Agile project. Star and Ruhleder (1996) argue that infrastructure needs to link, but also shape and be shaped by, the conventions of the communities of practice. In the three case studies this would mean a mixture of the conventions of the Agile communities, the IT industry and the financial sector. For example, the financial industry regulation documents are standardised forms (Star & Griesemer 1986): boundary objects that are standard for every party who is taking part in an endeavour. The industry regulations are non-negotiable, standardised forms that everyone who wishes to participate in the industry needs to adhere to; however, the conventions of an Agile development environment require flexibility and mutability from all boundary objects. Rigidity of infrastructural boundary objects can potentially hinder the Agile development process with overhead activities, to the point that the Agile environment begins to resemble a traditional, control-centric project environment (Conboy et al. 2010; Cao et al. 2010). This was a risk acknowledged by several informants across the three case studies, but such instances were not reported.

The projective boundary objects provide a preview of the project goals. They are used to convey the desired outcomes of the project – the end state of the system – relative to its current state. They include different visual representations of the developed system, such as wireframes, visual design documentation and the actual functional system (i.e. the work-in-progress). Here, the wireframes, visual designs and system versions were used as prototypes that facilitated the discussion of the project goals in all three cases (Carlile 2002; Poppendieck & Poppendieck 2003).

Projective boundary objects provide material for feedback, captured in process boundary objects. They tend to be malleable because they reflect ongoing requirement changes. Some projective objects, such as wireframes and other prototypes, are intentionally incomplete and are used to facilitate iterative feedback cycles. When not applied for feedback gathering but rather utilised as part of the development, the prototypes are applied to share design knowledge between the collaborating parties (Di Marco et al. 2012). Similarly, more complete projective objects, such as the actual system, are released in their incomplete state to elicit feedback from users (Boujut & Blanco 2003; Ciriello et al. 2014).

Desired outcomes are iteratively refined, clarified, and incorporated into functional versions of the system, and this evolution continues until the end of the project lifecycle. The high-level view of the system’s main functionalities allows the stakeholders or prototype testers to focus on the ‘big picture’ and identify more fundamental issues when

they are not distracted by the minor details. The purpose is to create common understanding via prototypes (Bechky 2003), not to be focused on minutiae.

In addition, projective boundary objects help to bridge the division between the stakeholders and/or development teams who are responsible for the product’s ‘look-and-feel’ and the developers who were responsible for the back- end functionalities (Strode et al. 2012). The richness of the information in the artefacts allowed business stakeholders, most of whom came from a non-technical, marketing or customer service background, or the developers, who were front-end specialists, to explore a more complete version of the system and identify whether there was a lack of expected requirement dependencies. By creating wireframes, prototypes or sharing the intermediate versions, case organisations were able to bridge all boundaries listed by Carlile (2002): pragmatic, syntactic and semantic boundaries. The prototypes and intermediate versions made abstract concepts more concrete, more plastic and more robust (Winkler et al. 2014).

Process boundary objects facilitate primary project processes: communication, collaboration and documentation (Subrahmanian et al. 2003; Strode et al. 2012). Containing different types of textual and visual information, process objects convey requirements information and customer feedback (Ciriello et al. 2014), as well convey abstract concepts such as project timelines and progress (Yakura 2002; Boell & Hoof 2015) The process objects in the three case studies include artefacts such as the different Agile walls, intranet wiki pages, document management tools, timelines or other plans, backlog tools, chat tools and feedback notes. In addition to communication benefits, certain process objects have other applications as well. For example, physical walls acted as territorial markers, announcing the areas of the office that belonged to each team and tribe (Sharp et al. 2009). The way the walls were organised and styled reflected the identity of the team, as discussed by Gal et al. (2008). Small paraphernalia that were related to the physical and virtual walls, such as team naming conventions, superhero figurines, avatars and colour schemes, all created a sense of team and a collaborative environment. Even a complete outsider could decipher that the walls were related to the projects or products, from the labels, timelines and user interface sketches posted on or next to the walls, creating common understanding of the project events (Strode et al. 2012). The benefits of applying boundary objects are summarised in Table 23.

BO Categories Artefacts Boundary Object Functions Infrastructural boundary objects Contracts Environments

Inform project participants’ shared understanding of what the project will encompass, shape their interactions, and guide their practices throughout the project (Koskinen & Mäkinen 2009).

Link, shape and be shaped by the conventions of the communities of practice (Star & Ruhleder 1996).

Facilitate collaboration before the commencement of the project, form the basis of the project’s existence (Nicolini et al. 2012).

Projective boundary objects Wireframes Visual design The system

Facilitate discussion of project goals (Carlile 2002; Poppendieck & Poppendieck 2003).

Create common understanding (Bechky 2003) and share knowledge of designs (Di Marco et al. 2012) across stakeholder groups (Strode et al. 2012).

Elicit feedback from users (Boujut & Blanco 2003; Ciriello et al. 2014).

Communicate abstract concepts in more concrete, more plastic and more robust ways (Winkler et al. 2014).

Process boundary objects Physical walls Virtual walls Backlog tools Chat tools Document storage Architectural plans

Mark territory and capture team and organisational identity (Sharp et al. 2009; Gal et al. 2008).

Create visual representation of time and events (Yakura 2002; Boell & Hoof 2015).

Create common understanding of the project events (Strode et al. 2012).

Table 23. Boundary Objects Categories and Functions

7.4.2. Application of Boundary Objects in the Case Studies

Figure 19 summarises which boundary objects were applied and how these objects were utilised in each of the case

studies. The top part of the illustration shows the connections between the objects: the infrastructural objects enable (Arrows 1) the existence of the two other object types. The projective objects inform (Arrow 2) the process objects on what clarifications or changes the collaboration between the vendor and the customer has yielded. These changes should be stored in the process objects as user stories or more detailed technical requirements. The development team can then utilise these stories and requirements and capture this information into the process objects as new or amended functionalities (Arrow 3). The middle row of the table describes how these boundary objects were applied by each case study and the bottom row describes why each of these objects was applied in the cases.

In the next section, I will tie the perspectives of the members of the organisations towards Agile, the stakeholder configuration and the application of boundary objects together.