ABSTRACT has been recognized as the source

ABSTRACT

 

As adopting Agile software
development becomes a trend, there is a need for a more structured definition
of what is Agile and what is a high-level of Agile maturity. Traditional
development methodologies rely on documents to record and pass on knowledge
from one specialist to the next. Feedback cycles are, in many cases, too long
or even nonexistent. Agile principles emphasize building working software that
people can get hands on quickly, versus spending a lot of time writing
specifications up front. Agile development focuses on cross functional teams
empowered to make decisions, versus big hierarchies and splitting by
function.There has been a tremendous importance in the field of agile software
development  approaches in the recent
past. This is because of the fastness that agile approaches  bring in the life cycle of software
development. This interest in the field shows that  there are benefits to reap through successful
implementation of agile methods. The field is relatively nascent and research
is in its initial stages. The paper has been carried with the distinct
objectives of examine and gain insights into the current agile methods and
practices, understanding the strengths and weaknesses of agile methods and
various issues of their applicability. To meet the set goals and objectives, we
used both qualitative and quantitative research methodologies.

We Will Write a Custom Essay Specifically
For You For Only $13.90/page!


order now

Keywords: Agile, Agile Maturity

 

I INTRODUCTION

 

Agile software
development (ASD) is a relative new term within software engineering. Agile
processes, or development methods, represent an apparently new approach for
planning and

 

managing software
development projects. ASD differs from traditional approaches as it puts less
emphasis on up-front plans and strict plan-based control and more on mechanisms
for change management during the project. Despite being a new approach, the
foundational principles of ASD are based on some existing principles and
theories, both from the field of software engineering, information systems and
others such as production management. Only recently the Lean
principles and the Agile development philosophy has been recognized as the
source for solutions to these challenges.

Organization of This
Paper

Paper starts
with describing Lean, Agile and Scrum methodology highlighting the difference
between traditional waterfall and new approach in software development.
The third chapter describes Lean Architecture and Common grounds between Lean
and Agile and also in this chapter we elaborated Scrum Overview.In fourth
Chapter we discussed about Feature Estimation in Agile.The fifth and Sixth
Chapter describes about Agile Approach and Agile Framework

.

II. ABOUT LEAN, AGILE
AND SCRUM

The classical way to
organize software development of large systems is the waterfall model, where
the development starts from defining and analyzing the requirements and ends to
operating (or maintaining) the software. Actual coding is only a minor part of
the entire process, whereas there is much emphasis on defining, designing, documentation,
testing and operating (maintaining) the software system.Figure 1 illustrates
the waterfall software development model.

Figure 1. Waterfall
Software Development      Model

Agile software
development model based on short iterations and quick releases challenges the waterfall
models having emphasis on design and documentation.

 

The Agile manifest recaps the
ideology:
 

Individuals
and interactions over     Processes
and  tools

Working
software over comprehensive
Documentation.

Customer
collaboration over contract   
Negotiation.

Responding
to change over following a           
plan.

 

III. LEARN ARCHITECTURE

 

Lean
architecture is developed based on lean manufacturing, while the lean
manufacturing is a generic process-management philosophy derived from Toyota Production
System with its focus on reduction of wastes to improve customer value. Lean
manufacturing considers the expenditure of resources as the goal other than the
creation of value for the end customer to be wasteful. From the perspective of
a consumer-customer, “value” is defined as any action or process that
the customer would be willing to pay for. Lean is centered on preserving value
with less work. The term “lean” was introduced by John Krafcik in 1988.Basically,
lean is a principle (or a practice) to eliminate wastes in the production cycle
on a broader perspective in many industry fields. Therefore, lean principle
must be coupled with the unambiguous definition of wastes in the identification
and elimination of waste thereby reducing both the time and cost expended in
the production of a product or service. In addition, Lean focuses on improving
the workflow, thereby steadily eliminating unevenness throughout the production
cycle. Finally, lean tools work to improve quality through error-proving the
production cycle and eliminating defects. In software engineering, wastes can
be defined in many ways at each phase in the development cycle. Agile programming,
despite its premises to speed up production, generates wastes such as
unnecessary “learning by doing” iterations due to premature
abstraction and optimization of the complex problem domain.

 

Common Grounds
between Agile and Lean

 

What can agile
do to avoid rework? Because agile often focuses on “get-it-right” iterations ,
it often fails to appreciate value-adding design or up-front deliberation that could
reduce excessive rework during implementation phase.As a result, too many agile
rules of thumb are often confined to the implementation phase in the project.To
resolve the problem and expend the use of agile,researchers have investigated
and presented Scrum and Lean as separate but complementary developments that
both arise from observations about complex adaptive systems.The question is how
lean can work with agile.Lean has tapped into software engineering from manufacturing
and its principles are amenable to agile software development. For example,
wastes such as unread documents or production reworks add nothing to the end-user
value, and these wastes can be eliminated by upfront thinking. Even “waiting”
is viewed as a wasted opportunity because one cannot achieve anything while waiting
for the other to finish the job. Lean’s “Poka-Yoke”(fail-proof) can reduce
defects that arise from the 80-20 rules and avoid rework through careful
deliberation. While lean is usually applied in the software requirement
analysis and architectural design but agile is often applied in software implementation
and testing, they share many common features, which are shown in Figure 2.

 

 

Figure 2 : Lean and Agile common
features

 

Scrum
overview

 

Scrum software
development project, Product Owner (PO) decides the product backlog, i.e. the
features expected fromnthe software (for the next release), signs off all
deliverables and represents budget and interests of the stakeholders. At the
start of each sprint, the project team decides in a sprint planning meeting,
which items from the product backlog are taken to the sprint backlog as use
cases for the software. This is based on the prioritization by the Product
Owner and teams work estimates and commitments. During each sprint, which
duration is typically two weeks, the team completes the sprint backlog.

Figure 3: Scrum Overview

 

 

IV FEATURE ESTIMATION IN AGILE

 

To be able to
estimate what can get done per sprint and how long the full project will take,
it is necessary to estimate how long each user story will take. Because one of
the major challenges in development is accurately predicting how long things
will take to get done, agile uses relative estimation.Features are rated on a
1, 2 or 3 point scale. More precise estimation is more challenging and ends up
less accurate. It is easy to compare things relatively on a scale of 3. And if
something is particularly challenging that you don’t think it fits within the
“3 point” bucket, it

should be broken
down into smaller features that can each fit into the respective buckets.There
are a number of ways to handle feature estimation. It can be as simple as just
talking about it or it can be slightly more complex using “planning poker”.It’s
also important to determine the sprint velocity of the team working on the
project. That is how many “points” the team can complete per sprint. This
velocity is averaged over time. And in typical average time value- the more
sprints you do, the estimates and velocity become more and more accurate. That
is to say that in some sprints you may not hit your goal number and other
sprints you may exceed it. Over the course of a standard project, this averages
out.

 

 

V AN AGILE APPROACH

 

The Agile
approach aims to nurture organization assets and to support other groups, such
as development teams, within organization. These groups should act in an Agile manner
that reflects the expectations of their customers and the ways in which their
customers work.First and foremost, the Agile values, principles and practices
should help to guide organization rchitecture modeling and documentation
efforts. This is just a good start though. In order to be successful at
organization architecture you need to rethink your overall approach and address
some fundamental issues. These issues are connected in a synergistic manner;
you must address all of them otherwise you will put your effort at risk. Some
of these issues are:

 

• Focus on people, not technology or  techniques:

All of the
arguments over “which model is right”, “which notation is right”, and “which
aradigm is right” are meaningless if you don’t have a viable strategy for
working together effectively. You could create a perfect organization
architecture model but it doesn’t matter if project teams can’t or won’t take advantage
of it.

 


Keep it simple:

A critical
concept is that organization architecture models and documents just need to be
good enough,they don’t need to be perfect. By keeping organization architecture
artifacts simple you increase the chances that your audience will understand
them, that project teams will actually read them, and that you will be able to
keep them up to date over time. Overly detailed documents might look impressive
sitting on a shelf, but a simple model that project teams actually use is what
your true goal should be.

 

• Work iteratively and incrementally

Agile
organization architects work in an iterative and incremental manner. They don’t
try to  create complete models. Instead
they create models that are just good enough. When they find that their models
are not sufficient they work on them some more. The advantage of this approach
is that they evolve their models incrementally over time, effectively taking a
just-in-time (JIT) model storming approach that enables them to get the models
in the hands of their customers as quickly as possible.

 

VI
AGILE FRAMEWORK

 

While the need
for architecture in agile development is still being debated, Jan Salvador van
der ven and Jan Bosch  proposed a
framework composed of three subjects: Agile, Architecture, and Axes.

 This framework identifies three axes:

 

1. The person
making architectural decisions     in
Agile

2. The way in
which the architectural decisions are communicated

3. Tthe length
of the decision feedback loop (how soon the    
proposed architecture

    can be implemented)

 

 

   

Figure 4 : Agile Framework

 

Problems with
Agile

 

Lack of
empirical studies at workplace, emphasis on principles and little guidance on
disciplines historically set back agile approach. As a result, agile is
criticized as undisciplined or lacking systematic processes. Project teams that
follow traditional development process such as waterfall find it hard to
translate agile principles into actual practices. Agile application is only
limited to implementation and early testing. Many agile practices, such as
daily standup meeting, pair programming and test-first coding are exercised
during implementation phase, and few agile practices bring mature domain
knowledge forward in a way that reduces the cost and effort of later decisions
during implementation .Especially, agile teams often confuse following a plan with
planning. Sticking to a plan discourages adaptive thinking. Therefore, a “plan”
might be useless. However, many practices show that a thoughtful planning ahead
can avoid a lot of rework.

 

VII. CONCLUSION

 

Successfully
implementing organizational wide change requires extra time and high energy
level from the whole organization.By using this approach in software design we
are able to first recognize and then eliminate activities which don’t add value
e.g. partially done work without any guarantee if customer will take it in use,
unnecessary task swapping, waiting, handoffs, faults, etc.This way of working
also implies improved responsiveness through rapid deliveries allowing
customers to delay decisions. This is especially enabled by short feedback
loops and continuous integration. Our motivation behind the change was not only
the current product under development but also to increase the Scrum framework
is the real source of learning. Only through experiencing it is possible to
express real meaning of how well the new way of working fits into our
situation.As agile development methods are widely utilized by the software
industry, the necessity of architecture related documentation is questioned and
sometimes even recognized as a conflict with agile principles,which encourages
constant requirement changes and promotes simplicity.

 

 

 

 

VIII REFERRENCES

 

1 ISO/IEC/IEEE 42010, Systems
and Software engineering — Architecture Description

2 Jim Highsmith, Agile Project
Management: Creating Innovative Products 2nd Edition

3 IEEE Std 1471, IEEE
Recommended Practice for Architectural Description of Software Intensive Systems,
October 2000.

4 Edition by Nick Rozanski,
Eoin Woods, Software Systems Architecture: Working with Stakeholders Using
Viewpoints and Perspectives, 2nd

5 Manifesto for Agile Software
Development

6 Veli-Pekka Eloranta and Kai
Koskimies, Lightweight Architecture Knowledge Management for Agile Software Development,
Tampere University of Technology, Tampere,Finland

7 SAFe Scale Agile,  Communities of
practice,http://www.scaledAgileframework.com/communities-ofpractice/

8 Jan Salvador van der ven, and
Jan Bosch, Architecture Decisions: Who, How, and When?, Factlink, Groningen,
The Netherlands, Chalmers University of Technology,Gothenburg, Sweden

9 Muhammad Ali Babar, Making Software
Architecture and Agile Approaches Work Together: Foundations and Approaches,
The University of Adelaide, Adelaide, SA,Australia Int’l Conf. Software Eng.
Research and Practice | SER