New TaskPaper Script Location

As of TaskPaper 2.2.6 the app’s script menu has been removed. This means that we’ve got to move our scripts to where they can be accessed from the script global menu. I moved mine to the following location:


The Scripts icon lives in the menu bar up by the clock. If you don’t see it there you can turn it on by going into the AppleScript Editor preferences and checking  ‘Show Script menu in menu bar’.

And voila:

Hint: You don’t have to go hunting for the AppleScript Editor in the Finder as the easiest way to launch it is to type its name into Spotlight.

The Skinny On Agile Game Design – Part 2: I Think I Kanban

In this article we’ll create a basic Kanban board that can be used for game design or just about any other kind of project. But first…

What is Kanban?

Kanban is a bit of a complex term. It is both an approach to development, in our case, game development, and it is also literally means “visual card” in japanese.

A Kanban board is a visual representation of your design workflow that uses cards or stickies to represent individual features (and sometimes tasks) to be completed. Cards are affixed to and flow across the board as work progresses. Let’s take a look at a simple example.

Our basic board looks a lot like a classic to-do list but there are two distinct features that set Kanban apart and make it tick; the “In Work” column and its accompanying Work In Progress (WIP) limit. All that you have to know now is that these bits are quite important. What they mean and their place in the system is covered later.

Creating and Using a Kanban Board

Step 1: Create Your Own Board
Go ahead and create your own board. Steal – err – copy the example but of course without the cards. Your board’s construction can be as simple as a set of columns on a sheet of paper or even better, columns on a wall made with tape.

Step 2: Add Items To Your Board
With board construction wrapped up, prime the system by adding items to the “To Do” column. They can come straight from your current to-do list.

Step 3: Start Using It
Select the items that you want to work on and pull them into the “In Work” column. When an item is wrapped up move it on into the “Done” column. Nice, quick, and easy.

But First We Gotta Talk (About Work In Progress Limits)

At this point you may be asking, What prevents me from pulling all of the items over to “In Work”? The answer is, one little but essential thing, the Work In Progress (WIP) limit. On the example board, In Work’s limit is 3. This explicitly means that at any given time only 3 items may be in that column.

Why are WIP limits important?
Coupled with at least one step between To Do and Done, WIP limits help prevent item traffic jams. Think of them working together as a valve for maximizing creative flow.

Who sets the Work In Progress limit?
You do, or in the case of a team environment, the entire team does. The beautiful part is that this number can be tweaked to better fit your workflow. The key is to do so only with careful thought. It should never be done on the fly or on a whim. Here’s why…

Don’t change them on the fly
Ad-hoc manipulation of WIP limits breaks the system. It simply turns the whole thing into extra meaningless work (waste) which is the antithesis of what we want. The voice of experience says to start low and carefully work your way up to a WIP sweet spot. But remember, improvement never stops. So, If at some point in the future a lower limit would make things better then go ahead and make the change.

From flow a myriad of other good things emerge.

Benefits of Kanban

With use, you will find:

  • Improved focus: Because you’re not distracted by the vague sense of how much needs done you can instead hone in on what you’re actually working on.
  • Improved prioritization: Because you are limited to focusing on a few items at a time you develop a keener eye for pulling items that will lead to improved flow.
  • Better risk analysis: Because you actively select items to pull into action you tend to give better thought to what you’re doing and its place within the project. You become freer to analyze and ask questions like, What can prevent this item from being delivered? Can I really hit the deadline?
  • Quicker turnaround times: You tend to complete items in a shorter amount of time because both you and the system become more efficient.
  • More value: Best of all, since you get better at what you do the opportunity presents itself to pack more value into what you’re creating.
  • Everyone on the same page: If you work with others then Kanban can make it easy to share the status of an item. All they have to do is look. This translates into less wasteful communication about status and more about the things that really matter, e.g. impediments, and improvement.

The Essentials of Kanban (How It Works)

You may be wondering why we waited all this time to talk about how Kanban works. Wouldn’t it be easier to know about this stuff ahead of time? Not really. Without seeing and walking through an example these things really don’t mean a whole lot.

The folks over at have done such an incredible job distilling how Kanban works that I’m not even going to try topping it:

  1. Visualize the workflow
    • Split the work into pieces, write each item on a card and put on the wall.
    • Use named columns to illustrate where each item is in the workflow.
  2. Limit WIP (work in progress) – assign explicit limits to how many items may be in progress at each workflow state.
  3. Measure the lead time (average time to complete one item, sometimes called “cycle time”), optimize the process to make lead time as small and predictable as possible.

Whoa, wait? What’s that last thing? Measure the lead time? Is this the first we’ve seen anything about that? No, it’s quicker turnaround times from the Benefits of Kanban section.

Measuring How Long It Takes

The simplest way to get started measuring is to jot the start date on an item when it goes onto your board. When the item is completed mark the finish date right along side. If you really want to get sophisticated then the dates can be entered into a spreadsheet or database. It really depends on your level of technical expertise though it’s probably a good idea to start as low-tech as possible. But no matter how you measure it is an excellent way to:

  • Learn how long it takes to do something.
  • Know how much you are capable of doing in a given period of time.
  • Identify where bottlenecks are in your process.


Remember, you don’t have to be perfect right out of the gate. The key is to gear yourself for continual improvement. Soon you’ll be beating your own expectations.

In the next article we’ll cover breaking the single “In Work” column out into multiple columns to better reflect a game design specific workflow. The current Firefight! workflow and Kanban board will be used as an example. Continue reading “The Skinny On Agile Game Design – Part 2: I Think I Kanban”

The Skinny On Agile Game Design – Part 1

One of my personal projects is the Firefight! Tactical Roleplay Engine. It is a live-action game system designed for use with airsoft. For the most part the project lies outside of the digital domain but the goal is not that different from that of a software project – to deliver a working system.

Non-techie readers, there’s a bunch of vocabulary here but have no fear. I’ve linked terms to definitions.

In The Beginning

Our process revolved around bare bones development iterations. It was pretty simple; we’d develop a chunk of system, write a game event to test that chunk, run the event, hold an informal retrospective and start the next iteration. This approach served us very well in getting the game system off the ground. The first iteration turned out to be an incredibly short 24 hours from initial concept to the first play test event. But since it is a live-action game where you have to organize an event and get people to the same location for testing, iterations tended to be longer than desired. Seasonal weather impacts event scheduling which means that iterations are of irregular length. And of course writing and coordinating events uses large portions of our available time. With these issues in mind we realized that we had to make the most of our development and testing opportunities.

As complexity of the project increased it was becoming ever more difficult for me to manage and communicate progress even though we had a development team of only two people including myself. Most critically, if I was pulled away by an outside force (danged day job!) then the entire project screeched to a halt even if the other developer was available and waiting to work. I was the bottleneck which was completely unacceptable especially considering the size of the team. This had to change.

Enter Agile

I had experience with Agile on software projects so I began pondering how it could be applied to game design. We were already doing a form of Pair Programming where we worked side-by-side to develop and codify ideas. And we were already doing iterative development. We wanted to enhance our adaptability, increase transparency, favor simplicity, and foster unity. These agile values mapped directly to our game design goals.

Initially, we turned to Scrum. It wasn’t a perfect fit but it was a good first step.

The good:

  • Scrum got us thinking about what exactly it was that we were building.
  • Our list of requirements and ad-hoc use cases became user stories that we could better evaluate and revisit.
  • For the first time we were really and truly looking at things from a player’s perspective. This amplified the usefulness of their feedback.
  • Short standup meetings had a positive impact on our motivation. A big problem was that the project could sit idle for periods of time due to burnout. Relying on flashes of inspiration to nudge us back into action is obviously not a good way to get things done. The standup meetings kept us primed and moving.
  • We were no longer just running on gut instinct informed by experience.

The not so good:

  • The reporting components of Scrum didn’t work that well for us. We weren’t able to increase visibility because our burndown chart was wacky because estimation was downright tricky. We simply didn’t have the necessary experience to estimate how long it would take to convert a rule concept into something fit for play. And the velocity chart wasn’t useful because we simply had no idea how to tackle business value during early prototyping.
  • The typical example task board while incredibly useful for visualization wasn’t granular enough to build flashlight metrics for wayfinding. At the time I was so focused on everything Scrum that I couldn’t see how to break the board down into smaller steps.
  • I (acting as ScrumMaster) was still the bottleneck. See next bullet point.
  • I felt overwhelmed far more often than I’d like to admit – like I was juggling too much.

It didn’t take long to figure out that pure Scrum really wasn’t a good fit so we moved on taking with us the bits that worked; bits like time boxing, standup meetings, user stories, and the concept of the task board. We kept moving forward but we soon bogged down a bit from spending too much time examining process. Then things took a lighter turn.

Getting Lean

When I discovered Lean development via the ebook Kanban and Scrum I was thrilled. It was exactly what we were looking for. Kanban in particular immediately jumped to the fore.

Here’s the definition of Kanban at Wikipedia:

Kanban can be divided into two parts:

  • Kanban – A visual process management system that tells what to produce, when to produce it, and how much to produce.
  • The Kanban Method – an approach to incremental, evolutionary process change for organizations.

In our case A visual process management system is a complicated way of saying, “A board with post-it notes stuck to it”. In a future article I’ll cover how we created our Kanban board for game development.

This is the Firefight! Kanban board as of June 2010. It has changed since then.

One tremendous benefit of a Kanban board is that virtually everything is right there for everyone to see at their leisure. This virtually eliminated the management bottleneck. Out of the gate I was doing less management with no sense of juggling.

Other great features include flashlight metric building and process improvement both of which are intrinsic parts of the system. Everyone can see the steps for creating value. And when tackling tasks that you’ve never attempted before you will eventually know exactly how long they take to complete. Building this kind of institutional knowledge is incredibly valuable. A direct benefit is that we are now able to examine both game design itself and the process by which we are creating ours.

Who knew that you could get so much by doing less?

Agile people still don’t get it?

Agile people still don’t get it
“Cute, but useless. Now let’s go back to work”.
Source: Otaku, Cedric’s Blog

Communication from the Agile camp needs to be better. In the past I’ve struggled pulling together the big agile picture. Though Jonathan Rasmusson does an excellent job in The Agile Samurai. It is hands-down the best book on Agile that I’ve ever read. Not because it contains bits that can’t be found elsewhere but because the Agile picture is pulled together very nicely providing an intellectual base camp for continued exploration. The samurai theme of the book is great because it reinforces the notion that if you’re talking about Agile then you’re not Agile. Just as if you’re talking about Zen Buddhism then you’re not talking about Zen Buddhism. I plan on writing a full review in the near future. But I digress.

In the past I tried Test Driven Development and I failed. I tried multiple times but now I think that I “get it.” I was so used to prototyping a bit here, building the project there, and prototyping over here some more, round and round. Then at some point I’d start sorting out the mess while trying to keep the fragile parts from breaking. I’m still not an expert and I still don’t always tackle every programming task with TDD but it makes me think about the problem that I’m working to solve instead of what I think the problem is.

Cedric criticized “Your code is your spec.” That’s one way to look at it but in doing so he misses the point. In this universe, tests [the code] can be the spec. Since an exponential function operates on data within a context the test examines its state. It’s a meta-statement about creating functional clean code. The Heisenberg Principle doesn’t apply here. He also advocates comments in code. I used to as well until I pored through enough legacy source and saw way too many comments that were lying to me. Sure, sometimes a short annotation is helpful for the next set of eyes but it has to be done judiciously. If comments executed and their state could be examined then it would be a whole different story. Last time I checked I couldn’t put a break-point on a comment.

Cedric also complained about TDD being used for toy ideas in presentations. He complained that he wanted comments along side code in order to understand what the code does but he wants an Agile practitioner to show him how to be agile on 500k line projects in 30 minutes or less. Funny how that works. Though In here a true gem is buried. Assuming a baseline of proficiency and understanding of TDD, If the devs do not know how to write a test for something then they probably don’t really understand the problem. In an industry where it’s not uncommon to one day be writing apps for the government and on another day writing medical software, being a software dev expert isn’t enough. Connecting with Subject Matter Experts and the customer is incredibly important. Through Agile I have been able to pose poignant and precise questions to SMEs and stakeholders. I feel that if I were not a student of Agile then asking such questions would have been far more difficult.

It also seems that Cedric conflates TDD with the Agile “cloud” of concepts. They’re not one and the same. TDD is an approach that can fall under the Agile umbrella. Agile is a guideline and emergent practices that can be snapped together like Legos to fit a particular setting or set of problems. Heck, I use Kanban and Lean along with principles of Agile. It’s about doing what works.

Tests are fantastic for continuous integration, especially when projects are 500,000+ lines of code. A couple of years ago a former coworker who is highly skilled showed me Cruise Control for .NET. He showed how he set it up and how it helped his team right a sinking project. I easily recognized the result but the inner workings seemed like an impenetrable monolith of arcaneness. I decided to rectify my lack of knowledge instead of complaining about it.

Cedric mentions smugness and infers dogma but then he goes on to say:

“Software is shipped with untested parts every day, and just because it’s not entirely tested doesn’t mean it’s bad software or that the untested parts are “useless”. Agilists just don’t understand the meaning of calculated risk. Early in the development cycle, it’s perfectly acceptable to go for a policy of “zero bugs” and “100% tests”. But as the deadline looms, these choices need to be reconsidered all the time and evaluated while keeping a close eye of the final goal. Very often, Agilists simply forget that their job is to produce software that satisfies customers, not software that meets some golden software engineering scale.”

That’s the problem! It’s part the whip-it-and-ship-it dogma that believes, “If we build it they will come.” It’s all too painfully obvious that software is shipped every day with untested parts. Somewhere in the neighborhood of 70% of IT/software projects crash. Could Agile have saved them? It depends on the group and their leadership. And of course doing something new isn’t as easy as old habits. Isn’t that obvious?

What he also fails to mention is that Agility means adjusting windage and elevation, making informed decisions as a team, so that the target can be hit with confidence. How can a close eye be truly kept on the final goal if it’s okay to take “calculated risks” on the fly? Are they really calculated? Who is making these decisions? Who is managing them? Embattled team members? Too often they’re made by people who have priorities that are divergent from the project’s stated design goals.

Here is an interesting indicator from the 4 year old article:

“So here is my advice to Agilists: get real now, or you will become irrelevant soon.”

Huh. They’re still here. My hunch is that they’ve been real all along.

What I see as one of the biggest benefits of Agile is that it provides a set of ideas and practices that are open for anyone to see and to test. If we endeavor to better our craft on our own then by what metric do we measure ourselves? And while doing so we may not notice Heisenberg tapping us on our shoulder.

UX Myths

From the excellent site

Build your website based on evidence, not false beliefs!

UX Myths collects the most frequent user experience design misconceptions and explains why they don’t hold true. And you don’t have to take our word for it, we’ll show you a lot of research and articles from design and usability gurus.

If I had a nickel for every time I heard one of these…