34,881 research outputs found
Non-Technical Individual Skills are Weakly Connected to the Maturity of Agile Practices
Context: Existing knowledge in agile software development suggests that
individual competency (e.g. skills) is a critical success factor for agile
projects. While assuming that technical skills are important for every kind of
software development project, many researchers suggest that non-technical
individual skills are especially important in agile software development.
Objective: In this paper, we investigate whether non-technical individual
skills can predict the use of agile practices. Method: Through creating a set
of multiple linear regression models using a total of 113 participants from
agile teams in six software development organizations from The Netherlands and
Brazil, we analyzed the predictive power of non-technical individual skills in
relation to agile practices. Results: The results show that there is
surprisingly low power in using non-technical individual skills to predict
(i.e. explain variance in) the mature use of agile practices in software
development. Conclusions: Therefore, we conclude that looking at non-technical
individual skills is not the optimal level of analysis when trying to
understand, and explain, the mature use of agile practices in the software
development context. We argue that it is more important to focus on the
non-technical skills as a team-level capacity instead of assuring that all
individuals possess such skills when understanding the use of the agile
practices.Comment: 18 pages, 1 figur
Boundary Objects and their Use in Agile Systems Engineering
Agile methods are increasingly introduced in automotive companies in the
attempt to become more efficient and flexible in the system development. The
adoption of agile practices influences communication between stakeholders, but
also makes companies rethink the management of artifacts and documentation like
requirements, safety compliance documents, and architecture models.
Practitioners aim to reduce irrelevant documentation, but face a lack of
guidance to determine what artifacts are needed and how they should be managed.
This paper presents artifacts, challenges, guidelines, and practices for the
continuous management of systems engineering artifacts in automotive based on a
theoretical and empirical understanding of the topic. In collaboration with 53
practitioners from six automotive companies, we conducted a design-science
study involving interviews, a questionnaire, focus groups, and practical data
analysis of a systems engineering tool. The guidelines suggest the distinction
between artifacts that are shared among different actors in a company (boundary
objects) and those that are used within a team (locally relevant artifacts). We
propose an analysis approach to identify boundary objects and three practices
to manage systems engineering artifacts in industry
What influences the speed of prototyping? An empirical investigation of twenty software startups
It is essential for startups to quickly experiment business ideas by building
tangible prototypes and collecting user feedback on them. As prototyping is an
inevitable part of learning for early stage software startups, how fast
startups can learn depends on how fast they can prototype. Despite of the
importance, there is a lack of research about prototyping in software startups.
In this study, we aimed at understanding what are factors influencing different
types of prototyping activities. We conducted a multiple case study on twenty
European software startups. The results are two folds, firstly we propose a
prototype-centric learning model in early stage software startups. Secondly, we
identify factors occur as barriers but also facilitators for prototyping in
early stage software startups. The factors are grouped into (1) artifacts, (2)
team competence, (3) collaboration, (4) customer and (5) process dimensions. To
speed up a startups progress at the early stage, it is important to incorporate
the learning objective into a well-defined collaborative approach of
prototypingComment: This is the author's version of the work. Copyright owner's version
can be accessed at doi.org/10.1007/978-3-319-57633-6_2, XP2017, Cologne,
German
Business Value Is not only Dollars - Results from Case Study Research on Agile Software Projects
Business value is a key concept in agile software development. This paper presents results of a case study on how business value and its creation is perceived in the context of agile projects. Our overall conclusion is that the project participants almost never use an explicit and structured approach to guide the value creation throughout the project. Still, the application of agile methods in the studied cases leads to satisfied clients. An interesting result of the study represents the fact that the agile process of many projects differs significantly from what is described in the agile practitionersâ books as best practices. The key implication for research and practice is that we have an incentive to pursue the study of value creation in agile projects and to complement it by providing guidelines for better clientâs involvement, as well as by developing structured methods that will enhance the value-creation in a project
Looking for Reasons behind Success in Dealing with Requirements Change
During development, requirements of software systems are subject to change. Unfortunately, managing changing requirements can take a lot of time and effort. Yet some companies show a better management of changes in requirements than others. Why? What is it that makes some projects deal with changing requirements better than others? We pursue the long term goal of understanding the mechanisms used to successfully deal with change in requirements. In this paper we gather knowledge about the state-of-the-art and the state-of-practice. We studied eight software development projects in four different companies --large and small, inclined toward structured and toward agile principles of development--, interviewing their project managers and analyzing their answers. Our findings include a list of practical (rather than theoretical) factors affecting the ability to cope with small changes in requirements. Results suggest a central role of size as a factor determining the flexibility showed either by the organization or by the software development team. We report the research method used and validate our results via expert interviews, who could relate to our findings
- âŠ