Introduction Agile Software Development

Document Sample
Introduction Agile Software Development Powered By Docstoc
					Christian Rehn,                                                                         18.07.2011
Ludger Overbeck,                                             Technical University of Kaiserslautern
Pierre Iraguha,                                                        Dept. of Computer Science
Rohit Dhiman,
Abrahale Tewelde

In the field of software development, many methodologies were introduced and one of them
is Agile Software Development. What makes a software development agile? This is the case
when software development is incremental (small software releases with rapid cycles),
cooperative (customers and developers working constantly together with close
communication), straight forward (the method itself is easy to learn and to modify) and
adaptive (able to make changes on the original requirements).

Agile development practices achieve the goal of producing quality software fast by
prioritizing first quality practices such as continuous integration, test-driven development,
concurrent testing, pair programming, and shared code ownership. And at the same time
making progress which is a very visible to the customer and other stakeholders. It changes
the focus of the development team from scope first, then time and lastly quality (so typical on
traditional projects) to quality first, followed by scope and time.

Scrum is one of the many agile software development methods. The term scrum originally
drives from a strategy in the game of rugby where it denotes “getting an out-of play ball back
into the game”.

Agile Software Development
Agile software development is one of software development methods based on iterative and
incremental development. In contrary to the common process-oriented oriented software
development approaches agile development tries to produce software with less bureaucratic
effort by focusing more on the end product rather than for example on the documentation. [4]

While it is still highly recommended to produce safety critical applications using process-
centered approaches, agile software development is a way to be able to react more flexibly
to changing and initially not well understood requirements as they are common for
information systems. Extreme Programming and Scrum are two of many forms of agile

Agile Manifesto and Agile Values
Individuals and interactions over processes and tools
in agile development following a process and using special tools are less important than self-
organization and motivation.

Working software over comprehensive documentation
Clients want to see in a meeting a working software rather than just being presented a document.

Customer collaboration over contract negotiation
It is almost impossible to collect all requirements at the beginning of the software development cycle.
For that reason continuous customer or stakeholder involvement is very important.

Responding to change over following a plan
Agile development is focused on quick responses to change and continuous development.[8] [4]

The agile development method Scrum was first published by Hirotaka Takeuchi and Ikujiro
Nonaka in 1986 as new approach to commercial software development applicable for
example for the automotive or computer industry. They referred to it as the rugby or holistic

The term Scrum (used to describe the whole team by Takeuchi and Nonaka) for this
approach was established by Peter DeGrace and Leslie Hulet Stahl in their book “Wicked
Problems, Righteous Solutions” in 1991 and was further promoted by Ken Schwaber and
Jeff Sutherland, who presented it in papers and on workshops.[1]

In 2002 the book “Agile Software Development with Scrum” written by Ken Schwaber and
Mike Beedle was published.

Basic Assumptions
Scrum is based on the assumption, that a software development process is so complex, that
planning it up to the granularity of days is not possible in advance. Instead a team should
organize itself with a rough given granularity.

In addition to that, Scrum fulfills the conditions for agile development methods as defined in
the chapter about “Agile Manifesto and Agile Values”.

In a team there are three basic roles: Product Owner, Team and ScrumMaster. [3]

Product Owner
The Product Owner represents the customer’s point of view. His/her job is to use methods
like user stories to define the customer’s need and to prioritize these needs, which are
added to the Product Backlog (see below). This role should not be combined with the

The Team, which develops the software product, typically consists of 5-9 Team members. It
usually organizes and leads itself using some sort of project management. For all required
skills there should (must) be at least one person in the Team with this skill (e.g. analyse,
design, develop, test).

The ScrumMaster is neither the Product Owner nor part of the Team. He/she is responsible
check that roles and rights are preserved. Thus he/she should make sure that the Team
works productively and should identify potential for improvement.

The heart of the Scrum process is a Sprint, i.e. an iteration of a fixed size (30 days are
suggested) in which the product is enhanced by a certain subset of the features to be
implemented. At the end of every Sprint there is a ready-to-ship product which has more
features than the one before the Sprint. That means every Sprint includes all the testing and
quality assurance that is needed for the product to be ready for deployment. [3]

On the other hand a Sprint is defined by its time frame and not by the implemented features.
That means that a Sprint has always a fixed size but it could be that less (or more) features
have been implemented as expected. The number of Sprints which are needed for
completing the product is not known in advance and can only be roughly guessed. This is by
intention as the goal is to be able to flexibly react to changing requirements.

Instead of a complete requirements document which comprises all requirements of the
product to be developed there is a list called the Product Backlog. The Product Backlog is an
incomplete but prioritized list of requirements. Prioritization and contents of the Product
Backlog is constantly kept up to date by the Product Owner in order to reflect new insights
and changed requirements. [3]

For every Sprint there is also a separate Sprint Backlog which lists the subset of
requirements which shall be implemented in the current Sprint. For the current sprint, the
sprint backlog can be further transformed into development tasks that could be done in less
than a day. [3]

For every Sprint there are three prescribed meetings: The Sprint Panning Meeting, the
Sprint Review and the Sprint Retrospective. In the Sprint Panning Meeting at the beginning
of a Sprint the requirements for the next iteration are selected, estimated, designed and
decomposed into tasks which form the Sprint Backlog.

As a Sprint always has a fixed size, in the end there has to be discussed what has been
done and what hasn’t been finished yet. There might be things that worked well and other
where problems were encountered and probably solved. In the Sprint Review these
questions are addressed. [3]

Scrum is an empirical process. That means the process is adapted when it’s used. The
Sprint Retrospective is used for collecting what went well and what could be improved. So
while the Sprint Review inspects the progress of the product, the Sprint Retrospective
inspects the (progress of the) process. Additionally to the three mentioned Sprint meetings
Scrum prescribes daily 15-minute standup-meetings called “Daily Scrum” for improving
communication in the Team. [3][2] In this meeting three questions are addressed: (1) What
have you done since the last meeting? (2) What will you do now? (3) What obstacles got in
your way? [1][2]

The most interesting effect of Scrum on software development environment is known as
“punctuated equilibrium” effect. This occurs in biological evolution when a species is stable
for long periods of time and then further undergoes a sudden jump in capability and
functionality. [1]

Managing Bigger Projects with Scrum
Managing bigger projects seems to be a bit more difficult in agile processes as in traditional
ones. As Teams should be self-organizing, management has less possibilities to coordinate
from a management side. For this reason the Scum Teams themselves have to coordinate
which is done in separate daily meetings called “Scrum of Scrums”.[6]

Scrum is not just a solution but a methodology. Scrum focuses not on documentation as in
other processes but on customers and there is a face-to-face communication among team
members. Nowadays, many bigger companies are introducing scrum as their software
development methodology. Some of the advantages of this process are:[1][2][4]

           ●   Makes transparency to stakeholders
           ●   Produces quality software fast
           ●   More functionality is achieved then waterfall method
           ●   Creates communication among team members
           ●   Highly adaptable to changing requirements

On the other hand Scrum is not applicable in every case:
          ● Scrum has limited scaleability; Projects should be small
          ● Scrum fits better for information systems than for embedded ones
          ● It can be difficult to address hard non-functional requirements in Scrum
          ● Scrum developers should be highly skilled generalists

[1] J.Sutherland: Agile Development:Lessons Learned From The First Scrum, 2004
[2] L. Rising and N. Janoff: The Scrum Software Development Process for Small Teams, 2000
[3] J.Sutherland: Scrum,
[4] Martin Fowler: The New Methodology,
[5] Paul Klipp: Scrum,
[6] Wikipedia: Scrum,
[7] Wikipedia: Scrum,
[8] Kent Beck et al.: Manifesto for Agile Software Development,


Shared By: