Most of you have probably seen the show “Whose Line is it Anyway?”, an improvisational comedy show that has been around longer than Agile, Scrum, and likely a significant number of Scrum Masters and Agile Coaches, too. Including the original British version that debuted in 1988, there are over 500 episodes… and at least 50 of them are pretty good! At the beginning of each show, the host welcomes the audience with this description: “…the show where the games are made up, and the points don’t matter”.

Do you know what else are made up? Estimates and Story Points. We even have made-up games for estimating like Planning Poker and Affinity Sizing. And what do we do with those made-up estimates? We aggregate the story points into another made-up thing, “Velocity”. And these things can actually be okay – teams can use these made-up things as a mental exercise to help forecast when something is likely (or unlikely) to occur in the near future. That is the sole utility of velocity – as an input into considering what we plan to do next.

Unfortunately, that is not the end of the life of made-up estimates in most organizations. Velocity is one of the most abused metrics in business because too many leaders see it as a proxy for productivity. But velocity cannot tell us whether we are building the right things, nor can it tell us the value of the thing we did. Take for instance, two teams – one team estimates that 50 points will take 5 weeks to build an application that no one asked for and no one uses; the other team estimates 50 points will take 10 weeks to build an application that adds 50% more paying subscribers. Which team do you think was really more productive? It is a false assumption that getting more points done quicker automatically means more productivity in software development. Especially if the teams aren’t doing something that matters.

So if the points don’t matter, what does? John Doerr’s book “Measure what Matters” introduces Objectives and Key Results (OKRs) – a way to radiate the most important objectives to be achieved and how those objectives will be achieved. OKRs are a fine blueprint for focusing an organization to work on what matters, but they’re not the only game in town. KPIs, NCTs, customer feedback, recognition, employee surveys – all can be used to help inform and rally teams to work on things that matter. And it won’t matter how many story points it took, because those teams will be adding to the success of the organization, not just making anything as fast as possible.

Because in the end, no one really remembers how many points our teams delivered to build something with little relevance; we only remember and celebrate when teams do something that matters for the users, customers, and the organization, and even then, the points don’t matter.

As a life-long Midwesterner, I grew up with most folks calling soft drinks “pop”. Being a contrarian from an early age, or perhaps because of the influence of television, I decided to always call it “soda”, and it usually elicited a quizzical look, if not a patronizing “You mean ‘pop’, right?” and I’d smile and nod. Later on, I was delighted by the Pop vs Soda infographic that showed where regional dialects dominated – “pop”, “soda”, or “coke” in the South. In the Midwest, I was an outlier – and that suited me just fine.

What’s interesting though, is that no matter which you grew up with, you always managed to get what you wanted wherever you visited. These synonymous terms were close enough that little clarification was needed. Although, I still shake my head when I hear someone order a “coke” and then get asked “What kind of ‘coke’ do you want?”

In the Agile community, we have a much harder time with the words “Scrum” and “Agile”. These are definitely not synonyms, but in so many organizations we hear about “doing Agile”, although after some follow-up questions, they’ll usually start talking about Scrum events or artifacts. Or an institution will say that all their developers are on “Scrum Teams” and that means they’re “Agile”. If only it were that easy!

In the business world most people understand simple terms like “project”, “deliverables”, “plans”, and “process”; so when Coaches and Scrum Masters throw out “framework” and “mindset” to describe Scrum and Agile, I think a lot of people just get glassy-eyed and tune us out. We’re not wrong, but we’re also not doing a good job of describing the difference between a framework and a process.

When I teach people about Scrum, I like to compare it to another framework that we’re all hopefully familiar with – the U.S. Constitution – which establishes the rules by which the government will exist, but says nothing about what types of rules or laws will be needed, only how they should be created, executed or adjudicated by the three branches. The Scrum framework, similarly, does not describe the kinds of products we would like to create, it only establishes a set of rules for how you can get better at making the products you would like to create.

If Scrum is akin to the Constitution, then what is the Agile mindset? Here I think the comparison is to the Declaration of Independence, a document that explained why the colonies wanted to be independent from Great Britain and descriptions of the values that helped them come to those conclusions. The Agile Manifesto, similarly, explains the values that led to breaking away from a decades-long status quo and charting a new course for software development focusing on small teams, incremental delivery, and focusing on customer value.

Are these perfect comparisons? Not at all. But they are enough to help most people understand that there is a significant difference between Agile and Scrum. In the United States, there are 50 states and the federal government that all have unique constitutional frameworks, but there is only one Declaration of Independence. Scrum isn’t the only framework out there for a single team, Kanban is popular, and there are historical ones like Crystal, Extreme Programming, and DSDM. And if you look at the competing scaling frameworks, Scrum @ Scale, Nexus, LeSS, and SAFe you can start to see just how many frameworks we’re dealing with. And let’s not forget about the experimental hybrids (Scrumban anyone?) or industry models like Spotify out there making noise, too. We’ve got plenty of frameworks to choose from, but the Agile mindset, that’s the secret sauce that makes all of these frameworks soar.

Getting this right seems like a basic thing for transparency and being on the same page in our Agile Transformations. Unless you really want your clients asking for “Scrum” and then you have to negotiate and debate “What kind of ‘Scrum’ do you want?”