A walkthrough of the Agile Methodologies for software Development

Dhanya Arumughom -


‘Agility’ has turned out to be one of the essential qualities to strive in this highly competitive and dynamic era. Needless to say that the software industry too is finding ways to strive in the digitally transformed world with software everywhere in some form. The huge increase in software demand and customer expectations has led to a change in the “ways to deliver”. Organizations today need to push their products out quicker than their competition for survival. You cannot obviously take a year anymore to get a product released. Delivering high-quality software as quickly as possible is the aim of every organization. There is no denial of the impact of the factors - ‘Time to market’, ‘Cost’ and ‘Quality’ in the highly a competitive industry. It has to be Faster, Cheaper and better. Organizations have to be more ‘agile’ in all ways. That exactly is why you need to go the Agile way of delivering software.
Agile methodology, in fact, has been around for more than fifteen years. However, it is only in the past few years that it has become a buzz word in the software industry. Agile methodology is nothing but a project management methodology approach which lets you adapt to change and deliver working software as quickly as possible. The methodology is all about being collaborative, flexible and adaptive. Agile Methodology, in fact, is an umbrella term and there are various methodologies practiced in organizations today. This article, we focus on the various agile methodologies for software development. Please read our article on ‘Agile Methodology- Why, What and how’ if you need a brief introduction about the agile methodology.
The various agile methodologies may have different development lifecycles and methods share the same philosophy and principles of the agile methodology described as in agile manifesto and emphasize collaboration, adaption to change and quick delivery. Each methodology just has different tactics and practices to achieve the goals and has different terminologies. Let’s now take a look at the practices and terminologies used in the different methodologies.

1. Scrum Methodology


Scrum, by far is the most popular agile methodology as of today. Rather than considering it as a methodology, it could even be thought of as a framework for agile software development. The name Scrum is borrowed from the game of rugby to stress the importance of teams in successful product development. Scrum methodology relies on self-organizing and cross-functional teams. The Scrum methodology consists of a team with three roles:

  • Scrum Master: Scrum Master can be thought of as a coach of the team who helps the whole team in the Scrum process and responsible for setting up the team and organize scrum meetings.
  • Product Owner: Product owner represents the business, customers or users, and is responsible for guiding the team to build the right product. The Product Owner works closely with the team to identify and prioritize the requirements as a list which is referred to as ‘Product Backlog’.
  • Scrum Team: The scrum team will be a self-organized, cross-functional team in which each member is responsible to manage his work and work as a team to complete the sprint or cycle and deliver the product.

The Scrum model takes a highly iterative approach and progresses as a series of sprints. Sprints are time boxed to few weeks usually 2 weeks and not more than a month. The approach focuses on defining key features and objectives prior to each sprint where the team members figure out how many items they can commit to from the Product backlog and create a sprint backlog which is the list of tasks to be performed during the sprint. Once a Sprint has been delivered, the team analyzes the product backlog and reprioritizes if necessary, and moves to the next sprint.
Scrum methodology gives importance to face to face meetings and interaction between team members. Various scrum events like the Daily Stand up, Sprint Review and the Sprint Retrospective are the meetings held to synchronize the work of team members.

  • Daily Stand Up: Short meeting around 15 mins in which each team member quickly covers the status of work and progress since the last stand up.
  • Sprint Review: A demonstration of the work completed during a sprint. The product owner gets the opportunity to check the deliverables against the requirements and can either accept or reject it.
  • Retrospective: Final team meeting (attended by the Scrum Master and Scrum team) in the sprint to discuss and analyze the work and identify strategies for continuous improvement of the team’s processes. The team discusses what went well, what didn’t go well and how the team can improve in the next sprint.

2. Kanban

Kanban can be thought of as a large, prioritized to-do list. It is almost similar to Scrum and the requirements in Kanban are tracked by their current stage in the process (to-do, in development, in a test, done, etc). One of the main differences from Scrum is that it is not time-based, it is solely based on priority. When a developer is done with a task and ready to do next, he or she just pulls the next task. The purpose of Kanban is to continuously improve one’s own work progress.

The first step in Kanban is to visualize the workflow. This step includes visualizing the process or the current work of the team on a physical board called Kanban board. It can be done in the form of a simple whiteboard and sticky notes or cards and each card represents a task. The tasks would be categorized in different columns based on their status as ‘To Do”, “Doing”, “Done”, etc. This visualization helps in creating transparency about the distribution of work as well as existing bottlenecks.
In Kanban, Work in progress (WIP) limits are defined at each stage of the workflow on a Kanban board to encourage the team members to finish the task at hand and only then take up a new task. At its core, Kanban is based on the concept of “Flow”. The cards or task should flow through the system as evenly as possible without any long waiting times or hindrances.

3. Lean Software Development

Lean Software Development methodology is also an iterative agile development methodology. The methodology got its start in the manufacturing industry and is based on the Lean principles. It focuses on delivering value to the customer, and on the efficiency of the mechanisms that deliver the value. The Lean methodology revolves around its 7 principles:
1. Eliminate Waste
Anything that does not add value to the customer is considered to be waste. Eliminating any kind of waste first principle in Lean methodology. Unnecessary code or functionality, Delay in software development process, defect and quality issues, Unclear or constantly changing requirements, etc are some of the wastes in software development that should be systematically eliminated in order to maximize customer value.
2. Build Quality In
Building quality into a product in software development implies preventing defects by seeking them out with your verification process rather than using post-implementation integration and testing to detect them. Some of the most popular Lean development tools or techniques for building quality in are Pair programming, Test driven development, Incremental development, and constant feedback and automation.
3. Create Knowledge
This principle encourages the developers to build and record or document the knowledge necessary to develop a project including requirements, architecture, technologies, etc. This is necessary to retain valuable learning. It can be done through several practices like ensuring proper documentation, ensuring the code is commented thoroughly, knowledge sharing sessions, training, usage of tools for managing requirements or user stories and so on.
4. Defer Commitment
It simply means to not plan too much for months in advance, or not commit to ideas or projects without a full understanding of the business requirements. Rather you have to constantly be collecting and analyzing information regarding any important decisions.
5. Deliver Fast
Delivering fast is very important as the speed to market is a competitive advantage. The Lean way of delivering fast implies building a simple solution, put it in front of customers and enhance incrementally based on customer feedback.
6. Respect People
It means giving the team members freedom to find the best ways to do their job and recognizing their efforts. Teams can further encourage respect for people by communicating proactively and effectively and surfacing any work-related issues as a team.
7. Optimize the whole
Optimizing the whole development process is necessary to generate better results rather than sub-optimization where just local processes are optimized. Different organizations have a different way of doing this.

4. Extreme Programming (XP)

XP is another project management methodology that supports frequent releases in short development cycles typically 1-3 weeks and allows developers to respond to changing customer requirements. The methodology promotes high customer involvement, rapid feedback loops, continuous testing, continuous planning, and teamwork.
XP develops software keeping the customer in the target. The technique is very helpful when there is constantly changing requirements from customers if they are not sure about the functionality of the system. The extreme programming methodology follows the following phases for each iteration:

  • Planning and Analysis: Business requirements are gathered as user stories, which defines the functionality with business value and priority of each feature. Based on the requirements, the team creates a release schedule and divides the project into iterations.
  • Designing- This phase includes breaking down tasks, test scenario preparation for each task, etc.
  • Coding- At this phase, the code is implemented. XP encourages collective code ownership where everyone reviews code and any developer can add code. It encourages practices such as standardizing naming schemes, pair programming, committing code to a repository every few hours, etc.
  • Testing: The team runs unit tests and acceptance tests frequently.
  • Wrapping: This phase has activities like regression testing, conducting demos and reviews, developing new stories if needed and look out for process improvements based on the end of iteration review comments.

5. Crystal Methodology

The crystal methodology is a collection of approaches which focuses primarily on people and interaction among them. It also gives importance to business criticality and priority of the system under development.
In Crystal methodology, the processes and tools are not fixed at the beginning of the project but are decided by considering business requirements and technical needs of the project. Crystal is a family of methodologies consisting of various methods names as Crystal Clear, Crystal Yellow, Crystal Orange, Crystal Red, Crystal Maroon, Crystal diamond and Crystal sapphire. These various methodologies are known as the “weights” of the crystal approach. The weight of the crystal methodology is determined by the project environment and size. Crystal clear is for team size of 8 or fewer people, Crystal yellow for 10-20 people, Orange for 20-50 people, Red for 50-100 people and so on. Given below are the main properties of Crystal methodology:

  • An iterative and incremental development approach and ensures frequent delivery of client-valued potentially shippable functionalities.
  • Iterations are generally time boxed.
  • People-centric approach and emphasizes transparency.
  • Emphasizes reflective improvement and user feedback taken at the end of an iteration is used to plan and refine the subsequent iterations.
  • Crystal methodology recognizes the importance of a technical environment with automated tests, configuration management, and frequent integration.

6. DSDM (Dynamic System Development Method)

DSDM methodology is based on the following principles:

  • Active user involvement.
  • Teams must be empowered to make decisions.
  • Focus on frequent delivery.
  • Criterion for accepted deliverable
  • Iterative and incremental development.
  • All changes during development must be reversible.
  • Requirements are baselined at a high level.
  • Testing is integrated throughout the life cycle.
  • Collaborative and co-operative approach.

The methodology at its core calls out “fitness for business purpose” as the most important criteria for delivery. In this approach, requirements are baselined at a high level early in the project, planned and delivered in short-fixed length time boxes, referred to as iterations. The requirements for DSDM projects are prioritized using the Moscow rule.

M- Must have requirements (system would not work without these)

S- Should have requirements (Important to the system but can be omitted if time constraints endanger)

C- Could have but not critical (Feature to enhance the system which can be easily assigned to later timebox)

W- Want to have (Feature least important.Wont have this time, but potentially later)

In DSDM approach, all critical requirements have to be completed and not every requirement in a project or time box is considered critical. Within each time box, less critical requirements will be included so that they can be removed if necessary and release the higher priority requirements on schedule.

7. FDD(Feature Driven Development)

FDD, as the name implies is a feature based design-oriented process. In FDD approach, the project is divided into features which are very specific and short phases of work. These features are like the user stories in Scrum methodology and are the primary source of requirements.
The FDD project life cycle has five major activities:

  • Develop an overall model – Client and development team work together to make an overall model.
  • Build a features list – Based on the overall model, the overall project is divided as a list of features. Each feature is a small client valued output and has to be delivered in a time box called iteration which is usually 2 weeks.
  • Plan by feature: Here the development of features is planned. The order in which features will be implemented is decided and feature sets are assigned to teams.
  • Design by feature – This includes detailed modeling of the features using sequence diagrams, design inspection, etc.
  • Build by feature- A this phase, code is developed, tested and packaged to completely build the feature.