Management challenges to implementing agile processes in traditional development organizations

Discussions with traditional developers and managers concerning agile software development practices nearly always contain two somewhat contradictory ideas. They find that on small, stand-alone projects, agile practices are less burdensome and more in tune with the software industry's increasing needs for rapid development and coping with continuous change. Managers face several barriers, real and perceived, when they try to bring agile approaches into traditional organizations. They categorized the barriers either as problems only in terms of scope or scale, or as significant general issues needing resolution. From these two categories, we've identified three areas - development process conflicts, business process conflicts, and people conflicts - that we believe are the critical challenges to software managers of large organizations in bringing agile approaches to bear in their projects.     

Adapting funding processes for agile IT projects: an empirical investigation

Agile software development that provides software development organizations, the ability to respond to changes in turbulent business environments, has been gaining wide adoption. Agile software development projects are characterized by ‘just enough’ planning and lack of upfront commitment to scope, cost, and schedule. These characteristics pose conflicting demands on managers responsible for making funding decisions, because traditional approaches to funding IT projects are often based on well-defined scope, cost, and schedule. These conflicts demand the adaptation of traditional funding processes to suit to agile projects. We draw from Adaptive Structuration Theory to understand the nature of conflicts between traditional IT project funding processes and the dynamic nature of agile projects, and how these conflicts are addressed by practices that are appropriated in the process of social interaction between funding decision makers and development teams. On the basis of a multisite case study, we present a framework that explains how organizations adapt traditional IT funding approaches to accommodate the unique characteristics of agile IT projects.     

Synthesizing Agile and Knowledge Discovery: Case Study Results

This research adopts a framework that synthesizes Knowledge Discovery in Database (KDD), Cross Industry Standard Process for Data Mining (CRISP-DM), and agile practices. The application of this framework is demonstrated through an institutional case study of three knowledge discovery projects: Persistence, Retention, and Donor projects. Results from the case study suggest that (a) interaction and iteration are foundations for the success of a knowledge discovery project, especially one with a strong business focus; (b) agile practices facilitate the interaction and iteration nature of a knowledge discovery project; (c) adding business understanding and deployment steps from CRISP-DM to KDD explicitly helps data miners stay focused on the ultimate goals of the project—the needs of the business and the users.     

A dependency taxonomy for agile software development projects

Agile software development is designed to achieve collaborative software development. A supporting pillar of collaboration is effective coordination, which is necessary to manage dependencies in projects. Understanding the dependencies arising in agile software development projects can help practitioners choose appropriate coordinative practices from the large number of practices provided by the various agile methods. To achieve this understanding, this article analyses dependencies in three typical cases of co-located agile software development and presents the dependencies as a taxonomy with decision rules for allocating dependencies into categories. Findings show that knowledge, process, and resource dependencies are present, with knowledge dependencies predominant. In addition, there are agile practices with a coordinative function that address multiple dependencies in these agile software development projects. These practices would be a good choice for coordinating a project and supporting collaboration in agile software projects.     

Coordination in co-located agile software development projects

Agile software development provides a way to organise the complex task of multi-participant software development while accommodating constant project change. Agile software development is well accepted in the practitioner community but there is little understanding of how such projects achieve effective coordination, which is known to be critical in successful software projects. A theoretical model of coordination in the agile software development context is presented based on empirical data from three cases of co-located agile software development. Many practices in these projects act as coordination mechanisms, which together form a coordination strategy. Coordination strategy in this context has three components: synchronisation, structure, and boundary spanning. Coordination effectiveness has two components: implicit and explicit. The theoretical model of coordination in agile software development projects proposes that an agile coordination strategy increases coordination effectiveness. This model has application for practitioners who want to select appropriate practices from agile methods to ensure they achieve coordination coverage in their project. For the field of information systems development, this theory contributes to knowledge of coordination and coordination effectiveness in the context of agile software development.     

No time to waste: the role of timing and complementarity of alignment practices in creating business value in IT projects

Despite significant research progress, alignment-related issues are among the top concerns of executives. Previous studies mostly focus on a company-wide strategic level of alignment; while this ‘top-down’ view has benefits, it largely ignores the operational practices that help achieve alignment in IT projects as well as the impact that timing and complementarity of practices have on achieving alignment. In our research we apply four alignment practices – communication, shared understanding, management commitment and IT investment evaluation – to individual IT projects rather than at a company level; specifically, we look at the role of timing and complementarity for these alignment practices throughout different project phases. A detailed analysis of six IT projects carried out at three companies in the telecommunications industry reveals that IT projects creating higher business value employ all four alignment practices immediately from the start. No project was able to recover from failing to establish these four alignment practices in the first phase. While supporting the importance of complementarity of alignment practices, our findings also add the importance of the earliness of this complementarity.     

Customising agile methods to software practices at Intel Shannon

Tailoring of methods is commonplace in the vast majority of software development projects and organisations. However, there is not much known about the tailoring and engineering of agile methods, or about how these methods can be used to complement each other. This study investigated tailoring of the agile methods, eXtreme programming (XP) and Scrum, at Intel Shannon, and involved experienced software engineers who continuously monitored and reflected on these methods over a 3-year period. The study shows that agile methods may individually be incomplete in supporting the overall development process, but XP and Scrum complement each other well, with XP providing support for technical aspects and Scrum providing support for project planning and tracking. The principles of XP and Scrum were carefully selected (only six of the 12 XP key practices were implemented, for example) and tailored to suit the needs of the development environment at Intel Shannon. Thus, the study refutes the suggestion that agile methods are not divisible or individually selectable but achieve their benefits through the synergistic combination of individual agile practices; rather, this study shows that an a la carte selection and tailoring of practices can work very well. In the case of Scrum, some local tailoring has led to a very committed usage by developers, in contrast to many development methods whose usage is limited despite being decreed mandatory by management. The agile practices that were applied did lead to significant benefits, including reductions in code defect density by a factor of 7. Projects of 6-month and 1-year duration have been delivered ahead of schedule, which bodes well for future ability to accurately plan development projects.     

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.     

Understanding customer relationship management (CRM) adoption in an Arab Middle Eastern context

While the development of customer relationship management (CRM) started in the developed west, it has rapidly spread to developing countries. However, the way organisations adopt CRM in developing countries, and more specifically in the Arab world, might be different and the context certainly differs. There is a shortage of rigorous studies that examine the drivers of CRM adoption in this context. In this study, we examine the antecedents of CRM adoption in the Jordanian service sector. The conceptual framework of this research is tested using a cross-sectional survey of more than 322 practitioners. Using structural equation modelling analysis, results specify six underlying factors that explain CRM adoption: segmentation analysis, clear direction and objectives, performance measurement, rewarding usage, managing project changes, and knowledge management. Each area has implications for improving practices and maximising the benefits of adopting the process or management practice of CRM. This paper identifies key practices to provide useful guidelines for organisations in the Arab world making plans to adopt CRM, with broader implications for the adoption of many systems and projects there and for CRM deployment in developed regions.     

Waste identification as the means for improving communication in globally distributed agile software development

Agile approaches highly values communication between team members to improve software development processes, even though, communication in globally distributed agile teams can be difficult. Literature proposes solutions for mitigating the challenges encountered in these environments. These solutions range from general-level recommendations and practices to the use of communication tools. However, an approach covering the whole development process for identifying challenges, and improving communication in globally distributed agile development projects, is missing. In order to address this, we conducted a case study within a globally distributed agile software development project focused on using the concept of waste as a lens for identifying non-value producing communication elements. In order to achieve this, we constructed a waste identification approach through which we identified five communication wastes, and solutions to mitigate them. These wastes can help companies identify communication issues that are present in their development efforts, while the presented waste identification technique gives them a mechanism for waste identification and mitigation. This work contributes to the scientific community by increasing the knowledge about communication in globally distributed agile development efforts.     

A multi-case study of agile requirements engineering and the use of test cases as requirements

ContextIt is an enigma that agile projects can succeed ‘without requirements’ when weak requirements engineering is a known cause for project failures. While agile development projects often manage well without extensive requirements test cases are commonly viewed as requirements and detailed requirements are documented as test cases.ObjectiveWe have investigated this agile practice of using test cases as requirements to understand how test cases can support the main requirements activities, and how this practice varies.MethodWe performed an iterative case study at three companies and collected data through 14 interviews and two focus groups.ResultsThe use of test cases as requirements poses both benefits and challenges when eliciting, validating, verifying, and managing requirements, and when used as a documented agreement. We have identified five variants of the test-cases-as-requirements practice, namely de facto, behaviour-driven, story-test driven, stand-alone strict and stand-alone manual for which the application of the practice varies concerning the time frame of requirements documentation, the requirements format, the extent to which the test cases are a machine executable specification and the use of tools which provide specific support for the practice of using test cases as requirements.ConclusionsThe findings provide empirical insight into how agile development projects manage and communicate requirements. The identified variants of the practice of using test cases as requirements can be used to perform in-depth investigations into agile requirements engineering. Practitioners can use the provided recommendations as a guide in designing and improving their agile requirements practices based on project characteristics such as number of stakeholders and rate of change.     

项目管理系统中管理流程的研究与设计

工作流技术是计算机支持的协同工作研究领域新出现的一门学科。它是实现企业业务过程建模,过程管理与集成,最终实现业务过程自动化的核心技术。针对建立固定资产投资项目库的实际需求,项目开发小组利用编程技术实现了系统对项目的增、删、改等操作,并计划创建工作流流程管理,实现项目的流程化管理,最大程度地提高了办公效率。这不仅解决了传统管理方式所带来的问题,而且满足了投资处管理项目的需求。文章从工作流定义、研究现状和研究内容、项目库系统架枸及建模工具的角度概述与分析,使读者对工作流技术有一个系统的认识与了解。文章描述了在整个项目库中工作流技术的应用。本论文的目的在于使读者便于理解工作流的概念,并对工作流的应用有一定的了解。     

Integrating agile software development into stage-gate managed product development

Agile methods have evolved as a bottom-up approach to software development. However, as the software in embedded products is only one part of development projects, agile methods must coexist with project management models typically of the stage-gate type. This paper presents a qualitative case study of two large independent software system projects that have used eXtreme Programming (XP) for software development within contexts of stage-gate project management models. The study is comprised of open ended interviews with managers as well as practitioners, followed by a structured, fully traceable, qualitative analysis. We conclude that it is possible to integrate XP in a gate model context. Key issues for success are the interfaces towards the agile subproject and management attitudes towards the agile approach. Editor: Marvin Zelkowitz     

Primavera gets agile: a successful transition to agile development

Primavera Systems provides enterprise project portfolio management solutions that help customers manage their projects, programs, and resources. When we decided to improve how we build software and increase the quality of life for everyone on the team, we found our answer in agile software development. Adopting agile practices is a process of continuous learning and improvement. Primavera's development team is a model for others looking to adopt agile processes.     

Agile distributed software development: enacting control through media and context

While face‐to‐face interaction is fundamental in agile software development, distributed environments must rely extensively on mediated interactions. Practicing agile principles in distributed environments therefore poses particular control challenges related to balancing fixed vs. evolving quality requirements and people vs. process‐based collaboration. To investigate these challenges, we conducted an in‐depth case study of a successful agile distributed software project with participants from a Russian firm and a Danish firm. Applying Kirsch's elements of control framework, we offer an analysis of how control was enacted through the project context and in the participants' mediated communication. The analysis reveals that formal measurement and evaluation control were persistently enacted through mediated communication. These formal control practices were, however, predominantly carried out in conjunction with informal roles and relationships such as clan‐like control inherent in agile development. Overall, the study demonstrates that, if appropriately applied, communication technologies can significantly support distributed, agile practices by allowing concurrent enactment of both formal and informal controls. The paper discusses these findings as they relate to previous research and concludes with their implications for future research.     

Individual empowerment of agile and non-agile software developers in small teams

ContextEmpowerment of employees at work has been known to have a positive impact on job motivation and satisfaction. Software development is a field of knowledge work wherein one should also expect to see these effects, and the idea of empowerment has become particularly visible in agile methodologies, in which proponents emphasise team empowerment and individual control of the work activities as a central concern.ObjectiveThis research aims to get a better understanding of how empowerment is enabled in software development teams, both agile and non-agile, to identify differences in empowering practices and levels of individual empowerment.MethodTwenty-five interviews with agile and non-agile developers from Norway and Canada on decision making and empowerment are analysed. The analysis is conducted using a conceptual model with categories for involvement, structural empowerment and psychological empowerment.ResultsBoth kinds of development organisations are highly empowered and they are similar in most aspects relating to empowerment. However, there is a distinction in the sense that agile developers have more possibilities to select work tasks and influence the priorities in a development project due to team empowerment. Agile developers seem to put a higher emphasis on the value of information in decision making, and have more prescribed activities to enable low-cost information flow. More power is obtained through the achievement of managing roles for the non-agile developers who show interest and are rich in initiatives.ConclusionAgile developers have a higher sense of being able to impact the organisation than non-agile developers and have information channels that is significantly differently from non-agile developers. For non-agile teams, higher empowerment can be obtained by systematically applying low-cost participative decision making practices in the manager–developer relation and among peer developers. For agile teams, it is essential to more rigorously follow the empowering practices already established.     

Does risk matter? Disengagement from risk management practices in information systems projects

Risk management and ‘routine-based reliability’ is considered fundamental to project performance. Existing theories of project risk management do not fully explain why project managers stop practicing risk management information systems (IS); however, constructs drawn from organisation theory offer insights into how and why such disengagement occurs. The study examines risk management practices in 21 IS projects within 10 organisations. By focusing on risks that resulted in significant events and mapping backwards over time the practices associated with those risks, we identify that in all but five projects the manager had disengaged from prescribed risk management before executing risk responses. In most projects, the majority of formally identified and assessed risks remained unallocated and untreated. A laddering technique was used to help explain why this transpired. We found five key underlying beliefs that governed project managers’ risk management attitudes and actions.     

一种新的业务过程管理模型

通过对工作流本质的探讨和对WfMC工作流参考模型的分析,提出了在分解业务过程控制逻辑与应用逻辑的基础上,进一步将控制逻辑分解为路由逻辑与资源管理逻辑的思想.提出了描述资源管理逻辑的资源管理模型.基于资源管理模型提出一种新的过程管理模型BRM,给出了基于BRM的业务过程管理系统的系统框架和功能模块.与WfMC工作流参考模型的对比表明:BRM模块更清晰,柔性更突出,分解粒度更小.