4 ms·
My current team is facing the exact same problem. We're doing Scrum, but our team isn't nearly as interchangeable as the Scrum dogma would like. Example: some o
by gchucky 17y ago
My current team is facing the exact same problem. We're doing Scrum, but our team isn't nearly as interchangeable as the Scrum dogma would like. Example: some of us are better at UI, some of us are better at IA, and so on. So while we're all supposed to take what's next on the list, it never really works out that way, and we actually end up picking what we're most comfortable with.
I'm curious as to how other people deal with this.
- deleted 17y ago[deleted]
- mechanical_fish 17y agoWe do exactly what you do. And that's fine. A good methodology is not like SQL programming. The system doesn't explode if you don't follow every rule to the letter. In the immortal words of R. A. Heinlein, a methodology is an art that you pursue rather than a goal that you expect to achieve. A methodology is like playing Dungeons and Dragons. There are rules. You gather together, you play the game, and you generally follow the rules. But the DM is empowered to bend or break any specific rule if it makes the story better or brings the game closer to the goal. Many RPG designers have suggested that you don't even need the rules. You could just gather everyone in a room and say "okay, let's all pretend that we are elves and dwarves". And that can work. The very best storytellers can get away with this. But, in general, people prefer games with rules, even if they're very sparse and loose rules. They provide important structure, and they give you an excuse for saying or doing things that other people might not like.