Toward Understanding Customer Preference Factors in Agile - A Research Plan

Our research plan is designed to discover factors that influence, positively or negatively, customer’s preference for agile software development. We will employ qualitative research techniques, specifically grounded theory, as our research method. Customers are an essential component of the agile approach and merit additional study on their preference for software projects developed using agile techniques. The results of our research will present emergent constructs that influence customer preference for agile development. These constructs can then be analyzed using quantitative techniques to assess their validity and understand their relationships

A Human Factors Study of Risk Management of Complex Agile Scrum Projects in Large Enterprises

Agile Project Management methods have gained phenomenal success in the IT software world in managing projects of high complexity and uncertainty. However, Agile projects come with their unique set of risks. This paper seeks to explore the risks posed by human factors to complex Agile Scrum projects in large enterprises. Project Risk Management is crucial in determining the future performance of a complex project. Increasing project complexity makes it more and more difficult to anticipate potential events that could affect the project and to make effective decisions to reduce project risk exposure. This is even more true for Agile projects that promote immediate and frequent visibility of risk factors and distributed decision making in projects. A dominant reason for failure of complex Agile projects are the risks caused by human and organization factors. This paper will analyze the delivery risks posed by human factors and the traditionally hierarchical decision making in large enterprise systems

“Primus inter Pares”?—The Perception of Emergent Leadership Behavior in Agile Software Development Teams

Despite being a key feature of Agile Software Development (ASD), self-organization within ASD teams has received limited research attention. Hence, this study furthers our understanding of how informal emergent leadership may develop within ASD teams by combining knowledge on ASD teams with extant research on emergent leadership. In an exploratory mixed-method study of two Scrum teams, we observed two specific types of emergent leaders, namely, a “detail-oriented structurer”, and a “big picture coordinator.” For emergent leadership to develop, the Scrum master had to create a “leadership gap.” Given this leadership gap, emergent leadership may develop in a circular manner: specific behaviors of team members and their perceptions may provide the basis for emergent leadership, which combined with implicit leadership theories of team members give rise to a leadership structure. Our results add to research on emergent leadership and increase our understanding of self-organization in ASD teams

Self-Organizing is not Self-Managing: A Case Study about Governance Challenges in an Agile IT Unit and its Scrum Projects

This paper presents a case study on the internal governance of Scrum projects and their relationships with their organization’s governance within a rich research setting: an IT agile unit and its mature Scrum project teams. This study reveals ambiguities about the meaning of self-organizing versus self-managing, and the associated challenges for governance processes, especially those related to HR governance, which can lead to unresolved issues and conflicts. Interestingly, these ambiguities are also found in the current IS literature, which rarely differentiates self-organizing from self-managing in agile projects. Thus, this paper enhances our knowledge of governance processes and associated challenges, particularly for mature Scrum project teams, which are still little covered in the IS literature

Tensions and ambidexterity: a case study of an agile project at a government agency

Today’s dynamic business environment must continuously adapt its software development methods to changing technologies and new requirements on the part of customers. Therefore, Agile methods are being used more and more used because they emphasize both flexibility and the ability to change. However, at the same time, the business-driven need for predictability and control remains. The purpose of this case study is to explore and theorize on paradoxical tensions and ambidexterity during an Agile software development project at a government agency. The study empirically examines how tensions and the ambidextrous responses to these tensions are related to Agile values. Data was collected by conducting interviews and studying internal project documents. Four categories of tensions (learning, organizing, performing, and belonging) were used for analytical purposes. The findings suggest that most of the tensions perceived were in the categories of learning and performing. There are, furthermore, several connectionsbetween the ambidextrous responses to these tensions and Agile principles. A deeper understanding of Agile values and principles is required in order to make projects successful. The contribution made by the study, therefore, is of great importance because Agile methods are for leading projects, not only in Agile software development, but also in other industries and sectors

Agile software development approach for \u27ad-hoc\u27 IT projects

Restrictive Scrum assumptions make the effectiveness of this approach debatable in projects deviating from typical execution conditions. This article delivers a comprehensive software development approach for both academic and commercial Information Technology (IT) projects effectuated by teams that are hampered by significantly unsystematic participation of project members and mercurial internal communication. The nature of ‘ad-hoc’ projects imposes another level of difficulty in terms of both managing the conduct of such a project and ensuring the quality of the end product. Multicyclic action research enabled a gradual adaptation of the Scrum approach to support such project conditions. This study introduces major alterations to Sprint implementation and minor enhancements within the documentation process to streamline knowledge sharing among Development Team members. Proposed key alterations include the evolution of Daily Scrum towards Weekly Scrum, the possibility of extending Sprints length, the eventuality to switch team members during Sprint due to substantial failure to meet deadlines, having at least two team members responsible for a single Product Backlog Item (PBI) at all times, as well as exclusion of Burndown Chart in favor for Development Team members updating their working time. Positive validation of enhancements in mixed settings confirms that the generic Scrum framework can be adapted to support highly volatile projects. The proposed approach is suitable not only for carrying out software development initiatives that rely heavily on the skills of external experts and/or volunteers. It also supports traditional Scrum teams that seek to reduce their exposure to risk arising from organizational changes

Security in agile software development: A practitioner survey

Context: Software security engineering provides the means to define, implement and verify security in software products. Software security engineering is performed by following a software security development life cycle model or a security capability maturity model. However, agile software development methods and processes, dominant in the software industry, are viewed to be in conflict with these security practices and the security requirements. Objective: Empirically verify the use and impact of software security engineering activities in the context of agile software development, as practiced by software developer professionals. Method: A survey (N=61) was performed among software practitioners in Finland regarding their use of 40 common security engineering practices and their perceived security impact, in conjunction with the use of 16 agile software development items and activities. Results: The use of agile items and activities had a measurable effect on the selection of security engineering practices. Perceived impact of the security practices was lower than the rate of use would imply: This was taken to indicate a selection bias, caused by e.g. developers’ awareness of only certain security engineering practices, or by difficulties in applying the security engineering practices into an iterative software development workflow. Security practices deemed to have most impact were proactive and took place in the early phases of software development. Conclusion: Systematic use of agile practices conformed, and was observed to take place in conjunction with the use of security practices. Security activities were most common in the requirement and implementation phases. In general, the activities taking place early in the life cycle were also considered most impactful. A discrepancy between the level of use and the perceived security impact of many security activities was observed. This prompts research and methodological development for better integration of security engineering activities into software development processes, methods, and tools.</p

Agile software development approach for 'ad-hoc' IT projects

Restrictive Scrum assumptions make the effectiveness of this approach debatable in projects deviating from typical execution conditions. This article delivers a comprehensive software development approach for both academic and commercial Information Technology (IT) projects effectuated by teams that are hampered by significantly unsystematic participation of project members and mercurial internal communication. The nature of ‘ad-hoc’ projects imposes another level of difficulty in terms of both managing the conduct of such a project and ensuring the quality of the end product. Multicyclic action research enabled a gradual adaptation of the Scrum approach to support such project conditions. This study introduces major alterations to Sprint implementation and minor enhancements within the documentation process to streamline knowledge sharing among Development Team members. Proposed key alterations include the evolution of Daily Scrum towards Weekly Scrum, the possibility of extending Sprints length, the eventuality to switch team members during Sprint due to substantial failure to meet deadlines, having at least two team members responsible for a single Product Backlog Item (PBI) at all times, as well as exclusion of Burndown Chart in favor for Development Team members updating their working time. Positive validation of enhancements in mixed settings confirms that the generic Scrum framework can be adapted to support highly volatile projects. The proposed approach is suitable not only for carrying out software development initiatives that rely heavily on the skills of external experts and/or volunteers. It also supports traditional Scrum teams that seek to reduce their exposure to risk arising from organizational changes

Análisis de las mejoras propuestas por la metodología SAP Activate en proyectos de implantación de sistemas de gestión de información

[ES] Las tecnologías de la información y la comunicación forman parte esencial de la revolución digital en la que estamos inmersos. Además, a nivel empresarial, se puede decir que tienen el éxito asegurado aquellas que sean capaces de integrar la mayor cantidad de información en una sola interfaz, así como lo hace SAP. A partir del proyecto que supone la instalación de este software en las diferentes organizaciones, nace una metodología para la implementación del programa, en un principio, desarrollaron ASAP para la versión SAP R3, cuya base se fundamenta en las metodologías tradicionales del PMI. Sin embargo, dada la nueva versión que está actualmente en el mercado, SAP HANA, se hizo necesario el desarrollo de la metodología SAP ACTIVATE, para implantar el mencionado software de manera óptima. Dicha metodología propone cambios en la forma de trabajar e incorpora las metodologías ágiles de manera esencial para el despliegue de los proyectos. Entonces, debido a la importancia que supone SAP HANA y SAP ACTIVATE no solo para el sector tecnológico, sino también para las empresas en general y todo lo relacionado con la dirección y gestión de proyectos; con el desarrollo de este TFM, se hace un análisis cualitativo acerca del desempeño de la nueva metodología propuesta, con base en la opinión de expertos que la han implementado y cuyas conclusiones sirven de referencia para la preparación interna de empresas y/o profesionales que decidan aplicarla.[EN] Information Technologies have become an essential part of the digital revolution we are involved. Also, at the company level, it can be said that those systems that can integrate the greatest amount of information into a single interface, as SAP does, has assured success. On the other hand, from the project that involves the installation of this software in the different organizations, a methodology for the implementation of the program was born. At first, they developed SAP Methodology for the SAP R3 version, whose base takes place on the PMI traditional methodologies. However, given the new version currently on the market, SAP HANA, it became necessary to develop a new methodology, named SAP ACTIVATE methodology, to be successful in SAP¿s implementation. This methodology changes the way of working and combines agile methodologies in an essential way for the deployment of projects. Then, due to the importance of SAP HANA and SAP ACTIVATE, not only for the IT sector, but also for companies and project management itself; This TFM, shows a qualitative analysis made to evaluate the performance of the new methodology, based on expert¿s opinion who have implemented it and whose conclusions serve as reference for the internal preparation of companies and / or professionals who decides to apply it.García González, AK. (2018). Análisis de las mejoras propuestas por la metodología SAP Activate en proyectos de implantación de sistemas de gestión de información. http://hdl.handle.net/10251/110125TFG