Post details: Agile and rpg


Permalink 02:53:15 pm, Categories: Philosophy, 949 words   English (US)

Agile and rpg

Cross posted at story-games. I've wanted to write about this for quite a time now and the subject arose at this forum, so ...

Okay, I've warned Matthijs, this is going to be some heavy stuff, but here we go. I'm going to discuss the relation between Agile and rpg. Note that I'll use the term Agile instead of scrum.
And on purpose, to reflect the initial discussion, I'm going to present you Agile in the wrong order.
Agile is most of the time presented as being opposed to the waterfall model.

Introduction to Agile

Agile uses some artifacts, among which are :
- Backlog : list of features a customer wants to implement.
- Users stories : a way to describe feature using stories (something everyone understands). Note that stories are high level description. Those are not specifications. They do not tell you how.
- Sprintlog : list of activities the team has to do to implement the features.
- Fixed time of iteration : the date of the end of the iteration if announced at the beginning and can't be moved.
- Demo : you have to do a demo of what you have done in an iteration.
- Debt : After the demo, you need to state what is left; what you should have done but is not finished. Might be features, documentation, tests.
- Scum meeting : daily 15 minutes standing meeting, at the same hour and place. Each person answer three questions : what have I done yesterday, what I'll do today, how can someone else help me.
- Poker planning : way to establish efforts needed to implement a feature. For each feature, each member uses a deck a card and reveal a single card (the higher the value, the harder to do the feature). Discuss and redo until consensus arise.
- Monopoly money : customer uses monopoly money to establish priority of features, "buying" them with an initial fixed amount of fictional money.
- Scrum master : oppose to the role of project manager (PM). A kind of referee, who challenges the group. A PM leads the group.
- Customer is part of the team : the customer is fully integrated into the team.

Now, does doing all those things means you do Agile ? The hell, no !!! In fact, each of this artifacts can be used in waterfall.

The real difference
In project management, you manage three parameters : perimeters (features you implement), money and delay.
Using the waterfall model, the perimeter is fixed and the object of the "game" is to respect budget and time. If the plan derails, you must take action to come back to the initial plan.
In Agile, budget and time are fixed, the object of the "game" is to do as much features as possible. This is a results oriented approach.

This is the first thing to present.

The values of Agile

Taken from the manifesto :
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

This is the second thing to present.

I'll take at look at indie vs traditional rpg using Agile as a reference.
Not much fluff out there, so I'll use Avalanche, my own project, as an example.
In a traditional "module", the story is presented in chapters. Chapter one, then two, then three ... Sounds like a waterfall to you ?
One of the problem with this is that if something goes wrong in chapter X, the DM has to make changes so that the group comes back to original plan, otherwise, chapter X+1, X+2 ... would become useless. You have a plan, you stick to it. This is truly a PM job in the waterfall model. The DM (PM) leads the show. This is how I see and explain railroading.

Avalanche, on the other hand, is not built that way. It is not based on chapters. There is no plan to follow. It is built for one purpose : if things derail, how can you adapt (not re-rail). Also, in Avalanche, the DM plays a role of referee, challengers. He does not lead. This is the team's show. And Avalanche is built for that purpose.

Finally, generally, those typical modules provide a lot of details; almost as for the sake of it. This would be "Working software over comprehensive documentation" : instead of trying to cover all documentation, I would suggest trying to give "working documentation" - just what is needed, no more no less.

I'm be using examples I know of ...

I do see the keys and beliefs as some kind of backlog : the themes the players wish to address, which as more value for them. And keys and beliefs do not tell you how. There is no such things in D20. You create a wizard, a warrior, so what ? What has more value for you ? Hard to tell.

I see BW as an Agile product, because of the way the rules are presented as incremental. You start with the basic rules and add the "advanced" rules in an incremental way, one by one, beginning by the ones who have the more values for you. Obviously, with d20 it's all or nothing.

I see TSOY also as Agile, but for a different reason. TSOY presents you a list of skills, keys and secrets. But, it tells you how to create your own. I don't think TSOY pretends to cover all the possibilities, so it teaches you the "recipe"; it provides you with "working documentation" instead of "all the documentation".

Finally, I think indie games really puts the emphasis over the social contract instead of the rules.

Is that comprehensive ? Is there any food for thought for you ?



Chronicles of a rpg campaign project.

March 2020
Mon Tue Wed Thu Fri Sat Sun
<<  <   >  >>
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31          


Syndicate this blog XML

What is RSS?

powered by