I had gone to the apartment where my ex-girlfriend lives with her parents to find her and get her back. After four months of living together, she had moved out a couple of weeks earlier, and I was desperate to find her. Unfortunately, she wasn’t there, and as things got heated with her parents, her dad stepped up on me, so I shot him in the shoulder. Shortly thereafter, the police showed up. I guess I should have expected that, but it took me by surprise.

The police had a negotiating team with them who called me to try to sort the situation out. They kept trying to get me to release her dad. I probably should have let him go, but I was scared, and felt like I’d lose my leverage without him there. Besides, they kept promising me things and then going back on their word, so I wasn’t too inclined to cooperate with them. About four hours into the standoff, my girlfriend’s sister escaped out a window, and I panicked for a while, boarding up the apartment and trying to make sure that nobody could get in the same way she got out. But I guess I knew at that point that it was only a matter of time. After repeated requests, they finally put my lawyer on the phone, and after talking with him for a while, I decided to surrender. I stepped out of the apartment with my hands above my head about 6 hours after the whole ordeal began, and was immediately arrested. I’ll be going to trial in a few weeks.

None of this, of course, actually happened.

This was all part of a training exercise for various police negotiating teams, and I was only playing the role of a hostage-taker. My dad is an expert in such matters — he literally wrote the book on crisis management– and helped to organize this training exercise. When he was looking for participants, he sent me and my brother a note saying “I need actors to play emotionally unstable, biploar, hostage-takers on the 10th of December (Saturday). Of course, you two came to mind, immediately.”

While I wasn’t actually holed up in an apartment, I did spend about 6 hours on a phone, talking with various negotiators from the New Braunfels team and giving them a chance to exercise their skills. It was fun, but exhausting, to play the role of a frightened, intransigent, irrational man-boy for that long. The negotiating team did a great job, maintaining their cool while I was being quite bellicose and disagreeable at times, and working hard to establish rapport and empathy without validating the destructive actions my character had taken. I was nasty enough that I felt the need to, once the exercise was done, apologize to them all and individually shake their hands. To their credit, none of them took advantage of the opportunity to shoot me — a homicide that, under Texas law, I’m pretty sure would have been considered justified at that point.

Thanks to Dad for the opportunity to be a part of the shenanigans, and to the whole crew involved for putting together such an interesting day. It seemed like the teams got something good out of it, and my siblings and I certainly got a fun story to tell. And delicious breakfast tacos. (Ironically, feeding me tacos is just about the best way to keep me from taking hostages in real life, so the crisis would have been pretty short-lived in reality.)

Since I invested a fair bit of time in writing the adventure, and there seems to be a dearth of free material out there for GURPS, I decided to go ahead and release it for other people to use. While it’s designed with GURPS in mind, should be able to be adapted for other RPG systems pretty easily. And while it’s fairly fleshed out, I haven’t spent the time to format and polish it up to a professional level. Thus, gamemasters should be sure to spend a bit of time with it before trying to run it to make sure they know how they’re going to handle various situations when they arise.

The adventure is released under a Creative Commons license. You can use it and adapt it, but not make money off of it or fail to credit me if you create derivative works. It also comes with many of the NPCs already fleshed out in the excellent GURPS Character Sheet software, and the documents available in Pages and PDF formats.

Without further ado, here it is:

ZombieTown

If you take a look at it, please drop me a note and let me know what you liked or didn’t like about it. I’d sure love the feedback, and would be especially tickled to know how it’s received if someone else runs it with players. Have fun!

This is great. But it gets better. In order to expand the scope of the class from the 200 people they’ve been teaching in person, the instructors will be using AI software to grade homework, aggregate discussion questions, and generally mediate interactions with students. Why bother? Because, to date, over 100,000 people have signed up for this course, and the enrollment is showing no signs of slowing.

The use of the software to scale allows students to get feedback on their individual homework assignments and quizzes, to interact with the instructors, and to get a ranking in the course compared to both other online attendees and the students enrolled at Stanford — feedback that would be utterly impossible to provide to that number of people if the instructors didn’t have the help of AI. It will be fascinating to see how the concepts taught in the class are used to administer it.

I’ve been intrigued by AI ever since reading Gödel, Escher, Bach way back when I was a teenager (and before I was really equipped to follow all of it). More recently, I’ve been increasingly interested in robotics and the applications thereof, which rely pretty heavily on some of the AI concepts that are in the syllabus for this class. And, of course, I have an enduring interest in games, which are probably where AI is used most often in modern computing.

So am I signing up? You betcha. And I hope some of my nerd friends will too, so that we can compare notes along the way.

This is one of the reasons I love living in the future: we have access to information and learning that is unparalleled in human history, opportunities to sit at the feet of experts that we could only have dreamed of even a decade or two ago. And wonderfully, access to an amazing education is increasingly being divorced from access to money, creating remarkable opportunities for people who are ready to work at their own learning, regardless of their backgrounds. I fully expect to be bested in the course rankings by smart 14 year olds in India and China, and will be excited to see it happen.

I’ll post some updates and reflections along the way, and possibly homework assignments too if they turn out to be interesting. This should be a fun ride.

(Thanks to Singularity Hub for the tip-off.)

• Player one selects a starting word.
• Play then alternates between player two and player one, each trying to create a new word by adding, subtracting, or changing a single letter.
• Once a word has been used once, it’s off-limits — you can’t use it again in that session.
• The player who is unable to come up with a valid move loses the round.
• Valid moves are limited to words in the dictionary. No proper nouns may be used.
• Special starting rule: if player two can’t think of a valid move from the starting word, then player one must be able to make a valid move from that word, or she loses the round. (This prevents player one from starting with “antidisestablishmentarianism”, for example.)

Example play session:

1. P1: CAT
2. P2: COAT
3. P1: COATS
4. P2: COTS
5. P1: CODS
6. P2: CODA
7. P1: CODE
8. P2: CODED
9. P1: CODES
10. P2: MODES
11. P1: MODEL
12. P2: MODELS
13. P1: YODELS
14. P2: YODEL
15. P1: can’t think of anything, so P2 wins the round

Try it out, and let me know what you think!

Most agile teams (at least in the literature) are focused on a single project, and have multiple people working together to get that project done. We, on the other hand, do all the development work for Texas State University’s Learning Management System (about 32,000 users), Content Management System (287 sites at current count), an Event Calendar system, the University iPhone app, a reservation system for training classes, a custom web content caching system, various custom-built content management systems for accreditation and regulatory compliance, and a bevy of internal tools — all with 6 people.

Needless to say, I’m very proud of my team.

Prioritizing the time of six people when we have ongoing responsibility for more than twice that many projects is, however, a daunting challenge. Our approach for a number of years had been to set release milestones for each project, to do release planning meetings to determine what should go into a given release based on our Planning Poker estimates, and then to try our best to get the work done in time.

This approach had a few problems:

1. Release planning meetings were long and boring. We would walk through the list of unresolved tasks for a given project one by one to see if anyone wanted to prioritize that task. 90% of our time was spent saying “Ticket #666: add a green widget to the defrobulator. Anyone interested? Anyone? Class? Bueller?” (Only to have Bueller pipe up three tickets later: “Can we go back to ticket #666 for a minute?”)
2. It was easy for people who had an interest in one project to commit 100% of the development team’s time to that project, while folks who were keen on another project would commit all of our time to that project as well. Our planning process didn’t reflect the fact that all the projects were competing for the same resources.
3. If we finished all of the tickets for a release early and had extra time (a pretty rare problem, admittedly), we didn’t know what to work on next.

So a few months back, I decided to try an experiment. I got the stakeholders for all of our projects in a room together, gave them each 10 pennies, and explained to them the rules of the game:

“Today you are going to help the development team set our priorities. You each have 10 pennies, which represent tasks you can vote for. In order to vote for a particular task, write it on an index card, put that card in the middle of the table, and plunk down as many of your pennies as you’d like on that card. You can use all of your pennies on one task, or spread them among as many tasks as you like. Also, I encourage respectful argument. Try your hardest to persuade the people around you that they should put their pennies on the tasks you like as well. When we’re done, the number of pennies on a task will help determine its priority for our team.”

Good natured chaos ensued for the next 30 minutes as we wrote cards, passed them around, combined them, discussed the relative merits of the tasks ahead, bumped into each other as we moved around the table, tried to figure out what the heck some of the cards meant, and generally made a mess of the conference room we were working in. When we were done, we had a big, unruly pile of index cards with big, unruly piles of pennies on each:

After the meeting’s conclusion, the dev team took another 15 minutes to count the pennies on each card and put that count into a special “Bounty” field in our ticketing system, creating new tickets as needed. (We use “bounty” and “pennies” interchangeably.) When I was done, I told the system to sort our tickets by bounty, and suddenly had a prioritized list, across all of our projects, of what tasks had the most business value. Beautiful!

Task List Sorted by Bounty

Of course, the number of pennies on a given ticket doesn’t directly determine the order in which we work on things. We also factor in the estimates for a given task we’ve come up with individually or during our Planning Poker sessions. One can divide the pennies by the estimated hours to get a “bang for the buck” rating for each of the tickets — a much more useful way to prioritize one’s work.

I don’t like to assign tasks to people on my team directly more than necessary. I find people to generally enjoy work much more when they are able to make their own decisions about what to spend their time on. On the other hand, I do want us as a team to provide the most real value we possibly can to our various customers. Since the penny game provided us a “here are tasks with business value” list, I decided to provide a couple of incentives for folks who were completing those tasks:

1. I took a bizarre southwestern style pot that I had sitting around, labeled it the “Pot of Honor”, and told the team that it would be filled with candy and awarded to the team member each week who managed to complete tasks worth the most pennies during that span. Battling for the dubious honor of having this homely artifact rest on one’s desk for the week provides some silly, low-level competition and recognition for individuals.
2. I set the team a collective, cumulative goal and told them I’d take them to lunch when they reached it. When we tally pennies for the awarding of the Pot of Honor, we also add up the number of pennies the whole team has completed and add them to a running total. Progress is noted on our work-area whiteboard, so we can all see how close we are to getting to have free food.

The Pot of Honor

I’ve also made space on the whiteboard in our team area where we have our daily stand up meetings to put up the “Top 10″ list of tasks that have accumulated the most pennies to help maintain focus on those high-value items.

The next time we played the penny game, a month later, it went much more quickly: we already had cards on the table from the last meeting, everyone had a better idea of what we were doing, and some folks had looked through the tickets in advance to see which tasks they wanted to support. I was surprised to see that, as we got more practiced, we were able to finish the entire exercise in about 20 minutes. We simply added the new pennies to the existing bounties in the ticketing system, making them increasingly juicy as they got older and people still had interest in them.

We’ve been playing the game for a number of months now, and I count our experiment a solid success. Advantages it has provided for us:

1. Prioritization is way more fun and engaging. It also goes considerably faster than all of our individual release planning sessions did.
2. The development team always has a clear idea of what our business needs are, and which of our tasks will provide the most value.
3. Stakeholders cannot say “everything is top priority”, but are forced to choose where to allocate their pennies. The finite scarcity of pennies reflects the limits on developer time.
4. Individual developers can exercise a good deal of autonomy and choose their own tasks while we still, as a team, deliver on the things we need to.
5. There are a number of tasks that, while people say they are important, apparently do not merit the expenditure of a penny. As these persist for a sufficient period of time without accumulating any pennies, we can close them as not really being a high priority. (We can always reopen them later if someone decides to spend a penny to raise them from the dead.)

We’ve introduced a few refinements as we’ve gone along: Because some of our systems have tens of thousands of users, it’s ill-advised to get all of the stakeholders in a room at once. To account for this, we give the support staff extra pennies to distribute as proxies for the absent users. We’ve started writing project names and ticket numbers on the index cards to make it easier to correlate them to our ticket system. We’ve begun bringing as many laptops and iPads as possible to the meetings so that people can see the details on the various tickets in question. We now add a penny to each task whenever a user request comes into our support team.

I should note that during the time I was designing this process, I was also reading through Total Engagement, and consciously built in many of their 10 Ingredients for Games: Feedback across a range of time scales (completion of individual tickets, weekly discussion of bounties cleared, longer-term goal of team lunch), Reputation (the awarding of the Pot of Honor), Marketplaces and Economies (the game itself is a market to “buy” the development team’s time), Competition Under Rules that are Explicit and Enforced (there’s no ambiguity about how many pennies are on a ticket or how they’re assigned), Teams (working toward the common lunch goal), and Time Pressure (weekly tallies of points, implicit time pressure of not wanting to be the last person with pennies left to spend while everyone else sits around). I think these elements have been critical in making this a more engaging way for us to do things.

So, if you’re facing a similar challenge with more projects than you have people, feel free to swipe any of these ideas that look helpful. I hope they’re of some use to you. If you do give the penny game a try, please post here and let me know how it goes. Good luck!

Teasing aside, it’s an interesting concept: allowing people to check-in on various websites and engage with the content there in various ways to earn credit. I’ve added it to the site here; feel free to play around with it if you’d like to see how it works. Just click that little “Earn Mojo” tab on the right to get started. (Though given how infrequently I get around to posting, if any of you earn the “365 Days in a Row” achievement, I’ll be forced to come over there and cut off your internet privileges. Don’t think I won’t.)

Is it faster to New York, or by bus?

Jane McGonigal gave a terrific talk at TED called “Gaming Can Make a Better World”. It’s well worth the 20 minutes it takes to watch:

Additionally, I’ve started reading Total Engagement: Using Games and Virtual Worlds to Change the Way People Work and Businesses Compete. It covers the authors’ experiences in this area, starting with poolside conversations and ending up with forming a company around these ideas. It’s a good read so far.

Based on these, it looks like the invasion of games into the workplace has the potential to create some important productivity gains and is already underway. It should be fun to see what the next decade brings.

The session went well: I got to use the GM’s Screen I received for Christmas, the players got through a little bit more than I expected them to, and found the dungeon guardians less of a challenge than I’d thought they would, due mostly to Liam’s somewhat unbalanced combat specialist character. Kathy very graciously kept us all supplied with food and drinks throughout the 6 hour long play time.

One interesting thing I noticed this time around was the marked difference in how the younger folks and the adults approached the game. Jason was playing as Gront the Dwarf, who would be a familiar sort of figure for anyone who saw John Rhys-Davies’ version of Gimli. Chris’ character went by the nom de guerre Jimmy Softshoe, and had the interesting quirks that he only referred to himself in the third person and he hated poetry. Both of the adults really engaged with and enjoyed the role-playing aspects. Jimmy screamed in frustration when the party encountered a sphinx with rhyming riddles, and Gront gruffly exclaimed “no tossing the dwarf!” when the party faced a chasm they had to cross.

The kids, on the other hand, almost entirely ignored the role-playing aspects except when forced to deal with them. (Liam, for example, wasn’t allowed to participate in decision-making and problem solving because his character’s intelligence was too low.) They instead spent hours beforehand figuring out how they could use their allotted points to make their character the most effective fighter (in the case of the boys), or finding the perfect character portrait for their winged elf (the girls). Even after traversing a particularly tricky obstacle, Ryan asked me “Was there a better way to do it?” still apparently thinking about optimizing the game system rather than having successfully navigated an obstacle.

But regardless of the play style, everyone enjoyed the time a great deal. I really like the cooperative spirit that develops during these things, and look forward to our next session.