Introduction
This article is a high level comparison of the traditional life cycle paradigms and the Agile paradigm and why most of the organizations are moving towards Agile.
Background
A basic knowledge of the following would be required while reading this article.
- SDLC (Software Development Life cycle).
- The Traditional life cycle models like waterfall and iterative models.
- The Agile models like Scrum, XP and Lean.
Phases of the Software Development Lifecycle
Every product right from its conception to its deployment passes through the different phases of the SDLC, short for the Software Development Life Cycle.
A product comprises of features and the completion of work on each of the features in its entirety leads to the completion of the product.
Traditional paradigms
The older and traditional paradigms require
that each phase of the SDLC be completed to its entirety before the next phase
starts. These paradigms are more like a pipeline in which each phase is
completed subsequent to which the next phase is started. The finished product is
gotten at the end of the pipeline.
1. Deviations from the project baseline
The implementation begins only after planning and designing the system. The user evaluation of the finished product takes place only towards the end of the SDLC.
This makes it difficult to find deviations from the project baseline early on in the development life cycle. The later the deviations are caught, the more the
amount of time and money required for course correction.
2. Handling changing business realities
This model assumes that all the requirements are captured during the
requirements gathering, planning and design phases. However, more often than
not during the time the product reaches the end of the SDLC, the business
realities might have changed so much that the finished product may be out of
date and the organization would have put in time and money to bring out a
product that no one wants.
3. Documentation
The traditional models are documentation driven. Projects in this model begin
with documenting a complete set of requirements during project initiation. This
is followed by creating extensive documentation during the design phase and so
on. This means that the team needs to spend a lot of time documenting before a
single line of code is written. Documentation is indeed a very important
process and forms a critical means for communication. However, the process of
documentation takes time. The larger the project, more the time needed for documentation.
4. Release spans
Since releases are planned for towards the end of the life cycle, the user gets a feel for the system only towards the end of the SDLC. Most users are able to
give a better feedback when they have actually worked and tried out the software for themselves. If feedback is received early on in the development
process, then it is easier to incorporate the user preferences and feedback into the product.
The Agile Paradigm
The fundamental aspect of Agile is that it
is iterative and incremental.
The Agile paradigm consists of short well
defined spans of work time called iterations or sprints. The span of a sprint
or iteration is set by teams and it varies from company to company and team to
team and is usually set to 1 or 2 weeks.
1. Deviations from the project baseline
At the end of each iteration, the team produces a tangible piece of work. Retrospectives at the end of these short
iterative spans help the team to re-evaluate the course of the project sooner and hence deviations from the project baseline are caught earlier on in the
process thus saving time and money. Even if the work produced at the end of an iteration has deviated significantly from its original intend, it is only an
iteration worth of work that has been lost and there is always time to steer the project back to the baseline.
2. Handling changing business realities
Almost always there is never a complete set
of requirements during the initial phase of a project. Requirements are added
and modified as the project progresses and more information about the project is
gathered. Agile accommodates for changing business realities since the
requirements are re-evaluated at the end of each iteration. Modifications to
the requirements and new requirements become part of the project backlog and
will move into subsequent iterations. However, drastic deviations from the
original set of requirements may be construed as scope change and may not be
considered as changing business requirements.
3. Documentation
The Agile Manifesto (http://agilemanifesto.org/) says “Working Software over Comprehensive
Documentation”. This does not mean that documentation should altogether be
avoided. The idea is to not create piles of documentation that would never be
used but to create just sufficient documentation to propel the project forward
and support the organization in future. The emphasis should be on creating working
software rather than depending too much on documents.
4. Release spans
A small portion of the finished product is
obtained at the end of every iteration. This is especially useful when proof of
concepts or throwaway prototypes are created for evaluation by the end users of
a new idea. Say, there is an idea which an organization has decided to invest in.
In order to evaluate the user acceptability of the idea, a proof of concept or
a throw away prototype can be created quickly and given to the users for
evaluation. The prototype will give the user a feel for how the final system
will be and the users can give valuable feedback on the product idea. The
organization will have achieved this in a short span of time and can make the
decision of whether to proceed with the idea or not based on user acceptance. If
the idea has not been welcomed by users, the organization at this point has the
advantage of not having spent too much of time, money and effort. On the other
hand, if the idea has wide acceptance, then the organization will have the
credit of putting the idea into the market much before its competitors.
Finding the right balance: Get Agile to work for you
Each organization is unique in its philosophy, functioning and protocol. A methodology that has worked for one organization
may not work for another one. Before choosing a particular agile methodology
for an organization, it would be essential to find out what the underlying
principles and philosophy of the organization is and then choose the
appropriate agile methodology that best suites the organization. The
organization hierarchies, team dynamics all play a major role in the decision
of picking the right agile methodology.
Sometimes it may not be feasible for an
organization to just pick any one of the Agile methodologies and adapt itself
to the methodology. In that case, it would be best to pick and choose the
features from the various agile methodologies that work best for the
organization and implement those in the team.
Agile works best in self motivated teams
where each member of the team offers to get a portion of the work done using
their expertise and knowledge in the area. An atmosphere conducive to the
members of the Agile team being able to freely contribute, ask questions,
openly discuss impediments and a collective ownership for the product being
developed are essential to the success of an Agile team.
