Traditional Paradigms vs. The Agile Paradigm

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.