Or should I ask, what are they?

Although there is this misconception to think they are the same the best way to describe it is by saying the are same same but different.

Agile Methodology provides the foundation for many project frameworks, more specifically for software development projects. Each framework has its own practice but they share the same baseline. Scrum is known for providing one specific framework based on the Agile methodology. Think of Agile Methodology as the master framework and Scrum as an alternative approach based on Agile. So technically no, they are not the same, they come from the same family and seek the same purpose but can differ slightly in the way they are executed. Scrum is though, one of the most known frameworks for software projects.

History: How Agile methodology evolves from the traditional Waterfall approach

It all starts back in the Waterfall Methodology, a framework that is useful for projects on specific industries, for example, construction, as it make sense to build a house in a certain order and you can apply the same formula over and over. Old ways of performing projects was mostly done by the use of Waterfall Methodology, where the entire project needed to be perfectly planned and just after that it could be executed. This approach though, was far from being accurate, as hardly something goes exactly as planned.

The problem arrives when people tried to replicate the same approach with software projects, in this case the execution is completely different. Software projects run differently, they work from a empirical point of view, you first try something and check if that works, you need to evaluate how is the user going to behave with the new system, how the business processes and rules will fit along other processes, how efficient could be implementing something after analysed the amount of effort in comparison to the value provided. That is why Waterfall is not recommended for software projects because you can not planned the process upfront of the discovery process.

This is when the Agile Manifesto was born

After realising all planned projects were mostly condemn to fail, a group of people decided to convey into a different alternative that were most suitable for software projects. They came up with 12 main principles that will become in the foundations of the Agile Methodology. To mention some of the most importants:

• Business partners to collaborate across the project. Ask and show for constant feedback. Direct and ongoing interaction
• No measuring success with KPI but with completed tasks using a software were everyone can transparently see
• Allow the team to self-organised. Upfront planning is theoretical. Evolving design is practical and tactical

And along with those, Agile Manifesto relies on the following values:

• Individuals and interactions over processes and tools
• Working with software over complex documentation
• Customer collaboration over contract negotiation
• Responding to changes over following a plan

Scope, Budget and Time

Traditional projects based on the Waterfall methodology are known for working based on 3 constrains: Time, Budget and Scope. However, this normally fails as you can hardly estimate these 3 constrains accurately on a software project. Particularly because they are constantly changing, especially the scope!

Hence contrary to Waterfall, Agile Methodology apply the following:

• Flexible scope
• Fixed cost
• Fixed time

Scrum: The Leading Project Methodology

Now, going back to Scrum, let’s see this in more detail. This term is appropriated from a technique used in Rugby called: Scrummage. I know nothing about Rugby but I know that Scrummage is when the team is tackled together in order to move as forward as they can while the opposed team is pushing. The concept behind is that regardless as high is the score, as long as they are slowly moving forward they will manage to get to the end of the ground, so by any yard gained, they have come closer.

Similarly, Scrum approach allows to breakdown the scope into small pieces in order to deliver the project in milestones. It is intended to avoid that after working on a project for months (or years) and seeing the outcome of the project is not going anywhere closer to what is expected, then, the project is most likely to fail. There is nothing wrong with failure as we learn a lot from it, though, it is better when we can identify failures in an early stage.

The result of this interesting story is the slogan Scrum is based on: Fail fast. If you are going to fail (and failure should be understood as lessons learned) better to do it sooner than when it is already too late. The sooner you realise something is not working, the sooner the team can find a workaround. Hence ultimately you are saying: Fail fast. Which really means: Learn fast.

This makes a huge difference and makes the learning path more effective. Instead of waiting long periods to realise is not working, by breaking into small work windows the learning cycle is shorter and more effective.

Hence they have 2 simple principles:

• Small scale focus
• Rapid learning cycles

Scrum: 3 main roles

• Product Owner (PO): focus on what needs to be done: Is a dedicated person from the business end that will guide, prioritise and inform everything about the product and the requirements.

• Scrum Master: focus on how the team is going to deliver: Is the person who manages the internal team making sure the team is under the scope with the amount of work required, so it balances the demands of the PO. It identifies blockers and try to remove them.

• Development Team: Is cross-functional. Everyone uses all skills to complete any tasks.

Scrum Events

• Sprint planning (timing): At the beginning of each sprint the PO shares the requirements and the development team selects they one they are confident they can achieve in the timeframe
• Daily scrum (Daily standups): Daily meeting so each member can show progress of their tasks, what have been completed, what’s the plan for the day
• Sprint review: Team run a Demo/walkthrough where is shown everything that was developed in the sprint. It aims to get feedback from the PO
• Sprint Retrospective (retrospective): Internal meeting to reflect on internal practices and ways of improvement

Methodologies applied to reality

Lastly, I know in the paper this sounds brilliant, but it is worth to mention how practical and useful are these methodologies in real life. Ultimately what IT companies do, is to modify these methodologies on their own ways so it can be adjusted to different industries and customer needs.

PS: I want to acknowledge that the main source of this article was inspired by the online course in Linkedin: Scrum Basics. If you enjoyed this post please give it a Like and remember, the coffee is on you!