When Agile Becomes Fragile

In my last post, I didn't addressed the issue of agile planning boiling down to "only planning 2-4 weeks ahead." Based on what I've seen, this is still a common misconception in game development. I've encountered skepticism about agile from managers at three different game companies who had seen agile projects go off the rails. One manager dubbed agile development, "fragile development." From what I understood, they attributed the failures to poor planning that focused on the short term.

Every project needs to find a balance between anticipation and adaptation. Finding a balance for a given project is part of being agile. Unfortunately, I think practices like daily stand ups and iteration planning are much better understood than longer-term planning practices like release planning. One game studio I know of was spending a lot of time rewriting the game engine for a franchise, and I wondered how that fit into their release plan, e.g., how would they fit that work in before full production needed to begin? I was told they didn't have a release plan. I think that's a recipe for disaster. Mike Cohn has explained the importance of release planning pretty clearly:

"A release plan helps a team avoid finishing a series of sprints and feeling that, while they always worked on the highest priority items, the collection of work completed does not add up to a satisfying whole."

I think this planning is especially important in game development with its different phases: concept, pre-production, production, and post-production.

I also surmise that projects run into problems with prioritization, risk assessment, and estimating costs, e.g., cost of delay. I think new agile adopters understand the practices for teams and the role of scrum masters much better than they do the role of the product owner. It's not always clear who should fulfill this role: design or production. I suspect this role isn't often filled well (or at all.).

Agile isn't synonymous with Scrum or time-boxed planning practices. I think that game development poses special challenges and tools in addition those used in Scrum are needed. I want to address this in "To Timebox or Not to Timebox (Part II)."

To Timebox or Not to Timebox (Part I)

I was never particularly interested in project management or scheduling until I read the book Agile Estimating & Planning by Mike Cohn five years ago. I'd been working in software for 20 years and scheduling seemed like a dull and tedious exercise at best. At its worst, scheduling seemed like a black art full of lies, falsehoods, and deceptions.

As a programmer interested in learning about agile, I started reading books focused on the technical side of agile software development. Most of the agile programming and software design practices made sense to me. As far as I could tell, the agile approach scheduling seemed to boil down to "only plan 2-4 weeks ahead." This seemed neither practical nor sensible. I picked up Agile Estimating & Planning to find out what the deal was. The answers I discovered were much more interesting than I expected and eventually motivated me to eventually change careers from programming to project management.

The first idea in Agile Estimating & Planning that rocked my world was planning using iterations (now more popularly  known as sprints). It was my first exposure to timebox scheduling. I was used to working with milestones in software development. It was often unclear whether milestones were defined by "date" or by a "state." Dates were set for milestones, but there was also the expectation that certain goals would be achieved. The dates were usually more clearly defined than the goals and milestones were usually months apart.
 
Timeboxed iterations immediately struck me as a great idea after seeing a lot of problems planning and scheduling programming work over the years:

• The time horizons for development could be long and work often involved a lot of uncertainty, failure, and iteration. Planning and scheduling was often done irregularly, if it all, after the initial phase of the project when the least was known and understood.
• Scheduling often took the form of getting precise estimates for a long, linear sequence of tasks. Gantt charts showing a single line tasks for individuals, each task starting on a specific day and ending on a specific day, were rarely a reflection of reality.

The timeboxed method of planning described in Agile Estimating & Planning made intuitive sense to me as an software engineer.I believe that there are many advantages:

• Regular frequency of planning. Planning and scheduling needs to be an on-going activity throughout a project. Requirements and priorities change and a lot of information is learned as development progresses. I've had problems when planning was irregular: 1) too long a period and plans and schedules are far out-of-date and people are no longer working to a plan; 2) it's annoying as a programmer when goals and priorities change out-of-the-blue on a frequent basis. There are costs associated with planning and switching tasks. They need to be considered and managed.
• A comprehensible time horizon for planning. When I'm thinking about time and programming work, I can wrap my head around a few weeks. Much longer than a month and I start waving my hands. It becomes easy to procrastinate. I've rarely seen a detailed task plan survive and be useful for more than a month.
• A focus on deliverables and not activities. The focus on planning for iterations is the delivery of useful functionality fulfilling a clearly defined definition of "done." It's not about completing activities. Ultimately, results are what matters. The activities required to meet goals are more uncertain and change more frequently than the goals themselves. I find focusing on completion of activities leads to the problem of  Parkinson's Law: Work expands so as to fill the time available for its completion..
• Commitment-driven planning. I'm a big fan of making and keeping commitments in work. [I could write a whole post about it.]  I want to be able to commit to results that are achievable. Given a fixed time horizon I can comprehend and a pile of estimated work, I can make judgment about "too much" or "too little."

As anyone who has seen my schedule diagrams, I have a much easier time picturing and working with schedules visually by using timeboxes: fitting work items of various and somewhat variable size into buckets. This has been a natural fit for how I've seen the activity of programming. I'm not usually proceeding along a linear series of steps that start on day X and end on day Y.

Other people have written about the virtues of timeboxing. As well as planning software projects, timeboxing has also been useful managing my own time using the Pomodoro Technique.

At first I thought timeboxing was "it," a general purpose solution for all of the planning and scheduling challenges I could care about. That lasted until I had to schedule game art and asset production. Next post I'll write about the limitations of timeboxing when I find a need to use a different approach.

More On New Choices & Roleplaying

A friend made several excellent points about the improv game "New Choice" and making stronger choices. Her comments got me reconsidering the way I was thinking about choices. I know there's always the risk of being partially or completely wrong when I write about something, but that's part of the reason I'm writing.

I'm not entirely sure what the instructional value is of the game New Choice (also called Bell & Buzzer). When played it, I thought it was about learning to make stronger choices. As my friend points out, it might be seen as tool for getting out of ruts, e.g., reusing the same locations again and again. How many scenes to you want to see in the kitchen or a park? It might also be an exercise to give "'permission' to improvisers to explore extreme states."

I'm rethinking the importance of coming up with "strong choices" (aka strong offers). My friend reminded me that I seen a lot of amazing improv moments where "dull" offers were accepted and built upon and made into great scenes. Those moments may outnumber the number of scenes made great by strong offers. I've also seen a lot of dull scenes that started with strong offers. It's ultimately about the teamwork and chemistry of the players.

I can't say I've played in a lot of roleplaying games with great chemistry and teamwork, except maybe in tactical battles destroying groups of monsters. I've experienced group chemistry playing scenes in improv. My effort now might be better spent listening to other players' "offers" and building upon them than thinking about "New Choice" or obsessing about character. I think it's still good "blurt." Whether players look at my offers and make "Yuck" faces is out of my control, but I can work to listen and help make other people shine.

After obsessing about improv and roleplaying, I'm now busy reading books about project management. I finished Management 3.0 a few days ago, and I got through another excellent book, Kanban. I now want to read more about lean development so I'm going to tackle The Principles of Product Development Flow after I read Project Management That Works. Whew!

New Choices & Roleplaying

I've been reading this thread on story-games.com about "Try A Different Way" in the game Archipelago. As I and Graham mention in our posts, there is a game in improv, "New Choice," where someone rings a bell and an improvisor needs to make a new choice during a scene.  To take Graham's example,

"This steak is undercooked."   (dull)
[Bell rings]
"This steak is overdone."        (the opposite, dull)
[Bell rings]
"This isn't a steak at all."       (trying to be creative, dull)
[Bell rings]
"I am a steak-pervert. Bring me seventeen juicy..."   (trying to be creative, dull)
[Bell rings]
"My steak just talked to me."   (something to work with!)
[Bell doesn't ring, scene continues.]

The intent is to practice blurting from the sub-conscious and finding stronger choices. It's not for one player to say to another "That's bad." You can accept the other choices, but they are weak. For awhile I've wondered if this could be used in roleplaying, either through structured statements like used in Polaris and Archipelago or maybe using a resource system like spending "fan mail."

Someone else in the thread suggests that most games he's played have something like "Try A Different Way" when people say,

"Oh! No Wait! I know! How about something more like this?"

Thiis is different than "New Choice."  Sometimes the new idea is a "Yes, and..." that builds upon the player's original choice, e.g., "Yes, the steak is speaking with the voice of your dead lover !" Often, the new idea offered is something entirely different .

This is an area where  improv and roleplaying are different.  In my experience, weak choices can be made in improv and they are accepted. If possible, they are built upon and otherwise may be dropped because they don't go anywhere. The players are acting and putting on a performance. In roleplaying, players aren't always talking in-character and the group's narration of the story can take many forms. Taking the Dust Devils description of Regular Play (outside of Conflicts) as an example:

The Dealer [GM] and the players talk freely among one another, and everyone has the opportunity to make suggestions about what happens, to talk with each other as characters would talk, to add details to the scene, and to create a story together. Players can request scenes or alter the story, even aggressively. ... However, during regular play, the Dealer has final say in what happens.

Generally, players have narrative authority over their characters' actions and dialog, which is something roleplaying has in common with improv. Depending on the game, players can also be called upon to frame scenes or narrate the outcome to conflicts.When the spotlight shifts to player and he or she needs to make a choice, one of the following can happen:

1. The player quickly steps up with a strong choice and everyone is satisfied and play flows smoothly
2. The player quickly steps up with a decent choice and someone suggests a better idea before play moves on. The player can accept or reject it. A discussion might ensue.
3. The player quickly steps up with a weak choice that people see he's clearly not entirely satisfied with and people make suggestions
4. The player doesn't have an idea, maybe after a pause, and asks for suggestions
5. The player is quiet and slow coming up with an idea and people jump in with suggestions

Perhaps because of my experience with improv, #1 is what I always want to happen when called upon. For me, #1 and #2 happen less likely than I'd like. It might be for any number of reasons like if I'm having a bad day (I need to watch out for H.A.L.T.), playing a game that isn't right for my tastes, don't have a handle on my character, or perhaps I'm just in my head and using my intuition (perhaps because I'm anxious and focused more on playing "well" than having fun). I think the last reason is probably the most frequent, which is why I'm interested how well "New Choice" could work in roleplaying. The narrating player can "blurt" and other players can call for a new choice, helping the narrating player without having to throw out ideas of their own.

In my experience, #5 above is the worst for me to do. When I do this too much, what results is 1) the GM or players get in the habit of immediately offering suggestions if I pause and sometimes before I have an opportunity to speak; and maybe 2) my engagement with the other players decreases quite a bit and I end up in the spotlight less often.

So just as in improv, I find it's a bad idea in roleplaying to spend time being quiet, trying to think of a strong choice. At best, if you are playing with friends who give you the space, the play often stalls.

I want to find a away for there to continue to be engagement at the table when #3 and #5 happen and for the game to keep flowing. My current working theory is that, absent a mechanism like "New Choice," I really need to get into the habit of blurting from my intuition.

The best case scenario for #3-#5 is that a strong idea is offered (maybe following an engaged discussion) , the player chooses it, and play continues to flow smoothly. I can get stuck when there are a lot of ideas or time passes and none of the ideas are clearly strong choices, i.e,., "Oh yes! That's right!"

What to do? The best I can think of is to pick the strongest idea, fully commit to it by narrating as colorfully as you can, build upon as much as you can, and keep things moving forward. I believe this is something I just need to practice (like having the courage to blurt).

Roleplaying Flow

Today offered up another outstanding blog post by one of my favorite bloggers and writers about roleplaying, Rob Donoghue: A Framework of Faces.

Everything in the game has faces. Bring those faces to life, and the game takes care of itself.

The idea that there's time for characters to "settle in" and improvisation can take over is what captured my imagination when I got into "indie roleplaying" several years ago. I was bringing hopes and expectations from improv theater, and I was looking for something quite different than the traditional roleplaying I'd done in the 80s and 90s. I was looking for character-driven play and improvisation.

Rob is speaking as a GM, but I don't know how often I've experienced "critical mass" as a player and I certainly haven't as a novice GM. A lot of my roleplaying experience in the last several years has either been traditional RPGs (e.g., D&D 3.5/4.0) or conventions in one-shots. At conventions, you create your character and charge ahead as fast as you can. Sometimes I have a hard time keeping track of all of the characters, PCs and NPCs. I'm often tongue-tied and breathless and definitely not "settled in."

After reading Rob's post, I reflected upon my Getting Lost in Narrative post. In addition to "peak experience" moments I also enjoy experiencing "flow." I have great memories of peak experiences, but they usually happened in the context of "flow."

Communication, Complexity, and Complication

I had a phone interview with a company today for a project management position. I was told it was a "phone screen." I'm glad I did it because I need the experience interviewing for project manager positions. The call turned out to be more of a full interview and an unpleasant one for a number of reasons.

Two questions among the battery of questions the interviewer asked (with no enthusiasm and pretty clearly reading from a standard form) were roughly

1. What are skills of good communicators? 
2. Describe the most complex problem you've solved in one of your jobs and give specific examples of what you did to solve the problem.

Like the subject of narrative in my last post, I can think of hundreds of things to say about good communication skills. It doesn't help that I just read Management 3.0 and my mind is full of new ideas. I could say so much, I'm kind of thrown for a loop when asked such a general question in such a context.

I get thrown by questions like these when they aren't part of a conversation, and  I can have a hard time with tests. In retrospect, I know I should tell stories that sell my abilities when asked these kinds of questions. Looking at the different types of communicators, I'm definitely not a salesman. However, I believe 'Influencing' is among my capabilities nonetheless.

What I was really thinking was the question was asked was, "Why are you asking this question?" Ironically, I need to work on my communication skills when interviewing. What I heard during the conversation was from the very start was, "I don't want to be interviewing you. I personally don't care about any of your answers." In retrospect,  that's what I heard, and I wish I would have reflected back (in a diplomatic fashion) what I heard instead of continue through an increasing painful interview process.

I've heard the second question many times in software engineering interviews. Now I need to be prepared to answer it in project management interviews. I wasn't prepared for this phone interview. Trying to answer it on the fly, I was flummoxed right off the bat because I was wondering what qualified as a "complex problem." This has tripped me up in the past. The word complex is used in a lot of different ways:

1. Complicated: difficult to analyze or understand

This is how I have usually interpreted "complex" in technical interviews, which are usually trying to determine how smart you are. By default, I think of technical smarts as mostly defined by your ability to solve technical problems requiring complicated math, complicated algorithms, or clever hacking skill.

I found a lot of my hard science coursework in engineering school hard to understand. In comparison to engineering school, the majority of the programming I've done hasn't been that hard to analyze or understand with several notable exceptions. In comparison to engineering school and some programming problems, I don't think of the problems I've solved in project management as complicated.

2. Challenging: requiring full use of one's ability or resources

A lot of the work I've done as a project manager and a software engineer has been challenging. I love being challenged and there lots of different types of challenges. In retrospect, I think this is how I should have interpreted the question.

3. Complex: 1. A whole composed of interconnected or interwoven parts; 2. somewhat predictable (but with many surprises) [the second is the definition applicable for describing complex systems]

I don't think complicated algorithms, complicated math used in games, and clever hacking is complex using these definitions. However, the large software systems I've worked on, and in many cases designed, have had a lot of interconnected parts. There was a lot to manage and organize. I think you could argue that that large software systems are also complex, adaptive systems.

Except for the rare trivial problem, managing people and projects is complex using either definition. How do I deal with complexity in project management?  I use the whole set of practices and tools I've been developing over the last several years and I'm continuing to develop. (Which I had described earlier in the phone conversation).

Well, I told the company I was not interested, but it was good practice. I'll be better prepared for the next test. I like storytelling so I'll come up with some good stories to tell when given a wide open opportunity to sell myself. A former studio GM showed me the value of being a good storyteller.

Getting Lost in Narrative

Holy cow, I've spent days trying to write a post about narrative in improv and roleplaying. I keep starting, stopping, and starting over. Being me, I also couldn't help picking up a couple of cool books - one by Orson Scott Card and another about screenplay writing (it's Mike Stout's fault).

It was much easier for me to write about character. Character has always been my primary interest in both improv and roleplaying. In both, I learned that I need to know how to play strong characters with well-defined abilities, beliefs, and goals before I can create interesting stories. I can and probably should write more about character (with examples and maybe pictures).

Thinking about narrative is proving a useful exercise for me since I've been pondering definitions of words like 'narrative', 'story', and 'plot' in ways I haven't since high school English classes. I haven't even gotten to 'theme' or 'genre' yet.

I've never thought much about plot in either improv and roleplaying games. I don't think I ever heard the word "plot" mentioned once in improv. You are extemporaneously creating a plot when playing either short form or long form formats in improv. I suppose certain games or genre work may provide a loose structure, e.g., a crime is committed, there's an investigation, there's a confrontation with the bad guy at the end, etc.

I think the main reason I haven't thought about plot is that I'm not interested in thinking ahead and "plotting." I have a hard enough time "not thinking," playing the character, and being in the moment. I really enjoy it most when there's no "wrong" place for the story go to. In the section on long form improv in Acting on Impulse, Carol Hazenfield writes:

There is no preordained "right place" for any story to go... There's no such thing as "The Story" existing in its entirety in advance of the end of the show.

In improv, you focus on one moment and one scene at a time. The audience can very forgiving of broken stories if there are great characters, scenes, and moments. I've watched probably over 200 improv shows, and I can't remember a single "plot." I do remember great characters, scenes, and moments where I said, "Wow."  A couple of memories from years ago:

• In LA theater sports, I remember a scene with a bunch of young single characters in a hot tub. It was funny but the characters also expressed genuine emotion that fit the moment perfectly.
• In Theater Roulette in SF, I remember a criminal gang with the most amazing collection of personalities, particularly a not very smart thief (Theatre Roulette was a short lived group I believe formed out of Carol Hazenfield's classes [EDIT: It was actually a class by Gerri Lawler, one of my favorite improvisors.]).

That's what I'm also looking for in roleplaying. When all is said and done, looking back on the game, a solid "plot" is just nice to have.

It occurs to me that I haven't really enjoyed roleplaying game sessions when I've put an "author" hat on and plotted things out in advance or in lieu of actually playing. I prefer it when there's scene framing and you just "go."
 
I don't think this is at all the last word about plot and its creation:

• I'm most concerned about characters and being in the moment, but it's still the case that we're creating a plot during play.

• In improv you can practice genre work,  which can provide more than "trappings." Directed improv can have a player who isn't playing any characters.

• Roleplaying games can provide a lot of support for structuring stories, e.g., games like Burning Wheel, Grey Ranks, and Leverage. Also, some games with GMs (like Smallville), the GM isn't necessarily playing NPCs who are pivotal to the story.

Fail Faster

Paul Tevis' blog post today captures the mind set of improvisation pretty well. There are a lot of skills to practice in improv, but the most important to practice is taking a leap and "going in" with eyes wide open.

"Nope, screw it. I'm going in."

In retrospect, I wish I had practiced it a lot more back in my improv days. Staying safe has been a hard habit to break. I used to frequently repeat the improv mantra "Dare to fail." Now I prefer the mantra I learned from game design, "Fail faster."

In "Finding Fun (Part IV)" I'm going to dare to briefly dip my toe into the subject of roleplaying and narrative. Libraries of books have been written about narrative including books with charts and graphs. I just picked up Robin Law's book, "Hamlet's Hit Points", which I plan on reading soon. Maybe this time the theory of turning points, rising action, and denouements will stick in my head better than it has in the past. Joseph Campbell's "Hero's Journey" has managed to stick with me pretty well, probably thanks to Bill Moyers.

For wisdom about narrative and roleplaying, there are people much wiser than me including Rob Donoghue, John Kim, among others. Next post I'll say what I can based upon what I've learned from improv and roleplaying.

Finding Fun in Roleplaying Games (Part III)

On the subject of improv and roleplaying, I recommend Paul Tevis' talk What Improv Has Taught Me About GMing. I'm tempted to get a couple of tattoos: "Do your thinking outside of your head" and "Listen and React." I also recommend Carol Hazenfield's book Acting On Impulse, which Paul's talk mentions. I took  classes  from Carol when I was studying improv and they were fantastic. What you learn in improv can be helpful in real life as well as on-stage, and this was especially true of Carol's classes.

Of all of the elements of roleplaying, I'm most interested in Character: the "role" in roleplaying. I don't want to confuse roleplaying with acting, but I believe they share some things in common. All of the players in a roleplaying game including the GM (if there is one) are playing characters who speak, act, and make choices.

I studied three aspects of character in improv: Vocal, Physical, and Emotional. Acting On Impulse talks about each of these.

Vocal

Vocal elements include dialects, accents, pitch, how fast or slow you speak, where you speak from (nose, chest, etc.), and where you place your pauses. Learning dialects and accents takes a lot of study and practice. The other elements are more easier to do. When roleplaying, I think a little can go a long way.

Speaking in-character is pretty common in roleplaying. I've played with a fair number of role players over the years that use vocal characterization and are good at it. Like everything else in improv and roleplaying, one of the keys is full commitment to whatever you are doing.

I'd like to speak in-character and use vocal characterization more often. I've found it can be a useful  tool in finding and expressing character. Unfortunately, I'm having more fundamental problems these days - in the heat of the moment, I can jumble up speaking in first and third person. In a recent game of Leverage, I spoke in the first person and said, "I'm pissed off" when I meant to speak in the third and say, "Amanda is pissed off."

Physical

I loved physical characterization in improv after I discovered mask acting. I found it was the easiest route for me to find characters, especially conforming your facial expressions to the mask. Physical characterization includes how you carry yourself, walk, where your physical center is, and more.

Unfortunately, you don't move around a whole lot in roleplaying (I haven't played LARPS or Jeepform) .  Ryan Macklin suggested that I can stand and move around more (he's often standing), but I haven't made good use of it yet. Fortunately, if you aren't moving around, what you describe about your character's physical appearance can be helpful with characterization. I was delighted with Apocalypse World's "Look" traits.

Note that above I've mentioned "finding" characters: like everything else in improv character is much more of a discovery process than a planning process. I find this is true in roleplaying - I can completely fill out my character sheet during character creation, but it isn't long before I want to change something. Some of my favorite games these days like Leverage flesh out the characters through play. In addition to "do your thinking outside your head, one of my other favorite phrases right now is "acting should precede planning." You can create elaborate plans ahead of time but once you act, things change and that's when you really need to plan.

Emotional

This is the hardest part of all in improv, and I've known improv actors skilled in all of the above areas but have very little range in terms of emotionality. It's easier to be funny than explore emotional perspectives quite different than your own, e.g., optimistic, pessimistic, spiteful, joyous, sorrowful, naive, etc. Usually, I was only able to access this when doing mask acting.

I don't even know how to start talking about character emotionality in roleplaying games. I've seen very little or none of it in games like D&D 4E. I've struggled with it when playing "story games."  I can look at all of the items on character sheets and try to reason through logically, given the current situation, "What would be character do now based on all of this stuff?" but I have to say that it feels like a very mechanical exercise and I usually come up dry if I don't have emotional understanding of or connection to the character.

Other Tools for Characterization

Two other tools for characterization in improv were Objectives and Status. I mentioned Objectives in my last post describing C.R.O.W. What does your character want? What are his or her goals? Status refers to social pecking order. Keith Johnstone, who introduced the idea of status transactions to theater, talks about status in his book Impro. It was a useful tool in improv, and I find it to be a useful tool when I can think to use it in roleplaying.

People aren't one dimensional and showing different sides of a character does a lot to bring a character to life and add interest. I believe roleplaying games like Burning Wheel support this - beliefs can show different aspects of character and it gets really interesting when they conflict. On a related noted, Change is vital component of character development. This is a core part of Burning Wheel (I believe the Spokes, actually) and many of other my favorite games provide great support for character change and development, e.g., Smallville.

A final tool that I think can be useful is to define the importance of characters'  Intrinsic Desires:

• Acceptance - the need for approval
• Physical Activity
• Curiosity - the need to think
• Power - the need for influence of will
• Eating
• Romance - the need for love and sex
• Family - the need to raise children
• Saving - the need to collect
• Honor - being loyal to a group
• Social Contact - the need for friends
• Idealism - the need for purpose
• Status - the need for social standing
• Independence - being an individual, to be autonomous
• Tranquility - the need to be safe
• Order - the need for a stable environment
• Vengeance - the need to strike back
• Competence - the need to feel capable, for mastery

Many roleplaying games focus on skills and attributes like strength, dexterity, etc. These are most useful in determining how competent characters are at accomplishing tasks. The parts of roleplaying that interest me most are figuring out what characters say and what characters choose to do, particularly when facing difficult decisions. I still struggle when roleplaying (actually as much or more than I did in improv), despite all of the things I write down on character sheets. Perhaps a good design challenge for myself would be to design a game that helps me with this. Or maybe I'll re-read and play A Penny For My Thoughts.

Finding Fun in Roleplaying Games (Part II)

There are a lot of different kinds of fun you can have playing roleplaying games. I think I enjoy them all to greater or lesser extents. Attempts have been made to categorize the different aspects of roleplaying, e.g., The Big Model. Weeks could be spent reading all of the theory.

A lot of the way I think about roleplaying is influenced by my experience studying improv acting for a few years back in the mid-90s. I took a lot of classes, read some books, and gained as much wisdom as I could from experience and instruction. I was never interested in performing on stage for audiences so my improv career was short-lived.

I was delighted to discover "indie roleplaying" several years ago since it seemed to combine a lot of what I liked the most about improv with my other life long passion - games. Today I roleplay for many of the same reasons I was interested in improv acting years ago: I love storytelling, I want to exercise my creativity, I want to continue to overcome my inherent shyness, and I want to practice being in the moment. (I  also have a habit of sticking to hobbies that don't come at all easily to me).

So looking through the lens of improv, here are some of the things I enjoy about roleplaying and some  recent experiences I've had having fun:

• Say yes.  I'd like to think this is one habit that I've gained from improv that has stuck with me - accepting offers and doing my best to support my fellow players. I occasionally catch myself blocking or negating, and I can still get better at building on offers (yes and...) instead of just agreeing to them. It can be tremendous fun to collaborate with fellow players. My favorite recent moment was in a game of Little Fears - the GM took my offer that an evil troll was ticklish and established that the troll could then be attacked using characters' Care ability. This suddenly made another player with an non-combat PC into a combat power house. It turned the tide of battle and was a lot of fun. It felt like a magic moment. 
• Don't be prepared. This is the absolute hardest thing for me to do, but I've gotten gradually better over the years. The moments of spontaneous creation in the moment, where great ideas come from Who Knows Where, are the absolute best (and, alas, all too rare for me). The "ticklish" idea in the Little Fears game was one such moment - I didn't think about it, it just came out of my mouth. I had spent a couple seconds thinking of "clever" ideas, let them go, and then BAM! an idea came out of my mouth. I think I was only able to do this because I was really into my Character (a 8 year old boy who was like a misbehaving Encyclopedia Brown).
• Character.  There's a useful mnemonic in improv, C.R.O.W., standing for Character, Relationship, Object, and Where. These are the main building blocks of scenes - if you establish them then you have the foundation for a good scene. For me, it starts with Character, who am I? That also happens to be what the heart of roleplaying games, the character sheet, is devoted to. I struggle a lot with character (one of those things that doesn't come at all easily tome ). In improv, I most easily accessed other characters and felt I was truly "acting" when doing improv mask work. Mask work is very physical (unfortunately, masks often don't do a lot of talking until after you spend a lot of time with them). When I feel a character like I'm wearing him/her like a mask, that's when magic happens. It happened in the Little Fears game. When roleplaying I'm usually somewhere between tongue tied - "What would Stilgar, a kick butt Fremen leader do in this moment??" - and saying things that are functional but not particularly imaginative (and I'm rarely funny). I miss the time I had in improv to work physically with the character and the environment so I don't have to be talking all of the time.
• Relationship. I truly understood the importance of Relationship a couple of years ago when playing With Great Power. The next best tool I know of next to, "When in doubt, have a man come through a door with a gun in his hand," is to establish strong (usually familial) relationships with PCs and NPCs. It's so much easier to create stakes that mean something and make conflicts personal. Smallville is a fantastic game for this. The recent Duneville game I played was incredibly intense and reminded me of an improv performance - the heart of that was driven by the characters' relationships and their conflicting Objectives.
• Objective. I'm usually going absolutely nowhere roleplaying unless there's an objective to follow somewhere. The simplest are provided by the GM to the players, doing something an NPC asks and obeying heroic logic, e.g, "Kill the bad guy before bad stuff happens."  It's absolutely awesome when PCs and NPCs all have their own individual objectives to drive them and they variously agree and conflict. The Duneville game was propelled along by strong player character objectives and my recent games of Leverage were pretty good in this way too. (Burning Wheel is the best game I know for defining and working with character objectives.)
• Where. This means the scene location, props, and more broadly the mise-en-scène. Aside from being able to get into characters kinesthetically, this is what I miss most from improv theater. You physically inhabit the imaginary space in improv (there are exceptions like radio plays). In my experience, a lot of the scenes in roleplaying games have a weakly established "where." (It can help if games explicitly support assigning traits to locations.) The best RPG scenes have had "just enough" quick, concise narrative description and color to bring the scene alive but not too much to bog things down. The weakest almost always involve talking heads, lost in abstraction with no walls or props or anything to work with. I love when "where" is well defined. "Assets" have provided a lot of great props in my Leverage games. I (Strangely, in D&D 4E I find that the map usually limits "where" to what is physically visible on the table).
• Reincorporation. Reincorporation is another fundamental technique of improv. One description of improv acting is that the actor is like a person "walking backwards and remembering and reincorporating things that have been established along the way." I think of establishing a "frame" for the story, populating elements within it, and the farther you go, you're reusing elements more and adding fewer and fewer. I've hoped that the games of  Leverage I've played in would have awesome Wrap Up scenes with great uses of reincorporation but so far this hasn't happened. In my recent game of Freemarket, one of the players made repeated brilliant use of reincorporation. I was stunned, but it was really quite simple - she used what we had established at the table in previous moments instead of spending a lot of time trying to grab new ideas from some theoretical "clever" space, which is in a dimension rarely connection to our own (where my mind often tries to visit).

Finding Fun in Roleplaying Games (Part I)

This is the first in a series of posts I want to write about finding fun in pen-and-paper roleplaying games. Why do I play roleplaying games? What's fun about them? What's not fun?

A lot has been written about roleplaying game theory. The effort continues to understand the nature of roleplaying games and how to talk about them (e.g., in this recent forum thread). I've read a fair amount of the theory, and some of it has stuck with me and been practically useful including the ideas of Shared Imaginary Space, The Lumpley Principle, deprotagonizing, Czege Principle, types of storytelling authority, and the differences between Intent, Initiation, Execution, and Effect.

I'm not thinking about theory a lot these days. I'm more interested in reflecting upon my actual roleplaying experiences and making sense of them. What do I find fun? What don't I enjoy? What do I do well? Where do I struggle? How can I have more fun? It occurred to me that if I were to attempt to design a roleplaying game, I should start with thinking about what I find fun when playing (and not theory or clever mechanics). Not coincidentally, working in video games I have learned some things about fun and the challenge of finding it.

It is too late to write more tonight. In my next post I want to touch upon my recent experiences playing Leverage, Smallville, Little Fears, Hero System, and Freemarket and mention some things about  what I  try to bring from improv acting to roleplaying games.

Complexity at the Workplace

Reading Management 3.0 is a departure for me. I've never been enthused by the thought of being a manager or been interested reading books about management. Despite my reservations, I picked it up and started reading it because it's a Mike Cohn series book, has a forward by Robert Martin, and explicitly mentions "agile leadership" in the subtitle. When I saw that it had a section explaining complexity theory, it jumped to the top of my reading queue.
 
I've sprinkled Management 3.0 with copious post-it notes and highlighted sections. I think I'll have to read the book at least 2 more times to fully digest the material. There are several main points I've taken away so far and I want to more fully explore and understand:

1. Management and leadership can be interesting. I thought the subject of project management was as dull as particle board until I read "Agile Estimating & Planning" by Mike Cohn. In agile, I  found planning and scheduling tools that were useful and practical to my daily life as a software developer. Management 3.0 seems to provide the same for leadership and management: how to empower teams, develop competence, facilitate communication, etc.
2. "Agile" is a memeplex. I'd heard about "memes" but hadn't heard the term "memeplex." Memeplexes are groups of memes. Memes grouped together in a memeplex because they are more successful when "teamed up." A lot of the elements of "agile" development and management aren't new or magical, but they reinforce each other when combined. I find "agile" and "lean" development subsume a large number of useful tools and ideas that work well together. For me, they have been more easy to understand, remember, and communicate when grouped together.
3. Leadership isn't just the domain of managers. Reading Management 3.0 has helped me untangle the big ball of elements subsumed by "leadership"and "management." I have a better understanding of the roles and responsibilities of managers and the difference between "governance" and "leadership." I haven't been a supervisor with direct reports for much of my career.  However, I have been a leader. I have acted as an adviser, architect, coach, mentor, and "competence leader" frequently over the years. I will be much more effective and confident as I gain a better understanding of management, leadership, and authority.
4. "Management 1.0" pervades my thinking. Somewhere my brain wiring has equated strong leadership with telling people what to do and placed faith in  "command-and-control" management (Management 1.0). Despite all I've learned through study and experience, those biases still linger. Those biases feel young and immature. Management 3.0 is helping clear up the muddle and gain a better understanding of the nature of complex systems. It's a much bigger deal than I imagined, and I understand why it's at the core of the book.
5. Practices not processes. I like studying, thinking about, and designing processes. However, I've never liked the idea of being the "process guy" whose job it is to impose rigid processes (thinking in these terms relates to #4 above). I was delighted to learn about this article, Enough of Processes: Let's Do Practices. I've found the best way to implement Agile processes is to do it our own way at the studios I've worked at. I've also noticed that places that supposedly do agile "by the book," make (what are to me) obvious mistakes and run into problems.
6. Manage the system, Not the people. As a person who loves to think about and manage systems, my favorite sentence in Management 3.0 so far is, "Manage the System, Not the People." My (not fully formed) understanding is that the core of the book is to treat teams as self-organizing systems and the job of management is to develop, protect, and direct the system. Before I read this, I told a person that I have experience as a development director and project manager, "managing projects and not people." I don't think I'll say it that way again, and I have yet to finishing putting together my pitch. Whatever the job titles are called, my interest is definitely in managing systems (it was also my interest when I was a software engineer).

Performance Metrics at Work

I'm in the middle of reading Management 3.0, a book about Agile leadership and management. The book has been thought provoking, and I would like to think and write about dozens of different topics. The subject that I've been thinking about today is "Performance Metrics," measuring individual or group performance at work.

In my experience, Agile usually just focuses on team performance, e.g., the Balanced Scorecard method described in the book Succeeding with Agile. The author in Management 3.0 argues for measuring metrics at multiple levels of an organization including individuals, teams, and higher levels.

I've worked in the software industry for over 20 years, and I've only seen the use of reviews for individuals with annual corporate "performance reviews." It's an ritual I always despise, both as a manager having to do reviews and as a person being reviewed.  I despise the multiple choice "satisfactory / unsatisfactory" questions. Right now I'll get angry even trying to remember them.  I liked having of list annual objectives in theory, but they never worked in practice: 1) a year is a long time, and there was usually no review or follow-up during the year; 2) what I'd written at the beginning of the year was often irrelevant because the direction of the company had changed so radically in the intervening time. I would have liked to see reviews or metrics done at higher levels of the organization. The top management usually rolled out nonsense goals every year like my favorite from Spectrum Holobyte, "Ship hits on time."

It makes me wonder what a good individual performance review process would look like. I've heard of "360" reviews, which are mentioned in , Management 3.0 and that sounds like a good idea particularly if done in a group meeting. Among Management 3.0's 8 tips for measuring performance, I was most taken aback by

• "Never create ratings yourself: The value of your opinion as a manager about the performance of a person or a team is very, very, very small. ..."

Upon reflection, I find I agree with this. Direct interaction with my manager is often been a lot less significant and frequent than my other work relationships: customers of my code and tools, departmental directors I'm supporting, etc.

Individual evaluation criteria and performance metrics I've seen have almost always been qualitative. I'm curious what useful quantitative ratings for individual software developers could look like, e.g., for programmers, producers, artists, designers. I've never worked in sales so "dollar sales" has never been relevant. I've been a fan of various agile team measurements: velocity, burn-down and burn-up charts, etc. Without measurement, I find both self-discipline and continuous improvement to be more challenging.