Anna Sandberg

Technical dependency challenges in large-scale agile software development

This qualitative study investigates challenges associated with technical dependencies and their communication. Such challenges frequently occur when agile practices are scaled to large-scale software development. The use of thematic analysis on semi-structured interviews revealed five challenges: planning, task prioritization, knowledge sharing, code quality, and integration. More importantly, these challenges interact with one another and can lead to a domino effect or vicious circle. If an organization struggles with one challenge, it is likely that the other challenges become problematic as well. This situation can have a significant impact on process and product quality. Our recommendations focus on improving planning and knowledge sharing (with practices such as scrum-of-scrums, continuous integration, open space technology) to break the vicious circle, and to reestablish effective communication across teams, which will then enable large-scale companies to achieve the benefits of large-scale agility.

How a Professionally Qualified Doctoral Student Bridged the Practice-Research Gap: A Confessional Account of Collaborative Practice Research

Information Systems (IS) is a profession-based discipline that constantly seeks new ways to bridge the practice-research gap. These efforts include enacting scholar-practitioner roles across institutional boundaries, developing and disseminating new knowledge, and engaging professionally qualified doctoral students. Against this backdrop, we provide a confessional account of 10 years of Collaborative Practice Research (CPR) between Anna, an IS practitioner, and Lars, an IS researcher. The collaboration was initiated when Anna, while working full-time, engaged as doctoral student with Lars as supervisor. Combining social process modeling with theories of change and learning, we show how Anna and Lars responded to the experienced challenges and opportunities, how Annas action strategies developed as she grew into becoming a practitioner-researcher, how the collaboration impacted the practice context, and, how the research resulted in traditional publication outcomes. On the basis of these analyses, we discuss how to engage professionally qualified doctoral students within the IS discipline. In addition, we offer lessons on how CPR can help bridge the practice-research gap as a path towards becoming a practitioner-researcher.

Scale and Responsiveness in Large-Scale Software Development

In large-scale software development, there is typically a conflict between being responsive to individual customers, while at the same time achieving scale in terms of delivering a high number of features to a large customer base. Most often, organizations focus on scale and individual customer requests are viewed as problematic since they add complexity to product variation and version control. Here, we explore the use of customer-specific teams as a means to address this conflict. First, we verify the use of customer-specific teams as successful for improving customer responsiveness, customer satisfaction and feature quality through a case study at Ericsson. Second, we identify three approaches for how to organize feature development, and recommendations on how software development companies can efficiently use these to improve their practices. Third, we observe new business opportunities that arise when using customer-specific teams.

Meeting industry: academia research collaboration challenges with agile methodologies

Continuous and long-term collaboration between industry and academia is crucial to develop front-line research in context-dependent areas like software development where both practitioners and researchers are searched for data collection, analysis and results. Despite many mutual benefits, this collaboration is often challenging, not only due to different goals, but also because of different pace in providing the results. The software development industry has during the last decade aligned around and organized their development adopting agile methodologies. For the researchers, the agile methodologies are a topic for a research, rather than a means of performing the research itself. We can state a question, whether the agile methodologies can be a good common ground for enabling successful research collaboration between industry and academia? This paper reports on a longitudinal industry - academia research collaboration case, which has stepwise adapted SCRUM over a six-year period. The implementation of SCRUM and the collaboration successes and challenges are presented, and findings are discussed.

Managing Slowdown in Improvement Projects

Process improvement projects depend on the active participation of managers and senior engineers. At the telecom company Ericsson, change agents were frustrated that requests to participate in improvement projects often precipitated behavior from colleagues that hampered progress. However, rather than accepting slowdowns, the change agents started to ask why managers and senior engineers reacted this way even though Ericsson is highly committed to process improvement. In this article, we show how to analyze slowdown behavior, increase commitment and reinforce progress.

Evaluating code complexity triggers, use of complexity measures and the influence of code complexity on maintenance time

Code complexity has been studied intensively over the past decades because it is a quintessential characterizer of code’s internal quality. Previously, much emphasis has been put on creating code complexity measures and applying these measures in practical contexts. To date, most measures are created based on theoretical frameworks, which determine the expected properties that a code complexity measure should fulfil. Fulfilling the necessary properties, however, does not guarantee that the measure characterizes the code complexity that is experienced by software engineers. Subsequently, code complexity measures often turn out to provide rather superficial insights into code complexity. This paper supports the discipline of code complexity measurement by providing empirical insights into the code characteristics that trigger complexity, the use of code complexity measures in industry, and the influence of code complexity on maintenance time. Results of an online survey, conducted in seven companies and two universities with a total of 100 respondents, show that among several code characteristics, two substantially increase code complexity, which subsequently have a major influence on the maintenance time of code. Notably, existing code complexity measures are poorly used in industry.

Scaling up the Planning Game: Collaboration Challenges in Large Scale Agile Product Development

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.

Validating software measures using action research a method and industrial experiences

Validating software measures for using them in practice is a challenging task. Usually more than one complementary validation methods are applied for rigorously validating software measures: Theoretical methods help with defining the measures with expected properties and empirical methods help with evaluating the predictive power of measures. Despite the variety of these methods there still remain cases when the validation of measures is difficult. Particularly when the response variables of interest are not accurately measurable and the practical context cannot be reduced to an experimental setup the abovementioned methods are not effective. In this paper we present a complementary empirical method for validating measures. The method relies on action research principles and is meant to be used in combination with theoretical validation methods. The industrial experiences documented in this paper show that in many practical cases the method is effective.

Prioritizing Architectural Concerns

Efficient architecture work involves balancing the degree of architectural documentation with attention to needs, costs, agility and other factors. This paper presents a method for prioritizing architectural concerns in the presence of heterogeneous stakeholder groups in large organizations that need to evolve existing architecture. The method involves enquiry, analysis, and deliberation using collaborative and analytical techniques. Method outcomes are action principles directed to managers and improvement advice directed to architects along with evidence for recommendations made. The method results from 3 years of action research at Ericsson AB with the purpose of adding missing views to architectural documentation and removing superfluous ones. It is illustrated on a case where 29 senior engineers and managers within Ericsson prioritized 37 architectural concerns areas to arrive at 8 action principles, 5 prioritized improvement areas, and 24 improvement suggestions. Feedback from the organization is that the method has been effective in prioritizing architectural concerns, that data collection and analysis is more extensive compared to traditional prioritization practices, but that extensive analysis seems inevitable in architecture improvement work.

A Complexity Measure for Textual Requirements

Unequivocally understandable requirements are vital for software design process. However, in practice it is hard to achieve the desired level of understandability, because in large software products a substantial amount of requirements tend to have ambiguous or complex descriptions. Over time such requirements decelerate the development speed and increase the risk of late design modifications, therefore finding and improving them is an urgent task for software designers. Manual reviewing is one way of addressing the problem, but it is effort-intensive and critically slow for large products. Another way is using measurement, in which case one needs to design effective measures. In recent years there have been great endeavors in creating and validating measures for requirements understandability: most of the measures focused on ambiguous patterns. While ambiguity is one property that has major effect on understandability, there is also another important property, complexity, which also has major effect on understandability, but is relatively less investigated. In this paper we define a complexity measure for textual requirements through an action research project in a large software development organization. We also present its evaluation results in three large companies. The evaluation shows that there is a significant correlation between the measurement values and the manual assessment values of practitioners. We recommend this measure to be used with earlier created ambiguity measures as means for automated identification of complex specifications.