Catálogo de publicaciones - libros

The integration of user-centred design and Agile development is becoming increasingly common in companies and appears promising. However, it may also present some critical points, or communication breakdowns, such as a variable interpretation of user involvement, a mismatch in the value of documentation, and a misalignment in iterations. We refine these themes, emerging from both literature and previous fieldwork, by analysing a case study performed in an IT company that adopts both software engineering approaches, and we further extend the framework with a new theme related to task ownership. We argue that communication breakdowns can become focal points to drive action and decision for establishing an organisational context acknowledging the value of user involvement: to this end, we suggest the adoption of design thinking and the active engagement of the customer in embracing its values.

Many tools have been created for measuring the agility of software teams, thus creating a saturation in the field. Three agile measurement tools were selected in order to validate whether they yield similar results. The surveys of the tools were given to teams in Company (). The questions were grouped into agile practices which were checked for correlation in order to establish convergent validity. In addition, we checked whether the questions identified to be the same among the tools would be given the same replies by the respondents. We could not establish convergent validity since the correlations of the data gathered were very few and low. In addition, the questions which were identified to have the same meaning among the tools did not have the same answers from the respondents. We conclude that the area of measuring agility is still immature and more work needs to be done. Not all tools are applicable to every team but they should be selected on the basis of how a team has transitioned to agile.

One of the benefits of agile is close collaboration of customer and developer. This ensures good commitment and excellent knowledge flows of information about priorities and efforts. However, it is unclear if this benefit can be leveraged at scale. Clearly, it is infeasible to use practices such as planning game with several agile teams in the room. In this paper, we investigate how a large-scale agile organization manages, what challenges exist, and which opportunities can be leveraged. We found challenges in three areas: (i) the ability to estimate, prioritize, and plan; (ii) the context of planning with respect to working environment, team build-up, and team spirit; and (iii) the ceremonial agreement which promises to allow leveraging abilities in a given context.

With agile teams becoming increasingly multi-disciplinary and including all functions, the role of customer feedback is gaining momentum. Today, companies collect feedback directly from customers, as well as indirectly from their products. As a result, companies face a situation in which the amount of data from which they can learn about their customers is larger than ever before. In previous studies, the collection of data is often identified as challenging. However, and as illustrated in our research, the challenge is not the collection of data but rather how to share this data among people in order to make effective use of it. In this paper, and based on case study research in three large software-intensive companies, we (1) provide empirical evidence that ‘lack of sharing’ is the primary reason for insufficient use of customer and product data, and (2) develop a model in which we identify what data is collected, by whom data is collected and in what development phases it is used. In particular, the model depicts critical hand-overs where certain types of data get lost, as well as the implications associated with this. We conclude that companies benefit from a very limited part of the data they collect, and that lack of sharing of data drives inaccurate assumptions of what constitutes customer value.

A bad software development process leads to wasted effort and inferior products. In order to improve a software process, it must be first understood. Our unique approach in this paper uses code and test changes to understand conformance to the Test Driven Development (TDD) process.

We designed and implemented , a tool that supports developers in better understanding how they conform to TDD. supports this understanding by providing novel visualizations of developers’ TDD process. To enable ’s visualizations, we developed a novel automatic inferencer that identifies the phases that make up the TDD process solely based on code and test changes.

We evaluate using two complementary methods: a controlled experiment with 35 participants to evaluate the visualization, and a case study with 2601 TDD Sessions to evaluate the inference algorithm. The controlled experiment shows that, in comparison to existing visualizations, participants performed significantly better when using to answer questions about code evolution. In addition, the case study shows that the inferencing algorithm in infers TDD phases with an accuracy (F-measure) of 87%.

Startups operate with small resources in time pressure. Thus, building minimal product versions to test and validate ideas has emerged as a way to avoid wasteful creation of complicated products which may be proven unsuccessful in the markets. Often, design of these early product versions needs to be done fast and with little advance information from end-users. In this paper we introduce the Minimum Viable User eXperience (MVUX) that aims at providing users a good enough user experience already in the early, minimal versions of the product. MVUX enables communication of the envisioned product value, gathering of meaningful feedback, and it can promote positive word of mouth. To understand what MVUX consists of, we conducted an interview study with 17 entrepreneurs from 12 small startups. The main elements of MVUX recognized are Attractiveness, Approachability, Professionalism, and Selling the Idea. We present the structured framework and elements’ contributing qualities.

Multi-project agile software development is a relatively new area of research. While original Scrum caters to co-located teams working on a single project, multi-project Scrum teams are a day-to-day reality, especially in small organizations. Multitasking across projects is frequently associated with loss of effectiveness, but this assumption is not sufficiently supported by empirical evidence. In order to better understand the phenomenon, we review existing literature across scientific domains and execute an action research project. Our findings show that the Team Portfolio Scrum (TPS) practice designed to support multitasking across projects is perceived to be useful, but with an associated increase in overhead.

Various agile methods have several quality assurance mechanisms embedded in the process itself, without any explicit QA role. In principle, the team takes care of quality assurance during sprints and as part of daily stand-ups, sprint reviews and retrospectives. We have defined SafeScrum, a variant of Scrum with some additional XP techniques that can be used to develop safety-critical software and have the software certified according to the IEC 61508 standard. This imposes a load of additional requirements on the process. In a recent industrial case, we have experienced that the quality assurance mechanisms in Scrum becomes insufficient. We have therefore analyzed the standard, consulted an independent assessor and worked with the Scrum team to identify necessary additional tasks for a team-internal QA role to be added to the SafeScrum process.

Software developers are both users of development tools but also designers of new software systems. This dual role makes developers special users of work-related software. To increase the understanding of developers as users and to evaluate the ability of common measurement scales to address developer experience, we conducted a survey measuring developers’ flow state, intrinsic motivation and user experience. Scales used were the Short Dispositional Flow Scale, items from the Intrinsic Motivation Inventory, the Short AttrakDiff-2, and our own DEXI scale. 57 developers from 25 countries responded and results indicate that intrinsic motivation and autotelic experience are significant predictors of developers’ UX whereas hedonic, pragmatic, and general quality are not. In addition, developers’ needs are characterized by efficiency, informativeness, intuitiveness, and flexibility of the tool.

Minimum viable product (MVP) is the main focus of both business and product development activities in software startups. We empirically explored five early stage software startups to understand how MVP are used in early stages. Data was collected from interviews, observation and documents. We looked at the MVP usage from two angles, software prototyping and boundary spanning theory. We found that roles of MVPs in startups were not fully aware by entrepreneurs. Besides supporting validated learning, MVPs are used to facilitate product design, to bridge communication gaps and to facilitate cost-effective product development activities. Entrepreneurs should consider a systematic approach to fully explore the value of MVP, as a multiple facet product (MFP). The work also implies several research directions about prototyping practices and patterns in software startups.