If you want to get your team on the same page, Zen can help. This is because the organization of information on the board is a clear representation of a project’s status. This makes it easy to understand a project at a glance, creating a shared "mental model" among members of a team. A mental model is a representation of knowledge that is used to describe, predict, and explain behavior.

Team member often differ in their mental models due to a lack of communication and differences in attention or awareness. The problem with differences among members of a team is that shared mental models lead to better performance (Lim & Klein, 2006), so increasing shared mental models by using Zen will likely increase your team’s performance.

Zen is designed to be open-ended, so you can use it that way that’s most helpful for your team, and adjust how you work as you find new ways to become more efficient.

However, Zen’s flexibility can make it difficult to understand how to get started, so we thought it might be helpful to explain how we use Zen to work on Zen. This should give a couple of ideas on how Zen can be customized to fit the needs of individuals and teams.

Our workflow is customized into three phases we called prepare, develop, and deploy:

• Stories in the prepare phase are “on our radar”, and require research, definition, or specification, but no development/creative work has actually been done yet.
• Stories in the develop phase have work artifacts (code, design comps, etc.) in progress but are unfinished.
• Stories in the deploy phase represent completed work that is ready to go live, but stories aren’t considered “done” until they’re in the hands of our customers.

The develop phase has a work-in-progress (WIP) limit of 2. Since each of us can only work on a maximum of one story at a time, this minimizes waste associated with context switching.

We also have some guidelines for story cards:

• We use different colors to indicate classes of work. For example, value-adds for us are green, bugs are orange, and priority fixes are in red. Red stories trump the priority system, and move through our pipeline as fast as possible.
• We prioritize tasks using the Moscow Method: each task is defined as must, should, could, or would, in descending priority.
• We generally don’t estimate story sizes, but this space could be used for story points, hours, or t-shirt sizing (small, medium, and large).

Other ideas for story cards:

• You could use colors to group stories into batches representing their minimally-marketable features (MMF).
• You could use tags to group stories into MMFs, iterations, or due dates.

Every project has an editable details section on its homepage – as you become familiar with Zen and find the best way to use it to work, this is a good place to share the information with the team. This way someone that’s new to the project can understand how the team uses Zen in a quick glance.

We’re interested in the different ways our users have found to work with Zen, so let us know!

I read an article recently called "Thinking for yourself in your context" is the heart of Lean. It stated that better efficiency in software development would be achieved if workers had shared goals, and that these goals should center around why you are implementing a feature rather than just how to do it. The point is that people should step back to understand the whole picture and use that information to inform their decisions. That is why a kanban board for a team is so important. It keeps everyone on the same page with a project, so they can stop focusing so much on the how and really focus on the why. This is definitely empowering to employees. Though empowerment can be a good and bad thing for the team, employees will appreciate the ability to "think for themselves" in the long-term. 

We built flexibility in to Zen to try to empower the team to use the product in their own way, but because there are so many ways to make Zen your own like coloring stories, tagging, etc., there can be some growing pains as you figure out the best way to use the software. In the end though, members of a team will appreciate that they are able to make the decisions rather than having unnecessary restrictions placed upon them. We have a documentation section on the homepage of each project, so that you can document the way you use the software and keep every member of your team in the loop. We will also be posting soon on how we "dogfooded" Zen to create Zen and how we continue to use it to manage the product. This may give teams some additional ideas about what might work for them.