Not signed in (Sign In)

Vanilla 1.1.9 is a product of Lussumo. More Information: Documentation, Community Support.

Welcome Guest!
Want to take part in these discussions? If you have an account, sign in now.
If you don't have an account, apply for one now.

Games and Gaming: Scrum and role-playing games

Bottom of Page

1 to 8 of 8

  1.  
    •  
      CommentAuthorMatthijs
    • CommentTimeJun 2nd 2010
     # 1
    Scrum is a framework for agile software development. Which is interesting in itself, but not the point of this specific post.

    I read the following from a scrum user - anyone else think this sounds familiar? I've done these things a lot when learning role-playing systems. And it's something to think about when writing games...

    Any time I've participated in a pre-packaged process with a label, like Scrum, Spiral, etc., things have gone way worse than when I've participated in an unnamed process that consisted of steps with rationale behind them.

    When you try to implement a prefab process like Scrum, several things can go wrong:

    1) You buy into the process, but you don't have time to write a thesis on it, so you follow the steps just because the process says to without fully understanding why. This is actually the path the people who push Scrum want you to take, which is why you are told to do artificial things such as not sit down in meetings rather than being told that it's important to keep the meeting short and trusting you to be able to do that. It's just like teaching 7th graders the FOIL method for distributing ordered pairs instead of making them actually understand how distribution works.

    2) You buy into parts of the process, but not the whole thing. But, because you have so much confidence in Scrum (or whatever) working, you don't put as much thought into each step as you would have if you were designing your own process. It fails because you are implementing just parts of someone else's good idea without understanding the implications of leaving out the parts you decided to leave out.

    3) You decide to invest enough time in understanding the process that you literally could write a thesis on it. In addition to consuming a bunch of your own time, you find yourself spending a lot of other people's time discussing the meaning behind each step. That isn't so bad. But, it can devolve into a team-wide argument over what Scrum (or whatever) really is and what it isn't, and you spend more time arguing over what fits under the label you have chosen to use and less time creating good process and documenting rationale for its existence. If this sounds unlikely, I'm only writing this because I've actually been on a team where this has happened.

    My advice is to focus on doing things that make sense for you to do. Then, write down why they make sense, and do them in the future because you know they make sense. If you are going to follow a pre-fab process, I suggest you follow "1)" above, in which you may have noticed nothing bad really happened - I just find it unfulfilling to not know why I am doing something.
  2.  # 2
    #1 sure does sound familiar! "Wax on, wax off" ;-)
    •  
      CommentAuthorWordman
    • CommentTimeJun 2nd 2010
     # 3
    I've done the apparently-called-Scrum meetings before. In my experience, the "everyone stands up" concept wasn't that artificial, it's just that "keeping the meeting short" wasn't its only purpose. The rule in our meetings was "if you see the meeting start to drift, sit down". What happened, then, was that sitting essentially provides everyone a way of silently, politely injecting a statement of "what you are talking about doesn't concern me" without having to be a dick about it. Worked well everywhere I tried it.
    • CommentAuthorRoger
    • CommentTimeJun 2nd 2010
     # 4
    I suspect this is a reflection of different learning preferences.

    Some people like "Here's the behaviour; figure out the drivers behind it on your own."

    Others like "Here's the principles; figure out the behaviour on your own."

    Yet other other people like to get the whole package at once.
    •  
      CommentAuthorRafu
    • CommentTimeJun 2nd 2010
     # 5
    This sort of reminds me of why I think The Mountain Witch is one of the best instructional texts ever.
    •  
      CommentAuthorpells
    • CommentTimeJun 3rd 2010
     # 6
    Matthijs, I don't know how far you want to go with this (we could talk about Agile and rpg in many contexts, including railroading).

    That said, about what you mentionned, but a little disclaimer first.
    I'm a project manager, been doing this for four years, and for two years I did managed important projects (over one million) using scrum. Most people do not use scrum properly.

    First off, scrum is very simple : you don't need to write a thesis about it.
    Secondly, you need to present it from the top-down. So, you start with the philosophy : http://agilemanifesto.org/. Once you get this, everything gets simplier for everyone.

    Also, the "scrum meeting" : this is just a "gadget", or an artefact, it is not a process (the process is there : http://www.didiergeorges.com/blog/wp-content/uploads/2009/06/Scrum-Overview-Diagram.png). It is not really important, and this is not what scrum about.

    Finally, scrum is a "buzz" word and is used very badly those days ...

    Back to rpg :
    - Let us start with the top-down approach.
    - Let us try not to confuse process and artefact.
    - Isn't "story games" a buzz word of its own ?
    •  
      CommentAuthorMatthijs
    • CommentTimeJun 3rd 2010
     # 7
    Posted By: pellsMatthijs, I don't know how far you want to go with this (we could talk about Agile and rpg in many contexts, including railroading).


    Please do! I think it's potentially very fruitful.
    •  
      CommentAuthorpells
    • CommentTimeJun 6th 2010
     # 8
    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
    Artifacts
    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.

    RPGs
    I'll take at look at indie vs traditional rpg using Agile as a reference.
    Fluff
    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.

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

    BW and TSOY
    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.

    BW
    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.

    TSOY
    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 ?

1 to 8 of 8

  1.