Prioritizing agile benefits and limitations in relation to practice usage

Abstract

Context. In recent years there has been significant shift from rigid development (RD) towards agile. However, it has also been spotted that agile methodologies are hardly ever followed in their pure form. Hybrid processes as combinations of RD and agile practices emerge. In addition, agile adoption has been reported to result in both: benefits and limitations.Objectives. This exploratory study (a) identifies development models based on RD and agile practice usage by practitioners; (b) identifies agile practice adoption scenarios based on eliciting practice usage over time; (c) prioritizes agile benefits and limitations in relation to (a) and (b).Methods. Practitioners provided answers through a questionnaire. The development models are determined using hierarchical cluster analysis. The use of practices over time is captured through an interactive board with practices and time indication sliders. This study uses the extended hierarchical voting analysis framework (EHV-F) to investigate benefit and limitation prioritization.Results. Four types of development models and six adoption scenarios have been identified. Overall, 45 practitioners participated in the prioritization study. A common benefit among all models and adoption patterns is knowledge and learning, while high requirements on professional skills were perceived as the main limitation. Furthermore, significant variances in terms of benefits and limitations have been observed between models and adoption patterns. Conclusions. The most significant internal benefit categories from adopting agile are knowledge and learning, employee satisfaction, social skill development, and feedback and confidence. Professional skills specific demands, scalability and lack of suitability for specific product domains are the main limitations of agile practice usage. Having a balanced agile process allows to achieve a high number of benefits. With respect to adoption, a big-bang transition from RD to agile leads to poor quality in comparison to the alternatives.

The impacts of agile and lean practices on project constraints: A tertiary study

“…We need to better understand why these practices are not investigated as intensively as the others. With new studies that show that some practices are declining in their adoption (Murphy et al, 2013;Solinski and Petersen, 2014), it is also worth investigating the reasons why practices, like TDD and pair programming, that appear to have a positive impact on quality are declining in their adoption.…”

Literature review of flexibility attributes: A flexibility framework for software developing organization

“…The lack of agreement on what constitute an Agile or Lean practice is further demonstrated in the variation of practices included in Agile surveys. Solinski and Petersen identified that the number of Agile practices included in Agile surveys vary between 14 and 59 practices . Meanwhile, Rodriguez et al reported the use of 16 Agile practices and 14 Lean principles from an industry survey in Finland .…”

“…Solinski and Petersen identified that the number of Agile practices included in Agile surveys vary between 14 and 59 practices. 50 Meanwhile, Rodriguez et al reported the use of 16 Agile practices and 14 Lean principles from an industry survey in Finland. 51 In our study, we included 26 practices provided by Petersen 12 and complement them with 2 practices reported by Williams,15 which are definition of done and informative workspace.…”

Supporting the combination of agile manner and architecture based development method

“…About the agile Adam Solinski and Kai Petersen in [1] discussed what are the most significant/insignificant benefits or limitations of agile practical usage. They find companies are inclined to switch to more flexible, adjustable approaches, but the usage of agile such as pair-programming and continuous integration with testing are commonly discarded.…”

“…ABSD is suitable for the big project where a higher level framework is needed. But like Adam Solinski and Kai Petersen in [1] said: SA is a good choice in certain domain where requirements are concise, stable, and seldom changed. However, in real world, there are almost no SA plans which are designed without revision.…”