Part of an ongoing series for Coherent Development

Take something complicated, break it up in to manageable parts, and then tackle them over time in order to achieve a goal. – Phil Vecchione

I am an avid player and facilitator of table top role-playing games. You’ve been warned.

In 2012 I picked up a copy of Phil Vecchione’s Never Unprepared: The Complete Game Master’s Guide to Session Prep. Phil is a table top gamer at heart. He is a project manager by trade. “Never Unprepared” is the intersection of the time management skills of a professional project manager and his hobby.

Phil speaks about the five steps of preparation.

  • Brainstorming - Spawn lots of ideas
  • Selection - Winnow down the ideas
  • Conceptualization - Expand on the selected ideas
  • Documentation - Write down meaningful notes for the concepts
  • Review - Reconcile the notes for consistency

In identifying the steps, Phil is creating boundaries for the types of tasks he does. In creating these boundaries, he declares the constraints on the time he is working.

There is no place for rejecting ideas during the brainstorming nor documentation phase. Selection is the time for doing so.

More than any software development book, Never Unprepared is a guide for my day to day professional life.

Applying this to Hydra::Works

On Wednesday, the Hydra Tech Call embarked on a collaborative design process for Hydra::Works.

I volunteered to write up some collaboration steps. They were enough for us to get started.

And started we did.

A flurry of conversations erupted. Our community is working hard to give shape to these conversations.

I’m not concerned with the output of the conversation. I don’t have a strong sense of what is the right model. I am more concerned with “are we doing it the right way”.

For the current work we are doing, I’m wanting to make sure that we are moving through log jams in our discussions. I want to identify which of Phil’s phases we are in?

But before we go to far, I need to determine what the end of this “project is.” I believe the end of this project is to have an agreed upon set of use cases that have been documented and reviewed.

Applying this to the General Case

As I work on something, I want to know my end goal. Once that is determined, I find following the above methodology very powerful. I can get a lot done at the right times.

One key assumption is that I know my end goal. If I don’t, then I need to create a small project to determine my end goal.

The Hydra Tech Call agreed that we were going to swarm on the generation of use cases for Hydra::Works. We weren’t going to implement Hydra::Works, just determine the needs that it must address.

The community has a lot of voices and does not have a benevolent dictator for life. So I’m looking to help form and suggest a framework for efficient work as a community effort.

If anyone has one, please let me know.