The Agile Umbrella – The Elements that Complement Agile

As we have previously mentioned in this LinkedIn post, Agile is a set of practices created by IT experts in the early 2000s, to make it easier for software projects to be executed and delivered. With time, Agile became popular and is now applied across organizations and is known as more than a set of practices and principles.  

But Agile is not something on its own – it has related components, and together with these components they provide for a modern business operating model. This article intends to talk about some of such related elements. 

The related elements include DevOps, Scrum, a number of Developments methods, and Kanban as a complementary tool. In this article, we will go through it, one by one. Hygger Blog does a very good job in summing them up.



Agile versus Waterfall 

Before Agile came to be, many companies used the Waterfall method. Waterfall gained this name because the phases of a project only happen once, and there is no going back – meaning that, if a mistake is committed in one phase of the project, this mistake would be carried on throughout the entirety of it. There’s no continuous feedback on it, and the user does not see or opines on the product until it is fully done. 

The issue with Waterfall is exactly this one – it is easy to have defects that were not caught and solved beforehand, resulting in dissatisfaction and extreme expenses. Agile is the opposite of that – it is a practical and fast-paced approach that fuels in communication and collaboration. 

In this article, Mondayblog highlights in what both methodologies differ. While Agile requires changes to be constant, Waterfall works well when the project scope is already well defined. Consequently, when a mistake happens, the project must start again. With Waterfall, the features of a project are not organized in priority – this gives a great margin for either failure or a total success – and the customer does not get involved as much. For these reasons, Waterfall works better if the scope is very well done, so there is no need to revisit it. 

Agile is the complete opposite in every aspect, and that is why it has solved many issues Waterfall possesses. 



Agile and Kanban 

On the other hand, Kanban introduces change by means of improvement. Created in the late 90s by Japanese company Toyota, this method focuses on the state of workflow of a project. The English translation for this word is “visual card” – hence why Kanban is usually managed with a lot of papers that gain the name of “Kanban Board”.  

A Kanban Board is a visual representation of the work being done through the use of – mainly – colourful sticky notes on a board, separated by categories: to be done; doing and done. This way, it is possible to see how the work is flowing, what needs to be finalized and how much is still left to complete. 

Kanban is a great complement to Agile. 


Now, back to its elements: 


DevOps is Agile extended beyond software – as we have covered before, development and operations came together to bring more efficiency and communication to projects. Many big and famous enterprises – like Netflix, Amazon, Nordstrom or Sony – were able to excel and get to where they are right now thanks to DevOps.  



If you’d like to know more about DevOps, check our LinkedIn page.


Scrum is a known framework for software projects. As Wrike points out in their article: “Scrum provides the rules, roles, events, tools and artifacts necessary for successfully adopting an Agile mindset.” 

Scrum is the most popular element of the Agile umbrella.  



In Scrum, tasks are placed by order of importance, and are to be dealt with accordingly. These tasks are kept in what is called the Product Backlog, and the tasks are usually named “user stories”. They can be requirements, special features or fixes that a team has to work on – a to-do list that is constantly revised and changed as priorities shift. 

For each iteration Agile has, Scrum is divided in “sprints”. And, for each sprint cycle, the selected work to be done is known as the Sprint Backlog. This backlog includes items taken out of the Product Backlog, to be done in the current sprint. During a different sprint, the team selects more items to form a new sprint backlog. 

But what are sprints? 


Sprints are timeboxes used by teams to get a set amount of work done, from the product backlog. The sprint is a Scrum event divided into different phases of development: 

Sprint Planning 

This is where the development team discusses what tasks will be performed for set amount of time. Along with that, it is defined the priority of each task, how long it will take for each one to be completed, any necessary resources for completion, or roadblocks that might come along. At the end, the backlog is created, and a goal is defined. 

Daily Sprint 

This consists of a daily – but, sometimes, weekly – meeting among team members to check on any progress and assess how the next day is going to be. This meeting has a usual duration of 15 minutes, and is also known as “Daily Scrum”. 

Sprint Review 

This stage occurs in the last day of the sprint, where the team shows stakeholders what has been done, allowing them to get feedback on their work and take note on what can be done for future sprints. 

Sprint Retrospective 

The final event is where the development team assesses what was well done and can be improved in the future – as there is always room for improvement. All of the Scrum roles take part in this phase. 

And what are the Scrum roles? 

The three most essential roles in Scrum are only three: 

  1. The Product Owner – they are the people who manage the product backlog, define the most to least important tasks, and decide when the product is final and ready to launch. 
  2. The Scrum Master – this is the mentor of the group. They coach everyone involved in their tasks, and make sure communication and collaboration are smooth. 
  3. The Development Team – and finally, the developers. They are the backbone of the entire Scrum team; performing the tasks to create the final product that will go out in the market. 



In the next article, we will discuss how to implement a great Agile team. 

No Comments Yet.

Leave a comment