Scrum is one of the most used agile approaches in the software industry. However, some aspects can hinder its implementation, e.g., the lack of detail of artifacts, meetings, generation of the ...product backlog, and team composition, among others. This paper presents Mr. Scrum, a Scrum reference model obtained from comparing existing Scrum guides and applying the GQM (Goal-Question-Metric) paradigm. Mr. Scrum proposes a clear and complete set of process elements, as well as: purpose, objectives, phases, activities, roles, satisfactory-expected results, and process flows. The proposed model was evaluated through a focus group where its suitability, clarity, and completeness were evaluated. The findings show that the participants agree with the acceptance of the proposed model and that its use in the industry could motivate and facilitate the adoption, implementation, and evaluation of the Scrum implementation. In this sense, Mr. Scrum would allow professionals and organizations to be guided toward a better understanding of Scrum and minimize the subjectivity and error of its interpretation, adoption, and assessment.
Using agile methodologies for adopting COBIT Amorim, Ana Cláudia; Mira da Silva, Miguel; Pereira, Rúben ...
Information systems (Oxford),
November 2021, 2021-11-00, 20211101, Letnik:
101
Journal Article
Recenzirano
COBIT 5 is a widely-used framework for implementing sound governance of enterprise IT (GEIT). Currently, the ISACA’s official implementation solution follows a sequentially ordered process, raising ...several issues related with lack of commitment from top management and misaligned solutions. Nevertheless, new project life-cycle strategies have emerged along with the agile paradigm for project management, providing flexible and adaptable environments for projects where the solution is complex and not clear, delivering the product incrementally with feedback loops. This research aims to eliminate some known challenges of COBIT 5 adoptions by providing a Scrum based methodology to address these programmes. Design Science Research Methodology was used to guide this work, where two iterations on the solution development, demonstration and evaluation activities were performed. With two different iterations to the same solution and two distinct demonstrations, it was possible to identify several relevant findings. Overall, the results demonstrated that an agile methodology is not sufficient to reduce the resistance to changes, however, it increased the commitment from senior managers on the adoption of new practices and allowed to detect scope misalignment earlier in the development of solutions.
•The methodology increased the commitment from senior management.•The methodology enabled an early detection of scope misalignments.•An agile methodology was not sufficient to decrease the resistance to change.
Background. There are many books about software development, slightly fewer books about software development team’s management, and very little about work metrics of software development teams. ...Existing developers scrum team metrics definition practices were analyzed in this article and common rules were proposed. Application of the rules will allow implementing the Pareto principle in the choosing and using of metrics in developer’s scrum teams.
Methods. General scientific methods such as the analysis of Russian-language and foreign thematic literature, comparative analysis, induction and analogy were used.
Results. The result of the article is an ordered action plan, using of which makes it possible to most effectively evaluate the work of the developer’s scrum team. The target audience of the article is wide. Managers of different levels (from the team manager or scrum master to the head of the department) can use the described approach to create metrics for their departments. Developers will be able to better understand how managers see their work and take this into account in their work.
Conclusion. Software developer typical tasks are divided into technical stages. When allocating metrics to evaluate the effectiveness of each stage, the risk of local optimizations increased. In addition, if the area of responsibility of the manager shifts from the whole to the part, from the efficiency of the company to the efficiency of the business unit, then the risk of choosing the wrong metrics increases many times. Metrics that evaluate a partial result are considered incorrect – they relate to a part of the functionality, a division within the company, etc. As a result, the likelihood of making a management decision in accordance with the interests of the division, rather than the company or the product as a whole, increases. For this reason, the use of private metrics should be avoided.
Distributed Scrum: A Case Meta-analysis Santos, Ronnie De Souza; Ralph, Paul; Arshad, Arham ...
ACM computing surveys,
04/2024, Letnik:
56, Številka:
4
Journal Article
Recenzirano
Odprti dostop
Distributed Scrum adapts the Scrum project management framework for geographically distributed software teams. Experimentally evaluating the effectiveness of Distributed Scrum is impractical, but ...many case studies and experience reports describe teams and projects that used Distributed Scrum. This article synthesizes the results of these cases using case meta-analysis, a technique for quantitatively analyzing qualitative case reports. On balance, the evidence suggests that Distributed Scrum has no impact, positive or negative, on overall project success. Consequently, claims by agile consultants who present Distributed Scrum as a recipe for project success should be treated with great caution, while researchers should investigate more varied perspectives to identify the real drivers of success in distributed and global software development.
This paper presents a rationale for establishing collaboration between corporate IT projects and those conducting empirical research on teamwork. A review of teamwork research reveals gaps in many ...teamwork models: the influence of context of performance, the mechanisms of team development over time, and data generated by practitioners in naturalistic settings. The paper describes the Scrum framework for executing projects in IT departments in terms of input artifacts, output artifacts, team processes, and the role of organizational context. Given the lack of quantitative project outputs, the method describes how Thematic Analysis and qualitative research are needed to convert project outputs to insights on team processes. This method of conducting research on team performance aligns closely with the Macroergonomics framework for research and its attention to team, task, context, and study with practitioners in naturalistic settings.
The aim of the paper is to present and analyze mayor problems with the implementation of Agile Scrum on the example of Wolters Kluwer. An attempt to find an answer to a question about an efficient ...way of implementing Scrum methodology in a large organization that adopts traditional management methods is another goal of the current article. Major advantages of Scrum practice are presented together with the scope of their implementation in the described organization. Basing on research findings and author’s experiences major problems faced in the implementation process are described together with recommendations about effective Scrum implementation.
The cultural component of the project team is recognized as one of the most critical factors in the implementation of agile project management (APM), especially in nonsoftware industries, where the ...diffusion of APM still involves several challenges. Particularly, the successful implementation of scrum-the most diffused APM methodology-seems related to the project teams' subculture, which may differ from the overall organizational culture of the company. This article contributes to the APM literature in nonsoftware contexts by studying the cultural values that develop inside agile teams and the scrum principles and practices that are particularly relevant for fostering these values. Using interview data collected from seven manufacturing and service organizations, we use the competing value framework as the theoretical model to understand the cultural profiles of their organizations, how they deploy into the project teams' subculture, and what, if any, connections exist with the adoption of scrum principles and practices. We find that clan and market values are the dominant subcultures in agile teams. These cultural values are fostered at a strategic level by a subset of scrum values (i.e., courage, openness, and respect) and pillars (i.e., transparency and adaptation). At an operational level, retrospective meetings and the definition of particular artifacts also contribute to develop these dominant cultural values.
Context: Agile software development has nowadays reached wide adoption. However, moving agile to large‐scale contexts is a complex task with many challenges involved. Objective: In this paper, we ...review practices, challenges, and success factors for scaling agile both from literature and within a large software company, identifying the most critical factors. Method: We conduct a focused literature review to map the importance of scaling practices, challenges, and success factors. The outcome of this focused literature review is used to guide action research within a software company with a view to scaling agile processes. Results: Company culture, prior agile and lean experience, management support, and value unification were found to be key success factors during the action research process. Resistance to change, an overly aggressive roll‐out time frame, quality assurance concerns, and integration into preexisting nonagile business processes were found to be the critical challenges in the scaling process. Conclusion: The action research process allowed to cross‐fertilize ideas from literature to the company's context. Scaling agile within an organization does not need to follow a specific scheme, rather the process can be tailored to the needs while keeping the core values and principles of agile methodologies.
We investigate practices, challenges, and success factors for scaling agile software development. We follow a 2‐step process: a literature review used as input for an action research process within a company scaling‐up the development process. Culture within the company and prior agile and lean experience, management support, unification of views, and values were key success factors, while resistance to change, too quick roll‐out, quality assurance issues, and integration with previous non‐agile parts of the organization were critical challenges
PDF
