Ask a room of leaders how their organization chose its agile framework and you will hear a few honest answers. Someone came back from a course with a certificate. A consultant arrived with a slide deck. Or, most often, Scrum was the only one anyone had heard of, so Scrum it was!
Choosing well begins with being clear about what a framework is, what it is not, and what you expect it to do for you.
Mindset, framework, methodology
These three words get used as if they were interchangeable, and they are not.
- A mindset is what you believe. The Agile Manifesto is a collection of values and principles. It describes a philosophy and a way of thinking, and it says nothing at all about what to do on Monday morning.
- A framework gives you guardrails. It tells you what to do and why, and it leaves the how to you. Scrum tells you there is a Daily Scrum and explains what it is for. It does not tell you how to run one. Kanban and XP work the same way.
- A methodology fills in everything else: who does it, when, by what date, in which template, saved to which folder, in triplicate, for audit purposes.
So the manifesto is the thinking, a framework is the guardrails that keep you true to that thinking, and the practices are what you choose to do inside those guardrails.
The picture frame
Here is a useful way to hold that in your head. Think of a picture frame.
What goes inside is up to you. Swap the pictures as often as you like and it is still the same frame. What goes in the frame does not change the definition of the frame.
Now take one side away. Then another. At some point you are holding two pieces of wood, and whatever that is, it is not the frame you bought.
Scrum has five events and three accountabilities. That is the frame. How three different teams run their Daily Scrum can be different, and probably should be, because that is the picture. Three questions, one question, no questions at all: your call. Holding the Daily Scrum twice a week is not a picture choice. That is taking a side off!
This also answers a fair question. If a framework is a set of fixed guardrails, is it agile at all? Yes, because it was never the practice that made a team agile. A team can stand in a circle and answer three questions every morning and still not be agile. The thinking, and the guardrails that protect the thinking, are what do the work.
How organizations choose, and how they could
Left to themselves, most organizations default to Scrum, because for many people agile and Scrum are close to synonyms. Sometimes the decision is simply handed down: we are doing this, therefore you will do this.
A few questions do a much better job.
- Do you have dedicated team members? If yes, Scrum is a good fit. If people are split across five things, consider Kanban.
- Can you control the work that arrives in any given two weeks? “Yes, somewhat” points toward Scrum. “Absolutely not a chance” points toward Kanban.
- How volatile is the product? Scrum needs at least a week of stability to be worth the name. If priorities change every few days, a Sprint is too much container for the work, and a continuous pull system will serve you better.
- What matters more: delivering something every time box, or a steady flow of work? The shape of the product should drive the answer, not the org chart.
And one warning sign. If the honest answer is “the kind of work we do cannot be finished in four weeks,” the team is not ready for any agile framework yet, and no choice of logo will fix that.
It does not have to be one or the other. One team was accountable for rebuilding and launching a new website, and delivered that work with Scrum. The same team ran Kanban in parallel for maintenance, bug fixes and everything else that kept the lights on. Two kinds of work, two frameworks, one team, and it worked well.
The best choices are made by the people doing the work. Lay out what Scrum asks of you, what Kanban asks, what XP asks, and what other frameworks ask then let the team decide what fits. They will sometimes choose wrong. They will learn more from that than from being told.
Standardization is not the goal
Once a few teams are delivering, a familiar question arrives. When do we standardize? Same framework, same point system, same everything.
Not all teams are equal. They have different flows of work and different ways of working. Set them up well, give them the guardrails, and they will evolve in different directions. That is fine, as long as the work is getting done and they keep finding better ways to do it. Standardization is not the goal. Getting work done is the goal.
When leaders stop listening at the word Scrum
Talk to a leadership team about Scrum and Kanban and you can watch the room close down. Those are team words.
The Business Agility Institute Tomorrow-Ready DNA framework is written for that room, and it does meet the definition of a framework. It describes the behaviors to focus on and why, offers options, and never tells anyone what to do at eight on a Monday morning. It has five domains: customer centered strategy, human centered leadership, value based delivery, high performance culture, and adaptive operations, with 18 capabilities spread across them.
In practice, adaptive operations tends to be the lowest score. Most organizations have made peace with putting customers first, prioritizing value and building strong teams. Funding teams instead of projects, reshaping structures, and sensing and responding to change are where “we have always done it this way” digs in.
The buffet, and the ones that faded
Beyond the single team frameworks sit the scaling frameworks: SAFe, LeSS, Disciplined Agile, Nexus, Enterprise Scrum, and more. Go back further and you find Crystal and DSDM, which came from some of the original manifesto signatories and are rarely seen in their original form today. Only a handful are known to lead to agility when implemented well.
The others did not vanish, though. There were once eight or nine human species on this planet, and only one is left, but we still carry some of their DNA. Frameworks work the same way. User stories came from XP. They are not part of Scrum, yet almost every Scrum team writes them, because they are useful. Kanban does not prescribe a retrospective, but why would a team not inspect and adapt its process? Plenty of teams walk the board instead of holding a Daily Scrum. The useful traits survive.
Is that butchering the frameworks? It depends what you are changing. A user story is a practice. How you run a retrospective is a practice. Those are pictures. Coming together at regular intervals to inspect and adapt is part of the frame, and every one of these frameworks has it in some form.
There is an order to this as well. Shu ha ri describes learning in three stages: follow the rules, then bend them, then go beyond them. Change every rule of baseball and whatever you are playing, it is not baseball. The Scrum Guide calls itself the rules of the game for a reason. Implement the framework as designed, work out the kinks, inspect and adapt, and in time you may arrive at something that is truly your own. You can end there. You cannot start there. And when you get there, call it your agility framework, not your version of Scrum.
Four questions before you adopt anything
- What problem are we trying to solve?
- Priorities that change every three days.
- Customers who see nothing for six months.
- Work nobody can see.
Each of those points to different help.
- What outcome are we trying to improve?
- Which parts of which framework will help us get there?
- How will we know it is helping?
- The retrospective is one answer. Better ones sit outside the team:
- Are customers happy with the product?
- Are Sprints succeeding often enough that the Product Owner and the stakeholders are happy too?
- Has the organization started to loosen its grip because the team is meeting its commitments?
The framework is not the destination
Think of a framework as scaffolding, or as a road. On a road you can go fast or slow, turn around, even back up. The one thing you cannot do is drive off into the field.
Frameworks also resemble getting healthy. You can eat well and take every supplement on the shelf, but if you never lift anything heavier than a laptop, your bones will not get stronger. Bits and pieces are better than nothing. They are never the whole.
Every organization will build its own approach to agility, and it should. So the question to ask is not “are we following the framework?” It is “is what we are doing helping us adapt?” Happier customers, happier people and better outcomes are the destination.
The framework is only how you get there!