Operational release planning in large-scale Scrum with multiple stakeholders – A longitudinal case study at F-Secure Corporation

ContextThe analysis and selection of requirements are important parts of any release planning process. Previous studies on release planning have focused on plan-driven optimization models. Unfortunately, solving the release planning problem mechanistically is difficult in an agile development context.ObjectiveWe describe how a release planning method was employed in two case projects in F-Secure, a large Finnish software company. We identify the benefits which the projects gained from the method, and analyze challenges in the cases and improvements made to the method during the case projects.MethodWe observed five release planning events and four retrospectives and we conducted surveys in the first two events. We conducted six post-project interviews. We conjoined the observation notes, survey results and interviews and analyzed them qualitatively and quantitatively.ResultsThe focal point of the method was release planning events where the whole project organization gathered to plan the next release. The planning was conducted by the development teams in close collaboration with each other and with the other stakeholders. We identified ten benefits which included improved communication, transparency, dependency management and decision making. We identified nine challenges which included the lacking preparation and prioritization of requirements, unrealistic schedules, insufficient architectural planning and lacking agile mindset. The biggest improvements to the method were the introduction of frequent status checks and a big visible planning status board.ConclusionThe release planning method ameliorated many difficult characteristics of the release planning problem but its efficiency was negatively affected by the performing organization that was in transition from a plan-driven to an agile development mindset. Even in this case the benefits clearly outweighed the challenges and the method enabled the early identification of the issues in the project.     

Large-scale agile transformation at Ericsson: a case study

Many large organizations are adopting agile software development as part of their continuous push towards higher flexibility and shorter lead times, yet few reports on large-scale agile transformations are available in the literature. In this paper we report how Ericsson introduced agile in a new R&D product development program developing a XaaS platform and a related set of services, while simultaneously scaling it up aggressively. The overarching goal for the R&D organization, distributed to five sites at two continents, was to achieve continuous feature delivery. This single case study is based on 45 semi-structured interviews during visits at four sites, and five observation sessions at three sites. We describe how the organization experimented with different set-ups for their tens of agile teams aiming for rapid end-to-end development: from component-based virtual teams to totally cross-functional, cross-component, cross-site teams. Moreover, we discuss the challenges the organization faced and how they mitigated them on their journey towards continuous and rapid software engineering. We present four lessons learned for large-scale agile transformations: 1) consider using an experimental approach to transformation, 2) consider implementing the transformation step-wise in complex large-scale settings, 3) team inter-changeability can be limited in a complex large-scale product — specialization might be needed, and 4) not using a common agile framework for the whole organization, in combination with insufficient common trainings and coaching may lead to a lack of common direction in the agile implementation. Further in-depth case studies on large-scale agile transformations, on customizing agile to large-scale settings, as well as on the use of scaling frameworks are needed.     

Estimeetings: development estimates and a front-end process for alarge project

A method for estimating software development effort in the early phases of a large software-intensive project and a front-end process incorporating this method are presented. The application of this methodology to the domestic US 5ESS Switch project (a large multiyear continuing effort, with new features incorporated into yearly releases) is described. For each feature to be estimated, a feature team generates a detailed feature definition with high-level functionality requirements and a high-level design proposal. These are used in a formal working meeting of estimators from affected parts of the project. The meeting produces a development estimate for use in deciding which features to include in the next release. The benefits of this methodology include well-defined milestones (high-level features requirements, high-level designs and estimates), and less tangible benefits like better working relationships between parts of the project, interorganizational synergy and increased confidence in the front-end process     

Combining agile methods with stage-gate project management

We encountered cultural changes and different management and engineering viewpoints in a study of three large software development organizations that started using agile methods. Case studies at three large software product companies show the benefits and pitfalls of integrating agile methods with stage-gate management models.     

The impact of agile practices on communication in software development

Agile software development practices such as eXtreme Programming (XP) and SCRUM have increasingly been adopted to respond to the challenges of volatile business environments, where the markets and technologies evolve rapidly and present the unexpected. In spite of the encouraging results so far, little is known about how agile practices affect communication. This article presents the results from a study which examined the impact of XP and SCRUM practices on communication within software development teams and within the focal organization. The research was carried out as a case study in F-Secure where two agile software development projects were compared from the communication perspective. The goal of the study is to increase the understanding of communication in the context of agile software development: internally among the developers and project leaders and in the interface between the development team and stakeholders (i.e. customers, testers, other development teams). The study shows that agile practices improve both informal and formal communication. However, it further indicates that, in larger development situations involving multiple external stakeholders, a mismatch of adequate communication mechanisms can sometimes even hinder the communication. The study highlights the fact that hurdles and improvements in the communication process can both affect the feature requirements and task subtask dependencies as described in coordination theory. While the use of SCRUM and some XP practices facilitate team and organizational communication of the dependencies between product features and working tasks, the use of agile practices requires that the team and organization use also additional plan-driven practices to ensure the efficiency of external communication between all the actors of software development.

On using planning poker for estimating user stories

While most studies in psychology and forecasting stress the possible hazards of group processes when predicting effort and schedule, agile software development methods recommend the use of a group estimation technique called planning poker for estimating the size of user stories and developing release and iteration plans. It is assumed that the group discussion through planning poker helps in identifying activities that individual estimators could overlook, thus providing more accurate estimates and reducing the over-optimism that is typical for expert judgment-based methods. In spite of the widespread use of agile methods, there is little empirical evidence regarding the accuracy of planning poker estimates. In order to fill this gap a study was conducted requiring 13 student teams to develop a Web-based student records information system. All teams were given the same set of user stories which had to be implemented in three Sprints. Each team estimated the stories using planning poker and the estimates provided by each team member during the first round were averaged to obtain the statistical combination for further comparison. In the same way the stories were estimated by a group of experts. The study revealed that students’ estimates were over-optimistic and that planning poker additionally increased the over-optimism. On the other hand, the experts’ estimates obtained through planning poker were much closer to actual effort spent and tended to be more accurate than the statistical combination of their individual estimates. The results indicate that the optimism bias caused by group discussion diminishes or even disappears as the expertise of the people involved in the group estimation process increases.     

A disciplined approach to adopting agile practices: the agile adoption framework

Many organizations aspire to adopt agile processes to take advantage of the numerous benefits that they offer to an organization. Those benefits include, but are not limited to, quicker return on investment, better software quality, and higher customer satisfaction. To date, however, there is no structured process (at least that is published in the public domain) that guides organizations in adopting agile practices. To address this situation, we present the agile adoption framework and the innovative approach we have used to implement it. The framework consists of two components: an agile measurement index, and a four-stage process, that together guide and assist the agile adoption efforts of organizations. More specifically, the Sidky Agile Measurement Index (SAMI) encompasses five agile levels that are used to identify the agile potential of projects and organizations. The four-stage process, on the other hand, helps determine (a) whether or not organizations are ready for agile adoption, and (b) guided by their potential, what set of agile practices can and should be introduced. To help substantiate the “goodness” of the Agile Adoption Framework, we presented it to various members of the agile community, and elicited responses through questionnaires. The results of that substantiation effort are encouraging, and are also presented in this paper.     

Interpretative case studies on agile team productivity and management

ContextThe management of software development productivity is a key issue in software organizations, where the major drivers are lower cost and shorter time-to-market. Agile methods, including Extreme Programming and Scrum, have evolved as “light” approaches that simplify the software development process, potentially leading to increased team productivity. However, little empirical research has examined which factors do have an impact on productivity and in what way, when using agile methods.ObjectiveOur objective is to provide a better understanding of the factors and mediators that impact agile team productivity.MethodWe have conducted a multiple-case study for 6 months in three large Brazilian companies that have been using agile methods for over 2 years. We have focused on the main productivity factors perceived by team members through interviews, documentation from retrospectives, and non-participant observation.ResultsWe developed a novel conceptual framework, using thematic analysis to understand the possible mechanisms behind such productivity factors. Agile team management was found to be the most influential factor in achieving agile team productivity. At the intra-team level, the main productivity factors were team design (structure and work allocation) and member turnover. At the inter-team level, the main productivity factors were how well teams could be effectively coordinated by proper interfaces and other dependencies and avoiding delays in providing promised software to dependent teams.ConclusionTeams should be aware of the influence and magnitude of turnover, which has been shown negative for agile team productivity. Team design choices remain an important factor impacting team productivity, even more pronounced on agile teams that rely on teamwork and people factors. The intra-team coordination processes must be adjusted to enable productive work by considering priorities and pace between teams. Finally, the revised conceptual framework for agile team productivity supports further tests through confirmatory studies.     

When agile meets the enterprise

ContextWhile renowned agile methods like XP and Scrum were initially intended for projects with small teams, traditional enterprise environments, i.e. environments where plan-driven development is prevalent, have also become attracted by the promises of a faster time to market through agility. Agile software development methods emphasize lightweight software development. Projects within enterprise environments, however, are typically confronted with a large and complex IT landscape, where mission-critical information is at play whose criticality requires prudence regarding design and development. In many an organization, both approaches are used simultaneously.ObjectiveFind out which challenges the co-existence of agile methods and plan-driven development brings, and how organizations deal with those challenges.MethodWe present a grounded theory of the challenges of using agile methods in traditional enterprise environments, based on a Grounded Theory research involving 21 agile practitioners from two large enterprise organizations in the Netherlands.ResultsWe organized the challenges under two factors: Increased landscape complexity and Lack of business involvement. For both factors, we identify successful mitigation strategies. These mitigation strategies concern the communication between the agile and traditional part of the organization, and the timing of that communication.ConclusionAgile practices can coexist with plan-driven development. One should, however, keep in mind the context and take actions to mitigate the challenges incurred.     

Enabling agile adoption practices through network organizations

As distributed organizations increasingly rely on technological innovations to enhance organizational efficiency and competitiveness, interest in agile practices that enable adoption of information technology (IT) based innovations has grown. This study examines the influence of a network organization environment on the ability to develop agile adoption practices. An exploratory case study design was used to investigate the interactions between network structure, social information processing, organizational similarity (homophily), and absorptive capacity during the adoption of a large-scale IT system in two network organization environments within New York State. The data suggest that network organization characteristics and communication processes that reinforced social influence and supported knowledge transfer positively influenced adoption agility. We propose a model of agile adoption practices and discuss implications for the development of theory about network organization characteristics and capabilities to adopt IT-based innovations.     

Role of situational method engineering to improve visual information systems in agile distributed environment

Software product prone to continuous evolution due to increase in the use of technology. Therefore, more stakeholders are involved in software evolution increases the cost and complexity. This required optimization of resources and cost to handle evolution with Global Software Development (GSD) to utilize time zones efficiently. The significance challenge of GSD reports: time zone difference, geographical location, communication delays, knowledge sharing, control among stakeholders and development team. Because of these challenges, the requirements for development in GSD environment are also challenge as compared to on site development. Different requirement engineering methods have been used to improve the requirements analysis to deal with ambiguities and inconsistency in large set of requirements. The customization and tailoring of requirements according to changing project’s situations required to improve project development with reusing existing agile methods during requirement engineering phase. Moreover, complex information systems where heterogeneity is inevitable that implies the involvement of divergent stakeholders and necessitate a comprehensive framework to capture multidimensional viewpoints and fulfill aforementioned issues. Therefore, a situational multi-dimensional agile requirement engineering method has been proposed to support team and stakeholders’ viewpoints. The schema of the proposed method is based on challenges recognized by performing Literature Review. Then proposed method has been evaluated via experimental approach and statistical analysis conducted to validated reliability of data collected. This result is significant approved both practically and statistically that the proposed approach ease to use, implement, trained and increased productivity and performance. Hence, the experimental study for the evaluation of the proposed approach results concluded that, proposed approach is the important multimedia tool for supporting organization and distributed development team for information sharing, collaboration, product development.

     

Managing software projects with business-based requirements

For many organizations that are neither software product companies nor system integrators, the expense and cultural change required for full process rollout can be prohibitive. Proponents of agile processes/methods (such as extreme programming) suggest that these "lightweight" approaches are extremely effective. I would agree that there are many powerful aspects within these approaches. I suggest, however, that by taking an objective-based business requirements approach to project management, software projects have a high probability of running on time, and remaining in scope and within budget. Addressing requirement challenges, independent of adopting a full process, can offer many of the benefits of full process adoption while avoiding most of the expense and human issues involved with full process rollout. A business-based requirements approach is an easy-to-adopt, risk-free entry point that offers tangible quality improvements. This approach suits any project scope. Whether building a complex system for enterprise resource planning or customer relationship management, or developing small, single-user software programs, defining business requirements improves any system delivery.     

Blending Scrum practices and CMMI project management process areas

Software development organizations that have been employing capability maturity models, such as SW-CMM or CMMI for improving their processes are now increasingly interested in the possibility of adopting agile development methods. In the context of project management, what can we say about Scrum’s alignment with CMMI? The aim of our paper is to present the mapping between CMMI and the agile method Scrum, showing major gaps between them and identifying how organizations are adopting complementary practices in their projects to make these two approaches more compliant. This is useful for organizations that have a plan-driven process based on the CMMI model and are planning to improve the agility of processes or to help organizations to define a new project management framework based on both CMMI and Scrum practices.     

Introducing an agile process to an organization [software development]

The transition from a plan-driven to an agile software development process affects not only the development team members, but also other teams, departments, and management. Any new process will likely attract developers excited to try it while repelling those opposed to change. Thus, how an agile process is introduced into an organization significantly affects its ultimate success.     

An Empirical Study of the Complex Relationships between Requirements Engineering Processes and Other Processes that Lead to Payoffs in Productivity, Quality, and Risk Management

Requirements engineering is an important component of effective software engineering, yet more research is needed to demonstrate the benefits to development organizations. While the existing literature suggests that effective requirements engineering can lead to improved productivity, quality, and risk management, there is little evidence to support this. We present empirical evidence showing how requirements engineering practice relates to these claims. This evidence was collected over the course of a 30-month case study of a large software development project undergoing requirements process improvement. Our findings add to the scarce evidence on RE payoffs and, more importantly, represent an in-depth explanation of the role of requirements engineering processes in contributing to these benefits. In particular, the results of our case study show that an effective requirements process at the beginning of the project had positive outcomes throughout the project lifecycle, improving the efficacy of other project processes, ultimately leading to improvements in project negotiation, project planning, and managing feature creep, testing, defects, rework, and product quality. Finally, we consider the role collaboration had in producing the effects we observed and the implications of this work to both research and practice.     

Agile software testing in a large-scale project

Agile software development in general and Extreme Programming (XP) in particular, promote radical changes in how software development organizations traditionally work. We present and analyze new data from a real, large-scale agile project to develop a business-critical enterprise information system for the Israeli Air Force (IAF). Our results offer new evidence that agile testing practices actually work, dramatically improving development quality and productivity. We describe the organization's successful practices and guidelines in four key areas: test design and activity execution, working with professional testers, planning, and defect management.     

Agile methods rapidly replacing traditional methods at Nokia: A survey of opinions on agile transformation

Context

Many organizations have started to deploy agile methods, but so far there exist only a few studies on organization-wide transformations. Are agile methods here to stay? Some claim that agile software development methods are in the mainstream adoption phase in the software industry, while others hope that those are a passing fad. The assumption here is that if agile would not provide real improvement, adopters would be eager at first but turn pessimistic after putting it into practice.

Objective

Despite the growing amount of anecdotal evidence on the success of agile methods across a wide range of different real-life development settings, scientific studies remain scarce. Even less is known about the perception of the impacts of agile transformation when it is deployed in a very large software development environment, and whether agile methods are here to stay. This study aims to fill that gap by providing evidence from a large-scale agile transformation within Nokia. While we have yet to confirm these findings with solid quantitative data, we believe that the perception of the impacts already pinpoints the direction of the impacts of large-scale agile transformation.

Method

The data were collected using a questionnaire. The population of the study contains more than 1000 respondents in seven different countries in Europe, North America, and Asia.

Results

The results reveal that most respondents agree on all accounts with the generally claimed benefits of agile methods. These benefits include higher satisfaction, a feeling of effectiveness, increased quality and transparency, increased autonomy and happiness, and earlier detection of defects. Finally, 60% of respondents would not like to return to the old way of working.

Conclusion

While the perception of the impact of agile methods is predominantly positive, several challenge areas were discovered. However, based on this study, agile methods are here to stay.     

Evaluating the impact of an agile transformation: a longitudinal case study in a distributed context

Many software-development organizations have recently started to adopt agile practices in order to benefit from the improvements they clearly bring, in terms of production speed and software quality, for example. However, in a large, distributed organization, such as Nokia Siemens Networks, an agile transformation may be a long-term, complex process, and therefore, evaluating the benefits achieved, and measuring the success of the change, can be difficult, especially in the early phases of the transformation. This paper is based on the results of a case study on the impact introducing agile practices actually had in a large, software-development organization, part of Nokia Siemens Networks. The impact of this agile transformation was evaluated in terms of how well it succeeded in achieving the goals set by the management before the transformation started. This longitudinal study included two separate analyses, made at 6 monthly intervals, which measured what agile practices were really in use in the organization, and what effects, if any, were visible in terms of the goals which had been set by the management The 6 monthly analyses included defect data metrics and opinion surveys of the personnel directly involved in the transformation. The study showed two things: firstly, that the introduction of agile practices does have the beneficial effects that one would expect, and secondly, that, using this kind of study, it is not only possible to evaluate the impact that the adoption of agile practices has in a large, established software-development company, but also that the effects are visible at a surprisingly early stage.     

Successful extreme programming: Fidelity to the methodology or good teamworking?

ContextDeveloping a theory of agile technology, in combination with empirical work, must include assessing its performance effects, and whether all or some of its key ingredients account for any performance advantage over traditional methods. Given the focus on teamwork, is the agile technology what really matters, or do general team factors, such as cohesion, primarily account for a team’s success? Perhaps the more specific software engineering team factors, for example the agile development method’s collective ownership and code management, are decisive.ObjectiveTo assess the contribution of agile methodology, agile-specific team methods, and general team factors in the performance of software teams.MethodWe studied 40 small-scale software development teams which used Extreme Programming (XP). We measured (1) the teams’ adherence to XP methods, (2) their use of XP-specific team practices, and (3) standard team attributes, as well as the quality of the project’s outcomes. We used Williams et al.’s (2004a) [33] Shodan measures of XP methods, and regression analysis.ResultsAll three types of variables are associated with the project’s performance. Teamworking is important but it is the XP-specific team factor (continuous integration, coding standards, and collective code ownership) that is significant. Only customer planning (release planning/planning game, customer access, short releases, and stand-up meeting) is positively related to performance. A negative relationship between foundations (automated unit tests, customer acceptance tests, test-first design, pair programming, and refactoring) is found and is moderated by craftsmanship (sustainable pace, simple design, and metaphor/system of names). Of the general team factors only cooperation is related to performance. Cooperation mediates the relationship between the XP-specific team factor and performance.ConclusionClient and team foci of the XP method are its critical active ingredients.     

Agile software development in large organizations

The need to see compelling evidence before adopting new methods looms greater in large organizations because of their complexity and the need to integrate new technologies and processes with existing ones. To further evaluate agile methods and their underlying software development practices, several Software Experience Center (SEC) member companies initiated a series of activities to discover if agile practices match their organizations' needs. Although each organization evaluated agile methods according to its specific needs, here we attempt to generalize their findings by analyzing some of their common experiences in the particular context of large organizations with well-established structures and processes. We base this analysis on experience collected and shared among four SEC members namely ABB, DaimlerChrysler, Motorola, and Nokia.