Ask an organization how it delivers work and the answer usually starts with one of two words: Scrum or Kanban. Those two get most of the attention. They are not the whole story.
The PMI Agile Certified Practitioner (PMI-ACP)® syllabus lists more than fifteen other frameworks, methods and ways of working. That is a lot of options. Some have faded, some thrive in particular industries or regions, and some have quietly leaked their best ideas into the frameworks everyone already uses. So which ones survived, and what can they teach us?
First, a reminder of the goal. The aim is not to do a framework. The aim is to be agile as an organization. Frameworks, models and flows can help with that. None of them is the destination.
What survived
The honest answer is that different frameworks survive in different parts of the world, in different industries, depending on the kind of work being done.
Extreme Programming, or XP, is used globally. Lean, whether in product development or manufacturing, is everywhere. Some industries focus on Feature Driven Development or Acceptance Test Driven Development. DSDM still has its pockets. Crystal is rare now, though a few organizations still use pieces of it. Then there is Scrumban, which is not officially a framework but gets called one anyway.
And then there are the homegrown models. Walk into enough organizations and you will find a system that someone taught them years ago, a bespoke blend that claims to have fixed agile once and for all. Some of these work well. Many are a collection of borrowed practices that nobody can trace back to a reason.
DevOps: why two weeks and six weeks never meet
DevOps comes up constantly, and it is worth defining. DevOps brings software development and IT operations together: automation, continuous integration and delivery, infrastructure, and release. When security is built in as a foundation rather than bolted on at the end, it becomes DevSecOps.
The reason it became so popular is easy to picture. Around two decades ago, large companies were moving their development teams to Scrum. One organization proudly adopted two week Sprints. Brilliant. Then came the catch: they deployed every six weeks. Development worked on a two week cadence, operations on a six week cadence, and never the twain shall meet.
Building every two weeks and delivering every six makes no sense. The cadence itself is negotiable. Make it four weeks if that suits. What matters is that the people building the software and the people releasing it are in sync. That is the problem DevOps exists to solve: helping teams build, release, and deliver working software more often.
There is a trap here too. Sometimes an organization has DevOps because it bought the tools, or because there is a department with DevOps on the door. Having the tools is not the same as understanding the approach. It is worth asking whether the tool has quietly made the decision for you.
XP: the framework that lent everyone its best ideas
Extreme Programming (XP) was built by software developers for software development. Kent Beck and colleagues including Ron Jeffries created it with a clear focus: we are developers, so this is about developing software. That sets it apart from Scrum and Kanban, which can be applied to almost any kind of work.
XP has its own values, practices and names. There is a coach instead of a Scrum Master, a customer instead of a Product Owner, and programmers and testers instead of developers. The names differ, but much of the job is the same.
Many teams now run a hybrid often called Scrum XP. They keep Sprints, the Scrum Master, the Product Owner and the Developers, and pull in XP’s engineering practices and values alongside them.
The bigger story is how much of XP has spread into teams that have never heard of it. User stories are not part of the Scrum Guide. They come from XP. Velocity is not in the Scrum Guide and is not a Kanban concept either. It also comes from XP, along with much of the relative estimation that Scrum teams now take for granted.
Even the familiar user story template has a history. The “As a, I want, so that” format is often credited to Ron Jeffries, who was coaching at the UK company Connextra at the time. The format itself came from Rachel Davies and her team there. Imagine creating a format that the whole world ends up using.
Lean: the root of all of it
Strictly speaking, Lean is not an agile framework. It is the root that agile frameworks grow from.
Lean is best known through the Toyota Production System, and its thinking draws on W. Edwards Deming and the Plan, Do, Check, Act cycle. Manufacturers saw that lean ideas were helping them build valuable products better and faster, and knowledge workers began to ask the obvious question: why can’t we use it too?
At its heart is a simple idea: inspect and adapt at regular intervals. That principle found its way into the Agile Manifesto, and from there into every framework that followed.
The other big idea is waste. Often called Muda, and the goal is to remove it from the system. That leads to a bold claim, and a fair one. An organization that never implements Scrum, Kanban, XP or SAFe, but brings in Lean principles, visualizes its workflow and steadily removes waste, will be more agile than an organization that fakes Scrum.
Agile in HR, or HR agility?
As agility spreads beyond technology, the labels get strange. Agile in HR. Agile in sales. Agile marketing. What does agile in sales even mean?
A better framing is to put the function first: HR agility, sales agility, marketing agility. The goal is for a department to be agile, not to do agile. The question becomes practical: how do we bring more agility into our sales cycle?
Lean thinking is often the most useful place to start. Map the process. Make it visible. Look at cycle time and flow efficiency. Get rid of the waste. Otherwise the agile label is just lipstick on the front of business as usual. Applying any of these principles is better than applying none.
Scaling: why leaders love it and teams pay for it
The scaling frameworks are a world of their own. In the United States, the most popular is the Scaled Agile Framework, or SAFe. Browse agile job postings and you will see it everywhere. In Europe, Large Scale Scrum, or LeSS, is more common. PMI promotes Disciplined Agile. Scrum’s two creators each have their own: Scrum@Scale from Jeff Sutherland and Nexus from Ken Schwaber. There is also Enterprise Scrum, created by another signatory of the Agile Manifesto.
These frameworks grew fast for a reason. Scrum, XP and Kanban are designed for a single team, not a whole organization. Scaling frameworks talk about portfolio, leadership and organization design, and that is the moment many leaders lean in and say, “Oh, this is not just about the IT teams. Okay, I’ll listen.”
The trouble is the order of operations. You crawl before you walk, and you walk before you run. If your teams cannot make Scrum, Kanban or XP work, scaling does not fix that. Scale a mess and you get a bigger mess.
It is tempting for leaders to look at a big, tidy diagram that says implement this at the portfolio level, this at the program level, this at the team level, and you are agile. When it does not go well, the cost is not only money. The coaches who come in afterward have to clean up and rebuild trust in agility across the whole organization, and fewer of them are willing to take that on.
Before reaching for a scaling framework, ask what problem you are trying to solve. If the real issue is that teams are not talking to each other, something as simple as a Scrum of Scrums might solve it without the overhead of a whole new system.
Take what works, and name it honestly
The common thread is cross-pollination. Ideas move from one framework to another, and that is agility at its core. It is not us versus them. There is something to learn from each of these frameworks, and a concept from one you have never heard of may already be working inside your process.
That is why blends such as Scrumban work so well for many organizations. A blend is fine. Just do not call it Scrum, and do not call it Kanban. Give it its own name, because it is a mix you have chosen deliberately for your environment.
Any of these frameworks can help a team adapt at speed and deliver value. The work is figuring out which one fits your product, your team, your customers, your culture and your organization design. There is no one size fits all.
Most of all, understand the why. Being agile for its own sake is not the point. You are solving a problem. Do not adopt a framework because you read about it in a blog or saw it in a magazine. First understand the problem you are trying to solve, then look at the frameworks, models and ways of working that might solve it. The answer might not be one thing off the shelf.