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.