Agile and Occam's Razor (2024)

Occam’s razor, the principle credited to the Scholastic philosopher William of Ockham (1285–1347/49), is that pluralitas non est ponenda sine necessitate, “plurality should not be posited without necessity.”1

Occam’s razor is often generalized (for better or worse) as “The simplest explanation is usually the best one.” Ironically, the principle now goes by many names (ex., law of parsimony, law of economy) and has varied applications to philosophy, ontology, science, economics, and software development. The signatories of the Agile Manifesto came together as leaders in an emerging field of “lightweight,”2 organizational models, implying that these models were intentionally crafted with only what was necessary. You’ve heard K.I.S.S, right? That’s another razor— and it is Principle #10: “Simplicity—the art of maximizing the amount of work not done— is essential.”3 Agile may not even be old enough to rent a car yet, but the ideas it is built upon are much older than that and have withstood the test of time.

Also ironically, if you are searching for a simple visual depiction of any of the agile org models, you’d be hard-pressed to find one that didn’t make you dizzy by looking at it. What happened? Did monetization do that? Was it fate that one thing should be built upon another, and what was once “lightweight” has become too big for its breeches? I am not putting an image here because I’m not interested in picking on any one visual in particular, but feel free to do a quick search and put your favorites in the comments if you’re feeling spicy.

Principle #10 is one of the most important Agile Principles. I have a mentor who often says, “Truth transfers.” What I love about principle ten is that it transfers to other industries, and has useful applications no matter what the subject matter is. I will say what goes without saying, which is this can be taken too far, and many philosophers have pointed that out. I bring us back to situating this principle in between two extremes, just like Aristotle would have done. Ockham doesn’t claim that there isn’t complexity, but to avoid unnecessary complexity. So yes, oversimplification is a sin, and so is convolution.

Applying Principle #10

How does one take a principle and manifest it into the day-to-day reality of an Agile team?

Think long and hard before adding a recurring meeting to the calendar. And I don’t let others do it willy-nilly either. Recycle or reuse a meeting that already exists instead.
Use your voice. Who isn’t guilty of staring at their screen for way too long, painstakingly crafting their response to an email or DM? You’re sitting there, taking care to make sure it’s not too casual or too serious, that there are not too many emojis or exclamation points, that the reader won’t misconstrue what you are saying, that no one will find it too hot, or too cold…seriously. Pick up the phone and say that thing in about six seconds.
Taking a “just enough, just in time” attitude. Don’t buy more house than you can afford right now, banking on making more money later. Don’t future-proof your software solutions for traffic you don’t have, yet keep open the possibility to scale later on as it becomes necessary. Don’t hire tons of staff and just lay them off in five years.
Ask, “What if we do nothing?” Sometimes, the best course of action is inaction. It allows time to observe a situation as it is unfolding and a path will reveal itself if given the opportunity.
Move decision-making down to the appropriate level. David Marquet made this idea famous in his book, Turn the Ship Around! It’s great— you should read it. What I like about this one is that it simplifies getting things done by not getting a bunch of people involved that have to be brought “up to speed,” who weren’t there and don’t know better than those on the frontlines.

I could probably think of other examples if I sat here, painstakingly staring at the screen for way too long. Instead, I will call this just enough and when I think of other examples I’ll publish a part two. Agile coalesced a bunch of centuries-old ideas, and understanding that foundation makes it much more trustworthy than just a bunch of guys sitting around thinking up these thoughts in a ski lodge one day 20-odd years ago. Principle #10 is one of those old ideas, and when you find ways to apply it to the day-to-day business of making decisions you’ll be glad you did.