Search

The nine papers in this special section focus on new developments in agile software and reports on applications for its use. A key aspect for the extensive use of agile software is that it supports developers with coping with the growing uncertainty and turbulence in technological and market environments. Feedback and change are at the core of Agile for a dynamic, evolving, and organic, rather than static, predefined, and mechanistic development process advocated by waterfall management. To create timely, high-quality, cost-efficient, and innovative solutions, Agile developers organized in small, colocated, autonomous teams, build and test software in rapid iterative cycles, actively involving users to gather feedback, updating the project scope, and plan "on-the-fly," using face-to-face communication as opposed to documentation. These papers contribute to the state-of-the-art of agile research by offering a rich, up-todate account of the dynamics occurring when expanding Agile into "not-just-software" contexts of the key challenges and perils related to the scaling and of the possible solutions to them. [ABSTRACT FROM AUTHOR]

Contribution: This article presents agile software engineers stick together (ASEST+), an improved version of a framework called ASEST that aims to develop team cohesion, leading to better team learning and software engineering student teams. Background: Effective teamwork is crucial for agile software development’s success and is, therefore, a key topic of current software engineering education. In the previous work, a preliminary proposal for ASEST+ was presented. Here, an improved version, more suitable for agile practice education and considering cohesion antecedents, is described. Intended Outcome: A teaching-learning framework to support teamwork in agile software education. Application Design: ASEST+ is built around Scrum teams and combines learning strategies to train students in collaborative and technical agile practices. ASEST+ establishes policies for role allocation and team rule agreements to regulate communication and address conflict management agile practices. ASEST+ addresses personality traits, conflict resolution, and task interdependence as the antecedents identified as the most important. Findings: A quasiexperiment showed that the use of ASEST+ significantly increases the students’ positive perceptions on team cohesion, team performance, and team learning compared with the control group. [ABSTRACT FROM AUTHOR]

Context: Agile software development has become commonplace in software development companies due to the numerous benefits it provides. However, conducting Agile projects is demanding in Small and Medium Enterprises (SMEs), because projects start and end quickly, but still have to fulfil customers' quality requirements. Objective: This paper aims at reporting a practical experience on the use of metrics related to the software development process as a means supporting SMEs in the development of software following an Agile methodology. Method: We followed Action-Research principles in a Polish small-size software development company. We developed and executed a study protocol suited to the needs of the company, using a pilot case. Results: A catalogue of Agile development process metrics practically validated in the context of a small-size software development company, adopted by the company in their Agile projects. Conclusions: Practitioners may adopt these metrics in their Agile projects, especially if working in an SME, and customise them to their own needs and tools. Academics may use the findings as a baseline for new research work, including new empirical studies.

Distributed agile software development is a promising paradigm, addressing the necessities of emergent software application markets that are described by huge user base and small time to market characteristics. A key decision involved during the development process, is task allocation to team members. An appropriate task-member assignment facilitates project management, lessens the complexities and influences chances of project success. Task allocation becomes a more challenging activity in a distributed agile software development due to insufficient understanding of different factors and dependencies involved. We propose a task allocation framework comprising of two phases: one, identifying factors and dependencies that strongly influence the task allocation decision; two, proposing a quantitative method that allocates tasks to team members who best match the task requirements. Task requirements are expressed as capabilities, catering for different aspects, such as technical, personal, and environment. Our method stays transparent to the targeted objectives, in this case the best match. Other objectives, such as quality and cost may be introduced conveniently; even multiple objectives can be addressed. Such a method also allows quality evaluation of task-member assignment during and after the project completion, toward minimizing related risks.

End-to-end network slicing is a novel concept based on virtualization and softwarization technology that can efficiently address the problems of legacy networks. It can leverage agile physical and network layer adaptability, and foster optimal user and system performance. These features make end-to-end network slicing suitable for scenarios such as flash crowds and emergency situations. This article presents an end-to-end network slicing framework capable of addressing the demands of flash crowd and emergency scenarios. The article provides details about these scenarios, and it introduces an end-to-end agile, flexible, and scalable wireless system architecture consisting of softwarized components that can be orchestrated to fulfill the underlying system requirements. By addressing important key performance indicators with experimental measurements, the article demonstrates the applicability of our slicing framework for flash crowd scenarios. [ABSTRACT FROM AUTHOR]

Background: Although agile and Scrum have been important frameworks in software engineering for over a decade, little research has explored how teams use Scrum language within their sprints. Literature review: Most explorations of Scrum communication have been collected through self-reported means. These studies are inherently unable to explore how Scrum teams use Scrum-centric language in their meetings in ways that adhere or run counter to standard Scrum practice. Research questions: 1. In what ways is Scrum reflected in the language used by team members in various sprint meetings? 2. What associations exist between the job title of team members and their use of Scrum language? 3. What does a discourse analysis reveal about the ways in which this team uses language to value and discount Scrum? Research methodology: For three sprints over 10 weeks, I recorded meetings of 27 Scrum team members. I transcribed these meetings, developed a codebook for assigning Scrum language categories, conducted an interrater reliability agreement on the data, completed a correspondence analysis on how Scrum language associates with meeting types and job titles, and conducted a discourse analysis to determine in what ways these teams value and discount Scrum. Results/discussion: Scrum language was found in all recorded meetings across all three sprints, with much language found in the planning meetings. Few associations existed between Scrum language and job title, suggesting that Scrum at this engineering firm is an egalitarian process. In addition, the discourse analysis revealed that this engineering firm valued User Story and Sprint Execution language while discounting Capacity and Story Pointing language. Conclusions: Although this group broadly adheres to Scrum practices about 68% of the time, this study finds that several current standard components of Scrum are routinely discounted. This exploratory study suggests that more research into the in-situ use of Scrum language in engineering workplaces is necessary to better inform engineering professionals about the communicative expectations of Scrum and to better enable engineering communication educators to prepare future engineers for Scrum realities. [ABSTRACT FROM AUTHOR]

Nowadays, considerable attention is paid to agile methods as a means to improve management of software development processes. The widespread use of such methods in professional contexts has encouraged their integration into software engineering training and undergraduate courses. Although several research efforts have focused on teaching Scrum through simulating a software development project, they covered only the learning of programming practices within a Scrum team. Furthermore, few studies tackle nontechnical skills other than the development practices themselves. The work presented here introduces an original Scrum-based training model enhanced with agile coaching to maximize student performance. This was validated by a case study on a capstone project in a Scrum course. This paper summarizes the positive results of introducing agile coaching, which resulted in approximately 22% more coverage of software engineering practices. In addition, a survey data showed that, compared to students who did not receive coaching, coached students gained valuable insight into the internalization of Scrum, problem solving, and guidance by means of checkpoint meetings. [ABSTRACT FROM PUBLISHER]

Although traceability information is vital to many software engineering activities, agile development approaches rarely use it because of the extra effort required. In this industry case study, the authors report the results of applying their lightweight semiautomated method that integrates traceability into software architecture developed with an agile process like Scrum. [ABSTRACT FROM PUBLISHER]

Recent events in the US defense community hold the promise of a major boost in the use of agile software development methods and a concomitant improvement in the effectiveness of defense software procurement and development. [ABSTRACT FROM AUTHOR]

The capacity to reflect on past practice is important for continuous learning in software development. Reflection often takes place in cycles of experience followed by conscious application of learning from that experience, during which a software developer might explore comparisons, ponder alternatives, take diverse perspectives, and draw inferences, especially in new and/or complex situations. Such reflective practice has been shown in different disciplines to be an effective developmental practice for organizations, for teams, and for individuals. The guest editors of this special issue on reflection describe the concept in general and the selected articles in particular. [ABSTRACT FROM PUBLISHER]

The theoretical underpinnings of agile principles emphasize regular reflection as a means to attain a sustainable development pace and continuous learning. In practice, high iteration pressure can diminish opportunities for ongoing learning and reflection threatening to deprive software teams of learning and reflection and possibly stagnating process evolution. The Reflective Agile Learning Model (REALM) combines insights and results from studies of agile development practices in India, New Zealand, and the US with Schön's theory of reflective practice. Using REALM, agile teams can establish self-organized learning as well as regular process maintenance and opportunities for process evolution to continuously improve practice. [ABSTRACT FROM PUBLISHER]

Self-organizing teams have been recognized and studied in various forms—as autonomous groups in socio-technical systems, enablers of organizational theories, agents of knowledge management, and as examples of complex-adaptive systems. Over the last decade, self-organizing teams have taken center stage in software engineering when they were incorporated as a hallmark of Agile methods. Despite the long and rich history of self-organizing teams and their recent popularity with Agile methods, there has been little research on the topic within software wngineering. Particularly, there is a dearth of research on how Agile teams organize themselves in practice. Through a Grounded Theory research involving 58 Agile practitioners from 23 software organizations in New Zealand and India over a period of four years, we identified informal, implicit, transient, and spontaneous roles that make Agile teams self-organizing. These roles—Mentor, Coordinator, Translator, Champion, Promoter, and Terminator—are focused toward providing initial guidance and encouraging continued adherence to Agile methods, effectively managing customer expectations and coordinating customer collaboration, securing and sustaining senior management support, and identifying and removing team members threatening the self-organizing ability of the team. Understanding these roles will help software development teams and their managers better comprehend and execute their roles and responsibilities as a self-organizing team. [ABSTRACT FROM PUBLISHER]

Several approaches that could be implemented on any platform via any methodology would greatly increase the odds of the successful deployment of a working information system. [ABSTRACT FROM PUBLISHER]

Proponents of various processes and methods in the agile and lean communities have made many bold claims about usefulness, but those claims are rarely supported by empirical investigations. Data gathered from more than 12,000 work items collected over two years sheds light on Kanban versus Scrum.To acquire more knowledge about the performance of different agile or lean methods, scholars should conduct similar studies in different organizations in different application domains and with people of different cultures and competences. [ABSTRACT FROM PUBLISHER]

In this paper, an undergraduate capstone course in software engineering is described that not only exposes students to agile software development, but also makes it possible to observe the behavior of developers using Scrum for the first time. The course requires students to work as Scrum Teams, responsible for the implementation of a set of user stories defined by a project domain expert playing the role of the Product Owner. During the course, data on project management activities are collected in order to analyze the amount of work completed, compliance with the release and iteration plans, productivity, ability in effort estimation, and the like. The paper discusses the achievement of teaching goals and provides empirical evaluation of students' progress in estimation and planning skills. A summary of lessons learned and recommendations is given, reflecting the issues to be considered when teaching courses in agile software development. Surveys of students have shown that they were overwhelmingly positive about the course, indicating that the course fully met or even exceeded their expectations. [ABSTRACT FROM PUBLISHER]

The article presents the author's comment on issues concerning the agile software development. The author argues that the agile software development is showing signs of saturation. He insists that like any other business trends, software engineers must keep the agile software development updated, to overcome its limitations. He also analyzed the outcomings of surveys that he conducted to show the evolution in the agile software development.

Attackers use rootkits and obfuscation techniques to hide while covertly extracting information from commercial applications. The authors describe how developers can use similar obfuscation approaches to build more agile, less vulnerable software. Obfuscation deliberately transforms software into an identically functioning, but purposefully unreadable form, implemented in a high-level programming language at the machine-instruction level, or, to some extent, in the compiled binary. Obfuscation's only requirement is that its generated code be functionally equivalent to its parent. [ABSTRACT FROM PUBLISHER]

Release engineering affects the software we build, how we build it, and how we can make money out of it. It also presents many challenges that will take time to overcome. [ABSTRACT FROM PUBLISHER]

Ambiguity in requirements isn't always a bad thing. In the right hands, it can be positively useful. [ABSTRACT FROM PUBLISHER]

As the last standardization effort was done in 2004, the software engineering curriculum is currently being revised. Haven't we reached the point where agile development should be part of all software engineering curricula? And if so, shouldn't new curriculum standards ensure that it is? [ABSTRACT FROM PUBLISHER]

Leadership is the key for architects to balance all their activities and duties with the interests of different stakeholders without losing control of the architecture under development. They must have a clear vision and strict focus on key aspects of success. All their activities should be goal-driven and in direct cooperation and interaction with the relevant stakeholder groups. [ABSTRACT FROM PUBLISHER]

The development of scientific software has similarities with processes that follow the software engineering "agile manifesto": responsiveness to change and collaboration are of utmost importance. But how well do current scientific software-development processes match the practices found in agile development methods, and what are the effects of using agile practices in such processes? [ABSTRACT FROM PUBLISHER]

Requirements engineering (RE) tools are increasingly used to ease the RE processes and allow for more systematic and formalized handling of requirements, change management and traceability. For developers and companies evaluating the use of RE tools it is thus essential to know which RE processes are supported by tools and how they fit to their own priorities. The answer isn't easy because many sales prospects highlight numerous features—yet leave out to which degree they're supported and whether all features really matter. To gain insight into how current RE tools adapt to RE activities, we ran a 146-item survey based on the features covered by the ISO/IEC TR 24766:2009, a new framework for assessing RE tool capabilities. We received responses from 37 participants, covering all relevant tools. In addition to the tools' score in each activity, we assessed their performance in three concrete use scenarios. Our findings can help practitioners select an RE tool as well as provide areas for improvement for RE tools developers. [ABSTRACT FROM AUTHOR]

Requirements analysts need a new toolbox with both the right tools and the instructions to use them including agile development and user-centered design for techniques such as analysis of Web analytics, wire-framing, and user stories. We can also look to the creativity literature and take techniques such as constraint removal, storytelling, and other worlds. [ABSTRACT FROM AUTHOR]

TomTom worked with the automotive industry to align traditional, risk-eliminating, slow development processes focusing on quality with high-speed, innovative development processes such as those introduced by the smart phone industry. In doing so, TomTom achieved short lead times without compromising on quality by adopting an agile development approach combined with explicit management of specification and schedule buffers. [ABSTRACT FROM AUTHOR]