What is an Agile Methodology?

As I go about answering the question ‘what is an agile methodology?’, I will try to clarify some of the challenges of language that tend to get in the way. For example, is there any difference between Agile (with an upper-case A) and agile (with a lower-case a)?  And what do we mean by method, framework or methodology and does it matter?

Opinions on the above differ so I will use the concept of agility to help with the answers because it is a word that sits above all of this without being contentious.

Agility is defined as the ability to think and move quickly and easily. In the context of planning and doing work, agility embraces the concept of continual change. It is particularly valuable in an environment where some degree of volatility, uncertainty, complexity or ambiguity makes rigid detailed plans difficult to formulate and execute.

Some people see ‘Agile’ as defining a way of working while some see it as describing a way of thinking or behaving. Some even attempt to use capitalisation of Agile versus agile to differentiate between these. This alone can fuel hours of sometimes entertaining, but more often frustrating, debate about which is more important or more valuable – doing Agile or being agile?

Personally, I would prefer to focus on the common ground – recognising that thinking and doing are tightly bound. In fact, given the earlier definition of agility, especially the aspect related to responsiveness, it should not even be possible to ‘do Agile’ in the absence of thinking. Also, without subsequent action, agility in thinking has no tangible value, except perhaps learning by observation. So, any truly agile way of working needs to combine both human and process perspectives if it is to be effective.

Before sharing my view on this, it is best to say that the words method, framework and approach are often used interchangeably with methodology.

Framework is most often used in a branded context with, for example, Scrum, AgilePM and SAFe all describing themselves as frameworks. The other terms are more often used when speaking in more generalised terms about agility.

The best of the agile frameworks describe specific combinations of values, principles, processes, practices, roles, responsibilities and supporting work-products or artifacts. Values, principles, roles and responsibilities deal with the human aspects of agility, while process, practices and work-products provide the structure and mechanics for delivery.

Some of the most popular agile frameworks include:

Scrum is an agile framework used primarily in the creation of products. It has its origins in the software development space and that is where it is still used most. Contrary to common language it is NOT a project management methodology because it does not address any aspects of project management. It focuses exclusively on product delivery where it truly excels.

Scrum comprises a set of 5 values (Commitment, Focus, Openness, Respect, and Courage) strongly focused on the human aspects of agility. They describe a set of ideal behaviours that everybody in a Scrum team should try to enact themselves and support in each other. Scrum also defines three roles are within the framework:

• One Product Owner responsible for identifying and prioritising work to deliver optimum value early and often;
• Multiple Developers who self-organise to deliver valuable Increments of the product; and
• One Scrum Master who helps the entire team get the most out of the agile way of working Scrum describes.

Product delivery is orchestrated in a simple repeating cycle of development known as a Sprint. Sprints are typically short – one month or less in duration. Each cycle starts with events (short, focused meetings) to agree and plan the work. It finishes with events to review what has been delivered and to explore how both the product and the way of working can be improved. Every day there is a 15-minute Daily Scrum meeting used by the Developers to maintain a focus on delivering to their agreed Sprint Goal and adjust the fine detail of their plans accordingly.

Scrum emphasises empiricism in the control of its processes - another key human underpinning of true agile methodology. As development proceeds, the team are expected to exploit the transparency afforded by Scrum events and artefacts. Based on inspection of these, they should continually adapt what they are doing to optimise delivery of value. Transparency, inspection and adaptation are the three pillars of empirical process control.

Some people consider Kanban to be a lean approach to development rather than an agile one. While there may be technical merit to that argument, for most purposes it is irrelevant. Like Scrum, Kanban describes a way of working that is focused on delivering value early and often, encourages collaboration amongst team members and empowers them to manage the detail of their work.

One key difference between Scrum and Kanban is that the Kanban process is one of continual flow of work rather than repeated cycles. Team members pull a work item from a backlog as soon as they have finished the previous item. Unlike Scrum, that prefers team members to be cross-functional (multi-skilled), hand-offs from one person to another in Kanban are more common. The number of items of Work in Progress (WiP) is deliberately restricted, encouraging team members to collaborate to solve problems when the WiP limit is reached.

The human behavioural aspects of Kanban are guided by six core practices: Visualise the work; Limit Work in Progress; Manage flow; Make policies explicit; Implement feedback loops; Improve collaboratively; and Evolve experimentally.

As in Scrum, an ordered backlog is maintained to guide and shape the work of the developers. Unlike Scrum, planning, reviews and retrospectives are not tied to cycles of development. Analogues of these do however exist in Kanban and are typically organised to a pre-agreed cadence and include a Daily Stand-up. The table below describes the Scrum events and their Kanban analogues.

SAFe – the Scaled Agile Framework – is a bit different because, as its name suggests, it addresses a much bigger picture. It is specifically designed to scale agile practices across large enterprises.

While Scrum and Kanban are well-suited to individual teams, SAFe provides a structure to coordinate multiple agile teams, often across departments and value streams, in the delivery of complex products and solutions.

SAFe builds on foundational agile and lean principles – drawing from frameworks like Scrum, Kanban and Lean Product Development – and integrates them into a structured hierarchy. It addresses not only team-level delivery but also strategic alignment, governance, budgeting, and cross-team collaboration.

Key roles in SAFe include:

• Agile Teams (following Scrum or Kanban),
• Product Owner and Scrum Master (at the team level),
• Release Train Engineer (RTE) – an agile-styled leader for an Agile Release Train (ART),
• Product Management and System Architect/Engineer – coordinating priorities and architecture across teams,
• Lean Portfolio Management – aligning investments to strategy.

Work is planned and delivered in Program Increments (PIs) – typically 8–12 weeks long – and structured around regular cadence-based events:

• PI Planning – a large-scale, face-to-face planning session that aligns all teams on goals and dependencies,
• System Demos – that show integrated progress across teams,
• Inspect & Adapt – a structured retrospective for continuous improvement.

SAFe encourages Lean-Agile leadership, a continuous learning culture, and customer-centric thinking. While more prescriptive than Scrum or Kanban, SAFe provides a scaffold for scale, enabling organisations to maintain agility while managing complexity and alignment at the enterprise level.

AgilePM is also a bit different in that it focuses on a project rather than a product context, dealing with all the classic aspects of project management but in a fundamentally agile way. It balances all the benefits of agility with the rigor of more traditional project management disciplines.

It is particularly well suited to organisations such as in government, financial services, or other regulated industries that require stakeholder assurance, defined roles and responsibilities, and a controlled delivery environment.

AgilePM includes elements of scaling to multiple self-organising teams and focuses on delivery of value. Unlike most agile approaches, however, it focuses on outcomes rather than outputs encompassing all work needed to realise value rather than just delivering something that should be valuable.

Like any good agile framework, it includes both human and process elements, all identified in the diagram below.

Having summarised some of the most significant agile frameworks, now is a good time to return to the term methodology.

For many, methodology is simply another word for framework, but I prefer to look a little deeper into the additional value the word might convey. Many sources define methodology as “the study, analysis or application of methods”. So an agile methodology could be interpreted a little differently to a framework in this context to include a real understanding of what makes a particular framework work, and why.

In recent times some organisations seem to have become disenchanted with ‘agile’, often turning away from significant investment that has failed to deliver to promises made. Why is that? Is it because agile frameworks don’t work? Is it because too much was promised? Or is it through a lack of attention to methodology?

I have been involved with agility since its emergence in the mid 1990s implementing, adapting and even creating agile frameworks. Having experienced, and sometimes led, the good, the bad and the ugly of initiatives to improve performance through agility, I think the last of these might be closest to the truth.

As I mentioned before, attention to both the human and process dimensions of any agile framework need to be considered.  The process part is easy… Work in short bursts from a prioritised backlog of work, hold frequent product reviews during development, hold 15 minute ‘stand-up’ team meetings every day, etc.

The human part is much trickier. A real understanding of the personal and interpersonal aspects of the agile way of working is needed if the potential of any framework is to be realised. These include:

All agile approaches emphasise self-organisation (or self-management) at the team level. The assumption behind this is that those closest to the work should be best qualified to decide the best way to do it. Add to that, the need to respond rapidly to relatively minor changes in the working environment and self-organisation becomes essential to the agile way of working.  The two dimensions to this are empowerment and ownership.

Empowerment relates to the degree of autonomy and self-determination teams and individuals within teams have. It needs to balance authority around what to do, when and how, to achieve an agreed goal, with the competence to do that effectively. 

This is counterbalanced by ownership. Individuals and teams who are empowered to take ownership of their work in this way show better performance and productivity, and increased job satisfaction when compared to those whose work is controlled by others.

A good agile leader (traditionally, a manager) will therefore work to ensure optimal empowerment of their teams.

Among the characteristics of human beings that set us apart from most other animal species is our ability to collaborate to solve problems. Collaboration is fuelled by our advanced skills in communication – primarily our ability to share thoughts and ideas through language. All agile approaches have collaborative working at their heart and rely on transparency supported by clear, open, honest communication about all aspects of the work being undertaken. This is an essential requirement within an agile team and should be the default for external communication too.

This is where methodology really kicks in… One of the main causes of failure of agile transformation initiatives stems from a lack of intelligent, pragmatic application. This plays back to the all-important human foundation of agility. If you treat Scrum, AgilePM or any other agile framework purely as a set of processes to be followed you are unlikely to get much in the way of value from it.

Full success with any agile framework requires empiricism. That is, it requires ongoing transparency and continual inspection and adaptation:

• Transparency of both the approach being followed and the progress being made towards the desired objectives is essential. It is necessary to allow…
• Inspection of both of these. Specifically analysing whether the everybody involved understands the way of working and is applying the chosen framework correctly and whether the outputs and outcomes are as expected. This is necessary to allow effective…
• Adaptation. Which might also relate to adaptation in people or process.
  • People new to an agile way of working will probably find it quite different to the way they have worked previously. Both team members AND the stakeholders external to the team will probably need to make adjustments to the way they work.
  • The default processes and practices in the framework might need to be adapted for optimum results. Any adaptations that allow the team to be more efficient and effective in achieving business end-goals should be considered. With agility, there should be no fear of experimentation in this regard.

AgilePM is the first, and arguably the best framework for Agile Project Management. It describes agile project management as a flexible and iterative approach to managing projects. It is designed to address the challenges of modern, dynamic environments. AgilePM focuses on delivering business value early and continually while embracing change and uncertainty throughout the project's lifecycle. Unlike traditional methods that rely heavily on detailed up-front planning and assume a stable environment, AgilePM is built to thrive in conditions of volatility, uncertainty, complexity, and ambiguity (VUCA).

In agile projects, people, collaboration, and working solutions are emphasised over rigid processes and documentation. AgilePM integrates the values of the Agile Manifesto – with which all truly agile approaches comply – into a broader project context, expanding beyond software development to apply to diverse business projects.

AgilePM emphasises iterative development of the business solution, timeboxing of work, and frequent stakeholder engagement to ensure solutions evolve in response to real-world feedback rather than fixed requirements defined early on. But AgilePM goes beyond that. It is not limited to overseeing product development but includes ensuring value realisation by aligning resources, managing risks, and maintaining governance. The framework supports just-in-time planning and decision-making, encouraging flexibility and adaptability while still providing robust controls and accountability.

Overall, Agile Project Management, exemplified by AgilePM, is a disciplined yet adaptable approach to projects that balances agility with governance. It is especially effective for projects where change is expected, and customer value is a central focus. It helps enable business agility by allowing organisations to respond rapidly and responsibly to changing needs without compromising quality or strategic direction.

Business agility is the capacity of an organisation to rapidly adapt to market and environmental changes in productive and cost-effective ways. It emphasizes responsiveness, innovation, and customer-centricity, enabling organisations to thrive amid uncertainty and change.

Historically, the concept draws from thinkers like Alvin Toffler and Peter Drucker, who highlighted the necessity for adaptability and innovation in the face of rapid change. The term "business agility" gained prominence in the early 2000s, influenced by the Agile Software Development movement, and has since evolved to encompass broader organisational practices.

Key aspects of business agility include:

• Customer Focus: Agile organisations prioritize delivering value to customers efficiently, using continuous feedback to enhance the customer experience.
• Flexibility and Adaptability: Such organisations can adjust processes and structures swiftly in response to both minor variations and significant changes, relying on empowered employees to make informed decisions.
• Operational Efficiency: By streamlining processes and reducing waste, agile businesses achieve efficiency, often through empowering teams to take ownership of their workflows.

Business agility is not a one-size-fits-all approach; it varies across organisations and even within different areas of the same organisation. It's a continuous journey, requiring a culture that supports ongoing learning and adaptation. Implementing agile frameworks like Scrum, can be a starting point, but true agility involves a mindset shift across the entire organisation.

Ultimately, business agility provides a competitive advantage by enabling organisations to respond swiftly to market demands, innovate continuously, and deliver sustained value to customers.

Many people use the terms agile methodology, agile method and agile framework interchangeably. That is fine – it is the way of the world. That said, I believe methodology suggests a deeper dive into the why and how methods and frameworks work.

Many will achieve modest improvements in performance through a relatively ‘unthinking’ implementation of an agile framework such as Scrum or AgilePM ‘out of the box’. For many of those, that will be sufficient reward but for those sold on a dream of radical improvement, ‘living agile’ rather than ‘doing agile’ is an essential next step.  

This can be achieved by harnessing the empirical underpinnings of all the best frameworks – by exploiting transparency and learning through inspection and experimental adaptation that underpin the agile way of working.

While significant improvements can be realised relatively quickly, embracing agility is not always easy because it usually requires a change in behaviour within and around delivery teams. Optimising agility is a never-ending journey, and it is worth noting that adaption in the human aspects of the way of working rather than the process aspects is likely to unlock the richest rewards.