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

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

Enterprise Agility: Why Is Transformation so Hard?

Enterprise agility requires capabilities to transform, sense and seize new business opportunities more quickly than competitors. However, acquiring those capabilities, such as continuous delivery and scaling agility to product programmes, portfolios and business models, is challenging in many organisations. This paper introduces definitions of enterprise agility involving business management and cultural lenses for analysing large-scale agile transformation. The case organisation, in the higher education domain, leverages collaborative discovery sprints and an experimental programme to enable a bottom-up approach to transformation. Meanwhile the prevalence of bureaucracy and organisational silos are often contradictory to agile principles and values. The case study results identify transformation challenges based on observations from a five-month research period. Initial findings indicate that increased focus on organisational culture and leveraging of both bottom-up innovation and supportive top-down leadership activities, could enhance the likelihood of a successful transformation

Management of software development projects in Brazil using agile methods

The aim of the paper is to analyze how agile management practices are being adopted by specialists from software development technology companies in Brazil, identifying actions that contribute to the success of software implementation, aiming to ensure the survival of organizations in the market. The study counted with a literature review to support the field research with software development specialists who use the agile methodology and work in Brazil in the states of Rio de Janeiro and São Paulo. The results were analyzed through a descriptive statistics and content analysis. The research identified that the companies that adopt agile software management methodology in Brazil prefer the Scrum method and the development teams may be geographically distributed. The main positive points identified when adopting agile methods were the process speed, team involvement, maximization of results, involvement with the client, and simplicity. Most experts identified problems in the implementation of the agile methodology and as points of attention: management of distributed teams, scope estimation and communication. It was possible to identify the existence of a positive financial result by adopting the agile method for software development projects, as well as actions that contribute to the success of these projects, such as controlling quality using different testing techniques, project management, time, stakeholders, scope, and have agile communication, with feedback and good leadership. On the other hand, it was observed in the statistics that, although efficient, this method is still not being widely used. This research can contribute to the managers of software development companies in the use of agile methods as well as improving management decision-making

An Empirical Study on Decision making for Quality Requirements

[Context] Quality requirements are important for product success yet often handled poorly. The problems with scope decision lead to delayed handling and an unbalanced scope. [Objective] This study characterizes the scope decision process to understand influencing factors and properties affecting the scope decision of quality requirements. [Method] We studied one company's scope decision process over a period of five years. We analyzed the decisions artifacts and interviewed experienced engineers involved in the scope decision process. [Results] Features addressing quality aspects explicitly are a minor part (4.41%) of all features handled. The phase of the product line seems to influence the prevalence and acceptance rate of quality features. Lastly, relying on external stakeholders and upfront analysis seems to lead to long lead-times and an insufficient quality requirements scope. [Conclusions] There is a need to make quality mode explicit in the scope decision process. We propose a scope decision process at a strategic level and a tactical level. The former to address long-term planning and the latter to cater for a speedy process. Furthermore, we believe it is key to balance the stakeholder input with feedback from usage and market in a more direct way than through a long plan-driven process

Requirements engineering challenges and practices in large-scale agile system development

Context: Agile methods have become mainstream even in large-scale systems engineering companies that need to accommodate different development cycles of hardware and software. For such companies, requirements engineering is an essential activity that involves upfront and detailed analysis which can be at odds with agile development methods. Objective: This paper presents a multiple case study with seven large-scale systems companies, reporting their challenges, together with best practices from industry. We also analyze literature about two popular large-scale agile frameworks, SAFe (R) and LeSS, to derive potential solutions for the challenges. Methods: Our results are based on 20 qualitative interviews, five focus groups, and eight cross company workshops which we used to both collect and validate our results. Results: We found 24 challenges which we grouped in six themes, then mapped to solutions from SAFe (R), LeSS, and our companies, when available. Conclusion: In this way, we contribute a comprehensive overview of RE challenges in relation to largescale agile system development, evaluate the degree to which they have been addressed, and outline research gaps. We expect these results to be useful for practitioners who are responsible for designing processes, methods, or tools for large scale agile development as well as guidance for researchers

Large Software Implementation Project: A study of software development and project management literature

This study focuses on large scale software delivery, where development is done on top of an existing system or parallel to it. This thesis aims to answer to the question: How to implement a large scale custom solution? Large scale projects take longer than smaller projects to implement and usually they are done in more than in one release. The application’s life-cycle is also planned to last up to decades. Large projects also need special project management skills, executive support, internal investments, strategical vision as well as alignment between IT and business. Large projects are usually complex and have several dependencies. This study also explains what issues projects usually have and what are the constrains of legacy systems and data migration. Different eras of IT systems are also presented as well as reasons why companies should invest to IT solutions. Waterfall model and Agile methodology fundamentals and background are presented shortly. From Agile methodology Scrum and SAFe frameworks are presented as examples. Keywords: Legacy system, Data Migration, Software implementation, project management, COTS, Agile development, Waterfal

Applying Behavior Driven Development Practices and Tools to Low-Code Technology

One of the main reasons software projects fail is the lack of communication between stakeholders. Low Code Platforms have been recently growing in the software development market. These allow creating state-of-the-art applications with facilitated design and integration, in a rapid development fashion and as such, avoiding communication errors among stakeholders is indispensable to avoid regressions. Behavior-Driven Development (BDD) is a practice that focuses on developing value-based software, promoting communication by bringing business people into development. The BDDFramework is an open-source testing automation framework within the Out- Systems environment. It allows describing test scenarios using the Gherkin syntax but it is not focused on enabling the BDD process. Our main challenge is: - How can we apply the BDD process in Low Code and support it from a technological point of view, considering the particularities of Low Code environments and having as case study the OutSystems platform? Is the BDDFramework prepared for this? We interviewed some people in the domain to understand their development and testing challenges and their experience with the BDDFramework. With the information gathered and after studying other existing BDD process supporting tools for other languages, we built a prototype that uses the existing BDDFramework and automates it, allowing scenarios to be described in text files, which helps the introduction of business people in the process. The prototype generates all the test structure automatically, reusing equal steps while detecting parameters in the Gherkin descriptions. We performed some real user testing to validate our prototype and we found that our solution was faster, easier, with better usability and we obtained more correct tests than with the previous approach - the BDDFramework alone. Testing in Low Code is still an area with a lot to explore and errors have a huge impact when development is very accelerated, so as communication errors tend to decrease we can start building software even faster and this is what BDD proposes to solve. With this prototype we have been able to demonstrate that it is possible to build a framework that will allow us to enable this process by taking advantage of the OutSystems language particularities to potentiate the BDD practice technologically, while setting a test standard for the OutSystems language

AHAA- Agile, Hybrid Assessment Method for Automotive, Safety Critical SMEs

The need for software is increasingly growing in the automotive industry. Software development projects are, however, often troubled by time and budget overruns, resulting in systems that do not fulfill customer requirements. Both research and industry lack strategies to combine reducing the long software development lifecycles (as required by time-to-market demands) with increasing the quality of the software developed. Software process improvement (SPI) provides the first step in the move towards software quality, and assessments are a vital part of this process. Unfortunately, software process assessments are often expensive and time consuming. Additionally, they often provide companies with a long list of issues without providing realistic suggestions. The goal of this paper is to describe a new low-overhead assessment method that has been designed specifically for small-to-medium-sized (SMEs) organisations wishing to be automotive software suppliers. This assessment method integrates the structured-ness of the plan-driven SPI models of Capability Maturity Model Integration (CMMI) and Automotive SPICETM with the flexibleness of agile practices

How Agile is Agile Enough? Towards A Theory of Agility in Software Development

One poorly investigated issue in organizational agility is the question how organizations change their speed while adopting and exploiting new IT capability. In this paper we outline a theory of software development agility that draws upon a model of IT innovations by Swanson and on March’s learning theory and in particular on his concepts of exploration and exploitation. We explore how both exploration and exploitation as organizational learning modes can software development agility. We propose a sequential model of organizational learning in which agility is driven by different factors during different stages – exploration vs. exploitation- of organizational learning. We show that software development agility is influenced by the external demands, the diffusion level and rate of the IT innovation, its radicalness, and the organizations’ needs to balance multiple conflicting process goals including speed, quality, cost, risk and innovative content. We illustrate the value of the model by exploring how seven software organizations controlled the demands for increased agility i.e. their development speed or over a period of five years (1999-2004), and how they balanced the need for the increased agility with other critical development criteria like cost, risk, quality and innovative content. In conclusion, we discuss the implications of our findings for future research on agility and related management practices