Frameworks and methodologies don’t matter because fundamentally they all work. Just pick one.
Honestly, it really doesn’t matter if you choose SAFe, or LeSS, or DAD, or vanilla Scrum or XP. Any of them are fine. As long as the context you’re applying them into fits the context the author intended them to operate within.
Asking which framework or methodology works best isn’t the right question.
Asking which framework or methodology is best suited to solve my particular business problem is a better question.
Asking what you’re willing to change in your organization so that you can take full advantage of whichever methodology or framework you choose is what you really want to know.
A few years ago it was popular to ask the question: “Is Agile Right For My Company?”
The answer to that question was almost always “no”.
Because, while any given company might have benefited from a more Agile approach to building products, most weren’t willing to fundamentally change anything to make Agile genuinely work in their particular context.
Here is how you decide which methodology or framework is best for you:
1. Understand what business problem you’re really trying to solve with your new methodology or framework. Just saying “I want to adopt Agile” isn’t good enough. There needs to be a real business reason.
2. Understand the benefits and limitations of all the different approaches out there. Waterfall has benefits and limitations. XP has benefits and limitations. SAFe has benefits and limitations.
3. Understand the context in which the methodology or framework was intended to operate. Scrum really only works within the context of small cross-functional teams. XP with sufficient safety in the code base. SAFe if you can fully encapsulate the value stream.
4. Choose a methodology or framework that is most likely to solve the business problem you want to solve, and make sure you’re willing to make the changes necessary so the approach will actually work in your given context.
It makes no sense to adopt Scrum if you aren’t willing to form teams, create backlogs, and regularly produce a working tested increment of product.
It makes no sense to do XP if you aren’t willing to refactor your code base, wrap it in tests, and move toward TDD.
It makes no sense to do SAFe if you’re not willing to get everyone in the same room for a planning meeting, organize around value streams, and deliver in release trains.
It just doesn’t make sense.
15 years ago, I allowed myself to get really overweight. Now I just allow myself to be a little overweight ;-) But back in the day, I dropped over 100 pounds in about a year and a half.
For folks that hadn’t seen me in a while, the effect was dramatic. Even for folks that saw me every day, it was still pretty dramatic. People would ask me all the time, how did you do it? What was your secret?
The answer is always the same. Diet and exercise. Burn more calories than you consume.
My fear is that we’re looking at frameworks and methodologies like our society looks at weight loss. We want a quick fix. We want to buy a program and have our problems melt away over night.
My reality was that, not only did I have to lose weight, I had to fundamentally change the behaviors that led to gaining that extra 100 pounds. If I wasn’t willing to change the fundamentals, there was no hope for long term success.
Agile is awesome. Agile works.
Let’s not let Agile go the way of the fad diets. Diets that really could work, but are really just a tool to help you while you make the fundamental lifestyle changes you need to make.
Adopting agile without being willing to make the necessary changes so it can actually work won’t be worth the time, money, or aggravation.
So again, frameworks don’t matter. Methodologies don’t matter. Pick what works for you, understand what has to change to make it work long term, and go about the hard work of making those changes. Anything short of that and you’ll be right back where you started.