Some years ago, you could say “Scrum is agile” and ask “is agile Scrum?”. Now we know there is more flesh on the bones.
At this moment there are more than fifty known and less known agile approaches, frameworks or methods available. Agile is so much more than a single methodology—in fact, you could argue that “agile methodology” in and of itself doesn’t exist at all.
An overwhelming majority of project professionals say that their organization has implemented hybrid project management methodologies, many of them combining agile principles with other methods like the more conventional Waterfall method.
So, how do you understand the difference between different agile management approaches, and how do you decide which agile process you should follow?
In this article, I look at those agile frameworks that are beneficial for the project manager who is working in the digital transformation world. This article will help you, as a project manager to understand that there are many agile flavors and to choose which way of working suits your project. This means I will not go into lesser-known, obscure approaches, so I won’t go into great depth on frameworks tied to engineering, program, portfolio, or culture-related frameworks.
List of Agile Methodologies, Frameworks & Approaches
In this article, I touch on the following methodologies, frameworks, and approaches which are all rooted in the agile principles.
- Design Thinking
- Agile Project Management (AgilePM)
- PRINCE2 Agile
- PMI-Agile Certified Professional (PMI-ACP)
- Project Half Double
- Agile Program Management (AgilePgM)
- Scale Agile Framework (SAFe)
- Large-Scale Scrum (LeSS)
- Scrum at Scale (S@S)
- Spotify Model
- Scaled Agile Lean Development (ScALeD)
- Agile Fluency
- Open Space Agility (OSA)
- Agility Scales
- Disciplined Agile (DA)
- Toyota Production System (TPS)
- Agile Digital Services (AgileDS)
- Management of Portfolios (MoP)
- Standard for Portfolio Management (SfPfM)
- Agile Portfolio Management (AgilePfM)
- Evidence-Based Portfolio Management (E-B PfM)
- Bimodal Portfolio Management (Bimodal PfM)
- eXtreme Programming (XP)
- Acceptance Test Driven Development (ATDD)
- Test-driven development (TDD)
- Behavior-Driven Development (BDD)
- Feature-Driven Development (FDD)
- Experiment-Driven Development (EDD)
- User Experience Design (UX Design)
- Agile Business Analysis (AgileBA)
- Continuous Integration/Continuous Deployment (CI/CD)
- Agile Modeling (AM)
As I said, I don’t go into depth on the approaches that are geared towards the portfolio-level, engineering-level, or organizational culture. So, I’ve put in bold the methodologies that I do cover in some depth in this article. For others, you can find more detail in my blog.
A Bird’s Eye View Of The Agile Forest
To get a first impression of the different approaches, I try to bring some structure in the jungle to approaches, methods and frameworks. In Figure 1, which I call my “bird’s eye view on the agile forest”, I position the 44 best-known agile approaches in a structure. This picture is based on a simpler version in the book Scaling Agile In Organizaties that I published in 2017.
Below, I break down the structure of the picture.
In the dark blue boxes, we see agile approaches that are only applicable in IT-focused organizations. All other approaches are in light blue, meaning that they can be used within IT and non-IT-oriented organizations.
The approaches, frameworks or methods are positioned within two main sections: the “One-time programs/projects” sections or the “Business as usual/indefinite”. Some fit within both, so they span the entire area.
Then, the approaches, frameworks or methods are clustered based on which level they generally operate upon: engineering, team, programme or portfolio level. Even though it’s light blue, the team level is really applicable in both IT-oriented and non-IT-oriented product development, services development and operations. Meanwhile, the engineering level focuses specifically on IT-oriented product development.
I also cluster some methods based upon their target: are they product-targeted, team-targeted, or culture-targeted? The business as usual or indefinite umbrella frameworks that are used more permanently (both product-targeted and team-targeted) focus specifically on IT and product development. The culture-targeted approaches help organisations to increase their agility.
A Few Caveats
1. I haven’t mapped all the known approaches, frameworks and methods in this figure.
And, to be honest, I think there is a lot of duplication, and it’s likely that commercial drivers play a role, too, to “develop” the next kid on the block without added value in comparison with the existing approaches, frameworks or methods.
2. The line between IT and non-IT applications is not set in stone.
For instance, the one-time, temporary projects and programme frameworks and methods are suitable for both IT and non-IT.
Overviews Of The Agile Methodologies That Digital Project Managers Should Know
In this section, I’ll give an overview of some of the most important methods and approaches that digital project managers should know. All mentioned frameworks or approaches embrace the Agile Manifesto and use some form of Scrum, but they differ depending on factors such as whether they are team- or product focused, what level they’re applied on, and more.
Get an idea of how these methodologies fit into the big picture below.
When teams start working with Agile, Scrum is often chosen. An obvious choice, but the question is whether this is always the right choice. In a Roman Pichler blog post, the link was made with the life phase of a product.
Scrum (positioned at the team level in Figure 1) is described by Ken Schwaber and Jeff Sutherland in their Scrum Guide.
During the first phase of a commercial product life cycle, in which the commercial product is finally put on the market for the first time, the uncertainty is high, and the focus is on on-time delivery of the first market-ready product. A deadline has been set and that date must be met. During this phase, the focus of the entire team is on delivering a commercially marketable product. This development is perfect for Scrum with its iterative approach, being able to deal with uncertainty and working together on the result (the commercial product). Optionally, a second launch can take place with a next set of important functionalities, so that eventually a mature product is put on the market.
In addition to Scrum, on the team level, you will see frameworks such as Kanban (as described in the Kanban Guide for Scrum Teams), or its relatives Scrumban, DevOps, and BusDevOps. The team level can be used both within the IT environment and the non-IT environment.
During the further course of the product lifecycle, we see the amount of uncertainty and requested changes decrease. At this moment you can make good use of Kanban. In a continuous flow, User Stories can be picked up, developed and deployed one by one by individual team members.
In case there is only one permanent agile team to develop and maintain a product or service, and the team uses Scrum or Kanban with a Product Owner who prioritises the product backlog, you can ask if there is a need for a project manager? I would say no, leave that team alone.
DevOps, (Bus)DevOps, and CI/CD
If one looks at the often difficult transfer to production environments, the time-to-market can be shortened by properly arranging the transfer and reducing the number of transfer errors when development and production teams are merged, and the integration testing and deployment are automated (Continuous Integration and Continuous Deployment CI/CD). In this way a DevOps team is created.
Scrumban is the combination of Scrum and Kanban. In the first instance it was intended as a transitional model to switch from Scrum to Kanban and let the team experience Lean- and Kanban concepts. Nowadays it is an approach in which the team has chosen to work according to Scrum with Sprints, but to use the Kanban system to continually view and improve its working method to optimize the flow of units of work (e.g. User Stories).
Scaling Up Towards Product Or Program Level Agile
In order to be able to use an agile way of working in an organization of some size, just having individual agile teams is in most organizations not enough. There are examples of organizations who have or are in the middle of creating a loosely coupled architecture based on micro services (e.g. Bol.com in the Netherlands). Each autonomous agile team manages one ore more micro services.
However, in most of the organisations the agile way of working needs to be scaled up, and where possible the overarching alignment needs to be taken care of. This can be done by a project manager or by institutionalizing the coordination. When institutionalizing the coordination the project manager disappears but many tasks of the project manager role are fulfilled by others (e.g. the integration team in Nexus, the Release Train Engineer and the Product Manager in SAFe, etc).
To institutionalize coordination, management of dependencies and integration between the different permanent agile teams within “the run-the-business” or “business-as-usual” side, there are various frameworks available. Here they are:
Nexus, as described in The Nexus Guide, is a framework for developing product or software development initiatives with three to nine Scrum Teams, in Sprints of up to thirty days. Nexus is the answer of Ken Schwaber, one of the founding fathers of Scrum, to the scalability of Scrum. It requires more than just the will and the agile behaviour of the different Scrum Teams to work together to deliver an integrated product. Nexus is based and builds on Scrum and the rules and roles formulated in The Scrum Guide. We can position Nexus over the team and program levels of SAFe, but it does not offer provisions on portfolio level.
Scrum at Scale (S@S)
Scrum at Scale (S@S, developed by Jeff Sutherland and Alex Brown) is a modular framework. The starting point at S@S is that an all-encompassing one-size-fits-all framework is not possible, but that every time we have to look at scaling of the underlying Scrum principles. The framework can be tailored for your own organization by adding the needed S@S modules. S@S builds on the well-known Scrum framework. By analogy with Nexus you could therefore say that S@S is the answer from Jeff Sutherland, next to Ken Schwaber, the other founding father of Scrum, on the scalability of Scrum.
Large-Scale Scrum (LeSS)
Large-Scale Scrum (LeSS, developed by Craig Larman and Bas Vodde) is an agile framework with rules, based on principles and doing experiments. The LeSS Company offers a freely accessible knowledge base (less.works) containing the integrated approach, principles, process descriptions, definitions, roles, examples, et cetera, for large-scale, mainly IT-related, product development. Transparency is also a key concept within LeSS. The first version dates from 2005 and since then, work is constantly being done on the use and further development of LeSS.
Scaled Agile Framework (SAFe)
Scaled Agile Framework (SAFe, developed by Dean Leaffingwell) is a framework to enable scaling up of agile teams in order to create better systems, create higher employee engagement and make use of correct cost considerations. This is the mission of the scaled agile organization and of the founder of SAFe, Dean Leffingwell. The scaled agile organization offers a knowledge base that is freely accessible to everyone (www.scaledagileframework.com) with an integrated approach in the form of process descriptions, definitions, roles, examples, etc. for Lean / Agile product development. SAFe is based on five core competences: Lean-Agile Leadership, Team and Technical Agility, DevOps and Release on Demands, Business Solutions and Lean Systems and Lean Portfolio management.
Looking back at Figure 1 at the “Business as usual/indefinite” section, we can see the above methods of SAFe, LeSS, Nexus, and S@S in the product-targeted section. They all relate to examples where multiple teams work on a single complex product or value stream (product-targeted frameworks).
There’s a division between product and team targets, namely on the basis of cooperation between teams. In other words, can the individual teams work autonomously (with a team focus) or do they have to work together to deliver a new or modified product (with a product focus).
Additionally, several approaches (not listed in the figure) make a distinction between products that need cooperation between a maximum of nine teams (in total the team of teams must not exceed the Dunbar number of 125-150 people) and a team of teams of teams (e.g. SAFe large solutions, Nexus+, LeSS Huge). An example of this in the real world occurs at Philips, a Dutch medical equipment supplier who uses SAFe and works with 20-30 teams on a single product.
The Spotify Model and ScALeD
Looking to the product-targeted frameworks, we see approaches that support IT departments maintaining dozens or hundreds of applications or services. In these settings, the dependencies between the teams are minimal (multiple team targeted frameworks).
Here, the Spotify model (developed by Henrik Kniberg, Anders Ivarsson and Joakim Sundén) can be positioned, but also Scaled Agile Lean Development (ScALeD, developed by Peter Beck, Markus Gartner, Christoph Mathis, Stefan Roock and Andreas Schliep).
For both groups, there are essential interfaces between the teams in areas such as data integrity, security and architecture that may not or sometimes will ask for coordination when implementing changes. In this group I don’t expect to find a project manager. Because these teams are autonomous, I believe that a project manager will not add value.
On the left side of Figure 1, we see the one-time projects frameworks. These are frameworks where the role of project manager is needed. Most of them are a further development of the more traditional project management frameworks:
Agile Project Management (AgilePM)
Agile Project Management (AgilePM, which is derived from DSDM) comes from Agile Business Consortium. It’s a method by which different, possibly permanent agile teams and non-agile teams are coordinated for the duration of a project.
The AgilePM method for managing agile projects consists of a framework, comprising a philosophy, derived principles and four building blocks people, processes, products and applications.
The AgilePM philosophy is that every project must be aligned to clearly defined business goals and must focus on the early delivery of products that provide real added value to the business organization.
PRINCE2 Agile (derived from PRINCE2 from AXELOS) includes both the existing PRINCE2 as the agile way of thinking. The agile way of thinking must be seen as agile behaviour, concepts, frameworks, focus areas and techniques. The existing PRINCE2 principles, processes and themes remain, but should be tailored using the agile way of working and the project itself.
PRINCE2 Agile searches for the best of both worlds where the emphasis lies in the use of PRINCE2 within project direction and project management and an agile approach in the product delivery. Depending on the project situation you can apply more or less of the PRINCE2 or agile way of thinking.
Here’s a short video I created about PRINCE2 Agile.
PMI Agile Certified Practitioner or PMI-ACP (in addition to the PMBoK Guide of PMI) is not a stand-alone framework, but it is a certification based on different books (and the frameworks and underlying techniques described therein).
Within PMI-ACP, seven domains are identified, each of which is subdivided into a number of task areas. The domains are Agile principles and framework, Value-driven delivery, Stakeholder management, Team performance, Adaptive planning, Problem detection and solution and Continuous improvement.
Project Half Double
Project Half Double is run by a community of dedicated project management practitioners who are passionate about what they do. It was co-created in an iterative way by a community of dedicated project management practitioners.
The methodology is based on the three building blocks to achieve double the impact in half the time: impact, flow, and leadership. Impact is all about stakeholder satisfaction. Flow represents high intensity and frequent interaction in project work, learning and impact. Leadership shows that a leader you must embrace uncertainty and make the project happen. Local translation is another key component of the methodology, and is intended to account for the fact that you have to tailor the methodology to the needs of your organization.
Disciplined Agile (DA)
Disciplined Agile (DA) covers both one-time projects and programs as well as business as usual product development. The DA toolkit is a process decision toolkit that describes how agile software development, DevOps, IT, and business teams work in enterprise-class settings.
Disciplined Agile (DA) offers a portfolio process in which, in addition to projects, a number of “business-as-usual” aspects are taken into account, such as the permanent teams and the operational management of existing IT solutions.
Agile Digital Services (AgileDS)
Agile Digital Services (AgileDS) is there for the delivery and the continuous operations, support and maintenance of that service (permanent agile delivery team, using the product/service lifecycle).
Learn More About Agile Methodologies, Frameworks & Approaches
Already more than 50 agile approaches, frameworks and methods and it’s still growing. The figure in this post can help you in your agile approach selection process. You can find many more explanations of agile methodologies, especially of the engineering-related portfolio-level agile methodologies that I don’t cover in-depth here, in my blog.
However, it cannot be said enough: Do not act dogmatically, see an approach, framework or method not as a panacea that can be implemented out of the box.
Common sense helps, too, in achieving greater agility. In fact, the best route to becoming more agile is probably a simple approach of dividing your products and services into smaller autonomous parts and have them supported by an individual team.
Also Worth Checking Out: How Solid Program Management Helps Organizations Scale