Conference PaperPDF Available

Towards a healthier collaboration at the business-development interface



Many studies have been conducted on the collaboration between software development and operation deployment (DevOps), but few have considered the interface between business strategy and software development (BizDev). The lack of a good connection between business and development may lead to problems such as misunderstanding of requirements, mismatch of expectations, fail to fulfill deadlines and waste of time and resources. Motivated by that, this study aims at defining roles, responsibilities, and practices concerned with the business-development interface, as well as assessing positive impacts of some practices and drawbacks of the disconnection, so that we can define directions on how to create a healthy interface. For this research, we performed a literature review to gather information on how agile methods have defined roles that act on this interface and to gather information on how practices related to this interface can impact on a project. Aiming a practical understanding regarding the impacts of this interface on real enterprises and organizations, we conducted qualitative research based on interviews. We performed a set of interviews in the IT department of a university, for which the customer was the administrative sector. The interviews were further analyzed using Grounded Theory practices. Relevant practices inserted on the business-development interface stood out, such as customer-on-site, production support, continuous maintenance of requirement lists, and frequent re-prioritization of requirements. We envision further investigations at other organizations targeting different cultures and profiles.
Towards a healthier collaboration at the
business-development interface
Caique Garutti Moreira and Breno Bernard Nicolau de França
Instituto de Computação - Universidade Estadual de Campinas e
Abstract. Many studies have been conducted on the collaboration between
software development and operation deployment (DevOps), but few have
considered the interface between business strategy and software development
(BizDev). The lack of a good connection between business and development
may lead to problems such as misunderstanding of requirements, mismatch of
expectations, fail to fulfill deadlines and waste of time and resources. Motivated
by that, this study aims at defining roles, responsibilities, and practices
concerned with the business-development interface, as well as assessing
positive impacts of some practices and drawbacks of the disconnection, so that
we can define directions on how to create a healthy interface. For this research,
we performed a literature review to gather information on how agile methods
have defined roles that act on this interface and to gather information on how
practices related to this interface can impact on a project. Aiming a practical
understanding regarding the impacts of this interface on real enterprises and
organizations, we conducted qualitative research based on interviews. We
performed a set of interviews in the IT department of a university, for which the
customer was the administrative sector. The interviews were further analyzed
using Grounded Theory practices. Relevant practices inserted on the
business-development interface stood out, such as customer-on-site, production
support, continuous maintenance of requirement lists, and frequent
re-prioritization of requirements. We envision further investigations at other
organizations targeting different cultures and profiles.
Keywords: Agile Software Development, BizDev, business-development
1 Introduction
As business models evolve and organizations need to adapt to the dynamic and fast
time-to-market, software development methodologies also need to be improved
regarding value delivery capability and meeting of customer expectations. For doing
so, organizations are targeting a wider and healthier collaboration among its
functional areas. In this context, the interface between business and development
includes all the interactions between the IT and the business sectors within an
organization and its partners. While the well-disseminated term DevOps is used to
describe the downstream collaboration between software development and its
operational deployment and administration [13], the term BizDev can be used to name
the upstream collaboration between business strategy and development [10].
The business sector of an organization may be composed of teams focused on
content, requirement, administration and even by the final customer. The business
area in this interface behaves as a customer for the technology area, establishing
demands, specifications, deadlines, and expectations. This way, the technology area
acts as the productive force, but it is not limited to it, being possible for it to
participate alongside with the business area in activities such as requirements
prioritization and establishment of deadlines.
One direct consequence of bad performance at the business-development interface
is communication problems, leading to a bad understanding of requirements,
mismatch of expectations, fail to fulfill deadlines and waste of time and resources.
Motivated by this scenario, this study aims at gathering information that allow a
better definition and categorization of the business-development interface, by raising
information on the roles that are involved on this interface, together with their
responsibilities and adopted practices. Another objective regards the analysis on how
efficient are the practices adopted by companies and organizations regarding this
interface, qualitatively comparing them, taking into account the different practices
adopted and their level of importance to the interface.
The knowledge resulting from this study should benefit practitioners from both
business and development areas, allowing them to achieve a better comprehension of
the existing relations around them. Through this understanding they should be able to
improve the projects they work on, either by directly applying the analyzed practices
inside their teams or by disseminating the understanding and critical insights acquired
to the rest of the company or organization.
The remaining sections are organized as follows: Section 2 presents the adopted
research methods for this study. Section 3 presents the theoretical foundation used as
a base for defining the goals of the qualitative study and how it would be conducted.
Section 4 describes the results that emerged from the interviews performed for the
qualitative study. Section 5 presents the limitations and threats to validity. Finally,
Section 6 presents the concluding remarks and future work.
2 Research Methods
This study is organized into two phases: a literature review and the application of
qualitative research through a set of interviews, with further analysis applying
Grounded Theory procedures [9].
2.1 Literature Review
Initially, we performed an ad-hoc literature review regarding agile methodologies and
their definitions for roles, responsibilities, and practices related to the
business-development interface. The first analyzed works discuss practices and
responsibilities present in different agile methodologies, especially in Scrum
[1][2][4][6]. We decided not focusing on any particular methodology, but rather focus
on collecting what each one defines for the interface between business and
development, identifying differences and similarities.
Additionally, we analyzed case studies conducted on different companies [3][7][8].
From these studies, it was possible to raise instances on the importance of the BizDev
interface and also about the effectiveness of the applied practices. We synthesized and
discussed the reviewed literature (see Section 3) to define the scope of this study as
well as the objective and script of the interviews.
2.2 Qualitative Research
After the literature review, we began the qualitative study by defining a broad
research goal, so it could be sent along with other research details as an invitation to
organizations interested in collaborating with data collection (interviews). Such goal
summarizes the focus of the study, allowing companies and organizations that
accepted to participate to identify practitioners to contribute. Therefore, this study
aims at raising practices adopted by those who work at the interface between business
and development and identifying their roles and responsibilities, as well as their
relationship with the adopted practices. Another goal is to analyze how the adopted
practices contribute to a healthier relationship between business and development.
Next, we worked on the development of the interview scripts, based on [5]. Given
the research goal, it is important to interview both technical and business profiles. For
this reason, two distinct scripts were developed. The scripts (Appendix A) contain
open questions, some in common for both profiles and some specific for each area.
The case reported in this paper is the IT department of a public university. For this
case, we contacted the director of the IT department and sent the scripts and a term of
consent to the interviewed people.
At the time the interviews were conducted, the entire IT department was working
on the migration of a legacy COBOL system. This migration task force had been
ongoing for several months and changed the way teams organized their tasks. Before
the migration, all teams followed an adaptation of the Scrum agile methodology,
organizing their work on 2-week sprints. Each sprint contained a set of stories that
had been scored during planning poker sessions. The teams also attended the regular
meetings defined by Scrum: plannings, retrospectives, and dailies. In order to track
the status of the sprint and to estimate if all the stories would be completed before the
deadline, the teams used a burndown chart. When the migration task force started,
they stopped following the Scrum methodology and started using Kanban. The sprints
with fixed story sets were removed, and all teams started working on continuous
releases: code would be deployed to production as soon as it was tested, without
following specific timelines.
A total of six interviews was conducted. The interviewed group is composed of
three requirement analysts, two development leaders, and one regular developer. All
the interviews followed a semi-structured format, in which the script acted as guide,
but was not followed rigorously. The interviews took 35 minutes on average.
All interviews were recorded and transcripted. The transcriptions were using
Grounded Theory procedures [9]. During the open coding, segments of the interview
were selected and associated with specific codes to better organize and relate relevant
information. Then, codes were all categorized iteratively. Better categorization is
development on the axial coding [9]. The QDA Miner Lite tool supports the analysis
of the transcribed interviews.
3 Theoretical Foundation
3.1 Agile Roles, Responsibilities and Practices
We analyzed different agile development methodologies as described in [2]. We
aimed at identifying roles inserted in the BizDev interface, as well as their practices
and responsibilities. Not all methodologies analyzed defined roles involved at this
interface, and we identified roles with similar responsibilities but different names.
In eXtreme Programming, the Customer is responsible for writing stories,
functional tests, defining when a requirement is satisfied and prioritizing
requirements. Scrum’s Product Owner is responsible for the product backlog. It
should make stories visible to everyone through the product backlog, estimate
delivery time for backlog items and translate backlog items into a definition of
features to be developed. The Customer and the Team should participate in the
creation and maintenance of the Product Backlog.
The Crystal methodology defines the Business Expert, which should possess
knowledge about the business context, being responsible for the business plan. It
should keep track of which requirements are changing and which are stable. The
Business Analyst-Designer should communicate and negotiate with users, and specify
requirements and interfaces based on that communication. In Feature Driven
Development, the Domain Expert is a role that can be performed by a user, customer,
sponsor or business analyst. The Domain Expert should possess knowledge about
what are the goals for every requirement, and pass this knowledge to the developers in
order to ensure that they will deliver a good system.
Finally, Dynamic System Development Method defines the Ambassador User,
which is responsible for bringing knowledge from the user community to the project.
It should also disseminate information from the project to the user community and
guarantee that enough feedback is obtained from it. The Visionary should guarantee
that essential requirements are discovered at the beginning of the project and that the
project is always fulfilling these essential requirements.
3.2 Impacts of business involvement on the development process
When requirements are solely created by the business people, they tend to be written
in a way developers cannot comprehend, creating the necessity of further clarification
[3]. Also, developers may encounter technical constraints that make the complete
fulfillment of a requirement unfeasible, creating the need for reporting the problem to
the business area and waiting for a decision. This scenario indicates that development
projects would benefit from good and constant communication between business and
technology teams. However, business people tend to be constantly busy and
unavailable, creating large waiting times for the development teams, even leading to
leading to situations when the development team is forced to make product decisions
without business basis to meet deadlines [3].
Other impacts from having the business area neglecting participation in the
development process regard problems with requirement prioritization and limited
feedback [3]. In some cases, it is not possible to deliver all requirements on the agreed
deadline, so it is needed to focus on delivering as much value as possible. If the
development team lacks business knowledge needed to prioritize tasks, the business
area should provide support and be available for the development process. When there
is no such support, business people neglect participation at important meetings like
presentations at the end of sprints, limiting the provided feedback, and decreasing the
improvement capacity of a product [3].
According to Beck [11], in eXtreme Programming, a "real customer" should be
interested in the project, making itself available for the development team to answer
questions and solve disputes. This practice is described as "on-site customer". The
impact of having the customer on site was studied on [4]. Perceived benefits of this
practice include the transfer of business knowledge to the development team, faster
feedback from the customer during the development process and increased quality to
the product [4]. However, the benefits of having the customer on-site were only
perceived on the team in which the customer behaved actively and was more involved
in the development process [4]. When the customer behaves passively, the price of
applying this practice was too high and it did not pay out [4].
Two reasons leading to little involvement from the business area on the
development process are traditional project organization and isolation of development
budget under the IT sector [3]. On traditional project organization, the business area
participates actively only on the initial phase, creating many documents containing
requirements, definitions, and deadlines. After such initial phase is finished, the
business area almost withdraws from the process, understanding its participation on
the project is over. When the cost of paying extra hours for developers is paid only by
the IT sector, the business area feels less responsible and sympathetic when a project
fails, since it had not invested resources on the development process [3].
Making business people involved in more project stages helps to create a sense of
ownership and belonging about the project and towards the development team [3]. As
result, people from the business area start to feel like they have more control about the
project progress and that the project becomes more predictable. For this reason, they
are more eager to collaborate with the development team [3].
4 Results
4.1 Organizing the BizDev Interface
Based on similarities between the responsibilities of the analyzed roles (Section
3.1), we proposed three distinct fronts. A front means a set of strongly connected
practices and responsibilities. The fronts do not have responsibility intersections
among them, but one role may be associated with more than one front, which means
that one role may possess responsibilities of more than one front. The union of the
responsibilities of the three fronts comprises all the responsibilities gathered during
the analysis that are involved in the BizDev interface.
Business Tracker. Comprises all activities regarding the creation and continuous
maintenance of a requirement list, such as user stories, product backlogs, and feature
lists. The Business Tracker should guarantee that project development is always
guided by the requirement list. Those associated with this front should define
requirements alongside with their importance and risk for the project, being able to
prioritize them. It is also expected that a Business Tracker is able to define when a
requirement is satisfied.
The following roles have one or more tasks and responsibilities on this front:
Customer (XP and Scrum), Product Owner (Scrum), Team (Scrum) and Visionary
(DSDM). Customer role does not refer to the final customer necessarily. This role is
played by someone who has interest in the project and that possess sufficient business
knowledge to define requirements.
Business Ambassador. Comprises all activities related to translating users’ needs
into business requirements and translating these requirements into features to be
developed. Other activities include negotiating deadlines with the customer. It is
expected from the Business Ambassador to be capable of explaining technical
constraints and resource allocation so that customers can understand demands to
fulfill each deadline. Ambassadors should inform developers regarding the priority of
each requirement, so they can invest effort towards maximizing value delivery.
All activities comprised in this front focus on communication. It is required for
those acting in this front to understand and clarify poorly defined requirements
created by the customers, as well as to minimally understand technical jargon.
The following roles have one or more tasks and responsibilities on this front:
Product Owner (Scrum), Business Analyst-Designer (Crystal), Domain Expert (FDD)
and Ambassador User (DSDM).
Business Expert. This front does not comprise well-defined tasks, it is rather defined
by one responsibility: having deep knowledge about the business domain, becoming a
source of requirements. Those who act in this front should be available during many
different stages of the project, reducing time to get additional information and
clarifications regarding requirements. Customers usually act on this front, even when
they are not considered part of the team. Team members may also act on this front
when they have deep knowledge of the business.
The following roles have one or more tasks and responsibilities on this front:
Business Expert (Crystal) and Domain Expert (FDD).
4.2 Understanding BizDev in the Field
The interview process described in Section 2 took three days. People from the IT
sector worked together at the same open place, while the administrative sector was
located at a different building. The administrative sector acted as both internal
customer and end user. Other end users include professors and students of the
university. The working teams are composed of five to six people. All the teams have
at least one requirement analyst, and one of the teams also had a customer allocated as
a part-time analyst. The remaining members of the team are one development leader
and a variable number of developers.
For the last couple of months before the interviews, the entire IT sector was
allocated on a task force to migrate large-scale legacy systems written in Cobol. For a
long period, the migration task happened alongside with improvements to the system,
but due to a deadline imposed by external factors, it was decided that the
improvements would be performed at a later time and that all teams would focus on
the migration. Since the projects' organization significantly changed for this migration
task force, we focused on getting information from both earlier and current state.
Before the migration project, each team was responsible for specific modules and
submodules of the system (such as student registration, grading, and discipline
scheduling). During the migration task, the teams kept the same members, but lost
responsibilities over specific modules and started participating in a shared backlog.
Before the migration, teams used to attend specific meetings defined by Scrum,
such as planning, daily and retrospectives. Team members also mentioned another
recurrent meeting, called status report, attended by one member from each team
(usually the development leader), by the IT and the administrative directors.
During the analysis of the interviews, important practices and behaviors upon the
BizDev interface stood up. They are described in the next subsections, in which the
terms "business area" and "customer" refer exclusively to the administrative sector.
When we want to emphasize end users, other terms appear. The term "team" is used to
describe teams located inside the IT sector, which are composed of developers and
requirements analysts.
Customer-on-Site. The business area selected two teams from the IT department to
participate in an initiative for reengineering business processes, guided by one
external consulting company. The lead developer of one of those teams mentioned
that the decision of having the customer being allocated inside the development team
came during this initiative. Initially, the customer was allocated full time on the
development team. However, it is currently allocated as part-time, working half
period on the administrative sector, half period with the development team.
The lead developer working along with this on-site customer reported some
benefits of this practice. Being closer to the developers, the customer started seeing
the difficulties they had for understanding requirements written by the business area.
Thus, the customer started to provide additional details about the requirements before
handing them off to the development team. Another perceived benefit is increased
productivity due to fewer interruptions and needs for clarifying requirements. Because
of her participation on the process of gathering requirements and on the specification
of use cases, the customer-on-site can act as a local source of business knowledge for
the developers, eliminating the need to wait for external communication. As a result
of the axial coding, these interactions and activities are depicted in Figure 1.
Fig 1. Activities and Interactions of the Customer-on-Site
The customer-on-site is empowered with the authority of making business
decisions, which made the re-prioritizing process more natural to the development
team. This happens because the customer can understand better technical limitations
and how they are affecting tasks by lowering their priority. The customer-on-site
never had the obligation to report to the business area before making decisions, which
evidences his/her empowerment.
One unexpected behavior reported by the lead developer experiencing the
customer-on-site is that a new type of conflict was created with the business area. It
regards that some people from the business area started seeing the customer-on-site as
someone exclusively from the development team, as an outsider. We observed this
conflict on comments saying the customer-on-site has biased opinions due to its
proximity to the development team, claiming that its opinion is based on some kind of
protective behavior and not on technical or business knowledge. The lead developer is
concerned with the possibility of such conflict to decrease the power the
customer-on-site has for making decisions for the business area.
Requirements Analysts inside Development Teams. The fact that all teams
contained at least one requirement analyst is a sign of approximation between
business and development. The three analysts interviewed had a technical
background, which allowed them to write the requirements sent to the developers in a
very detailed way, even by referring to table and column names from the database.
Previously, the analysts gathered requirements from the customers. During the
migration task force, the requirements are extracted directly from the legacy systems,
in a reverse engineering process. As analysts write new use cases, developers
implement the use cases previously specified, in parallel. It is the analysts'
responsibility to homologate implemented use cases and inform existing problems to
the development team. When developers encounter problems on understanding any
requirement, they ask the analysts for clarification. In cases when the requirements
analyst also needs more information on a requirement, they contact the business area
and ask for information. In this scenario, the requirements analysts are in constant
communication with both business and development people.
One of the interviewed analysts reported the attendance at planning meetings of the
developers, helping to detail requirements and their priorities. He/she also reported
that after some time the whole development team was invited to take part in meetings
with the business area, usually attended by requirements analysts only. As the
collaboration improved, he/she started taking part in daily meetings, explaining what
he/she was working on and what use cases were currently under tests.
List of Use Cases and Re-Prioritization. Prior to the migration task force, demands
were passed to the developers through a requirement list in the form of use cases. The
entire team could participate in the prioritization and re-prioritization of those use
cases. Besides, teams worked on two-week sprints, engaging on planning and
retrospective meetings. On both meetings, the current priorities were discussed and
re-evaluated. From these meetings, the priority of use cases could change. For priority
changes considered to be small, the team was allowed to take decisions by itself.
Otherwise, when changes are critical or involve many dependencies, one specific
meeting would be planned, with participation from members of the business area. The
list of use cases was not fixed or closed, but rather an open artifact, receiving
continuous updates.
Currently, the backlog of the IT sector is composed by a list of "applications",
where each "application" is defined as one entire system flow. This list of applications
has no details about the flow, and for this reason one of the responsibilities of the
requirements analysts is to generate detailed use cases from the applications, using the
legacy system as the source of information.
Production Support. Production support involves all the work made to maintain
systems already released and used in production. Existing activities are bug fixes,
failure analysis and answering users' and customers' questions. Some bugs are
detected automatically and reported through the Redmine tool, while others are
reported directly by end users or by the business area, through the creation of issues at
the Redmine tool or through other means of contact (phone, email, direct contact).
There is no team allocated exclusively to work on production support, so every team
has to engage frequently on this kind of activity. It is the lead developer's
responsibility to pull production support tasks to their team, prioritizing it against the
team's current priorities. However, one of the teams reported that developers also
helped on this prioritization, pushing tasks to themselves based on their knowledge
about how critical the support task is.
As one of the interviewed lead developers mentioned production support tasks are
frequent and do interfere on planned deadlines. Due to the academic nature of the
systems, there are certain periods of the year such as beginning and ending of
semesters when demands for production support grows significantly. At these periods,
not only the number of tasks increase but their criticity increase as well, demanding
faster attention and solution from the development teams.
One practice adopted by one of the interviewed teams to reduce the impact of the
production support on planned deadlines is to allocate a fixed amount of items for the
sprint. In this case, three stories (~15 hours) are held for ongoing support tasks and,
for this reason, the amount of stories regarding feature implementations is reduced.
This team's lead developer considered that this practice worked fine, even though
sometimes production support tasks continued to impact planned deadlines. Another
practiced adopted by this team is to create new stories (besides the three already
reserved) for production support tasks that began on the previous sprint but had not
finished yet, still demanding effort from the team. This practice is applied on the
critical periods of the academic year, as described before.
Situating BizDev Fronts. Through the use of coding procedures from Grounded
Theory, we identified in which fronts the analyzed roles were inserted. For example,
an interview segment describing how team members would discuss the priority of
backlog items during planning meetings coded as both “re-prioritization of backlog
items” and “developer”, indicating the “developer” role performs this practice when
playing on the Business Tracker front.
We were able to identify benefits of having people acting in the Business Expert
front through interview segments coded as “Constant clarification of use cases”.
Being more available to the development team, the customer-on-site was able to
reduce significantly the amount of time spent with clarification of requirements. The
customer-on-site allocated in one of the interviewed teams worked alongside with the
requirements analyst, and due to his/her business knowledge, he/she was able to write
more detailed requirements.
The presence of requirements analysts inside development teams indicates how
pertinent and relevant is the Business Ambassador front. Interview segments coded as
“technical background” indicated how requirement analysts have no complications in
communicating with developers. Since requirements analysts had a technical
background, they are able to understand and communicate well with both developers
and customers, even being able to write requirements adding technical details. The
requirements analysts work as a bridge between developers and the business area,
gathering requirements from customers and translating them into user stories or use
cases that developers can understand, and also by communicating questions from the
development team for the business area to answer.
All roles analyzed in the qualitative study have one activity associated with the
Business Tracker front: the continuous re-prioritization of backlog items. The
requirements analysts and the customer-on-site also acted at this front by creating and
detailing the use cases that compose the backlog. Even though all roles participated at
the Business Tracker front, we were not able to identify anyone having the specific
responsibility of guaranteeing that all the development process is always guided by
the requirements list (backlog).
5 Threats to Validity
Mainly, this qualitative research is limited to the adopted investigation methods,
namely an ad-hoc literature review and a set of interviews with practitioners. In this
sense, we discuss the threats to validity under a pragmatic worldview [12].
5.1 Theoretical Validity
We started by identifying roles, responsibilities, and practices proposed and
well-documented in the literature. Then, we synthesized those elements to reach a
perspective that is agnostic to any particular agile method. It allowed us to structure
two interviews scripts (instruments) to collect information regarding the BizDev
interface. As far as we could identify, these instruments provided a large spectrum of
the intended phenomenon, with no bias to any specific reference on how the BizDev
interface should be.
5.2 Generalizability
Although the definition of the BizDev fronts (Section 4.1) intends to be general, we
understand it as a first version for characterizing this interface. Internally, i.e., within
the teams and the observed organization, we understand it fully captures the roles,
responsibilities, and practices. However, we also recognize that more instances are
required, i.e., we need to further investigate the BizDev interface externally,
observing different teams and organizations, with different cultures and development
5.3 Descriptive Validity
Apart from the instruments intending to be agnostic to particular agile methods, we
understand the data collected using interview scripts as free from bias as participants
were free to answer as much as they need with no time constraints and also aware of
the importance on collaborating for this research. The interviews were audio recorded
and transcribed in full with no synthesis or intervention by the researchers. Finally,
the analysis of the interview data was performed using Grounded Theory procedures
for coding the data, namely the Constant Comparative Method, using
conceptualization and abstraction. Thus, we understand the current state of our
codebook as an authentic abstraction of the raw data.
5.4 Interpretive Validity
Qualitative analysis naturally faces subjectivity due to interpretive synthesis and
conceptualization. However, we understand the reasoning leading to our findings can
be traced back to raw data in a reasonable way through the generated codes and
categories in the codebook. Two researchers performed and constantly reviewed the
analysis to reduce possible bias.
6 Final Remarks
This paper presented a study concerning a better characterization of the BizDev
interface. For that, we conducted a literature review and a qualitative study to gather
information considering the consolidated knowledge available in the literature and the
state of the practice by conducting a set of interviews.
The information gathered so far indicates that a healthy interface between business
and development can benefit software projects. Closer communication with the
business area can improve the productivity of development teams by reducing the
time spent waiting for requirements clarification. Also, to have additional business
knowledge inside the development teams enables major flexibility through a better
re-prioritization process.
As future works, we envision to conduct further investigation on other
organizations and cultures with different profiles. For that, we plan to review the
interview scripts aiming at improving the data collection efficiency without
compromising their current effectiveness, as we experienced a great effort to
transcribe all the interviews and some data was not relevant for the research goals.
1. Agile Manifesto, Access at: 2018/02/07.
2. Abrahamsson, P., Salo, O., Ronkainen, J., Warsta, J.: Agile software development
methods: Review and analysis, VTT publication 478, Espoo, Finland (2002)
3. van Waardenburg, G., vans Vliet, H.: When Agile Meets Enterprise. Journal Information
and Software Technology, Volume 55, Issue 12, 2154-2171 (2013).
4. Conboy, K.: Agility from first principles: reconstructing the concept of agility in
information systems development. J. Inf. Systems Research 20 (3), 317-480 (2009).
5. Stuart Weiss, R.: Learning from Strangers: The Art and Method of Qualitative Interview
Studies. Free Press, New York (1995).
6. Schwaber, K.: Agile Project Management With Scrum. Microsoft Press (2004).
7. Bass, J. M.: Agile Method Tailoring in Distributed Enterprises: Product Owner Teams. In:
8th Intl. Conf. on Global Software Engineering (ICGSE), p. 154-163. IEEE, Bari (2013).
8. Gregorio, D. D.: How the Business Analyst Supports and Encourages Collaboration on
Agile Projects. In: Systems Conference (SysCon), IEEE International. p. 1-4. IEEE,
Vancouver (2012).
9. Corbin, J., Strauss, A. L: Basics of Qualitative Research - Techniques and Procedures for
Developing Grounded Theory. 4th ed. SAGE Publications (1990).
10. Fitzgerald, B., Stol, K.: Continuous Software Engineering: A Roadmap and Agenda.
Journal of Systems and Software, Volume 123, p. 176-189 (2015).
11. Beck, K. Extreme Programming Explained: Embrace Change. 2nd. ed. Addison-Wesley
12. Petersen, K., Gencel, C.: Worldviews, research methods, and their relationship to validity
in empirical software engineering research. In: International Workshop on Software
Measurement and the Eighth International Conference on Software Process and Product
Measurement (IWSM-MENSURA), pp. 81-89. IEEE, Ankara, Turkey (2013).
13. de França, B. B. N., Jeronimo Junior, H., Travassos, G. H.: Characterizing DevOps by
Hearing Multiple Voices. In: Proceedings of the 30th Brazilian Symposium on Software
Engineering, pp. 53-62. ACM, Maringá, Brazil (2016).
Appendix A - Interview Scripts
1. Common Questions
Warm Up:
For how long have you been in the company?
How many people are part of your team? (or teams, in cases when the
interviewed works in more than one)
About the Job Description:
What is the name of the interviewed position?
What are the interviewed responsibilities?
Requirement Managing:
How are the product's features defined?
Where does the information needed to decide these features come
from? Customer inputs? Are there specific meetings on the business
team for that purpose?
Is there any requirement list?
How is it build? How are updates made to it? How is it exposed to
the development team? And for the business team?
How are requirements translated into features to be developed?
How far does it plan? Months? A year?
How are the requirements prioritized? Who participates on this process?
Can requirements be re-prioritized?
Case positive: How often does this happen? Does the interviewed
believe this is beneficial?
Case negative: For what reason do the priorities keep stable? Does
the interviewed think having reprioritization would be beneficial?
2. Specific Questions for Technical Profile
Task Division:
How is the definition of the tasks the team will work on through the week?
Feature Delivery:
How is a task defined as done?
Do you make any tests with the final customer? Case positive, how is it done
and who participates on this process?
How is the delivery of a feature made?
Is there any follow up after the features are delivered?
How do you get to know whether the delivery fulfilled the requirement of the
customer and business area?
Communication With Business Area and With Customers:
Is there any planned meeting? Like daily, weekly, post-sprint presentations.
Case Positive: How are these meetings? Who participates on them?
How long they last? What is discussed?
What happens when developers have business questions during the process?
How hard is it for the development team to talk to customers and to
the business area?
Are there conflicts between the business and development areas? (Get
specific examples)
How does the development team communicate problems encountered to the
business area?
What happens when the development team realizes that it won't be
able to reach a deadline? How are expectations managed?
How is communication itself? Is it needed for the development team to
translate technical jargons? How is the experience of explaining technical
obstacles and problems for the business area?
Does communication problems like fail to comprehend
requirements happen?
3. Specific Questions for Business Profile
Requirement Managing:
How are the product's features defined?
Where does the information needed to decide these features come
from? Customer inputs? Are there specific meetings on the business
team for that purpose?
Communication With the Development Team:
How are product requirements transmitted to the development team?
How often does this communication happen? (Formal and informal)
How is the tracking of development made? How do you know if everything
will end on the planned time?
Do you happen to find it hard to understand the technical team? For example,
many technical jargons, many unknown technologies being used.
Do you usually involve someone technical in any type of business meetings?
Communication with the customer:
How do you gather feedback from the customer about delivered products?
Are there any tests made with the customers?
How are bugs detected?
After a bug is detected, what actions are taken?
ResearchGate has not been able to resolve any citations for this publication.
Full-text available
This paper explores practitioner descriptions of agile method tailoring in large-scale offshore or outsourced enterprise projects. Specifically, tailoring of the product owner role is discussed. The product owner identifies and prioritizes customer requirements. But in globalized projects, the product owner must reconcile large numbers competing business interests and generate prioritized requirements for many development teams. The study comprises 8 international companies in London, Bangalore and Delhi. Interviews with 46 practitioners were conducted between February 2010 and May 2012. A grounded theory approach was used to identify that product owner teams comprise nine roles: Groom, Prioritizer, Release Master, Technical Architect, Governor, Communicator, Traveler, Intermediary and Risk Assessor. These product owner roles arbitrate between conflicting customer requirements, approve release schedules, make architectural design decisions, provide technical governance and disseminate information across teams. Understanding these roles will help agile coaches guide large scale agile teams.
Conference Paper
Full-text available
Background - Validity threats should be considered and consistently reported to judge the value of an empirical software engineering research study. The relevance of specific threats for a particular research study depends on the worldview or philosophical worldview of the researchers of the study. Problem/Gap - In software engineering, different categorizations exist, which leads to inconsistent reporting and consideration of threats. Contribution - In this paper, we relate different worldviews to software engineering research methods, identify generic categories for validity threats, and provide a categorization of validity threats with respect to their relevance for different world views. Thereafter, we provide a checklist aiding researchers in identifying relevant threats. Method - Different threat categorizations and threats have been identified in literature, and are reflected on in relation to software engineering research. Results - Software engineering is dominated by the pragmatist worldviews, and therefore use multiple methods in research. Maxwell's categorization of validity threats has been chosen as very suitable for reporting validity threats in software engineering research. Conclusion - We recommend to follow a checklist approach, and reporting first the philosophical worldview of the researcher when doing the research, the research methods and all threats relevant, including open, reduced, and mitigated threats.
Full-text available
peer-reviewed Awareness and use of agile methods has grown rapidly among the information systems development (ISD) community in recent years. Like most previous methods, the development and promotion of these methods have been almost entirely driven by practitioners and consultants, with little participation from the research community during the early stages of evolution. While these methods are now the focus of more and more research efforts, most studies are still based on XP, Scrum, and other industry-driven foundations, with little or no conceptual studies of ISD agility in existence. As a result, this study proposes that there are a number of significant conceptual shortcomings with agile methods and the associated literature in its current state, including a lack of clarity, theoretical glue, parsimony, limited applicability, and naivety regarding the evolution of the concept of agility in fields outside systems development. Furthermore, this has significant implications for practitioners, rendering agile method comparison and many other activities very difficult, especially in instances such as distributed development and large teams that are not conducive to many of the commercial agile methods. This study develops a definition and formative taxonomy of agility in an ISD context, based on a structured literature review of agility across a number of disciplines, including manufacturing and management where the concept originated, matured, and has been applied and tested thoroughly over time. The application of the texonomy in practice is then demonstrated through a series of thought trials conducted in a large multinational organization. The intention is that the definition and taxonomy can then be used as a starting point to study ISD method agility regardless of whether the method is XP or Scrum, agile or traditional, complete or fragmented, out-of-the-box or in-house, used as is or tailored to suit the project context.
Conference Paper
Recently, DevOps has emerged as an alternative for software organizations inserted into a dynamic market to handle daily software demands. As claimed, it intends to make the software development and operations teams to work collaboratively. However, it is hard to observe a shared understanding of DevOps, what potentially hinders the discussions in the literature and can confound observations when conducting empirical studies. Therefore, we performed a Multivocal Literature Review aiming at characterizing DevOps in multiple perspectives, including data sources from technical and gray literature. Grounded Theory procedures were used to rigorous analyze the collected data. It allowed us to achieve a grounded definition for DevOps, as well as to identify its recurrent principles, practices, required skills, potential benefits, challenges and what motivates the organizations to adopt it. Finally, we understand the DevOps movement has identified relevant issues in the state-of-the-practice. However, we advocate for the scientific investigations concerning the potential benefits and drawbacks as a consequence of adopting the suggested principles and practices.