Catálogo de publicaciones - libros

A retrospective is a standard agile meeting practice designed for agile software teams to reflect and tune their process. Despite its integral importance, we know little about what aspects are focused upon during retrospectives and how reflection occurs in this practice. We conducted Case Study research involving data collected from interviews of sixteen software practitioners from four agile teams and observations of their retrospective meetings. We found that the important aspects focused on during the retrospective meeting include identifying and discussing obstacles, discussing feelings, analyzing previous action points, identifying background reasons, identifying future action points and generating a plan. Reflection occurs when the agile teams embody these aspects within three levels of reflection: reporting and responding, relating and reasoning, and reconstructing. Critically, we show that agile teams may not achieve all levels of reflection simply by performing retrospective meetings. One of the key contributions of our work is to present a reflection framework for agile retrospective meetings that explains and embeds three levels of reflection within the five steps of a standard agile retrospective. Agile teams can use this framework to achieve better focus and higher levels of reflection in their retrospective meetings.

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 startup’s progress at the early stage, it is important to incorporate the learning objective into a well-defined collaborative approach of prototyping.

Agile Software Development (ASD) is becoming more popular in all fields of industry. For an agile transformation, organizations need to continuously improve their established approaches to Requirements Engineering (RE) as well as their approaches to software development. This is accompanied by some challenges in terms of agile RE. The main objective of this paper is to identify the most important challenges in agile RE industry has to face today. Therefore, we conducted an iterative expert judgement process with 26 experts in the field of ASD, comprising three complementary rounds.

In sum, we identified 20 challenges in three rounds. Six of these challenges are defined as key challenges. Based on the results, we provide options for dealing with those key challenges by means of agile techniques and tools. The results show that the identified challenges are often not limited to ASD, but they rather refer to software development in general. Therefore, we can conclude that organizations still struggle with agile transition and understanding agile values, in particular, in terms of stakeholder and user involvement.

Today, software teams can deploy new software versions to users at an increasing speed – even continuously. Although this has enabled faster responding to changing customer needs than ever before, the speed of automated customer feedback gathering has not yet blossomed out at the same level. For these purposes, the automated collecting of quantitative data about how users interact with systems can provide software teams with an interesting alternative. When starting such a process, however, teams are faced immediately with difficult decision making: What kind of technique should be used for collecting user-interaction data? In this paper, we describe the reasons for choosing specific collecting techniques in three cases and refine a previously designed selection framework based on their data. The study is a part of on-going design science research and was conducted using case study methods. A few distinct criteria which practitioners valued the most arose from the results.

Eliciting requirements from customers is a complex task. In Agile processes, the customer talks directly with the development team and often reports requirements in an unstructured way. The requirements elicitation process is up to the developers, who split it into user stories by means of different techniques. We aim to compare the requirements decomposition process of an unstructured process and three Agile processes, namely XP, Scrum, and Scrum with Kanban. We conducted a multiple case study with a replication design, based on the project idea of an entrepreneur, a designer with no experience in software development. Four teams developed the project independently, using four different development processes. The requirements were elicited by the teams from the entrepreneur, who acted as product owner and was available to talk with the four groups during the project. The teams decomposed the requirements using different techniques, based on the selected development process. Scrum with Kanban and XP resulted in the most effective processes from different points of view. Unexpectedly, decomposition techniques commonly adopted in traditional processes are still used in Agile processes, which may reduce project agility and performance. Therefore, we believe that decomposition techniques need to be addressed to a greater extent, both from the practitioners’ and the research points of view.

Technical Debt is a metaphor that has, in recent years, helped developers to think about and to monitor software quality. The metaphor refers to flaws in software (usually caused by shortcuts to save time) that may affect future maintenance and evolution. We conducted an empirical study in an academic environment, with nine teams of graduate and undergraduate students during two offerings of a laboratory course on Extreme Programming (XP Lab). The teams had a comprehensive lecture about several alternative ways to identify and manage Technical Debt. We monitored the teams, performed interviews, did close observations and collected feedback. The results show that the awareness of Technical Debt influences team behavior. Team members report thinking and discussing more about software quality after becoming aware of Technical Debt in their projects.

While the effects of mindfulness are increasingly explored across different fields, little is known about the application of these practices in agile project teams. In this paper we report on a rigorous controlled trial executed to understand the impact of the three minute breathing exercise on the perceived effectiveness of stand-up meetings. We compare (1) an active group using a three minute breathing exercise, to (2) a placebo, and (3) a control group in 3 organizations and 8 teams with over 152 measurements. Our findings indicate an immediate positive impact on perceived effectiveness, decision-making and improved listening in the active groups compared to the placebo and natural history groups. We provide a preliminary agenda for future research based on our findings and previous evidence from other fields.

Agile software development has become mainstream, and with it many tools have been developed to support Agile software development. Nonetheless, studies show, that most Agile software teams still also use physical cardboards for their daily work. This is error prone and causes a lot of extra effort to keep both in sync. In our research project we conducted an interview study about the reasons for this media break. Based on the findings we developed visualization and interaction concepts for an Agile cardwall using an extra-large multi-touch wall display which provides Agile teams the lightweight collaboration workspace for their Agile meetings. We implemented the concepts in the software prototype , and evaluated the usability of aWall in a user study. The evaluation indicates that aWall enables and encourages team work due to the large size of the wall, the easy accessibility and visibility of the needed information, and the integration with existing issue tracking tools. This suggests that augmenting digital cardwalls with large interactive touch technology and integration with task tracking systems is a useful way to support effective collaborative Agile software development processes.

Knowledge is a core resource for agile organisations that is transformed into products and services during the development process. Sharing of knowledge is essential across any organisation, and it has been claimed that the software industry requires more knowledge management than any other sector. Agile methodologies concentrate on team level collaboration, and some techniques for inter-team knowledge sharing have also proved to be successful. But these techniques focus on within-team and between-team knowledge sharing rather than knowledge sharing across the organisation. This paper presents the results of a survey with 81 responses on organisational knowledge sharing in a multinational agile company. The survey focuses on three aspects of knowledge sharing: within agile teams, beyond the team with company colleagues, and with customers. It concentrates on knowledge sharing practices, ease of knowledge sharing and motivation for knowledge sharing. Summary statistics, regression, and test of equity are used as analysis techniques. Results show that knowledge sharing with team members is significantly easier than with customers or company colleagues beyond their team. In addition, using agile practices improves ease of knowledge sharing within teams but not with customers or colleagues. Extrinsic motivators need to be in place to encourage knowledge sharing across the organisation, especially where such knowledge sharing is not an automatic consequence of completing the work.

Agile methods are an essential resource for software engineers. The Agile movement evolved out of industry and is the common approach to software development today. Teaching Agile methods challenges students’ working attitudes, where putting Agile into practice is not possible through simply applying methods prescriptively, but by having an Agile mindset. In this paper we present and discuss our experiences over the last decade of teaching a novel intensive Agile methods week long course as part of a professional Masters of Software Engineering degree programme at the University of Oxford. We describe the typical shape of the course, discuss how students experience Agile values and management practices to foster an Agile mindset, and provide student feedback indicating a consistently positive response to our approach at teaching Agile methods to software engineering professionals. Our reported experiences and material can help other educators who want to run similar courses and adapt where required.