Scrum metaprocess: a process line approach for customizing Scrum

Agh, Halimeh; Ramsin, Raman

doi:10.1007/s11219-021-09551-4

Cited by 6 publications

(8 citation statements)

References 55 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Separating the bottom and top-down approaches has specific benefits, including the following:  The organization can use an existing metaprocess to improve the core pro instead of expending time and effort on improving existing processes. For ex ple, the Scrum metaprocess [56] can be used in organizations that use diffe versions of Scrum.  The organization may not have enough knowledge to improve existing proce Creating the metaprocess through the application of the top-down approac experts can address this issue.…”

Section: Identification Of Commonalities and Variabilities Among The ...mentioning

confidence: 99%

A Model-Driven Approach for Software Process Line Engineering

Agh

Ramsin

2023

Software

Self Cite

View full text Add to dashboard Cite

It has become increasingly preferable to construct bespoke software development processes according to the specifications of the project at hand; however, defining a separate process for each project is time consuming and costly. One solution is to use a Software Process Line (SPrL), a specialized Software Product Line (SPL) in the context of process definition. However, instantiating an SPrL is a slow and error-prone task if performed manually; an adequate degree of automation is therefore essential, which can be achieved by using a Model-Driven Development (MDD) approach. Furthermore, we have identified specific shortcomings in existing approaches for SPrL Engineering (SPrLE). To address the identified shortcomings, we propose a novel MDD approach specifically intended for SPrLE; this approach can be used by method engineers and project managers to first define an SPrL, and then construct custom processes by instantiating it. The proposed approach uses a modeling framework for modeling an SPrL, and applies transformations to provide a high degree of automation when instantiating the SPrL. The proposed approach addresses the shortcomings by providing an adequate coverage of four activities, including Feasibility analysis, Enhancing the core process, Managing configuration complexity, and Post-derivation enhancement. The proposed approach has been validated through an industrial case study and an experiment; the results have shown that the proposed approach can improve the processes being used in organizations, and is rated highly as to usefulness and ease of use.

show abstract

Section: Identification Of Commonalities and Variabilities Among The ...mentioning

confidence: 99%

A Model-Driven Approach for Software Process Line Engineering

Agh

Ramsin

2023

Software

Self Cite

View full text Add to dashboard Cite

show abstract

“…Indeed, previous studies have reported numerous challenges while adopting such frameworks, 4,6,17 including a mismatch between framework and organization, 6,7,13 controversies within the framework, 18–20 complex organization setup, 15,20 changes in management structure, 6,15,19,21,22 fluctuating company's policies, 15,19,21 and change resistance 15,19,20 . Not surprisingly, it has been acknowledged that agile methods often need to be tailored to accommodate specific situations 6–8,12,14,23–25 or issues (e.g., risk management) 26 …”

Section: Introductionmentioning

confidence: 99%

“…These fragments are selected and integrated to take advantage of the strengths of different methods 14,27 . The latter, on the other hand, always takes one particular method as a starting point that is configured to the specific development situation 23,27,28 . Nonetheless, the base method may need to be enhanced with additional fragments from other methods, while some of its original fragments may need to be removed 28 .…”

Section: Introductionmentioning

confidence: 99%

“…15,16 Indeed, previous studies have reported numerous challenges while adopting such frameworks, 4,6,17 including a mismatch between framework and organization, 6,7,13 controversies within the framework, [18][19][20] complex organization setup, 15,20 changes in management structure, 6,15,19,21,22 fluctuating company's policies, 15,19,21 and change resistance. 15,19,20 Not surprisingly, it has been acknowledged that agile methods often need to be tailored to accommodate specific situations [6][7][8]12,14,[23][24][25] or issues (e.g., risk management). 26 Tailoring software engineering methods can be classified into one of two approaches -namely, situational method engineering and method configuration 5,27 (some researchers consider method configuration as a particular form of situational method engineering).…”

mentioning

confidence: 99%

“…14,27 The latter, on the other hand, always takes one particular method as a starting point that is configured to the specific development situation. 23,27,28 Nonetheless, the base method may need to be enhanced with additional fragments from other methods, while some of its original fragments may need to be removed. 28 As far as agile software development is concerned, method fragments are known as agile practices.…”

mentioning

confidence: 99%

See 2 more Smart Citations

Scaling scrum with a customized nexus framework: A report from a joint industry‐academia research project

2023

View full text Add to dashboard Cite

Despite a wide range of scaling frameworks available, large‐scale agile transformations are not straightforward undertakings. Few organizations have structures in place that fit the predefined workflows – while once one applies an off‐the‐shelf framework outside of its prescribed process, guidance quickly runs out. In this paper, we demonstrate how to instantiate a method configuration process using a lightweight experimental approach embedded in Action Research cycles. The proposed approach was developed to assist practitioners working on a multiple‐team project at Intel Technology Poland to find the right practices to continue their Nexus‐based transformation and integrate their in‐house method into the already established company structures, processes, and routines. In particular, it enabled identifying a series of challenges with scaled practices and coping with those. The challenges ranged from logistical problems, through poor availability of the Product Owner, to lackluster knowledge transfer and a wide array of communication/coordination issues at meetings. The study broadens the current body of knowledge within technology management and the scaled agile method‐tailoring domain. It indicates potential corrective actions that may be taken advantage of by entities that are not inclined, due to organizational constraints, to directly implement an off‐the‐shelf framework. Furthermore, our study demonstrates that a gradual transition to large‐scale agile at the project level (1) is possible with the preservation of traditional command‐and‐control management practices; (2) requires neither middle management involvement nor upfront investment; and (3) does not need to disrupt the continuous delivery of the product.

show abstract