Moving back to scrum and scaling to scrum of scrums in less than one year

Abstract

We report on the experience of re-introducing Scrum in a project team that had previously failed to adopt that agile method. We explore the reasons we believe that caused the failure and explain how we approached the team to uncover them. Then, we describe our strategy to avoid incurring in those problems again and to take the team to a higher level of productivity, quality and personal satisfaction. We also present the motivation and the actions taken to go further and scale this scenario to multiple feature-oriented teams using Scrum of Scrums. All these changes occurred in less than one year.

A Study on Applicability of the Scrum Framework for Large Software Projects

“…Study 1 [42] reported that adoption of Scrum resulted in quick releases for customers to test. S3 [34], S5 [39] and S6 [23] reported an increase in productivity and quality. The factors leading to increased productivity were listed as increased team velocity, teams with mixed high skills, anchored methodology, improved motivation, business and user involvement, colocation, good infrastructure and frequent communication.…”

“…The study 5 [39] showed successful adoption of Scrum of Scrums by scaling team to multiple feature oriented teams. They demonstrated that separating teams by feature was perfect in order to focus on the main priorities for the development of the product and to avoid conflicts in backlog management.…”

“…In study 5 [39], multiple feature-oriented teams were used to scale scrum for large project. In this project special focus was given to the team's values such as commitment, teamwork and transparency.…”

“…In study 3 [34], Retrospectives meetings were held at the end of every iterations and project members seems to be content with the retrospective meetings as they gain valuable insights through them. In study 5 [39], Retrospectives were initially conducted between cross functional teams and there was a failure due to disagreement among different teams. Then retrospectives were conducted between feature teams and they deemed to be successful.…”

“…Since all models are abstractions, a model represents only some of the many aspects of a software process that potentially could be modeled namely the ones believed by the model developer to be especially relevant to the issues and questions the model is used to address. Two main modeling approaches used for software process simulation are system dynamics (continuous simulation) and discrete event simulation [39]. System dynamics models [39] describe the interaction between project factors, but do not easily represent queues and discrete process steps.…”