Making your chosen agile methodology work – Part 1: the basics

As those who know us already know, we don’t follow any one specific methodology. After 20 years of trying to implement different agile methodologies by the book, the conclusion we reached was: it doesn’t work. At least, incredibly rarely.

The reason? In almost ALL methodologies, there is a caveat statement that says “please adapt these methods to fit your context.” The problem? None of them tell you how or what contextual elements might make you consider alternative approaches.

When does Scrum stop being Scrum? What is the most important part of the Scrum guide that needs to be followed for the purists to agree it is still Scrum? How do you adapt SAFe before it stops being SAFe? With all of the volumes of text provided, nowhere does it describe a mechanism for judging whether it is or isn’t.

Regardless, none of that really matters. Are you delivering what your customers want and need? Is it of the right quality? Are you creating as much value as possible? Are you delivering against your strategy and is your strategy working? Are you doing it fast enough to keep pace with changes in technology, competition and customer expectations?

These are the questions that are more interesting for us to explore, regardless of the applied methodology. And, that’s what VFQ Foundations is ultimately for: to help you get started on a journey of developing your own, judge your current implementation or figure out what to do to take your way of working to the next level.

That said, there is much to learn from examining each agile model. Over the next three blog posts, we’ll be taking a look at the different frameworks, methodologies and guides available out there. We’re starting with some of the basics:

Agile Manifesto

It didn’t all start with the manifesto, but this was the moment where all the people who were figuring out this agile thing came together to define its values and principles. It was the galvanizing force of the movement, and the principles are still valid today (although some would argue it’s more than just software now). It’s definitely a good place to learn about what makes agile, agile. If you’re ever in need for ideas on how to improve or determine whether you’re on the right track, take a look at the 12 agile principles.

Scrum

Probably the most-used of all agile frameworks, the Scrum methodology is one of the simplest out there, highlighting the efficacy of an organization’s product management and work techniques, and empowering users to improve on their team structure, working environment and product development cycles. It has been slightly undermined by the certifications that exist (where people get awarded for showing up and still get called a Master), but when you understand the elegance and simplicity of the framework, it’s a great thing. Because of its simplicity it often gets knocked, but there’s a saying: “Scrum helps you uncover your problems. It doesn’t always help you fix them. That’s your job.”

Kanban

Often set in opposition of Scrum, the Kanban methodology is an approach that focuses on improving workflow from any position. It’s sometimes set up as the evolutionary approach rather than a revolutionary change like Scrum or SAFe. Kanban has a solid following and many people who enter agile and don’t succeed fully with Scrum may find Kanban superior and better for their environment.

SAFe

SAFe has become the go-to method for the enterprise because it’s believed to support scale well. It has solutions for how product owners and product managers might interact, and it deals with solutions for architectural roadmaps. It is criticized as a framework that doesn’t actually lead to agility and doesn’t really deal with either enterprise problems or the mindset required to be customer focused. Rather, it puts a new method name onto some existing ways of working. With each iteration of SAFe, more complexity is added to deal with how enterprises work. As a response to that criticism, Essential SAFe was launched.

Read Part 2 of this series, as we dig into some other useful agile methodologies out there that don’t get as much attention.