Agile development using Scrum Management

Agile development using Scrum Management

Abstract

We all know what the best is, but not what enough is. We design and implement things aiming at perfection and thus spending more money and effort than real need and real justifications are. This problem is also present in the world of software engineering. In traditional software development processes a significant number of bureaucratic procedures exist that are spending a lot of money and time, leading to insignificant or unnecessary quality. Agilists are trying to solve this problem by creating lightweight development processes with minimal set of actions needed for successful project completion. In the past ten years, agile methodologies are successfully applied for small and medium projects, but there is still mistrust when it comes to large and critical projects. This paper summarizes the most common problems of Scrum agile process for large projects and gives guidance how Scrum process should be scaled in order to be more applicable for them. (Hossain, 2011)

Introduction

Scrum of Scrums (SoS) is an approach of scaling Scrum to large project teams. Unlike Scrum itself, it is not a complete methodology, just a technique of conducting coordination meetings between Scrum teams working on a large project. As such, it leaves open many questions related to scaling Scrum. This has led many authors to be skeptical about the concept, to build their own concepts on top, or to propose alternatives. (Paasivaara, 2012)

A software development process is a scheme to structure and manage the various aspects of development (requirements elicitation, design, implementation, verification, maintenance, etc.). Software engineering has traditionally targeted so-called structured processes, such as the Rational Unified Process (RUP), the waterfall model, or the spiral model(Estler, et. al. 2012). Structured processes are characterized by a focus on rigorously defined practices, extensive documentation, and detailed planning and management. More recently, a surge of agile development processes have been introduced to overcome some of the limitations and unsatisfactory aspects of structured processes.

Scrum was designed to achieve a hyperproductive state where productivity increases 5-10 times over industry averages and many collocated teams have achieved this effect. The best standard metric to compare productivity across projects is Function Points as it directly represents features delivered (Sutherland, Jeff et. al. 2008). Capers Jones demonstrated years ago that the number of features delivered in Function Points can be estimated by “back-firing” using lines of code delivered. While this is a less direct measure of business value, it is the best measure available to compare teams industry wide. Thus the message of this paper is that Xebia Scrum/XP teams deliver Function Points over seven times faster than industry average waterfall teams and the Function Points they deliver have higher business value than the waterfall teams by over an order of magnitude. It is possible to create a distributed/outsourced Scrum with the same velocity and quality as a collocated team and this capability is reproducible over many projects(Sutherland, Jeff et. al. 2008).

Traditional or heavy software development processes are used by software teams more than ...