\documentclass[11pt,twoside]{article}\makeatletter

\IfFileExists{xcolor.sty}%
  {\RequirePackage{xcolor}}%
  {\RequirePackage{color}}
\usepackage{colortbl}
\usepackage{wrapfig}
\usepackage{ifxetex}
\ifxetex
  \usepackage{fontspec}
  \usepackage{xunicode}
  \catcode`⃥=\active \def⃥{\textbackslash}
  \catcode`❴=\active \def❴{\{}
  \catcode`❵=\active \def❵{\}}
  \def\textJapanese{\fontspec{Noto Sans CJK JP}}
  \def\textChinese{\fontspec{Noto Sans CJK SC}}
  \def\textKorean{\fontspec{Noto Sans CJK KR}}
  \setmonofont{DejaVu Sans Mono}
  
\else
  \IfFileExists{utf8x.def}%
   {\usepackage[utf8x]{inputenc}
      \PrerenderUnicode{–}
    }%
   {\usepackage[utf8]{inputenc}}
  \usepackage[english]{babel}
  \usepackage[T1]{fontenc}
  \usepackage{float}
  \usepackage[]{ucs}
  \uc@dclc{8421}{default}{\textbackslash }
  \uc@dclc{10100}{default}{\{}
  \uc@dclc{10101}{default}{\}}
  \uc@dclc{8491}{default}{\AA{}}
  \uc@dclc{8239}{default}{\,}
  \uc@dclc{20154}{default}{ }
  \uc@dclc{10148}{default}{>}
  \def\textschwa{\rotatebox{-90}{e}}
  \def\textJapanese{}
  \def\textChinese{}
  \IfFileExists{tipa.sty}{\usepackage{tipa}}{}
\fi
\def\exampleFont{\ttfamily\small}
\DeclareTextSymbol{\textpi}{OML}{25}
\usepackage{relsize}
\RequirePackage{array}
\def\@testpach{\@chclass
 \ifnum \@lastchclass=6 \@ne \@chnum \@ne \else
  \ifnum \@lastchclass=7 5 \else
   \ifnum \@lastchclass=8 \tw@ \else
    \ifnum \@lastchclass=9 \thr@@
   \else \z@
   \ifnum \@lastchclass = 10 \else
   \edef\@nextchar{\expandafter\string\@nextchar}%
   \@chnum
   \if \@nextchar c\z@ \else
    \if \@nextchar l\@ne \else
     \if \@nextchar r\tw@ \else
   \z@ \@chclass
   \if\@nextchar |\@ne \else
    \if \@nextchar !6 \else
     \if \@nextchar @7 \else
      \if \@nextchar (8 \else
       \if \@nextchar )9 \else
  10
  \@chnum
  \if \@nextchar m\thr@@\else
   \if \@nextchar p4 \else
    \if \@nextchar b5 \else
   \z@ \@chclass \z@ \@preamerr \z@ \fi \fi \fi \fi
   \fi \fi  \fi  \fi  \fi  \fi  \fi \fi \fi \fi \fi \fi}
\gdef\arraybackslash{\let\\=\@arraycr}
\def\@textsubscript#1{{\m@th\ensuremath{_{\mbox{\fontsize\sf@size\z@#1}}}}}
\def\Panel#1#2#3#4{\multicolumn{#3}{){\columncolor{#2}}#4}{#1}}
\def\abbr{}
\def\corr{}
\def\expan{}
\def\gap{}
\def\orig{}
\def\reg{}
\def\ref{}
\def\sic{}
\def\persName{}\def\name{}
\def\placeName{}
\def\orgName{}
\def\textcal#1{{\fontspec{Lucida Calligraphy}#1}}
\def\textgothic#1{{\fontspec{Lucida Blackletter}#1}}
\def\textlarge#1{{\large #1}}
\def\textoverbar#1{\ensuremath{\overline{#1}}}
\def\textquoted#1{‘#1’}
\def\textsmall#1{{\small #1}}
\def\textsubscript#1{\@textsubscript{\selectfont#1}}
\def\textxi{\ensuremath{\xi}}
\def\titlem{\itshape}
\newenvironment{biblfree}{}{\ifvmode\par\fi }
\newenvironment{bibl}{}{}
\newenvironment{byline}{\vskip6pt\itshape\fontsize{16pt}{18pt}\selectfont}{\par }
\newenvironment{citbibl}{}{\ifvmode\par\fi }
\newenvironment{docAuthor}{\ifvmode\vskip4pt\fontsize{16pt}{18pt}\selectfont\fi\itshape}{\ifvmode\par\fi }
\newenvironment{docDate}{}{\ifvmode\par\fi }
\newenvironment{docImprint}{\vskip 6pt}{\ifvmode\par\fi }
\newenvironment{docTitle}{\vskip6pt\bfseries\fontsize{22pt}{25pt}\selectfont}{\par }
\newenvironment{msHead}{\vskip 6pt}{\par}
\newenvironment{msItem}{\vskip 6pt}{\par}
\newenvironment{rubric}{}{}
\newenvironment{titlePart}{}{\par }

\newcolumntype{L}[1]{){\raggedright\arraybackslash}p{#1}}
\newcolumntype{C}[1]{){\centering\arraybackslash}p{#1}}
\newcolumntype{R}[1]{){\raggedleft\arraybackslash}p{#1}}
\newcolumntype{P}[1]{){\arraybackslash}p{#1}}
\newcolumntype{B}[1]{){\arraybackslash}b{#1}}
\newcolumntype{M}[1]{){\arraybackslash}m{#1}}
\definecolor{label}{gray}{0.75}
\def\unusedattribute#1{\sout{\textcolor{label}{#1}}}
\DeclareRobustCommand*{\xref}{\hyper@normalise\xref@}
\def\xref@#1#2{\hyper@linkurl{#2}{#1}}
\begingroup
\catcode`\_=\active
\gdef_#1{\ensuremath{\sb{\mathrm{#1}}}}
\endgroup
\mathcode`\_=\string"8000
\catcode`\_=12\relax

\usepackage[a4paper,twoside,lmargin=1in,rmargin=1in,tmargin=1in,bmargin=1in,marginparwidth=0.75in]{geometry}
\usepackage{framed}

\definecolor{shadecolor}{gray}{0.95}
\usepackage{longtable}
\usepackage[normalem]{ulem}
\usepackage{fancyvrb}
\usepackage{fancyhdr}
\usepackage{graphicx}
\usepackage{marginnote}

\renewcommand{\@cite}[1]{#1}


\renewcommand*{\marginfont}{\itshape\footnotesize}

\def\Gin@extensions{.pdf,.png,.jpg,.mps,.tif}

  \pagestyle{fancy}

\usepackage[pdftitle={Comparative Study on Agile Software Development Methodologies},
 pdfauthor={}]{hyperref}
\hyperbaseurl{}

	 \paperwidth210mm
	 \paperheight297mm
              
\def\@pnumwidth{1.55em}
\def\@tocrmarg {2.55em}
\def\@dotsep{4.5}
\setcounter{tocdepth}{3}
\clubpenalty=8000
\emergencystretch 3em
\hbadness=4000
\hyphenpenalty=400
\pretolerance=750
\tolerance=2000
\vbadness=4000
\widowpenalty=10000

\renewcommand\section{\@startsection {section}{1}{\z@}%
     {-1.75ex \@plus -0.5ex \@minus -.2ex}%
     {0.5ex \@plus .2ex}%
     {\reset@font\Large\bfseries}}
\renewcommand\subsection{\@startsection{subsection}{2}{\z@}%
     {-1.75ex\@plus -0.5ex \@minus- .2ex}%
     {0.5ex \@plus .2ex}%
     {\reset@font\Large}}
\renewcommand\subsubsection{\@startsection{subsubsection}{3}{\z@}%
     {-1.5ex\@plus -0.35ex \@minus -.2ex}%
     {0.5ex \@plus .2ex}%
     {\reset@font\large}}
\renewcommand\paragraph{\@startsection{paragraph}{4}{\z@}%
     {-1ex \@plus-0.35ex \@minus -0.2ex}%
     {0.5ex \@plus .2ex}%
     {\reset@font\normalsize}}
\renewcommand\subparagraph{\@startsection{subparagraph}{5}{\parindent}%
     {1.5ex \@plus1ex \@minus .2ex}%
     {-1em}%
     {\reset@font\normalsize\bfseries}}


\def\l@section#1#2{\addpenalty{\@secpenalty} \addvspace{1.0em plus 1pt}
 \@tempdima 1.5em \begingroup
 \parindent \z@ \rightskip \@pnumwidth 
 \parfillskip -\@pnumwidth 
 \bfseries \leavevmode #1\hfil \hbox to\@pnumwidth{\hss #2}\par
 \endgroup}
\def\l@subsection{\@dottedtocline{2}{1.5em}{2.3em}}
\def\l@subsubsection{\@dottedtocline{3}{3.8em}{3.2em}}
\def\l@paragraph{\@dottedtocline{4}{7.0em}{4.1em}}
\def\l@subparagraph{\@dottedtocline{5}{10em}{5em}}
\@ifundefined{c@section}{\newcounter{section}}{}
\@ifundefined{c@chapter}{\newcounter{chapter}}{}
\newif\if@mainmatter 
\@mainmattertrue
\def\chaptername{Chapter}
\def\frontmatter{%
  \pagenumbering{roman}
  \def\thechapter{\@roman\c@chapter}
  \def\theHchapter{\roman{chapter}}
  \def\thesection{\@roman\c@section}
  \def\theHsection{\roman{section}}
  \def\@chapapp{}%
}
\def\mainmatter{%
  \cleardoublepage
  \def\thechapter{\@arabic\c@chapter}
  \setcounter{chapter}{0}
  \setcounter{section}{0}
  \pagenumbering{arabic}
  \setcounter{secnumdepth}{6}
  \def\@chapapp{\chaptername}%
  \def\theHchapter{\arabic{chapter}}
  \def\thesection{\@arabic\c@section}
  \def\theHsection{\arabic{section}}
}
\def\backmatter{%
  \cleardoublepage
  \setcounter{chapter}{0}
  \setcounter{section}{0}
  \setcounter{secnumdepth}{2}
  \def\@chapapp{\appendixname}%
  \def\thechapter{\@Alph\c@chapter}
  \def\theHchapter{\Alph{chapter}}
  \appendix
}
\newenvironment{bibitemlist}[1]{%
   \list{\@biblabel{\@arabic\c@enumiv}}%
       {\settowidth\labelwidth{\@biblabel{#1}}%
        \leftmargin\labelwidth
        \advance\leftmargin\labelsep
        \@openbib@code
        \usecounter{enumiv}%
        \let\p@enumiv\@empty
        \renewcommand\theenumiv{\@arabic\c@enumiv}%
	}%
  \sloppy
  \clubpenalty4000
  \@clubpenalty \clubpenalty
  \widowpenalty4000%
  \sfcode`\.\@m}%
  {\def\@noitemerr
    {\@latex@warning{Empty `bibitemlist' environment}}%
    \endlist}

\def\tableofcontents{\section*{\contentsname}\@starttoc{toc}}
\parskip0pt
\parindent1em
\def\Panel#1#2#3#4{\multicolumn{#3}{){\columncolor{#2}}#4}{#1}}
\newenvironment{reflist}{%
  \begin{raggedright}\begin{list}{}
  {%
   \setlength{\topsep}{0pt}%
   \setlength{\rightmargin}{0.25in}%
   \setlength{\itemsep}{0pt}%
   \setlength{\itemindent}{0pt}%
   \setlength{\parskip}{0pt}%
   \setlength{\parsep}{2pt}%
   \def\makelabel##1{\itshape ##1}}%
  }
  {\end{list}\end{raggedright}}
\newenvironment{sansreflist}{%
  \begin{raggedright}\begin{list}{}
  {%
   \setlength{\topsep}{0pt}%
   \setlength{\rightmargin}{0.25in}%
   \setlength{\itemindent}{0pt}%
   \setlength{\parskip}{0pt}%
   \setlength{\itemsep}{0pt}%
   \setlength{\parsep}{2pt}%
   \def\makelabel##1{\upshape ##1}}%
  }
  {\end{list}\end{raggedright}}
\newenvironment{specHead}[2]%
 {\vspace{20pt}\hrule\vspace{10pt}%
  \phantomsection\label{#1}\markright{#2}%

  \pdfbookmark[2]{#2}{#1}%
  \hspace{-0.75in}{\bfseries\fontsize{16pt}{18pt}\selectfont#2}%
  }{}
      \def\TheFullDate{2013-01-15 (revised: 15 January 2013)}
\def\TheID{\makeatother }
\def\TheDate{2013-01-15}
\title{Comparative Study on Agile Software Development Methodologies}
\author{}\makeatletter 
\makeatletter
\newcommand*{\cleartoleftpage}{%
  \clearpage
    \if@twoside
    \ifodd\c@page
      \hbox{}\newpage
      \if@twocolumn
        \hbox{}\newpage
      \fi
    \fi
  \fi
}
\makeatother
\makeatletter
\thispagestyle{empty}
\markright{\@title}\markboth{\@title}{\@author}
\renewcommand\small{\@setfontsize\small{9pt}{11pt}\abovedisplayskip 8.5\p@ plus3\p@ minus4\p@
\belowdisplayskip \abovedisplayskip
\abovedisplayshortskip \z@ plus2\p@
\belowdisplayshortskip 4\p@ plus2\p@ minus2\p@
\def\@listi{\leftmargin\leftmargini
               \topsep 2\p@ plus1\p@ minus1\p@
               \parsep 2\p@ plus\p@ minus\p@
               \itemsep 1pt}
}
\makeatother
\fvset{frame=single,numberblanklines=false,xleftmargin=5mm,xrightmargin=5mm}
\fancyhf{} 
\setlength{\headheight}{14pt}
\fancyhead[LE]{\bfseries\leftmark} 
\fancyhead[RO]{\bfseries\rightmark} 
\fancyfoot[RO]{}
\fancyfoot[CO]{\thepage}
\fancyfoot[LO]{\TheID}
\fancyfoot[LE]{}
\fancyfoot[CE]{\thepage}
\fancyfoot[RE]{\TheID}
\hypersetup{citebordercolor=0.75 0.75 0.75,linkbordercolor=0.75 0.75 0.75,urlbordercolor=0.75 0.75 0.75,bookmarksnumbered=true}
\fancypagestyle{plain}{\fancyhead{}\renewcommand{\headrulewidth}{0pt}}

\date{}
\usepackage{authblk}

\providecommand{\keywords}[1]
{
\footnotesize
  \textbf{\textit{Index terms---}} #1
}

\usepackage{graphicx,xcolor}
\definecolor{GJBlue}{HTML}{273B81}
\definecolor{GJLightBlue}{HTML}{0A9DD9}
\definecolor{GJMediumGrey}{HTML}{6D6E70}
\definecolor{GJLightGrey}{HTML}{929497} 

\renewenvironment{abstract}{%
   \setlength{\parindent}{0pt}\raggedright
   \textcolor{GJMediumGrey}{\rule{\textwidth}{2pt}}
   \vskip16pt
   \textcolor{GJBlue}{\large\bfseries\abstractname\space}
}{%   
   \vskip8pt
   \textcolor{GJMediumGrey}{\rule{\textwidth}{2pt}}
   \vskip16pt
}

\usepackage[absolute,overlay]{textpos}

\makeatother 
      \usepackage{lineno}
      \linenumbers
      
\begin{document}

             \author[1]{A B M  Moniruzzaman}

             \author[2]{Dr. Syed Akhter  Hossain}

             \affil[1]{  Daffodil International University}

\renewcommand\Authands{ and }

\date{\small \em Received: 6 December 2012 Accepted: 3 January 2013 Published: 15 January 2013}

\maketitle


\begin{abstract}
        


Today?s business environment is very much dynamic, and organizations are constantly changing their software requirements to adjust with new environment. They also demand for fast delivery of software products as well as for accepting changing requirements. In this aspect, traditional plan-driven developments fail to meet up these requirements. Though traditional software development methodologies, such as life cycle-based structured and object oriented approaches, continue to dominate the systems development few decades and much research has done in traditional methodologies, Agile software development brings its own set of novel challenges that must be addressed to satisfy the customer through early and continuous delivery of the valuable software. It?s a set of software development methods based on iterative and incremental development process, where requirements and development evolve through collaboration between self-organizing, cross-functional teams that allows rapid delivery of high quality software to meet customer needs and also accommodate changes in the requirements. In this paper, we significantly indentify and describe the major factors, that Agile development approach improves software development process to meet the rapid changing business environments. We also provide a brief comparison of agile development methodologies with traditional systems development methodologies, and discuss current state of adopting agile methodologies.

\end{abstract}


\keywords{agile, traditional methods, agile adoption, SCRUM, XP.}

\begin{textblock*}{18cm}(1cm,1cm) % {block width} (coords) 
\textcolor{GJBlue}{\LARGE Global Journals \LaTeX\ JournalKaleidoscope\texttrademark}
\end{textblock*}

\begin{textblock*}{18cm}(1.4cm,1.5cm) % {block width} (coords) 
\textcolor{GJBlue}{\footnotesize \\ Artificial Intelligence formulated this projection for compatibility purposes from the original article published at Global Journals. However, this technology is currently in beta. \emph{Therefore, kindly ignore odd layouts, missed formulae, text, tables, or figures.}}
\end{textblock*}


\let\tabcellsep& 	 	 		 \par
Introduction lot of people have been asking the question "What is Agile Software Development?" and invariably they get a different definition depending on who they ask. Here's a definition that conforms to the values and principles of the Agile Manifesto  {\ref [1]}. An iterative and incremental (evolutionary) approach to software development which is performed in a highly collaborative manner by self-organizing teams within an effective governance framework with "just enough" ceremony that produces high quality solutions in a cost effective and timely manner which meets the changing needs of its stakeholders  {\ref [6]}.Agile software development is actually a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between selforganizing, cross-functional teams  {\ref [4]}. In 2001, the "agile manifesto" was written by the practitioners reveals which items are considered valuable by ASDMs  {\ref [1]}. As shown in Table  {\ref 1}.\par
Table  {\ref 1} : Agile Manifesto (Source: [1]) a) Research Review Agile software development (ASD) is major paradigm, in field of software engineering which has been widely adopted by the industry, and much research, publications have conducted on agile development methodologies over the past decade. The traditional way to develop software methodologies follow the generic engineering paradigm of requirements, design, build, and maintain. These methodologies are also called waterfall-based taking from the classical software development paradigm. They are also known by many other names like plan-driven, \hyperref[b23]{(Boehm and Turner, 2004}), \hyperref[b23]{[39]}; documentation driven, heavyweight methodologies, and big design upfront, \hyperref[b2]{(Boehm, 2002)}, \hyperref[b2]{[16]}. Boehm and Phillip \hyperref[b56]{[72]} report that during their project development experience, requirements often changed by 25\% or more. Due to constant changes in the technology and business environments, it is a challenge for TSDMs to create a complete set of requirements up front \hyperref[b6]{[26]}.  {\ref Williams and Cockburn,}\hyperref[b14]{[18]} also mentioned that one of problems of TSDMs is the inability to respond to change that often determines the success or failure of a software product. The agile approach to software development is based on the understanding that software requirements are dynamic, where they are driven by market forces  {\ref (Fowler, Title 2002;}); \hyperref[b2]{[16]}, \hyperref[b20]{[36]}. Agile systems development methods emerged as a response to the inability of previous plan-driven approaches to handle rapidly changing environments \hyperref[b53]{(Highsmith 2002}), \hyperref[b53]{[55]}. Williams and Cockburn \hyperref[b14]{[18]} state that agile development is "about feedback and change" , that agile methodologies are developed to "embrace, rather than reject, higher rates of change".\par
Agility is the ability to sense and response to business prospects in order to stay inventive and aggressive in an unstable and rapidly shifting business environment \hyperref[b53]{(Highsmith, 2002)}, \hyperref[b53]{[55]}. The agile approach to development is about agility of the development process, development teams and their environment \hyperref[b23]{(Boehm \& Turner, 2004}), \hyperref[b23]{[39]}. This approach incorporates shared ideals of various stakeholders, and a philosophy of regular providing the customers with product features in short time-frames \hyperref[b29]{(Southwell, 2002)}, \hyperref[b29]{[45]}. This frequent and regular feature delivery is achieved by team based approach \hyperref[b31]{(Coram \& Bohner, 2005)}, \hyperref[b31]{[47]}. Agile teams consist of multi-skilled individuals  {\ref (Fowler, 2002)}, \hyperref[b2]{[16]}. The development teams also have on-site customers with substantial domain knowledge to help them better understand the requirements (Abrahamsson, Solo, Ronkainen, \& Warsta, 2002), \hyperref[b21]{[37]}. Multiple short development cycles also enable teams to accommodate request for change and provide the opportunity to discover emerging requirements \hyperref[b53]{(Highsmith, 2002)}, \hyperref[b53]{[55]}. The agile approach promotes micro-project plans to help determine more accurate scheduling delivery commitments \hyperref[b32]{(Smits, 2006)}, \hyperref[b32]{[48]}.\par
M Lindvall, V Basili, B Boehm, P Costa, (2002), \hyperref[b0]{[17]} summarize the working definition of agile methodologies as a group of software development processes that must be iterative (take several cycles to complete), incremental (not deliver the entire product at once), self-organizing (teams determine the best way to handle work), and emergent (processes, principles, and work structures are recognized during the project rather than predetermined). In the paper by \hyperref[b4]{(Abrahamsson, Warsta, Siponen \& Ronkainen, 2003)}, in general, characterized agile software development by the following attributes: incremental, cooperative, straightforward, and adaptive \hyperref[b4]{[24]}. Boehm, B., \& Turner, R. (2005), generalize agile methods are lightweight processes that employ short iterative cycles, actively involve users to establish, prioritize, and verify requirements, and rely on a team's tacit knowledge as opposed to documentation \hyperref[b10]{[30]}. 
\section[{II.}]{II.} 
\section[{Agile Methods}]{Agile Methods}\par
For over a decade now, there has been an ever increasing variety of agile methods available includes a number of specific techniques and practices of software development. Agile methods are a subset of "iterative and evolutionary methods" \hyperref[b67]{[83,}\hyperref[b68]{84]} and are "based on iterative enhancement" \hyperref[b69]{[85]}  The major methods include eXtreme Programming \hyperref[b65]{(Beck, 1999)}, \hyperref[b66]{[82]}, Scrum (K. \hyperref[b51]{Schwaber \& Beedle, 2002)}, \hyperref[b51]{[53]}, Dynamic Systems Development Method \hyperref[b36]{(Stapleton, 1997)}, Adaptive Software Development \hyperref[b37]{(Highsmith, 2000)}, Crystal  {\ref (Cockburn, 2002)}, and Feature-Driven Development \hyperref[b39]{(Palmer \& Felsing, 2002)}. \hyperref[b36]{[58]}, \hyperref[b37]{[59]}, \hyperref[b38]{[60]}, \hyperref[b39]{[61]}. Figure \hyperref[fig_2]{1} shows an agile software development methodology process flow (Scrum).  
\section[{Year}]{Year}\par
The Agile Manifesto articulates the common principles and beliefs underlying these methods  {\ref (Cockburn, 2002)}, \hyperref[b2]{[16]}. Among the first and perhaps best known agile methods are Scrum and XP , \hyperref[b33]{[49]}. See Figure \hyperref[fig_3]{2} shows the current rate of Agile methodologies used. Scrum is aimed at providing an agile approach for managing software projects while increasing the probability of successful development of software, whereas XP focuses more on the project level activities of implementing software. Both approaches, however, embody the central principles of agile software development \hyperref[b11]{[31]}. Agile software development processes --such as the Rational Unified Process (RUP), Extreme Programming (XP), Agile Unified Process (AUP), Scrum, Open Unified Process (OpenUP), and even Team Software Process (TSP) --are all iterative and incremental (evolutionary) in nature \hyperref[b41]{[63]}. Some these modern approaches, in particular XP and Scrum, are agile in nature. The agile methods are focused on different aspects of the software development life cycle. Some focus on the practices (extreme programming, pragmatic programming, agile modeling), while others focus on managing the software projects (the scrum approach) [12]. 
\section[{III.}]{III.} 
\section[{Comparison Agile Software Development Methodologies over Traditional SDMs}]{Comparison Agile Software Development Methodologies over Traditional SDMs}\par
There are many different characteristics between ASDMs and TSDMs. Boehm \hyperref[b2]{[16]}, for example, reports nine agile and heavyweight discriminators. He believes the primary objective of ASDMs is on rapid value whereas the primary objective of TSDMs is on high assurance.\par
Study performed S. Nerur, R. Mahapatra, G. Mangalaraj \hyperref[b18]{[22]} state a comparison of traditional and agile development, they report seven issues to differentiate traditional and agile development. Their fundamental assumption of traditional development: "system are fully specifiable, predictable and are built through meticulous and extensive planning", whereas agile development: "high-quality adaptive software is developed by small teams using the principles of continuous design improvement and testing based on rapid feedback and change".\par
T. Dyba, \& T. Dingsoyr, \hyperref[b58]{[74]} summarize the differences between Agile development and traditional development basis on the of an unpredictable world, as well as emphasizing the value competent people and their relationships bring to software development. Agile methods address the challenge of an unpredictable world, emphasizing the value competent people and their relationships bring to software development \hyperref[b58]{[74]}.\par
Different researchers compare traditional and agile approaches, in their different perspectives, are summarized in Table  {\ref 2} (All sources from additional information). Linear; Life-cycle model (waterfall, spiral or some variation)\par
Iterative; The evolutionarydelivery model\par
Style of development , \hyperref[b48]{[50]} Anticipatory Adaptive\par
Requirements \hyperref[b2]{(Boehm, 2002)}; \hyperref[b23]{(Boehm and Turner, 2004}), \hyperref[b2]{[16]}, \hyperref[b23]{[39]} Knowable early, largely stable; Clearly defined and documented\par
Emergent, rapid change, unknown -Discovered during the project Architecture \hyperref[b2]{(Boehm, 2002)};  {\ref (Wysocki, 2009}\hyperref[b34]{(Wysocki, , 2011) )} , \hyperref[b2]{[16]}, \hyperref[b34]{[56]} Heavyweight  
\section[{Predictability and optimization}]{Predictability and optimization} 
\section[{Exploration or adaptation}]{Exploration or adaptation}\par
Change , \hyperref[b15]{[19]} Tend to be change averse Embrace change\par
Team members \hyperref[b2]{(Boehm, 2002)} , (Sherehiy, Karwowski, \& Layer, 2007), \hyperref[b2]{[16]}, \hyperref[b25]{[41]} Distributed teams of specialists; Plan-oriented, adequate skills access to external knowledge Agile, knowledgeable, collocated and collaborative; Co-location of generalist senior technical staff;\par
Team organization , \hyperref[b50]{[52]} Pre-structured teams Self-organizing teams Client Involvement ), \hyperref[b17]{[21]} Low involvement; Passive Client onsite and considered as a team member; Active/proactive Organization culture \hyperref[b53]{(Highsmith, 2002)} , \hyperref[b18]{(Nerur, Mahapatra, Mangalaraj, 2005)}, \hyperref[b53]{[55]}, \hyperref[b18]{[22]} Command and Control Culture 
\section[{Leadership and Collaboration Culture}]{Leadership and Collaboration Culture}\par
Software development process \hyperref[b26]{(Salo, \& Abrahamsson, 2007)}, \hyperref[b26]{[42]} Universal approach and solution to provide predictability and high assurance Flexible approach adapted with collective understanding of contextual needs to provide faster development Measure of success  {\ref (Highsmith, 2010)},  {\ref [1]} Conformance to plan Business value delivered a) Major agile benefits in comparison to the traditional approach\par
In this section, we presenting list and explain some of agile benefits in comparison to the traditional approach which significantly improves software development in many ways. We try to provide an indepth understanding (in some cases with figures), of these merit issues:  \hyperref[b64]{Dagnino, 2002)}, they believe, Agile methods are iterative, evolutionary, and incremental delivery model of software development \hyperref[b10]{[30]}, \hyperref[b63]{[79]}, \hyperref[b9]{[29]}, \hyperref[b16]{[20]}, \hyperref[b64]{[80]}, \hyperref[b4]{[24]}, \hyperref[b65]{[81]}.\par
Entire application is distributed in incremental units called as iteration. Development time of each iteration is small (couple of weeks), fixed and strictly adhered to. Each iteration is a mini increment of the functionality and is build on top of previous iteration. Agile software development of short iterative cycles offers an opportunity for rapid, visible and motivating software process improvement \hyperref[b59]{[75]}. Traditional approaches to the data-oriented aspects of software development; however, tend to be serial, not evolutionary and certainly not agile, in nature.   {\ref 2005}), generalize agile methods are lightweight processes that employ short iterative cycles, actively involve users to establish, prioritize, and verify requirements, and rely on a team's tacit knowledge as opposed to documentation \hyperref[b10]{[30]}. G Perera, \& MSD Fernando (2007), also describe Agile practice is a customer oriented, light-weight software development paradigm, best suited for small size development teams in projects under vague and changing requirements \hyperref[b43]{[65]}. A number of agile software development methods such as extreme programming (XP), feature-driven development, crystal clear method, scrum, dynamic systems development, and adaptive software development, fall into this category \hyperref[b18]{[22]}. Traditional Software Development Methods (TSDMs) including waterfall and spiral models are often called heavyweight development methods \hyperref[b6]{[26]}. These methods involves extensive planning, predefine process phases, heavy documentation and long term design process. Lightweight methodologies put extreme emphasis on delivering working code or product while downplayning the importance of formal process and comprehensive documentation \hyperref[b1]{[23]}. lifecycle based software development delivers the software only after entire completion of development process and before that clients have no clear idea and view of software to be developed. According to \hyperref[b10]{(Boehm \& Turner, 2005)}, Fast cycles, frequent delivery: Scheduling many releases with short time spans between them forces implementation of only the highest priority functions, delivers value to the customer quickly, and speeds requirements emergence \hyperref[b10]{[30]}. ASD methods are iterative and incremental development [4], and each successful completion of development iteration, it delivers software product increment to client, thus Agile software development is satisfying the customer through early and continuous delivery of the valuable software \hyperref[b44]{[66]}. Traditional, emerged as a response to the inability of previous plandriven approaches to handle rapidly changing environments \hyperref[b53]{(Highsmith, 2002)}. As second principle of Agile Manifesto [1] --welcome changing requirements, even late in development?, all agile method(s) is well organized, accommodate to change requirements. According to B. Boehm, (2002), organizations -are complex adaptive systems in which requirements are emergent rather than pre-specifiable? and agile approaches -are most applicable to turbulent, highchange environments? \hyperref[b2]{[16]}   In contrast, agile development framework allows both customers and developers to change the requirements throughout the project, but only the customers have the authority to approve, disapprove and prioritize the ever-changing requirements \hyperref[b35]{(Koch, 2005)}, \hyperref[b35]{[57]}. In traditional SDMs it increases complexity for accepting changing requirements while developing, and also increases and delivery time, as well as cost to deliver software product. Agile requirements prioritization techniques to support and deal with frequent changes in priority lists which have been identified as success issue to accommodate over changes \hyperref[b57]{[73]}. In traditional development, software product with all features will be delivered at a time only after completion of software project. Customers are actively involved, and get higher priority in agile approaches rather than any traditional approaches. There is face to face communication and continuous feedback from customer (product owner) always happen in agile approach.\par
Figure  {\ref 9} : Active customer involvement in agile approach Customers appreciate active participation in projects as it allows them to control the project and development process is more visible to them, as well as, they are kept up to date \hyperref[b57]{[73]}. This customer involvement mitigates one of the most consistent problems on software projects: "What they will accept at the end of the project differs from what they told us at the beginning". This interaction helps the customer to form a better vision of the emerging product. Along with the ability to visualize the functionality that is coming based on having seen what was built so far, the customers develop a better understanding of their own needs and the vocabulary to express it to the developers [9]. Agile projects require a meaningful client involvement in every part of the project to provide constant feedback in an open and honest way  {\ref (Wysocki, 2009)}, \hyperref[b35]{[57]}. This feedback is a key element of agile methodologies, which is why the customer must be committed, knowledgeable, collaborative, representative, and empowered to avoid risk of failure \hyperref[b2]{(Boehm, 2002)}, \hyperref[b2]{[16]}. People are the primary drivers of agile projects and agile teams work best when people are physically close and document preparation and dissemination are largely replaced by face-to-face communication and collaboration , \hyperref[b17]{[21]}. 
\section[{vii. Reduce cost and time}]{vii. Reduce cost and time}\par
The study reports conducted by B. Bahli and ESA Zeid \hyperref[b61]{[77]} that the development team found using the waterfall model to be an "unpleasant experience", while XP (an agile method) was found to be "beneficial and a good move from management". The XP project was delivered a bit less late (50\% time-overrun, versus 60\% for the traditional), and at a significantly reduced cost overrun (25\%, compared to 50\% cost overrun for the traditional project). Agile development involves less cost of development as rework, management, documentation and other non-development work related cost is reduced. Figure \hyperref[fig_2]{11} : Design phase composition between waterfall and agile development According to \hyperref[b10]{(Boehm \& Turner, 2005)}, agile approach design is simple which involves Designing for the battle, not the war. The motto is YAGNI (You Aren't Going to Need It). The antimotto is BDUF (Big Design Up Front). Strip designs down to cover just what you're developing. Since change is inevitable, planning for future functions is a waste of effort \hyperref[b10]{[30]}. Customer gets to know regular and frequent status of the application and delivery is defined by fixed timescale. So, customer is assured of receiving some functionality by a fixed time period. Due to the short development life cycle through an iterative and incremental process, the agile methods have been used widely in business sectors where requirements are relatively unstable \hyperref[b6]{[26]}. ix. Self organized team Agile teams are self organizing and roles and relationships evolve as necessary to meet objectives . Team composition in an agile project is usually cross-functional and self-organizing, without consideration for any existing corporate hierarchy or the corporate roles of team members  {\ref [4]}. Agile product development practices introduce changes in team culture in an attempt to bringing reciprocal effects of roalty and commitment to the team and projects (Sherehiy, Karwowski, \& Layer, 2007). Team members normally take responsibility for tasks that deliver the functionality an iteration requires. They decide individually how to meet an iteration's requirements. Teams develop applications collaboratively and in cooperative environment. Agile alliance [5], claims that for a given problem size, "fewer people are needed if a lighter methodology is used, and more people are needed if a heavier methodology is used," and asserts that, "There is a limit to the size of problem that can be solved with a given number of people" \hyperref[b28]{[44]}.  According to \hyperref[b10]{(Boehm \& Turner, 2005)}, agile approach design is simple which involves Designing for the battle, not the war. The motto is YAGNI (You Aren't Going to Need It). The anti-motto is BDUF (Big Design Up Front). Strip designs down to cover just what you're developing. Since change is inevitable, planning for future functions is a waste of effort \hyperref[b10]{[30]}. In their research paper \hyperref[b30]{[46]}, (K Molokken \& Ostvold, 2005), define agile method(s) as a flexible software development model(s), basis on evolutionary and incremental models; and also claim that, among the benefits of using these models are reduced software project overruns.\par
xii. Improves Software Quality Boehm, B., \& Turner, R. (2004, May), Agile development methodologies (such as XP, Scrum, and ASD) promise higher customer satisfaction, lower defect rates, faster development times and a solution to rapidly changing requirements. Plan-driven approaches such as Cleanroom, the Personal Software Process, or methods based on the Capability Maturity Model promise predictability, stability, and high assurance \hyperref[b22]{[38]}.\par
The regular and continuous interaction between the customer and the developers have as their primary objective assuring that the product as built does what the customer needs for it to do and assures the usability of the product as well. The strong technical focus results in much better testing on an Agile project than in most other methods  {\ref [9]}. According to Charvat, (2003), agile practices: iterative and adaptive life cycles have the advantage of a continual testing throughout the project, which has a positive impact on quality \hyperref[b27]{[43]}. Agile developers take responsibility for the quality of the code they write. In addition to producing cleaner code, it means that if there are testing specialists on the project, they will start their testing with better software, which always results in more effective testing and a better resulting product. In addition to, developers value the technical focus on testing and refactoring of agile methods increasing their motivation. There is also a perception of increased quality in software products and higher productivity when using some agile teams use practices like coding standards, peer reviews, and pair programming to assure that the code they produce is technically solid \hyperref[b57]{[73]}.\par
xiii. Increase business value, visibility, adaptability and reduce cost Agile software development accelerates the delivery of initial business value, and through a process of continuous planning and feedback, ensures that value continues to be maximized throughout the development process. ASD provides customer satisfaction through collaboration and frequent delivery of implemented features. By delivering working, tested, deployable software on an incremental basis, agile development delivers increased value, visibility and adaptability much earlier in the life cycle, significantly reducing project risk.  In a study by Boehm and Papaccio \hyperref[b56]{[72]} discovered that a typical project experiences a 25\% change in requirements, while yet another  {\ref [Johnson]} showed that 45\% of features were never used. Agile approach aims to reduce waste and over-production by determining which parts are actually needed by the customer at each stage. In Agile approaches, delivering software on an incremental basis, customers give continuous feedback and agile team will always deliver products on time and on budget. As traditional project management isn't succeeding, more and more companies are turning to Agile development. According to the Standish Group's,  {\ref [11]} famous CHAOS Report of 2000, 25\% of all projects fail outright through eventual cancellation, with no useful software deployed. Sadly, this represents a big improvement over CHAOS reports from past years. Recently, they conduct a survey for Agile implementation success rate, see figure \hyperref[fig_2]{19}.   
\section[{Agile Adoption}]{Agile Adoption}\par
Agile methods are highly being adopted because of expectations that these methods can bring development success (Esfahani, Yu, \& Annosi, 2010). One of the main reasons for success with agile methods is that they are highly adaptive , \hyperref[b22]{[38]}. Figure \hyperref[fig_2]{1} reveals the current levels of agile adoption. In this case, 71\% of respondents indicated that they work in organizations that have succeeded at agile and an additional 15\% work in organizations that have tried agile but have not yet succeed at it. According to \hyperref[b8]{(West \& Grant, 2010)}, "in the past few years, Agile processes have not only gained increasing adoption levels; they have also rapidly joined the mainstream of development approaches" \hyperref[b8]{[28]}. Mary large companies including HP, IBM, Oracle, and Microsoft use Agile methodologies \hyperref[b60]{[76]} -and more and more smaller organisations turn Agile each year. In their study \hyperref[b8]{(West \& Grant, 2010)}, conducted by Forrester Research in 2009, agile software development processes were in use in 35\% of organizations, and another 16\% of organizations used an iterative development approach, while only 13\% of organization use a Waterfall approach. However, nearly 31\% did not use a formal development methodology \hyperref[b8]{[28]}. The main reasons behind for adopting Agile approaches rather than plan-driven approaches relate to: rapid changes; need for rapid results; emergent requirements , \hyperref[b22]{[38]}. According to Charvat, (2003), , \& Perrin, (2008), Agile methodologies have numerous advantages including that they: adapt very well to change and dynamism; are people-oriented and value-driven, rather than process-oriented and plan-driven; mitigate risks by demonstrating values and functionalities up front in the development process; provide a faster time to market; improve productivity (by reducing the amount of documentation) and will fail early/quickly and painlessly, if a project is not doable [34], \hyperref[b13]{[33]}, \hyperref[b12]{[32]}.\par
A state of Agile survey 2011, conducted by versionone Inc. result shows: the top three reasons for adopting Agile to -accelerate time to market, increase productivity, and to more easily manage changing priorities. Prior to adoption, respondents said productivity and time to market ranked as their top reasons to adopt agile. But experienced agile users said actual benefits were primarily project visibility (77\%) and the ability to manage changing priorities (84\%). 5. Conclusion Agile software development methodologies are evolutionary and incremental models have become increasingly popular in software development industry. Through, in many organizations, agile system development methods at adoption stage, agile methods might start to become well-established processes of these small, mid-level, even large organizations. There is increasing need to have a deeper understanding of agile methods in use in software development industry; as well as, have a better understanding -the benefits of agile approach as for accepting agile methods into their development style and for cope-up with their dynamic business needs. In this paper, we present main issues of agile numerous benefits in comparison to the traditional approach which significantly improves software development process in many ways. We also provide with this paper, the current adoption state of Agile software development with different current survey results with graphs. The purpose of this paper is to provide an in-depth understandingthe benefits of agile development approach into the software development industry, as well as provide a comparison study report of ASDM over TSDM. \begin{figure}[htbp]
\noindent\textbf{}\includegraphics[]{image-2.png}
\caption{\label{fig_1}}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{1}\includegraphics[]{image-3.png}
\caption{\label{fig_2}Figure 1 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{2}\includegraphics[]{image-4.png}
\caption{\label{fig_3}Figure 2 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{}\includegraphics[]{image-5.png}
\caption{\label{fig_5}}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{3}\includegraphics[]{image-6.png}
\caption{\label{fig_6}Figure 3 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{4}\includegraphics[]{image-7.png}
\caption{\label{fig_7}Figure 4 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{}\includegraphics[]{image-8.png}
\caption{\label{fig_8}}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{5}\includegraphics[]{image-9.png}
\caption{\label{fig_9}Figure 5 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{6}\includegraphics[]{image-10.png}
\caption{\label{fig_10}Figure 6 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{7}\includegraphics[]{image-11.png}
\caption{\label{fig_11}Figure 7 :C}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{8}\includegraphics[]{image-12.png}
\caption{\label{fig_12}Figure 8 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{10}\includegraphics[]{image-13.png}
\caption{\label{fig_13}Figure 10 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{12}\includegraphics[]{image-14.png}
\caption{\label{fig_14}Figure 12 :C}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{13}\includegraphics[]{image-15.png}
\caption{\label{fig_15}Figure 13 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{14}\includegraphics[]{image-16.png}
\caption{\label{fig_16}Figure 14 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{15}\includegraphics[]{image-17.png}
\caption{\label{fig_17}Figure 15 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{17}\includegraphics[]{image-18.png}
\caption{\label{fig_18}Figure 17 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{1921}\includegraphics[]{image-19.png}
\caption{\label{fig_19}Figure 19 :Figure 21 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{22}\includegraphics[]{image-20.png}
\caption{\label{fig_20}Figure 22 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{2023}\includegraphics[]{image-21.png}
\caption{\label{fig_21}Figure 20 :Figure 23 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{24}\includegraphics[]{image-22.png}
\caption{\label{fig_22}Figure 24 :}\end{figure}
 			\footnote{© 2013 Global Journals Inc. (US) Global Journal of Computer Science and Technology} 			\footnote{© 2013 Global Journals Inc. (US)} 		 		\backmatter  			  				\begin{bibitemlist}{1}
\bibitem[ Information Systems Management]{b3}\label{b3} 	 		\textit{},  	 	 		\textit{Information Systems Management}  		23  (3)  p. .  	 
\bibitem[Cockburn]{b28}\label{b28} 	 		\textit{},  		 			A Cockburn 		.  		 \url{http://alistair.cockburn.us/crystal/articles/ms/methodologyspace.htmAccessedon2/2/2005}  	 	 		\textit{The Methodology Space?}  		 	 
\bibitem[Petersen and Wohlin ()]{b57}\label{b57} 	 		‘A comparison of issues and advantages in agile and incremental development between state of the art and an industrial case’.  		 			K Petersen 		,  		 			C Wohlin 		.  	 	 		\textit{Journal of Systems and Software}  		2009. 82  (9)  p. .  	 
\bibitem[Molokken-Ostvold and Jorgensen ()]{b30}\label{b30} 	 		‘A comparison of software project overruns-flexible versus sequential development models. Software Engineering’.  		 			K Molokken-Ostvold 		,  		 			M Jorgensen 		.  	 	 		\textit{IEEE Transactions on}  		2005. 31  (9)  p. .  	 
\bibitem[Larman and Basili (2003)]{b67}\label{b67} 	 		‘A History of Iterative and Incremental Development’.  		 			C Larman 		,  		 			V Basili 		.  	 	 		\textit{IEEE Computer}  		June 2003. 36  (6)  p. .  	 
\bibitem[Palmer and Felsing ()]{b39}\label{b39} 	 		\textit{A Practical Guide to Feature Driven Development},  		 			S Palmer 		,  		 			Felsing 		.  		2002. Prentice Hall.  	 
\bibitem[Sherehiy et al. ()]{b25}\label{b25} 	 		‘A review of enterprise agility: Concepts, frameworks, and attributes’.  		 			B Sherehiy 		,  		 			W Karwowski 		,  		 			J K Layer 		.  	 	 		\textit{International Journal of Industrial Ergonomics}  		2007. 37  (5)  p. .  	 
\bibitem[Highsmith ()]{b37}\label{b37} 	 		\textit{Adaptive software development},  		 			J A Highsmith 		.  		2000. Dorset House.  	 
\bibitem[Larman ()]{b52}\label{b52} 	 		\textit{Agile and iterative development: a manager's guide},  		 			C Larman 		.  		2004. Addison-Wesley Professional.  	 
\bibitem[Larman ()]{b66}\label{b66} 	 		\textit{Agile and Iterative Development: A Manager's Guide},  		 			C Larman 		.  		2004. Boston: Addison Wesley.  	 
\bibitem[West et al. ()]{b8}\label{b8} 	 		\textit{Agile development: Mainstream adoption has changed agility},  		 			D West 		,  		 			T Grant 		,  		 			M Gerush 		,  		 			D Silva 		.  		2010. Forrester Research.  	 
\bibitem[Fowler and Highsmith ()]{b45}\label{b45} 	 		‘Agile methodologists agree on something’.  		 			M Fowler 		,  		 			J Highsmith 		.  	 	 		\textit{Software Development}  		2001. 9 p. .  	 
\bibitem[Salo and Abrahamsson ()]{b11}\label{b11} 	 		‘Agile methods in European embedded software development organisations: a survey on the actual use and usefulness of Extreme Programming and Scrum’.  		 			O Salo 		,  		 			P Abrahamsson 		.  	 	 		\textit{Software}  		2008. 2  (1)  p. .  	 	 (IET) 
\bibitem[Salo and Abrahamsson ()]{b19}\label{b19} 	 		‘Agile methods in European embedded software development organisations: a survey on the actual use and usefulness of Extreme Programming and Scrum’.  		 			O Salo 		,  		 			P Abrahamsson 		.  	 	 		\textit{Software}  		2008. 2  (1)  p. .  	 	 (IET) 
\bibitem[Southwell ()]{b29}\label{b29} 	 		‘Agile process improvement’.  		 			K Southwell 		.  	 	 		\textit{TickIT International Journal}  		2002. p. .  	 
\bibitem[Garg ()]{b44}\label{b44} 	 		\textit{Agile Software Development},  		 			A Garg 		.  		2009.  	 
\bibitem[Highsmith ()]{b53}\label{b53} 	 		\textit{Agile software development ecosystems},  		 			J A Highsmith 		.  		2002. Addison-Wesley Professional.  	 
\bibitem[Abrahamsson et al. ()]{b21}\label{b21} 	 		\textit{Agile Software Development Methods},  		 			P Abrahamsson 		,  		 			O Solo 		,  		 			J Ronkainen 		,  		 			J Warsta 		.  		2002.  		 			VTT technical Research Centre of Finland 		 	 
\bibitem[Cockburn and Highsmith ()]{b17}\label{b17} 	 		‘Agile software development, the people factor’.  		 			A Cockburn 		,  		 			J Highsmith 		.  	 	 		\textit{Computer}  		2001. 34  (11)  p. .  	 
\bibitem[Koch ()]{b35}\label{b35} 	 		\textit{Agile software development: evaluating the methods for your organization},  		 			A S Koch 		.  		2005.  	 	 (Artech house) 
\bibitem[Williams and Cockburn ()]{b54}\label{b54} 	 		‘Agile software development: it's about feedback and change’.  		 			L Williams 		,  		 			A Cockburn 		.  	 	 		\textit{IEEE Computer}  		2003. 36  (6)  p. .  	 
\bibitem[Williams and Cockburn (2003)]{b14}\label{b14} 	 		‘Agile Software Development: It's about Feedback and Change’.  		 			L Williams 		,  		 			A Cockburn 		.  	 	 		\textit{IEEE Computer}  		June 2003. p. .  	 
\bibitem[Highsmith and Cockburn ()]{b5}\label{b5} 	 		‘Agile software development: The business of innovation’.  		 			J Highsmith 		,  		 			A Cockburn 		.  	 	 		\textit{Computer}  		2001. 34  (9)  p. .  	 
\bibitem[Highsmith and Cockburn ()]{b20}\label{b20} 	 		‘Agile software development: The business of innovation’.  		 			J Highsmith 		,  		 			A Cockburn 		.  	 	 		\textit{Computer}  		2001. 34  (9)  p. .  	 
\bibitem[Leffingwell ()]{b13}\label{b13} 	 		\textit{Agile software requirements: Lean requirements practices for teams, programs, and the enterprise},  		 			D Leffingwell 		.  		2007. Addison-Wesley Professional.  	 
\bibitem[Glass (2001)]{b61}\label{b61} 	 		‘Agile Versus Traditional: Make Love, Not War’.  		 			R Glass 		.  	 	 		\textit{Cutter IT Journal}  		Dec. 2001. p. .  	 
\bibitem[Beck and Boehm ()]{b42}\label{b42} 	 		‘Agility through discipline: A debate’.  		 			K Beck 		,  		 			B Boehm 		.  	 	 		\textit{Computer}  		2003. 36  (6)  p. .  	 
\bibitem[Dagnino (2002)]{b64}\label{b64} 	 		‘An evolutionary lifecycle model with Agile practices for software development at ABB. In Engineering of Complex Computer Systems’.  		 			A Dagnino 		.  	 	 		\textit{Eighth IEEE International Conference on},  				2002. December. 2002. IEEE. p. .  	 
\bibitem[Salo and Abrahamsson ()]{b26}\label{b26} 	 		‘An iterative improvement process for agile software development’.  		 			O Salo 		,  		 			P Abrahamsson 		.  	 	 		\textit{Software Process: Improvement and Practice},  				2007. 12 p. .  	 
\bibitem[Turk et al. ()]{b41}\label{b41} 	 		‘Assumptions underlying agile software-development processes’.  		 			D Turk 		,  		 			F Robert 		,  		 			B Rumpe 		.  	 	 		\textit{Journal of Database Management (JDM)}  		2005. 16  (4)  p. .  	 
\bibitem[Boehm and Turner (2004)]{b23}\label{b23} 	 		‘Balancing agility and discipline: Evaluating and integrating agile and plan-driven methods’.  		 			B Boehm 		,  		 			R Turner 		.  	 	 		\textit{Proceedings. 26th International Conference on},  				 (26th International Conference on)  		2004. May. 2004. 2004. IEEE. p. .  	 	 (Software Engineering) 
\bibitem[Boehm et al. ()]{b55}\label{b55} 	 		‘Balancing plan-driven and agile methods in software engineering project courses’.  		 			B Boehm 		,  		 			D Port 		,  		 			A W Brown 		.  	 	 		\textit{Computer Science Education}  		2002. 12  (3)  p. .  	 
\bibitem[Scanlon-Thomas ()]{b59}\label{b59} 	 		\textit{Breaking the Addiction to Process: An Introduction to Agile Project Management},  		 			E Scanlon-Thomas 		.  		2011.  	 	 (Itgp) 
\bibitem[Vinekar et al. ()]{b49}\label{b49} 	 		‘Can agile and traditional systems development approaches coexist? An ambidextrous view’.  		 			V Vinekar 		,  		 			C W Slinkman 		,  		 			S Nerur 		.  	 	 		\textit{Information systems management}  		2006. 23  (3)  p. .  	 
\bibitem[Nerur et al. ()]{b18}\label{b18} 	 		‘Challenges of migrating to agile methodologies’.  		 			S Nerur 		,  		 			R Mahapatra 		,  		 			G Mangalaraj 		.  	 	 		\textit{Project management methodologies. Selecting, implementig, and supporting},  				2005. 2003. 48 p. .  	 	 (Charvat, J.) 
\bibitem[Cockburn ()]{b38}\label{b38} 	 		\textit{Crystal clear: a humanpowered methodology for small teams},  		 			A Cockburn 		.  		2005. Addison-Wesley Professional.  	 
\bibitem[Curtis ()]{b69}\label{b69} 	 		 			B Curtis 		.  		\textit{Three Problems Overcome with Behavioral Models of the Software Development Process (Panel)," International Conference on Software Engineering},  				 (Pittsburgh, PA)  		1989. p. .  	 
\bibitem[Stapleton ()]{b36}\label{b36} 	 		\textit{DSDM, dynamic systems development method: the method in practice},  		 			J Stapleton 		.  		1997. Addison-Wesley Professional.  	 
\bibitem[Dybå and Dingsøyr ()]{b16}\label{b16} 	 		 			T Dybå 		,  		 			T Dingsøyr 		.  		\textit{Empirical studies of agile software development: A systematic review. Information and software technology},  				2008. 50 p. .  	 
\bibitem[Wysocki ()]{b34}\label{b34} 	 		\textit{Effective project management: traditional, agile, extreme},  		 			R K Wysocki 		.  		2011. Wiley.  	 
\bibitem[Beck ()]{b65}\label{b65} 	 		‘Embracing change with extreme programming’.  		 			K Beck 		.  	 	 		\textit{Computer}  		1999. 32  (10)  p. .  	 
\bibitem[Lindvall et al. ()]{b0}\label{b0} 	 		\textit{Empirical findings in agile methods},  		 			M Lindvall 		,  		 			V Basili 		,  		 			B Boehm 		,  		 			P Costa 		,  		 			K Dangle 		,  		 			F Shull 		,  		 			. . Zelkowitz 		,  		 			M 		.  		2002. 2002. p. .  	 
\bibitem[Perera and Fernando (2007)]{b43}\label{b43} 	 		‘Enhanced agile software developmenthybrid paradigm with LEAN practice. In Industrial and Information Systems’.  		 			G I U S Perera 		,  		 			M S D Fernando 		.  	 	 		\textit{ICIIS 2007. International Conference on},  				2007. August. 2007. IEEE. p. .  	 
\bibitem[Livermore ()]{b7}\label{b7} 	 		‘Factors that significantly impact the implementation of an agile software development methodology’.  		 			J A Livermore 		.  	 	 		\textit{Journal of Software}  		2008. 3  (4)  p. .  	 
\bibitem[Boehm ()]{b2}\label{b2} 	 		‘Get ready for agile methods, with care’.  		 			B Boehm 		.  	 	 		\textit{Computer}  		2002. 35  (1)  p. .  	 
\bibitem[Reifer ()]{b24}\label{b24} 	 		‘How good are agile methods’.  		 			D J Reifer 		.  	 	 		\textit{Software},  				2002. IEEE. 19 p. .  	 
\bibitem[Lemétayer ()]{b12}\label{b12} 	 		\textit{identifying the critical factors in software development methodology FIT},  		 			J Lemétayer 		.  		2010.  	 
\bibitem[Cho ()]{b6}\label{b6} 	 		‘Issues and Challenges of Agile Software Development with Scrum’.  		 			J Cho 		.  	 	 		\textit{Issues in Information Systems}  		2008. 9  (2)  p. .  	 
\bibitem[Larman and Basili ()]{b62}\label{b62} 	 		‘Iterative and incremental developments. a brief history’.  		 			C Larman 		,  		 			V R Basili 		.  	 	 		\textit{Computer}  		2003. 36  (6)  p. .  	 
\bibitem[Basili and Turner ()]{b68}\label{b68} 	 		‘Iterative Enhancement: A Practical Technique for Software Development’.  		 			V R Basili 		,  		 			A J Turner 		.  	 	 		\textit{IEEE Transactions on Software Engineering}  		1975. 1  (4)  p. .  	 
\bibitem[Smits ()]{b32}\label{b32} 	 		\textit{Levels of Agile Planning: From Enterprise Product Vision to Team Stand-up},  		 			H Smits 		.  		2006.  	 	 (Rally Software Development Corporation Whitepaper) 
\bibitem[Boehm and Turner ()]{b10}\label{b10} 	 		\textit{Management challenges to implementing agile processes in traditional development organizations. Software},  		 			B Boehm 		,  		 			R Turner 		.  		2005. IEEE. 22 p. .  	 
\bibitem[Beck et al. ()]{b40}\label{b40} 	 		\textit{Manifesto for agile software development. The Agile Alliance},  		 			K Beck 		,  		 			M Beedle 		,  		 			A Van Bennekum 		,  		 			A Cockburn 		,  		 			W Cunningham 		,  		 			M Fowler 		,  		 			. . Thomas 		,  		 			D 		.  		2001. p. .  	 
\bibitem[Meso and Jain ()]{b1}\label{b1} 	 		 			P Meso 		,  		 			R Jain 		.  		\textit{Agile software development: adaptive systems principles and best},  				2006.  	 
\bibitem[Abrahamsson et al. (2003)]{b4}\label{b4} 	 		‘New directions on agile methods: a comparative analysis’.  		 			P Abrahamsson 		,  		 			J Warsta 		,  		 			M T Siponen 		,  		 			J Ronkainen 		.  	 	 		\textit{Proceedings. 25th International Conference on},  				 (25th International Conference on)  		2003. May. 2003. Ieee. p. .  	 	 (Software Engineering) 
\bibitem[Charvat ()]{b27}\label{b27} 	 		\textit{Project management methodologies. Selecting, implementig, and supporting},  		 			J Charvat 		.  		2003.  	 
\bibitem[Paetsch et al. (2003)]{b63}\label{b63} 	 		‘Requirements engineering and agile software development’.  		 			F Paetsch 		,  		 			A Eberlein 		,  		 			F Maurer 		.  	 	 		\textit{Enabling Technologies: Infrastructure for Collaborative Enterprises, 2003. WET ICE 2003. Proceedings. Twelfth IEEE International Workshops on},  				2003. June. IEEE. p. .  	 
\bibitem[Leffingwell ()]{b48}\label{b48} 	 		\textit{Scaling software agility: best practices for large enterprises},  		 			D Leffingwell 		.  		2007. Addison-Wesley Professional.  	 
\bibitem[Leffingwell ()]{b50}\label{b50} 	 		\textit{Scaling software agility: best practices for large enterprises},  		 			D Leffingwell 		.  		2007. Addison-Wesley Professional.  	 
\bibitem[Schwaber and Beedle ()]{b51}\label{b51} 	 		 			K Schwaber 		,  		 			M Beedle 		.  		\textit{Agile software development with Scrum},  				2002. Prentice Hall. 18.  	 	 (PTR Upper Saddle River\textasciicircum  eNJ NJ) 
\bibitem[Greer and Ruhe ()]{b9}\label{b9} 	 		‘Software release planning: an evolutionary and iterative approach’.  		 			D Greer 		,  		 			G Ruhe 		.  	 	 		\textit{Information and Software Technology}  		2004. 46  (4)  p. .  	 
\bibitem[Highsmith et al. ()]{b46}\label{b46} 	 		‘The Great Methodologies Debate: Part 1’.  		 			J Highsmith 		,  		 			A V Traditional 		,  		 			M Love 		,  		 			N War 		.  	 	 		\textit{The Journal}  		2001.  (12)  p. 14.  	 
\bibitem[Highsmith et al. ()]{b47}\label{b47} 	 		‘The Great Methodologies Debate: Part 2’.  		 			J Highsmith 		,  		 			A V Traditional 		,  		 			M Love 		,  		 			N War 		.  	 	 		\textit{The Journal}  		2001.  (12)  p. 14.  	 
\bibitem[Coram and Bohner (2005)]{b31}\label{b31} 	 		‘The impact of agile methods on software project management’.  		 			M Coram 		,  		 			S Bohner 		.  	 	 		\textit{ECBS'05. 12th IEEE International Conference and Workshops on the},  				2005. April. 2005. IEEE. p. .  		 			In Engineering of Computer-Based Systems 		 	 
\bibitem[Pikkarainen et al. ()]{b33}\label{b33} 	 		‘The impact of agile practices on communication in software development’.  		 			M Pikkarainen 		,  		 			J Haikara 		,  		 			O Salo 		,  		 			P Abrahamsson 		,  		 			J Still 		.  	 	 		\textit{Empirical Software Engineering}  		2008. 13  (3)  p. .  	 
\bibitem[Bahli and Zeid (2005)]{b60}\label{b60} 	 		‘The role of knowledge creation in adopting extreme programming model: an empirical study’.  		 			B Bahli 		,  		 			E A Zeid 		.  	 	 		\textit{Information and Communications Technology, 2005. Enabling Technologies for the New Knowledge Society: ITI 3rd International Conference on},  				2005. December. IEEE. p. .  	 
\bibitem[Boehm and Papaccio ()]{b56}\label{b56} 	 		‘Understanding and controlling software costs. Software Engineering’.  		 			B W Boehm 		,  		 			P N Papaccio 		.  	 	 		\textit{IEEE Transactions on}  		1988. 14  (10)  p. .  	 
\bibitem[Boehm and Turner ()]{b15}\label{b15} 	 		‘Using risk to balance agile and plan-driven methods’.  		 			B Boehm 		,  		 			R Turner 		.  	 	 		\textit{Computer}  		2003. 36  (6)  p. .  	 
\bibitem[Boehm and Turner ()]{b22}\label{b22} 	 		‘Using risk to balance agile and plan-driven methods’.  		 			B Boehm 		,  		 			R Turner 		.  	 	 		\textit{Computer}  		2003. 36  (6)  p. .  	 
\bibitem[Dyba and Dingsoyr ()]{b58}\label{b58} 	 		\textit{What do we know about agile software development? Software},  		 			T Dyba 		,  		 			T Dingsoyr 		.  		2009. IEEE. 26 p. .  	 
\end{bibitemlist}
 			 		 	 
\end{document}
