Methodology is the systematic, theoretical analysis of the methods applied to a field of study. It comprises the theoretical analysis of the body of methods and principles associated with a branch of knowledge. Typically, it encompasses concepts such as paradigm, theoretical model, phases and quantitative or qualitative techniques. A methodology does not set out to provide solutions—it is therefore, not the same as a method. Instead, a methodology offers the theoretical underpinning for understanding which method, set of methods, or best practices can be applied to a specific case, for example, to calculate a specific result.
Wikipedia
9 popular project management methodologies
Classification of project management methodologies — some are based on themes, some on principles, processes, standards, or a combination
Source: this excellent article https://thedigitalprojectmanager.com/project-management-methodologies-made-simple/
Methodology examples from my team
Over the last few projects my team has shifted from Waterfall to Scrum methodology. In the Waterfall projects we had a very simple approach that valued collecting the requirements in full early on, accurately estimating the lead time and then make a solid plan and execute it in phases. After the plan was approved, there would be little scope to adapt the plan unless absolutely necessary. All changes would undergo extensive reviews and would require change requests. In the real world this was very often the case because changes would naturally occur in projects that span years and have to deal with cutting-edge, often immature technology. The Waterfall approach, though simple, resulted in delays, confusion and a lot of stress on the management team that needed to constantly poll various teams and individuals to get the current status and monitor progress.
Scrum brought an approach that defined a set of new roles, standard meetings, and tools to efficiently, iteratively and incrementally deliver releasable features and functionality. Suddenly we had to be a self-managing team with a Product Owner (typically a senior engineer) and a Scrum Master having to deliver the right thing, the right way with extreme flexibility in feature scoping. Another big change was that the team had to be cross-functional, breaking the barriers between design and verification. Anyone should be able to work on items in the backlog (user stories/requirements) that had been defined and prioritized by the product owner and/or the system architect. The sprints are divided into a development cycle of 2weeks, during which, daily scrum meetings take place where the team reports on progress and impediments. At the end of each sprint, work is reviewed with the primary goal to determine if it passes the Definition of Done. Scrum is facilitated and served by a Scrum Master. The SM leads the scrums, sprints, demos, reviews and a “sprint retrospective” meeting after each sprint. The SM needs to ensure the team is continually delivering within each sprint’s time box while also optimizing and improving. The SM is the single point of contact for reporting the team’s status and progress. By transitioning into a Scrum methodology we were able to accelerate the team’s workflow, provide a steady feedback to the stakeholders and kept learning new things to meet the cross-functional requirements. The biggest overhead has been so far the inelastic time spent in the standad meetings.
Ioannis' blog 