A Comparison of Agile Software Development and Tabletop Roleplaying Games

I have a problem with Dungeons and Dragons 5th edition. It is supposed to be a
game of vivid imagination. That's what I like about it. Its many rules hold it
back, though. People sit down at the table and look at their character sheet.
They see that it is complicated. It has a dizzying array of abilities and
skills. Someone plops down a thick book in front of them. They are intimidated.

The game master asks the player what they want their character to do?

The player looks down at their character sheet, scanning the numerous abilities
and skills. Right away, their imagination is gone. They are now thinking about
the **rules**. The scope of things they believe their character can do is
limited. They will only consider the options that are written down for them.

This is a huge problem if you want to encourage story-driven games and player
creativity. If such things are your priority, you have to switch to a
rules-light RPG. These systems have barely any rules at all. They define just
enough to get you going. The idea is, if you run into a situation where there
isn't a rule for something, you just figure it out. You have a whole team of
smart people. You don't need a rule for everything. This encourages imaginative
gameplay. It allows people to get into a space where they can think creatively.

Agile Software Development is the same way. It, too, has a number of different
implementations. Some of them are very heavy on the rules and procedures. The
authors attempt to legislate every possible contingency.

Here's my problem: If you complain about a rule you don't like, advocates will
throw up their hands and say, "Oh, you don't have to use that! It's just about
the story/productivity! You can pick and choose what work for you! Do what fits
your team!"

This, to me, feels super disingenuous. If you publish a huge book of rules, you
know that some rules lawyer is going to memorize them all, obsess over every
detail, and say things like, "Actually, on page 37, it says that we should doing
blah blah blah. This is rules as written in the book!"

Nothing matters but what's written in the book. People are like this. That
attention to detail is what makes us good at software.

This is about the ivory-tower idealized view of how a complex system of rules
and procedures is meant to be used versus how such systems are actually used on
the ground in the real world. Some people will always hyper-focus on the rules
as written. They won't care about the spirit of the rules.

I would argue that the reason people keep "getting Agile wrong" is because they
are mesmerized by the dizzying amount of procedures and rules. Just look at
this SAFe chart as an example.

https://framework.scaledagile.com/#big-picture

I don't think modifying a large framework to your own taste is a good idea. I
believe that a lighter system would work better. It makes people feel more
welcome to make their own changes. My reason for this argument is human nature.
People need to consider what humans do when presented with tons of rules. They
follow them blindly.

I would be remiss if I didn't link my favorite article on SAFe.

https://seandexter1.medium.com/beware-safe-the-scaled-agile-framework-for-enterprise-an-unholy-incarnation-of-darkness-bf6819f6943f

This is what I had in mind when I wrote this article. Although, it could
certainly be argued that SAFe is not Agile at all.

In particular, this quote is interesting:

> A key part of SAFe that I have not yet touched on is the aggregation of
> existing concepts like Scrum, Kanban, Lean Product, Lean UX, and DevOPs.
>
> If you're unfamiliar, I'd suggest exploring each concept independently over
> time rather than all at once. Many are valuable themselves, but SAFe doesn't
> do a great job at actually synthesizing them and can sometimes add confusion.

This reminds me of D&D games where every sourcebook is allowed and players end
up creating broken characters. The analogy isn't perfect, but the general idea
is that the more disparate systems you jam together, the more complex a thing
gets and the less willing its participants are to question it or to think
creatively at all.