Business analysts' contributions to the dynamic capabilities of agile software development teams

Abstract

Purpose

Literature reveals ongoing debates around the role of business analysts in agile software development (ASD) teams. This can be attributed, in part, to a knowledge gap concerning how business analysts contribute to overall team capabilities, particularly those which are essential in enabling teams to respond to fast-paced environmental changes. The purpose of this study was to address this gap by investigating how business analysts (BAs) contribute to the dynamic capabilities of ASD teams.

Design/methodology/approach

Through a deductive approach, this study adapted and applied a research model based on the team dynamic capabilities (DC) theory to explore the contributions of BAs in agile teams. The study was executed using a qualitative, single case study research strategy directed at an ASD team in the financial services industry. Moreover, data were collected through face-to-face, semi-structured interviews; a focus group; non-participant observation and physical artefacts review. The thematic analysis technique was used to analyse the data.

Findings

The study contributes to teams DC theory through four theoretical propositions centred on the role of BAs. The proposition highlights how BAs relationship management, tacit knowledge sharing, task mental models and transactive memory are key contributors of ASD teams' DC. The study also found that BAs contribute to ASD teams' ability to embrace agile principles 2, 4, 6 and 12. This study can inform the design of capacity development programmes for individual team members and BAs and thus help managers curate teams that will best promote DC.

Practical implications

This study can inform the design of capacity development programmes for individual team members and BAs and thus help managers curate teams that will best promote DC.

Originality/value

This study builds on the relatively few studies which focus on DC within software development (SD) teams and ASD project teams. Moreover, the study explores how an individual (i.e. a BA) can contribute to the DC of a team.

Citation

Ndlela, M. and Tanner, M. (2023), "Business analysts' contributions to the dynamic capabilities of agile software development teams", Information Technology & People, Vol. 36 No. 8, pp. 1-20. https://doi.org/10.1108/ITP-08-2021-0656

1. Introduction

In today's fast-paced business environment, organisations are pressured to rapidly adapt and respond to ever-changing market demands. Thus, many software organisations increasingly turn to agile software development (ASD) methodologies to help them stay competitive (Waja et al., 2021). ASD methodologies can quickly create change, embrace that change reactively and proactively and learn from that change (Rathor et al., 2016).

ASD methodologies are people-oriented rather than process-oriented, implying that these methods depend mainly on people's skillsets. Hence, the success of agile projects is dependent on team members' abilities, whilst procedures are there to support the team (Kunda et al., 2018). There exist different types of ASD methodologies (Scrum, eXtreme Programming, Kanban etc.) and each methodology comprises different roles. For instance, in Scrum, the key roles are product owner, Scrum master, team member and stakeholder (Stewart, 2019). It is noticeable that the role of the business analyst (BA) is not named explicitly mentioned (Stewart, 2019). Nonetheless, BAs play an essential role in software development (SD). In traditional approaches (e.g. Waterfall), BAs are responsible for unpacking clients' requirements and formulating requirement specification documents. They are also involved in formal and informal testing after the development phase is concluded (Hamilton, 2020). Given the absence of such a key role in the formal definition of ASD methodologies, there is a debate in literature on the relevance of the BA role and the different ways in which they can contribute to ASD teams (Hamilton, 2020; Stewart, 2019).

Whilst many ASD methodologies do not overtly advocate for the role of the BA, in practice, BAs still form part of these teams (Permana, 2015). ASD methodologies address the challenge of developing software in a dynamic business environment (Veera, 2018). This necessitates the search for relevant business insights, enabling organisations to quickly apply such knowledge and react to the emergence of new competitors whilst developing high-quality solutions (Cegarra-Navarro et al., 2016; Oliva et al., 2019). Gobov et al. (2020) argue that BAs can assist in that regard as they contribute to ASD teams by providing opportunities to adapt to rapid business changes. BAs achieve this by identifying needs and recommending solutions that bring value to stakeholders.

DCs are critical for organisations involved in ASD, as they help promote organisational agility which is needed to operate in an environment of uncertainty. DC supports a company's ability to innovate, adapt and create change that is unfavourable to competitors but favourable to the consumer market (Teece et al., 2016). Thus, DC fosters ASD agility which is necessary to address deep uncertainty and cope with fast-paced environment (Teece et al., 2016).

Past studies have established that BAs can assist ASD teams in several ways; however, they have not identified specific ways in which BAs can contribute to an ASD team's ability to respond to changes in a dynamic environment. Thus, according to Zajac-Woodie (2013), not much is known about how BAs contribute to an ASD team's DC. Also, little is known on the theoretical relationship between agile management practices and the innovation and evolution of organisations in dynamic environments (Oliva et al., 2019). Hence, this study sought to use a theoretical lens that would help illuminate some of the key factors related to how BAs contribute to the DC of ASD teams. The study's primary research question was: How do BAs contribute to the DC of ASD teams? A qualitative in-depth single case study of an ASD team in the financial services industry was conducted to answer this question. The study was specifically conducted in South Africa. South Africa represents an interesting context of study as past research has revealed that SD projects are more challenged in the country, compared to international contexts (Khoza and Marnewick, 2021). It is, therefore, important to understand how ASD projects can be made more effective in the South African context. This can be achieved by studying the DC of BAs in ASD teams.

By answering this question, we seek to provide a valuable contribution to theories around DC and ASD. In particular, four theoretical propositions are formulated to articulate how BAs can contribute to ASD teams' DC. The propositions highlight how BAs relationship management, tacit knowledge sharing, task mental models and transactive memory are critical contributors of ASD teams' DC. BAs' specific activities concerning the above traits are proposed with implications on ASD teams' ability to abide by agile principles. This study can inform capacity development programmes for individual team members and BAs and thus help managers curate teams that best promote DC.

The paper is organised as follows. A review of literature on the research and debates regarding the role of the BA in an ASD is first presented. Next, the theoretical framework section builds on the insights from the literature review. It identifies DC theory as an appropriate lens that can be used to address the research problem. Next, the research design section presents an overview of the methodology employed in the study. The findings are then described, followed by a discussion to ascertain the theoretical contributions. The paper is then concluded.

2. Literature review

2.1 The business analyst role

The most widely accepted definition of the BA relates to someone responsible for bridging the communication gap between the business and the development team and specifying user requirements (Zajac-Woodie, 2013). However, ASD methodologies do not always recognise that role (e.g. Scrum and XP) (Paul, 2018).

Mundra et al. (2013) acknowledge that although the BA role is not clearly defined in Scrum, it cannot be discarded as it brings significant value to the team. Takpuie and Tanner (2016) further suggest that BAs can be integrated into ASD teams under their organisational roles and contribute to the team as “documenters”. Matturro et al. (2018) posit that BAs contribute to ASD teams by taking on new roles such as customer representatives. Under these roles, BAs can contribute to ASD teams by performing the following activities: requirements elicitation and analysis, assisting the team in understanding business requirements (Mundra et al., 2013), creating and maintaining an agile document repository (Gregorio, 2012) and acting as a proxy customer representative (Shah, 2017). In addition, it is also suggested that BAs can contribute to the ASD team by executing verification tests throughout the sprints (Gregorio, 2012).

These examples offer little clarity about the way in which BAs can contribute to an ASD team's ability to respond to changes in its environment dynamically, which is known as an ASD team's DC (Li et al., 2010). Due to literature's emphasis on the importance of having the right people involved in ASD teams and the significance of an individual's skills and talents (Lalsing et al., 2012), it is necessary to identify ways in which BAs contribute to the DC of ASD teams.

2.2 Dynamic capabilities

DC theory differentiates between “ordinary” capabilities (doing the right things) from “dynamic” capabilities, which are “doing the right things, at approximately the right time, based on new product (and process) development …” (Teece, 2017, p. 698). DCs are the potential of organisations to solve problems systematically, from the perception of opportunities and threats, in order to make timely and market-oriented decisions (Oliva et al., 2019). From this standpoint, DC can contribute to competitiveness in response to fluctuating market needs (Ambrosini and Bowman, 2009). DC requires the integration of individuals' expertise in the organisation (Adegbite et al., 2018), leadership, orientation and culture (Schilke et al., 2018). It also needs the reorganisation and redefinition of corporate strategies to satisfy identified demands (Adegbite et al., 2018). DC theory is relevant to the case under investigation as it is suited to studies conducted in turbulent environments, and the ASD context is subject to rapid business changes.

As DC operates in rapid changing environment, it depends heavily on the organisation's knowledge and learning (Easterby-Smith and Prieto, 2008). The organisation's knowledge and learning are, in turn, strongly linked to the availability of key individuals during the process of knowledge development. Therefore, Li et al. (2010, p. 1727) define DC in ASD team as the actions that allow teams to “continuously integrate, reconfigure, and renew resources and competencies in response to the changing socio-technical environments”. The DC team has, at least, six commonly identified categories (Li et al., 2010; Hsu et al., 2012). These categories are reaction capabilities, anticipatory capabilities (Li et al., 2010), absorptive capacity, collective mind, market/environment orientation and coordination capability (Hsu et al., 2012).

This study focusses on the role that BAs play in ASD teams' DC in relation to market/environment orientation and coordination capability. The rationale for this choice is twofold. First, Jiang et al. (2020) note that market/environment orientation affects an organisations' performance and responsiveness in acquiring, utilising and analysing resources by processing market information and keeping pace with market velocity and changing customer needs (pp. 1241–1242). Lee and Xia (2010) also argue that SD agility is critical for performance as it helps to respond to changing user requirements. It is, therefore, relevant to explore the market/environment orientation DC of ASD teams (Chiarelli, 2021). Second, the coordination capability is highlighted by some scholars as a key enabler of an ASD team's success (Lindsjørn et al., 2016). Mishra et al. (2012) argue that coordination gives team members awareness about the tasks they must carry out and the timeframe attached to completing them. Lindsjørn et al. (2016) add that coordination allows team members to manage the dependencies between their interrelated tasks. Hence, coordination capability is a relevant dimension for studying DC in ASD teams.

2.3 Market/environment orientation of ASD teams

A project team's market/environment orientation is “the ability to effectively sense environmental changes occurring outside of the workspace that may influence teamwork” (Hsu et al., 2012, p. 81). The “environment” aspect of this capability emphasises that whilst a team should understand their clients and users, it should also be critically aware of the changes in their environment, which are usually caused by the business needs of diverse stakeholders (Hsu et al., 2012). Particularly, market/environment orientation works alongside other capabilities (both ordinary and dynamic), and some studies have recognised it as one of the main factors enabling firms to effectively meet the needs of their customer base (Chiarelli, 2021; Rodrigues et al., 2011).

In broad terms, an ASD team with good market/environment orientation takes part in several activities to understand external changes. Literature highlights the importance of involving clients (Alzoubi et al., 2016) and understanding the changing needs of users and stakeholders throughout the SD process (Ozkan, 2015). Hsu et al. (2012) stress that whilst the team must ensure that it understands these needs, in the context of DC, attention must also be given to other stakeholders, as they may also affect the development of the system.

2.4 Coordination capability of ASD teams

Coordination capability leads to the development of new resources and capabilities that help an organisation gain a competitive advantage. It has a positive influence on the performance of DC (Gao and Tian, 2015). Coordination capabilities are needed when changes are made to requirements or technologies, as there will subsequently be a change in the task structure (Hsu et al., 2012).

Literature categorises coordination as being explicit or implicit (Bick et al., 2017). Explicit coordination suggests that to commence work on shared tasks, teams must rely on each other's verbal communication to express plans, assign responsibilities and obtain information (Aggarwal et al., 2019). Conversely, implicit coordination calls for team members to anticipate each other's activities and needs and be able to “dynamically adjust their own behavior, without explicit communication” (Aggarwal et al., 2019, p. 3). Hence, this study focusses on the implicit nature of coordination, as literature posits that in fast-paced and volatile settings a team's success is often determined by its ability to coordinate implicitly (Aggarwal et al., 2019). Implicit coordination comprises five components: know why, know what is going on and when, know what to do and when, know who is doing what and know who knows what (Strode et al., 2012).

3. Theoretical framework: BA's contribution to selected dynamic capabilities

This section focusses on the contribution of BAs towards the two relevant categories of ASD team DC (i.e. market/environment orientation and coordination capability). The DC lens was utilised in this study to develop a research model informed by Hsu et al. (2012) and illuminate factors that allow BAs to contribute to ASD team DC. First, BAs can contribute to ASD team market/environment orientation through their relationship management and tacit knowledge sharing (Schlosser and McNaughton, 2007). Second, BAs can contribute to team coordination capability through their task mental model (Hsu et al., 2012) and transactive memory (Hsu et al., 2012) (see Figure 1).

3.1 BA's contribution to ASD team market/environment orientation DC

3.1.1 BA relationship management

Relationship management or interpersonal skills (Takpuie and Tanner, 2016) describe a person's capacity to participate in social communication and interact with others (Florea and Stray, 2018). ASD emphasises the need to create and maintain relationships with customers and users, as they are the primary provider of requirements (Nørbjerg et al., 2017).

BAs' skills in relation to relationship management are often manifested when they act as a communication bridge between the business stakeholders and Information Technology (IT). In order to properly manage these relationships BAs are required to be tactful diplomats, effective verbal communicators, ruminators, analysers and problem solvers. These skills allow BAs to understand and respond to their stakeholders' requirements in rapidly changing business environments. If the relationship between the business and stakeholders is dysfunctional, the process of product delivery that meets stakeholders' requirements will be negatively impacted (Mehta, 2016).

3.1.2 BA tacit knowledge sharing

Cummings (as cited in Santos et al., 2015, p. 1007) defines knowledge sharing as “the provision of task information and know-how to a person, so that (s)he can collaborate with others to solve problems, develop new ideas, or implement policies or procedures”. Tacit knowledge is highly personal, contextual and gained through experience (Duryan and Smyth, 2019). These characteristics make tacit knowledge difficult to formally document and share with others (Polanyi, 1958).

The role of BAs in tacit knowledge sharing is to understand the untold requirements of stakeholders. They also focus on analysing, eliciting, documenting, verifying and validating stakeholders' requirements from explicit knowledge, whilst also identifying inarticulate requirements to deliver a relevant product to stakeholders (MallowTechnologies, 2017).

BAs take a personalised approach to knowledge sharing (Santos et al., 2015). They often share their tacit knowledge with ASD teams through face-to-face interactions (Patanakul and Rufo-McCarron, 2018). They also share their tacit knowledge through customer collaboration, release planning, iteration planning, sprint planning, daily stand-ups, retrospectives and pair programming (Razzak and Ahmed, 2014).

3.2 Business analyst's contribution to coordination DC

3.2.1 BA task mental model

A task mental model refers to a team's “shared representation” or understanding of a task (Kotha et al., 2013, p. 17). For this study, BAs tasks mental model describes how well they understand their tasks, how aware they are of tasks being performed by other team members and how well they understand the relationship between their BA tasks and the tasks of others. Task mental models are critical to a team's coordination capability because they allow team members to complete the tasks they have been assigned whilst being aware and considerate of the tasks being performed by others (Hsu et al., 2012).

This study proposes that BAs can develop their task mental models by participating in synchronisation activities and using synchronisation artefacts. Sprint planning sessions and daily stand-up meetings are examples of synchronisation activities (Strode et al., 2012). Agile task boards are examples of synchronisation artefacts (Stray et al., 2019).

3.2.2 BA transactive memory

In a team context, transactive memory can be described as how well a team member is aware of “who knows what” (Argote and Ren, 2012, p. 1376). Transactive memory is defined as a person's ability to identify and locate team members who possess a specific knowledge (Hsu et al., 2012). This study, therefore, investigated the BAs' ability to identify and find the expertise required to promote their ASD team's coordination DC.

Social interactions increase an individual's chance of being exposed to the expertise of others. Participating in frequent interactions regarding one's work has a significant impact on building one's transactive memory (Kwahk and Park, 2018). In ASD, social interaction can occur in meetings (Drury-Grogan, 2018) such as sprint planning meetings, team leader meetings, daily stand-ups and retrospectives. These meetings are also used to manage expertise dependencies (Stray et al., 2019). Managing these dependencies requires teams to identify the roles and expertise possessed by others (Stray et al., 2019).

4. Methodology

The study was interpretive and exploratory. A deductive approach to theory was also taken as the DC theory was used as a lens to explore how BAs contribute to ASD teams DC (see Figure 1). A qualitative, single case study research strategy was used for this study. Saunders et al. (2012) suggest that case studies serve as a relevant strategy when answering “how” questions. Through a case study, the issue of BAs and their contributions to an ASD team's DC were studied in that team's natural environment (Yin, 2013). Moreover, the unit of analysis was the team.

The target population consisted of ASD teams and the sampling strategy was purposive to ensure that a relevant ASD team was chosen (Saunders et al., 2012). The case had to satisfy the criteria as follows: (1) be an ASD team that operates in a volatile business environment and (2) be an ASD team that has dedicated BA roles. The case selected for this study operates in the financial services industry, which has been described as subject to rapid changes (Zhao et al., 2019). The second criterion addresses the fact that some ASD methodologies do not explicitly advocate for the role of the BA.

This study was cross-sectional as data collection process took place in March to April 2019. Qualitative data were collected through face-to-face, semi-structured interviews; a focus group; non-participant observation; documentation and physical artefacts. The individual and group interviews served as the primary data sources and were supplemented by the three other data sources. During the data collection phase, participants were asked to describe the business environment, project background and the key role that BA plays within the organisation under investigation (see Table 1).

Ten audio-recorded interviews were held with ASD project team members, which lasted for approximately 45 min. The audio recordings were then transcribed. The semi-structured interview approach allowed for predefined and follow-up questions to be asked by the researcher (Saunders et al., 2012). Along with the notes taken during the interviews, a research diary was kept reflecting upon the answers provided by the participants.

A focus group was conducted with six developers. The researchers posed a question and invited each participant to share their opinion. This enabled each developer to share their views whilst allowing for some interaction between the participants.

Non-participant observations were mainly used to understand how the ASD team coordinates their tasks and how BAs contribute to the ASD team's coordination capability. In line with literature, which states that ASD teams can coordinate their work by participating in synchronisation activities (agile ceremonies) (Stray et al., 2019), the researchers asked to attend the team's agile ceremonies. They were permitted to observe two activities: product backlog refinement and sprint planning. The researchers attended the sessions through a Skype call. The chat function in Skype was used to ask the Scrum master any additional questions related to the ongoing meeting. Notes were made throughout the session, and the audio of the recorded meeting was revisited during analysis. Therefore, the observations helped compare the views expressed in the interviews to what was observed in the meeting.

Literature reveals that ASD teams coordinate their work by making use of synchronisation artefacts such as task boards (Stray et al., 2019). A photo of the ASD team's synchronisation artefact (Scrum board) was taken. This was the only artefact that could be made available to the researchers. The Scrum master explained the contents of the Scrum board. The Scrum board allowed the researcher to understand how the BAs use synchronisation artefacts to contribute to the ASD team's coordination capability.

The researchers asked the participants if there were any documents that we could review and were given access to two confidential documents: Fit-Gap Analysis and a PowerPoint presentation. The Fit-Gap analysis assisted in making sense of the “gaps” that are referred to by the participants throughout the study. The PowerPoint presentation allowed the researchers to form a better understanding of each project team members' roles and responsibilities.

Snowball sampling was used during the interviews where the researcher would conclude the interview by asking the question as follows: are there any other people you think I should speak to? This encouraged the participants to identify the development or project team members who could provide more insight into the research problem.

Data analysis was guided by Braun and Clarke's (2006) guide to thematic analysis. Moreover, the data were also analysed in a deductive manner guided by the research framework (see Table 2).

Concerns of validity and reliability are crucial to all qualitative studies. Whilst there is no unanimously agreed upon criteria for evaluating the validity and reliability of qualitative studies (Noble and Smith, 2015), there are several strategies that have been suggested to ensure the credibility of a study's findings. This study made use of the following verification strategies: selecting the appropriate sample (Morse et al., 2002), using “rich” and “thick” verbatim quotes from participants (Noble and Smith, 2015), consulting multiple data sources (Buchan et al., 2017), reflexivity (i.e. using a research diary) (Noble and Smith, 2015) and developing a case study protocol (Yin, 2013).

5. Case study description

The case was composed of ASD team members from two organisations: a financial services group (O1) and a software engineering company (O2). O1 was the client, and O2 was the software engineering service provider. Whilst O1 had a dedicated IT department, it outsourced the development aspects of its group risk (GR) system to O2. Therefore, system development projects related to GR were made up of O2 and O1 employees who come together to form one Scrum project team. This study was conducted after completing O1's GR system migration project and during the period in which new functionalities were being added to the migrated system.

5.1 Organisation 1 (O1): the customer

O1 is one of South Arica's largest financial services groups and is listed on the Johannesburg Stock Exchange as well as the Namibian Stock Exchange. The group was founded over a century ago and operates on both a local and global scale. O1's head office is located in the Western Cape, South Africa and has several branches in each South African province and around the world. O1 offers financial services to individuals, businesses and organisations which include but are not limited to insurance, investments and financial planning. This case study focussed on the head office branch as it has employees who are responsible for providing technological solutions to the O1 group.

More specifically, this study's O1 participants are members of the Employee Benefits (EB) insurance division and are responsible for providing a range of risk related products and services (benefits) to their corporate clients. Some of the products and services offered by the EB insurance division deal with retirement savings, life insurance, disability income protection and accident insurance.

O1 assigned 13 of its employees to the Scrum project team, which included a product owner, technical architect, five business specialists, two BAs, two testers and two customer service managers. Four O1 team members were able to participate in this study: two BAs, one business specialist and one tester (see Table 3).

5.2 Organisation 2 (O2): the service provider

O2 is a leading South African software engineering company which specialises in delivering administration systems to financial service organisations. O2's administration systems allow customers such as O1 to efficiently collect contributions and make benefit payments to their clients. O2 offers its products as well as its development services to help customers develop bespoke administration software. The company has been in operation for over 29 years and has approximately 20 local as well as international clients. O2 is currently headquartered in Gauteng (South African province) and has branches in the Western Cape (South African province).

The Western Cape branch assists O1 in developing and maintaining their GR system. The branch is home to employees who are members of the combined O1 and O2 project team. The project team members from O2 include a BA, development manager, Scrum master and six developers. Of the nine O2 project team members, seven were available to be interviewed (see Table 4).

5.3 The project details

O1 faced a business problem whereby that their previous system was slow and did not allow their insurance agents to capture business tasks quickly enough. The development team, therefore, created a new and faster GR system and migrated the existing insurance schemes from the old GR system onto the new one. The system migration project was initiated in 2011 and was estimated to take 8 months to build. The project's complexity was, however, underestimated, as it was only completed at the end of 2018. The most recent project, which is made up of the same members of the system migration project, was initiated in 2019 and is estimated to last 3 months. The goal of the project is to introduce new functionalities for managing O1's insurance schemes.

6. Analysis and findings

6.1 BA contribution to ASD team market/environment orientation DC

Figure 2 highlights the factors which allow BAs to contribute to an ASD team market/environment orientation DC. As previously mentioned, market/environment orientation refers to a development team's ability to recognise and understand environmental changes which may affect teamwork (Hsu et al., 2012).

6.1.1 BA relationship management

Findings indicate that relationship management factors promote BAs' ability to contribute to ASD teams' market/environment orientation DC. BAs must take the initiative to involve the product owner, business specialists, system users and various other stakeholders to ensure that all their needs and concerns are met. For instance, BAs proactively speak to business specialists and different user groups to ensure they stay up to date with business needs and gather user feedback. These behaviours ensure that business and user needs are met throughout the development process (see Table 5).

BAs also contribute to the ASD team's market/environment orientation DC by establishing rapport with project stakeholders, allowing them to better understand the body language of those with whom they communicate. Building rapport also allows BAs to maintain cordial relationships with stakeholders, which gives the development team easy access to the pool of knowledge and resources necessary to deliver business value and satisfy user requirements. In addition to having access to the required knowledge, a BA's ability to establish rapport ensures that knowledge is delivered to the team as quickly as possible to deliver new features and resolve issues rapidly (see Table 6).

BAs also nurture the ASD team's market/environment orientation DC by establishing rapport with the team. Building a relationship with team members creates a sense of comfortability. It encourages the developers to interact with BAs about business requirements and changes to those requirements. BAs who are easily accessible, approachable and engage in informal, face-to-face interactions can develop cordial relationships with team members (see Table 7).

6.1.2 BA tacit knowledge sharing

BAs contribute to the ASD team's market/environment orientation DC by sharing their business operations tacit knowledge. Instead of constantly relying on business specialists to provide knowledge about business operations, BAs who have spent a significant amount of time in an organisation can take on the role of a trusted knowledge source. Sharing this tacit knowledge is not only important for the team, but also allows team members to learn about their environment and prepares them to understand and respond to changes in business needs. Instead of approaching the business specialists for information about the business, developers often directly speak to BAs. It is evident that although BAs usually share information related to business operations, a BA that has spent a significant time in the organisation can develop operational knowledge through years of experience (see Table 8).

By sharing their tacit knowledge about business rules, BAs promote team learning, which contributes to the ASD team's market/environment orientation DC. The development team described the BAs' tacit knowledge as knowledge that clarifies how complicated business rules should be implemented. This understanding provided by BAs contributes to the ASD team's ability to respond to changes in requirements in a manner that aligns with business needs and the business rules (see Table 9).

6.2 BA influence on ASD team coordination DC

Figure 3 depicts how BAs contribute to an ASD team coordination DC.

6.2.1 Task mental model

BAs contribute to the ASD team's coordination DC by engaging with various project stakeholders before attending product backlog refinement sessions. Findings indicate that engaging in preliminary discussions and ad hoc meeting with multiple stakeholders ensures that BAs understand tasks from both a business and technical perspectives. Hence, for BAs to contribute to the team's coordination DC, they must first develop their task mental model.

When BAs are fully prepared for these refinement sessions, they can give the project team, including the development team, a richer understanding of each task from a business point of view. Therefore, explanations given by BAs add to the development team's shared understanding of the project's tasks, which leads to the improvement of the team's “know why” component of implicit coordination. This allows the development team to remain aware of the project goal whilst completing their tasks and find appropriate ways to coordinate their tasks when confronted with change requests (Table 10).

Findings also reveal that BAs promote a development team's coordination DC by actively participating in sprint planning meetings, allowing them to enrich their task mental models. These meetings enable BAs and other team members to become familiar with the tasks being completed by themselves and other development team members and understand the relationships between their tasks and the tasks of others. As members of the development team, BAs' nurturing of their task mental models contributes to the whole team's “know what to do and when” and the “know who is doing what” components of implicit coordination. Furthermore, establishing this understanding within the development team supports the organisation and management of tasks. This is necessary for reacting to future changes in the team's environment (Table 11).

Lastly, BAs promote a development team's coordination DC by monitoring task boards which allow them to develop a visual understanding of the relationships between their tasks and the tasks of others. This task mental model created through visualisation promotes the “know what to do and when” component of a development team's implicit coordination capability. BAs who can identify when to work on tasks relative to tasks of others, as well as address impediments faced by the team, ensure that the team makes progress on their prioritised tasks (see Table 12).

6.2.2 BA transactive memory

A team member's transactive memory is defined as the ability to identify and locate team members who possess relevant knowledge (Hsu et al., 2012). By taking part in synchronisation meetings and gaining experience as members of the project team, BAs can mature their transactive memory, which supports their ability to contribute to the ASD team's coordination DC. By identifying and locating the knowledge required by the development team, BAs add to the team's “know who knows what” component of implicit coordination. This coordination of expertise allows the development team to gain quick access to the knowledge it requires to develop the system and satisfy business requirements (see Table 13).

7. Discussion

The findings indicate that BAs contribute to the ASD team's market/environment DC by sharing their tacit knowledge related to business operations and business rules through various processes of socialisation (Proposition 1). Such tacit knowledge can only be acquired over time and through formal and informal engagement with key business stakeholders. This implies that a BAs ability to contribute to DC matures over time, allowing BAs to play a critical role in clarifying the context in which business rules should be applied.

Hsu et al. (2012) highlight that teams should be critically aware of their clients' environment and the changes that emerge within it due to evolving business and stakeholders' needs. This study further contributes to this theoretical viewpoint by proposing that BAs who have immersed themselves in the project business context over time develop tacit knowledge which is instrumental in promoting an ASD team's market/environment DC. Moreover, whilst Gobov et al. (2020) argue that BAs contribute to ASD teams by providing opportunities to adapt to rapid business changes, this study further unpacks how tacit knowledge on the business context and rules is particularly relevant in that regard. BAs who engage in socialisation processes are particularly effective in sharing their tacit knowledge. Indeed, Mehta (2016) argues that working closely with stakeholders provides BAs with the opportunity to ask scenario-based questions, which might have never been investigated. Thus, close collaboration between BAs and stakeholders is crucial to elicit requirements and expand the tacit knowledge base. The need for socialisation to support the transfer of BAs tacit knowledge is also in line with Agile principle 6, which states that the most effective method of conveying information is a face-to-face conversation (Fowler and Highsmith, 2001). Hence, the study contributes to ASD literature by revealing how BAs play a key role in helping teams adhere to this agile principle.

DC literature has linked knowledge sharing to market/environment orientation by discussing organisational learning, the ability to respond to customer requirements and adaptability. It is argued that knowledge sharing which takes place amongst employees is necessary for organisational learning, which in turn improves an organisation's market sensitivity and its ability to innovate (Wang and Wang, 2012). Knowledge sharing also allows organisations to quickly respond to customer requirements (Wang and Wang, 2012). It must be noted that tacit knowledge sharing, in particular, has more of a significant effect on employee adaptability (Zamir and Park, 2017). Adaptability in this sense refers to the ability to effectively adjust to change, complete new tasks and consider new ways of approaching work (Zamir and Park, 2017). Proposition 1 contributes to DC theory by establishing that the nurturing of market/environment orientation DC is not only achieved through the integration of individuals' expertise (Adegbite et al., 2018), leadership, orientation and culture (Schilke et al., 2018). The socialisation process which supports the effective sharing of tacit knowledge sharing in the team is a fundamental ingredient to establishing DC in support of organisation's knowledge and sharing.

The need for socialisation is also relevant between BAs and the ASD team. In that regard, this study found that when BAs establish rapport with the ASD team, it creates a work environment in which the development team interacts freely with BAs and seek to understand business requirements, which further supports ASD teams' market/environment orientation DC (Proposition 2). BAs must be easily accessible to the ASD team, approachable and willing to partake in informal, face-to-face interactions to build rapport. This behaviour allows for relationship building and encourages collaboration between the BAs and the team.

Past literature highlighted the various activities that BAs usually engage in during the agile process, namely requirements elicitation and analysis, assisting the team in understanding business requirements (Mundra et al., 2013), creating and maintaining an agile document repository (Gregorio, 2012) and acting as a proxy customer representative (Shah, 2017). This study has found that informal and impromptu engagements are as essential to nurture ASD team's market/environment orientation DC. This requires BAs to have an approachable and open demeanour within the team. Indeed, past studies have found that when team members are not familiar with one another, they find it difficult to communicate, collaborate and ultimately implement the correct functionalities for their customers (Lalsing et al., 2012). Instead, members of ASD teams who nurtured their relationships can easily share project-related information (Takpuie and Tanner, 2016) and individuals who value collaborating can assist team members in managing the changes in their environment (Li et al., 2010). The study, therefore, contributes to ASD literature by positing that BAs who establish good rapport with the development team can better liaison between the business and the development team, thus supporting Principle 4 (Fowler and Highsmith, 2001). Moreover, as the ASD team are encouraged to unpack business requirements given their good relationship with BAs, they may develop work ethics that welcome changes in requirements to suit business needs better, in line with Agile principle 2 (Fowler and Highsmith, 2001).

According to Schlosser and McNaughton (2007), individuals contribute to an organisation's market/environment orientation by building relationships with others. Through Proposition 2, this study contributes to DC by positing that establishing rapport is an important component of relationship building, through which market/environment orientation DC can be promoted. Establishing rapport can help individual pick up on the non-verbal cues expressed by stakeholders whilst adjusting their own non-verbal cues.

The study found that when BAs continuously develop their task mental models by engaging with project stakeholders in preparation for backlog refinement sessions, engaging in sprint planning sessions and monitoring tasks boards, they contribute to an ASD team's Coordination DC (Proposition 3).

Task mental models are critical to an ASD team's coordination capability because they allow team members to complete the tasks they have been assigned, whilst being aware and considerate of the tasks being performed by others (Hsu et al., 2012). From the literature reviewed, there are no studies that have described the nature of a BA's task mental model. This study bridges this gap by revealing that by taking part in synchronisation activities and making use of synchronisation artefacts, BAs can strengthen their task mental models. In addition, the study found that by participating in backlog refinement sessions and sprint planning meetings, BAs understand their tasks and the tasks being performed by other team members. They can also understand how their tasks are related to the tasks of others. Such a mutual understanding is critical to enable the ASD team to reprioritise their tasks in response to the changes in their environment (Hsu et al., 2012). When BAs nurture their task mental models, it allows the whole team to “know what to do and when” and “know who is doing what” in support of coordination (Stray et al., 2019). This is an important contribution to ASD literature as individuals in well-coordinated teams are conscious about the tasks they must complete, and they understand how their work affects the work of others (Lindsjørn et al., 2016). It is, therefore, important for BAs to develop their task mental models throughout the SD process, as the success of projects is dependent on team members having a relevant set of attributes (Kunda et al., 2018). In the case of BAs, it is dependent on having well-developed task mental models in one such attribute. The continuous development of the BAs task mental model in support of the ASD team's DC aligns with Agile principle 12. Indeed, as BAs partake in various activities to improve their task mental model, they continuously reflect on how to be more effective and adjust their behaviour accordingly (Fowler and Highsmith, 2001).

This study also established that when BAs continuously develop their transactive memory by attending synchronisation meetings, they contribute to an ASD team's coordination DC (Proposition 4). It is important for ASD teams to fully understand any changes in requirements to properly implement such changes to meet the business needs. The study reveals that BAs can streamline this process when their transactive memory enables them to identify who knows what. The BA's knowledge of where to locate relevant sources of information assists the rest of the team in quickly coordinating to satisfy any changes in business requirements. Past studies have established that ASD methodologies address the challenge of developing software in a rapidly changing business environment (Gobov et al., 2020). This study further contributes to ASD literature by revealing that BAs transactive memory plays a key role in helping ASD teams respond to these business environment changes. This builds on previous studies positing that transactive memory develops as groups of people spend more time interacting and becoming aware of one another's expertise (Kwahk and Park, 2018). As BAs develop their transactive memory, they allow the ASD team to abide by Principle 2 (Fowler and Highsmith, 2001).

Transactive memory is essential in teams, as the extent to which team expertise can be used and coordinated depends on whether individual members are aware of where to locate the required expertise (Hsu et al., 2012). Although the majority of the current literature focusses on transactive memory at an organisational level (Kwahk and Park, 2018), it is possible for individual team members to develop their own transactive memories (Hsu et al., 2012). Through Proposition 4, this study contributes to DC theory by providing insights into how an individual can also develop their own transactive memories and how coordination DC can be supported by individuals within an organisation.

8. Conclusion

This study explored how BAs contribute to ASD teams' DCs with a focus on market/environment orientation and coordination DC. The study contributes to both ASD literature and DC theory through four theoretical propositions centred on the role of BAs.

The study contributes to ASD literature by revealing that BAs tacit knowledge is developed over time though socialisation processes. Furthermore, the sharing of this tacit knowledge contributes to ASD team's market/environment orientation DC. Socialisation processes also allows for good rapport between stakeholders, which contributes to team's market/environment DC. ASD literature is also enriched as the study provides specific insights into how BAs task mental model can be promoted through synchronisation activities, as well as how BAs transactive memory plays a key role in helping ASD teams handle changes in business environment.

The study contributes to DC theory by establishing that the socialisation processes which supports effective tacit knowledge sharing is a fundamental ingredient to establishing market/environment orientation DC. The need to establish rapport as an essential component of relationship building in support of market/environment orientation DC is also revealed. Lastly, contributions are made to DC by providing insights into how individuals can develop their own transactive memory and ultimately support coordination DC within an organisation.

This study is important for practitioners as it highlights the specific activities BAs can engage in to contribute towards ASD teams DC. In this regard, this study can also help inform the design of capacity development programmes for BAs and thus help managers curate ASD teams to nurture DC best.

Whilst substantial data were collected and analysed, the study was limited, to some extent, by the restricted access to classified and confidential documents that would have been useful to the study. A related limitation was the sometimes closed nature of some meetings for purposes of non-participant observations. Where permissible, the researchers were allowed access to segments of these meetings via Skype. However, this limitation did not adversely impact the study's outcomes as it was mitigated by the optimal use of complementary data collection methods.

Two categories of teams' DCs were investigated, namely market/environment orientation and coordination capability. There is scope for future research to also explore the absorptive capacity of BAs in ASD teams. Absorptive capacity refers to team's ability to identify important external information so that it can be obtained, fully understood and applied as new knowledge (Hsu et al., 2012). Teams with high levels of absorptive capacity are able to acquire and understand new knowledge with the intention of using it to quickly react to changes (Hsu et al., 2012). According to Cohen and Levinthal (1990, p. 131), “an organisation's absorptive capacity will depend on the absorptive capacities of its individual members”. Hence, future studies could investigate the extent to which BAs acquire skills and knowledge from other team members, as well as how BAs take in information from other team members and incorporate it as their own. Future studies could also explore how BAs use their newly acquired knowledge to put ideas into practice.

Figures

Figure 1

Research framework

Figure 2

BAs contribution to ASD team market/environment orientation DC

Figure 3

BAs contribution to ASD Team Coordination DC

Table 1

Description data collection method used

Data collection methods	Description
One-on-one, face-to-face, semi-structured interviews	10 interviews (approx. 45 min each)
Focus group interview	1 focus group (6 developers)
Non-participant observations	1 product backlog refinement session
	1 sprint planning meeting
Physical artefacts	Scrum task board
Confidential project team documentation	Fit-gap analysis
	PowerPoint slides on team roles and responsibilities

Table 2

Analysis process summary

Analysis phase	Application
Familiarising oneself with the data	First, the researchers familiarised themselves with the data. The interviews were transcribed and the researchers read through each transcript whilst listening to the interview audio. Corrections were made and aliases were added. The researcher's notes and research diary were also reviewed whilst listening to the audio and reading through the transcripts
Generating initial codes	Next, the initial codes were generated as guided by the research framework. Examples of these codes were individual market/environment orientation, tacit knowledge sharing and relationship management
Searching for themes	The codes were used to produce themes that described how BAs contributed to a particular DC
Reviewing, defining and naming themes	The themes were assessed to ensure that they represented the coded quotes and were accurate and precise
Formulation of propositions	After having unpacked the themes, some form of coherence could be perceived in the data, following which the theoretical propositions were formulated. A decision table was used to facilitate the formulation of the theoretical propositions

Table 3

Scrum project team role of O1 participants

Project team role	Pseudonym	Time on project team	Study participation
Business analyst	BA1	3 years	Individual interview
	BA2	3 years
Business specialist	BS1	5 years
Tester	TES1	3 years

Table 4

Scrum project team role of O2 participants

Project team role	Pseudonym time on project team		Study participation
Technical business analyst	BA3	2 years 9 months	Individual interview
Scrum master	SM1	1 year 6 months	Individual interview
Software developer	DEV1	1 year 3 months	Individual and group interview
	DEV2	6 years	Individual and group interview
	DEV3	8 months	Individual and group interview
	DEV4	7 years	Group interview
	DEV5	4 years	Group interview

Table 5

Proactively involving project stakeholders

Proactively involving project stakeholders	“In between I'll also go to the doctor's department or anywhere that we need to, just to show them, ‘listen are you comfortable with this because in future you're going to do this now’. So, that's the type of stuff that I'm doing, running around to make sure. I really like to get everybody involved and informed” (BA1)
	“I think he's a lawyer or something and BA1 sort of was interacting with him to make sure that what we're doing like suited what they wanted as well. And he went to the doctors as well to be like, ‘if we do it like this would that […] work for you?’ So yeah, he sorts of went to them and got their feedback whilst we're busy with severe illness.” (DEV1)

Table 6

Establishing rapport with project stakeholders

Establishing rapport with project stakeholders

“I think as a BA it is very important to be able to build relationships. That is a key in actually BA work. You must be able to read quickly from someone's body language or their tone or their speech; what they are trying to say so you need to be able to read between the lines and having to communicate in all sorts of ways; body language, tone, voice, volume maybe and that is all very important because once a business user for example, gains your trust that is what you must try and aim for; that they are confident in what you are doing […] and they have faith in your capabilities and they trust that what you are doing is right.” (BA3)

“Like the other risk consultant, she likes nature photos and stuff. You just say, ‘oh, another of your photos, did not you […] ?’ Listen, just to start off and then you ask the question quickly after that.” (BA1)

Table 7

Establishing rapport with development team

Contributing factors	Participants quotes
Establishing rapport with the development team	“Yes, it is also nice that you do not have to Skype him, you make an appointment and whatever. He sits right next to us. He is also quite approachable you can literally stand up and say hey, I need to talk to you, or can I show you something.” (FG)
	“Even if they have discussions, we would also chip in. And that makes it quite nice, but I think that's why the whole agile thing, because, you are becoming sort of friends, you know.” (FG)

Table 8

Sharing business operations tacit knowledge

Sharing business operations tacit knowledge	“[…] because I know a bit about the business it makes my job different to other BA's stuff maybe because sometimes, they will ask me for some information, because I know the business and I know the processes and I know, everything, not everything but I know of some of the processes.” (BA1)
	“BA1 has been in the business forever […] because he's been here forever, he knows everything inside out. So ja, he is, without him we'd be in a bit of trouble.” (BS1)

Table 9

Sharing business rules tacit knowledge

Sharing business rules tacit knowledge

“It also depends on what we were working on, but when we're working on something quite complicated, and the rules are sometimes unclear to us, it helps us. For example, they'll change one thing, we can speak to BA1 and it helps us to respond to the change pretty well” (DEV1)

“Okay, there are lots of times that's happened and it's mostly between myself and the developers and some of the developers are keener on working like that […] but we often sit in front of the board […] mostly three of us. And, I'll say, ‘if we do that this is not going to work’ and they'll say, ‘if we do that, that's not going to work’. So we speak to each other and discuss it and I like that because then you sort out a lot of stuff and they understand the bigger picture and sometimes I understand the bigger picture from the system side.” (BA1)

Table 10

Engaging with project stakeholders

Engaging with project stakeholders, distributing documentation, taking part in product backlog refinement sessions	“Because in Agile they actually have sessions for sprint planning, so they have refinements in which I play more of a key role and then they have the planning, which is purely for the devs, basically.” (BA3)
	“I'd say definitely for the first portion because that is literally, this is the direction we go, we go through the whole project. We go from gap one to gap eight, we only going to do gap one now, but everyone should have an understanding of what's to come so when we build, we build appropriately.” (DEV3)

Table 11

Participating in sprint planning meetings

Participating in sprint planning meetings	“We'll speak about every detail of the task, what we are going to do so that everybody knows. From the developer's side, they will say what they are going to do.” (BA1)
	“So, in this meeting […] one of the developers will say, ‘okay, I'll take this story of this sticky, this activity kind of. I'll take this one. And then we'll say, ‘okay what does that involve?’” because then we make notes to say okay, ‘yes, we must test it, we must set it up a test’.” (BA1)

Table 12

Monitoring task boards

Monitoring task boards	“I think it's the one thing that I've learned from agile: ‘all hands-on deck’. You get involved where you can, especially if it's a developer struggling with something. If it's an impediment that's put in place by someone, then I'll speak to them to sort it out. Otherwise, we do not deliver.” (BA2)
	“It's the responsibility of the Scrum master to let the BA know that there's an issue that they have to attend to. So often the BA will just be told, look there's something here and we need someone to have a look at it.” (DEV3)

Table 13

Taking part in synchronisation meetings and gaining experience

Taking part in synchronisation meetings and gaining experience	“They need to attend all those meetings (refinement and planning sessions, daily stand-up, review and retrospective).” (SM1)
	“Yes, often that comes with time, you know who to go to for certain aspects to get the correct answers and the correct information.” (FG)