Game Design is Iterative

Dice for game designIn my side job of game design, I’ve learned a lot about how games are made. Games can have a strong mathematical component to them, and you can apply game theory to any interaction. But when designing a game to be played, the process is highly iterative and experimental. In tabletop games, there’s usually an underlying mechanic, like “roll a d6 and move that many spaces” for a roll-and-move game like Monopoly, and a theme, which is what the game looks and feels like– “building a real estate empire” for Monopoly, for example. Zombies was a hot theme a few years ago, and cats seems to be the theme-of-the-year for 2017.

When I design a game, I start with some idea of what I think would be fun. I’m a “theme first” designer, so I start with “this game is…. (escaping from a space station, or fighting monsters in space, or being a walking, talking toy). I usually keep going, and play a solo improv game of “yes, and/no, but.” That’s where I may discard the first idea so that I come up with something more interesting, or I add to the starter idea (” a walking, talking toy” had “in a post-apocalyptic, broken world” added to make a much more interesting theme and therefore game).

Side note: Other designers are “mechanics first,” where they design a clever or new way to play a game, and then put a theme over it. You can usually identify these designers because they have clever mechanics but either very little theme, or no theme at all (abstract games). An abstract game is something like Go, where there is almost no theme at all, but there’s deep strategy involved in where one places the stones.

 

After I’ve played this game of “yes and,” in which I run through a lot of different ways to explore an idea or theme, then I start thinking about mechanics. If I were building a backlog of “make a game,” I’d have the following items in it:

  1. Decide on a theme.
  2. Flesh out the theme– make it more interesting!
  3. Pick a game mechanic.
  4. Flesh out the game mechanic– give it a twist!
  5. Write the first draft of the rules.
  6. Get some components and players and Playtest.
  7. Revise the rules.
  8. Repeat from step 6 until it’s either ready to ship or you run out of time, money, or patience.
  9. Release the game.

The repetitions between 6 and 7 are, of course, where the bulk of the work comes in; they are the inspect-and-adapt portions of creating a good game.

I’ve written several games, sometimes using this method, sometimes with less playtesting, and I can honestly say that iterative playtesting is the cornerstone of good game design. I even playtested my Improve Drawing Game before posting it.

Certified Scrum Professional – Achievement Unlocked!

Scrum Alliance CSP logoAs of this afternoon, I am a CSP (Certified Scrum Professional) with the Scrum Alliance!

The CSP is a certification demonstrating a commitment to my continuing education in Agile and Scrum, and to the profession. The CSP requires a few years of experience as  a scrum team member, as well as 70 hours of continuing education, which might include independent study, Scrum Alliance training and conferences, non-Scrum Alliance trainings, and scrum-related volunteer work. My blog posts here, events, and Scrum Alliance articles also contributed to the certification. In addition, my coursework for the CSM and attendance at the Global Scrum Gathering in San Diego last month gave me both necessary education and SEU (Scrum Educational Units) for the certification.

I’ve been working towards my CSP since getting my CSM last year, and I am very proud of this accomplishment.

 

 

Certified Scrum Professional® is a certification mark of Scrum Alliance, Inc.  Any unauthorized use is strictly prohibited.

Scrum Master Interview – What a Relief

Stephanie on scrum master interview dayI just had a terrific scrum master interview with a local company, and it was a huge relief! Not because the job is terrific (although I’m sure it will be if I get it), but because the hiring process has me meeting with the product owners and current scrum master in my first interview. I’m not meeting with executives or even the functional manager– at this stage, the company doesn’t even know who the my functional manager might be, because they haven’t decided which team would be the best fit!

I’ve had quite a few Scrum Master interviews in the past 2 months, and I can tell you– most people hiring scrum masters don’t know what they do. That’s usually fine– as a technical writer, I have coached hiring managers on how to interview me and other writers, even during the interview process. But when I come into an interview and I’m talking to product owners and scrum masters who want me to tell them how my last team worked, and demonstrate how I approached that role? That’s a huge relief.

A little bit of knowledge went a long way today. When we talk about “culture fit,” we usually often talk about work/life balance, office wardrobe, and whether there’s a ping pong table in the cafeteria. But for me, culture fit is about how much I have to push to get people to understand what I’m talking about. I don’t mind coaching, and a scrum master is always going to have a lot of opportunities to help the team learn and improve.

But I really love it when the company is already on that path, and I no longer have to explain what I do, just how I do it so well during the interview.

Agile and AWS: A Presentation at AWS Las Vegas

Jon Hathaway and Alex Singh, presenters of Agile and AWSWednesday night, I went to a presentation on Agile and AWS held by AWS Las Vegas at Innevation Center. The speakers were Jon Hathaway of HATech, and Alex Singh of OrgAgility. The presentation was primarily a case study of transitioning slot machine manufacturing giant IGT into having a lean, Agile DevOps team and company culture to support it. By coaching the DevOps team in using Agile and AWS, they report that IGT reduced the time to upgrade slot machines on the floor from 18 months to 2 weeks.

That’s a phenomenal reduction in time, and I was very impressed with their results.

My One Takeaway

I took three pages of notes during the presentation. A lot of it was repeat information from my experiences with Agile, but I always like to have one takeaway to share, and here’s the one I chose from last night:

In this particular DevOps team, each day was like a mini-iteration. They start the day with a standup, like most teams, but that standup plans the goals and tasks for that day only. This keeps the team extremely flexible and able to solve problems. Multi-day tasks can be tackled, but if they have a higher priority item come in, they can switch focus on that item for one day, then refocus on the next. This reduces the overhead from context-switching. Employees are already context-switching by going home at night, so changing focus in the morning doesn’t reduce more productivity.

There were a lot of other topics and tons of information on using Agile and AWS, so much so that I felt almost like we were cramming a 2-day session on Agile into 90 minutes! But it was a very solid talk and both Alex and Jon were highly receptive to questions from the attendees.

Can You Get Unicorns? Agile Estimating and Planning at the Las Vegas Agile User Group

Agile Estimating and Planning was the topic of the first Agile and Scrum User Group meeting here in Las Vegas on Monday night, and it was a good one!

A little club business

In the last 3 months, Jim Schiel reached out to users of numerous local IT-related groups to invite them to join this new meetup group. As a result, we are now over 50 members and growing! Our first meeting was April 24th, and had about 8 attendees– not bad for a first time! We started by talking about the group and organization, then did introductions. The group was a wide range, from project managers and scrum masters like me, to developers and IT administrators. Slightly more than half were currently unemployed.

A great presentation

Can you get unicorns?Jim then gave a 90-minute presentation on Agile estimating and planning. He led an exercise in which we created and sized a backlog for a wedding. The exercise was a bit fun and a bit frustrating. I took on the role of an enthusiastic bride (the customer): “Of course the carriage should be pulled by horses. Unless you can get unicorns! Can you get unicorns?”

Jim’s a trainer and coach for numerous Agile methodologies, including Scrum. He explained the difference between estimating by “effort,” such as work hours or ideal person days, versus “size,” like story points or t-shirt sizing used in Scrum.

Some useful numbers I wrote down so I wouldn’t forget them:

When estimating the deliverable date, use the following formula:

backlog size/velocity * a variable = the number of iterations to complete the backlog.

This is a common approach, though it doesn’t really account for changes in the backlog after development has begun. The variable mentioned above is just for the team’s ability to work together:

  • If your team has worked together and is already a good, Agile team, with a fairly consistent and known velocity, the variable number is about 1.2 (adding 20%).
  • If your team is experienced-but-learning, multiply by 1.4 (adds 40%).
  • If your team is new, or they haven’t done Agile before, or there’s lots of technical debt, multiply by 1.7 or 1.8 (add 70-80%).

This really highlighted the importance of a strong team. Jim tried to hammer home that an organization’s process maturity isn’t its agility– the people/culture are its agility.

What’s next?

What’s next for the Agile and Scrum User Group? The next currently scheduled meeting isn’t till July, but I’m planning a Lean Coffee sometime in May or early June so we don’t lose momentum.

Training Game to Build Teamwork

Here’s a 10-minute training game you can do with visual learners to build teamwork.

Setup the Training Game

Sort into small groups of 2-3 people.

Distribute 1 piece of paper per group and 1 pen or marker per person– no erasers! Remind players to keep their content PG. Otherwise, tell them there is no “bad” drawing in this exercise.

Start the Training Game

One person draws a basic symbol or shape on a piece of paper. Pass the paper to the next player in the group.

The next player adds something to the drawing. Pass the paper to the next player.

Finish the Training Game

Repeat for 8 minutes. Players may talk to each other during this exercise. See if a story emerges. Players may not erase or undo any element in the drawing. Pick one team to explain their drawing and the process.

Learning Objective of the Training Game

Teams build on each others’ work to make something greater than one individual could do alone. By passing the page back and forth several times, team members also see incremental improvement during the development of the final drawing.

Read More

The Final Retrospective

“The Final Retrospective” was originally published on the Scrum Alliance website on March 7, 2017. https://www.scrumalliance.org/community/articles/2017/march/the-final-retrospective-(1)

Gutted.

Absolutely gutted.

That’s how I felt when my manager told me the contract had fallen through and we were out of a job in a week. It wasn’t personal or performance based — defense contracts don’t always make sense.

I still felt gutted, and I know our manager did, too. Despondent, he said, “Let’s cancel the standups next week — there’s no point.”

“I disagree,” I said. “Let’s hold the meetings anyway. It can’t hurt to give people some space to talk. We don’t need to do the planning meeting, but we should have the review and retrospectives.”

Read More