(The fifth in a series of blog posts on how you can make use of the status indicators on cards, in Task Boards and Scrum Boards.)

In our last post we talked about how to use the “On Hold” flag; today, let’s take a look at “Is Blocked”

“Is blocked” sounds similar to “On hold”, but it should be used in a different context: Blocked is a red flag to the team — it indicates that you are unable to proceed with a task, and you need help.

The essential difference between Blocked and On Hold is that:

• You, or perhaps your boss, chose to put something On Hold.

• You were forced to mark something as Blocked.

For teams working in a Kanban or Scrum model, the highest priority for a Project Leader should be to unblock cards.

Unblocking cards (and hence, people) is the most useful thing that a Project Leader can do to help move work smoothly.

This is why “Is blocked” is shown in red on a card, so that you can literally raise a red flag!

All posts in this series:

• “Ready to Pull”
• “Needs review”
• “Needs rework”
• “On hold”
• “Is blocked”
• “Done”

(The third in a series of blog posts on how you can make use of the status indicators on cards, in Task Boards and Scrum Boards.)

In our last post we talked about how to use the “Needs review” flag; today, let’s take a look at “Needs rework”.

In an ideal world, cards would only move from left to right: starting off on the left-most column, e.g. the Backlog in a Scrum Board, and moving in stages to the Done column.

In the real world, however, work can sometimes need rework, and that’s what the “Needs rework” status indicator can be used for.

The amount of rework that’s needed will vary widely, depending upon the project and the team:

If someone new has just joined a well-established team, that person may need some time to understand exactly what’s expected of them at each stage of the project’s workflow: they may, for example, be too quick to move a card from “Planning” to “In Development”, without realizing what’s expected of a card that’s fit to exit the Planning stage.

This new person may find that her work gets pushed back to the left, marked as “Needs rework”.

It’s imperative that whoever pushes back work as “Needs rework” also provides some precise description of what rework is needed.

This is most often done using chat, but sometimes a marked up document, screenshot or other materials may be more useful, particularly if the task is complex.

But, simply marking a card as “Needs rework”, without providing a good explanation, is never a good idea: it will generate ill-will within the team, discourage the new person, and simply result in more work for everyone.

Some times of work will always require a lot of rework: e.g. design.

Mockups of new products or features, or copy for new advertising, will go through a lot of rework before it is considered ready to move along a workflow.

This is quite normal, which brings up another critical point: good Project Leaders will ensure that there is no stigma attached to cards being marked as “Needs rework”.

If people are made to feel, however subtly, that their work is of poor quality because many of their cards are frequently marked as “Needs rework”, this will have a very bad effect on individual and team morale.

It’s really incumbent on the Project Leaders to ensure that people understand that “Needs rework” is simply a status indicator, not a judgment of someone’s abilities!

All posts in this series:

• “Ready to Pull”
• “Needs review”
• “Needs rework”
• “On hold”
• “Is blocked”
• “Done”

(The first in a series of blog posts on how you can make use of the status indicators on cards, in Task Boards and Scrum Boards.)

Kerika makes it really easy to flag cards on a board, if you need to alert your team members; here’s an example:

There are several statuses that you can report on cards (in addition to “Normal”, the default setting), and we will try to provide some advice in these blog posts on how best to use them.

First up: “Ready to Pull”

Ready to Pull is great if your team works in a “pull” environment, rather than a “push” environment. Here’s the easiest way to differentiate between the two:

• In a “push” environment, work gets pushed onto people — quite literally. For example, Project Leaders (or even Team Members) decide that a particular card should be handled by a particular person, and they assign that card to that person: in other words, they push that work onto people.

• In a “pull” environment, people only assign work to themselves: as they get freed up from whatever they are working on, they look at the board and pick up whatever task is waiting to be pulled (i.e. done) — in other words, they pick up a card that is marked as “Ready to Pull”.

There are advantages and disadvantages to both models, and it’s really a question of how your team prefers to work.

Particularly in organizations that are still transitioning from traditional (Waterfall-style) project management, the push model can be the easiest way to adopt a tool like Kerika: it helps retain the traditional role of a Project Leader as someone who is responsible for the assignment of work among the team.

This is definitely the easiest pathway for organizations that are still in the process of transitioning to a Lean or Agile model — a process that can take months in most cases.

There are, however, some disadvantages to the push model:

• It can delay the organization’s cultural transformation to Lean/Agile: people feel less empowered, and can be more passive if they wait for work to get pushed to them by others.

• A less empowered team is often slower to take the initiative.

• Someone who has had work pushed onto them may feel less ownership of the outcome.

• It provides a misleading picture of what’s actually getting done: this, in our experience, is the biggest shortcoming of the pull model!

When work gets pushed onto people, you can find that individuals have 10 or more items currently assigned to them. There’s no way they could be working on all 10 items at the same time, so one of the biggest advantages of Kerika — providing an accurate, real-time view of what’s getting done, and by whom — is somewhat negated.

The pull model is truer to the spirit of Kanban: it allows people to work at their own (true) pace, and empowers them to pick up new work as they get freed up — or blocked.

The Kerika team itself has transitioned from push to pull: with push we never had a true sense of what’s getting done; with pull, we do!

There are disadvantages to the pull model:

• It requires more training and cultural change up-front: even for a team that generally feels empowered, it is a big shift in thinking and process to move from push to pull.

• It can require a more complex workflow: for example, here’s a partial (!) view of the workflow that we adopted as part of transitioning to Pull, to make it work within our constraints:

Pull is best implemented in conjunction with Work-In-Progress (WIP) Limits, which is a feature that we will be adding shortly to Kerika.

So, how should you use “Ready to Pull” as a status indicator?

If you are working in a push model, there’s nothing to do: you don’t need this feature.

If you are working in a pull model, whenever a user is done with a piece of work, she should mark it as “Ready to Pull”, and then take her name off the card.This will clearly signal the rest of the team that the work item is ready to be taken on by someone else.

All posts in this series:

• “Ready to Pull”
• “Needs review”
• “Needs rework”
• “On hold”
• “Is blocked”
• “Done”