Agile Software Development Methodologies

There are so many different ways that we can develop software and there are not right or wrong methods to do that. Although nowadays after decades in the lifetime of the Software Industry some methods are more adopted from the community. And that is not limited to one option decision but frequently that is a mix between benefits from different methodologies.

To start, let’s first briefly describe a famous methodology called Waterfall. It was one of the first development methodologies and today it is considered very outdated. It has rigid sequence stages: define requirements and scope, analyze those requirements, design, implement, deploy, test and maintain. For many times that project management was problematic because its rigid workflow did not embrace business changes in time to the customers current needs (a poor Market Timing).


So at the beginning of the 20th century 17 people met to talk about some common problems that they were facing during their years in the software development industry. They all agreed that the companies are first over-documented in the process of developing software so they were always spending so much time documenting or analyzing than dropping solutions to the customers. In that meeting, after understanding what was the problem they wrote the Agile Manifesto which came with twelve items to rule that the software development process needs to be focused on customer needs, flexibility to change, progress metric based on working software deployed and people over process or tools.


Scrum is an Agile framework that helps all kinds of teams (not only development teams) to get the work done through the Agile principles, and incorporating those. In Scrum the teams manage the project breaking it in a small works series called sprints, using a set of tools, meetings and rules to do that. To Scrum works three key items are needed:

  • Product backlog: a list of features, bugs to fix and analyses to delivery and maintain your product
  • Sprint backlog: a subset from the product backlog, that was chosen by the team to achieving the sprint goal
  • Increment with your definition of done: it was what the team decided to consider as the definition of work done. That can be just a part of an epic story (a feature longer than one sprint), a story, or a new deployment to customers.

There are three types of roles in Scrum team:

  1. Product Owner: the person who knows very well the product business and the client. The product owner defines the product backlog and prioritizes the features that will come in the sprints.
  2. Scrum Master: an expert on Scrum framework who coaches all team members.
  3. Scrum development team: all team members which will build the product.


Kanban is also an Agile methodology framework. Its concept is based on a visual workflow that can be seen by anyone in the team and in the transparency in communication between the team members. We can highlight three key feature to describe Kanban:

  • Kanban Board is responsible to show the workflow, through it the team can know the state of each item in the project. The Board has some columns that can be more but at least the three ones: TODO, DOING and DONE.
    - In DOING we put the tasks that we are working on (and we always start a Kanban Board creating a doing column)
    - In TODO we put the tasks that we have not yet started (that is our backlog)
    - In DONE we put the tasks that we finished
  • Kanban Card is the place where we describe a task, always a small piece of work from the project. The card needs to have a title, a description, a time to complete and the name of the member responsible to work that task.
  • Kanban has a continuous flow, so any card that is pushed to the next column (like a task pushed from DOING to DONE) allows the team member to get another task and brings it to the current column (like a task from TODO pushed to DOING).

In short, Agile is a mindset, a set of principles while Scrum and Kanban are frameworks to apply those principles, create the culture in the team and deliver working software.

Even though Scrum and Kanban diverge in some points like the continuous delivery cadence (Scrum limits the delivery to about two weeks of work, while Kanban may deliver at any time) they come from the same principles and have the same goals, so one thing that can be done and a lot of companies do is use a mixed version from both of they to potentialize the Agile features. Maybe called “Scrumban” you can use backlog, sprints, team roles, all that from Scrum and use the Kanban board and Kanban cards to show tasks in a visual workflow.




Latin American • Brazil • São Paulo

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

ElasticSwap — Explaining Decay

Caution : Aurora MySQL 2.10.0

Setting up Workflows with WSO2 Identity Server

Google Trends API for Python


Achieving greater Transparency with Kanban

CAGE Codes Decisions Mapped for Ten of the S1000D Issues: 1.9 through 5.0

My experience at LetsGrowMore

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
André Rodrigues

André Rodrigues

Latin American • Brazil • São Paulo

More from Medium

Agile Quickie: Working Software & Responding to Change

📅 April 13: Scrum Master & Agile Coach Remuneration 2022

How to get results effectively in your engineering side job with Agile practices

Are you a Puppet Owner?