Category Archives: Kanban & Lean

Posts related to Kanban and Lean methodology.

Using status indicators on Task Boards and Scrum Boards: “Ready to Pull”

Agile & Scrum, Kanban & Lean, ,

(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:

Examples of status flags on cards
Examples of status flags on cards

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”

Setting status
Setting status

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:
Understanding the Pull Model
Understanding the Pull Model

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:

A case study in transforming a Government Agency

Agile & Scrum, Government, Kanban & Lean, Team Collaboration, Technology, Týmová spolupráce, , , ,

Dan Genz from the Washington State Auditor’s Office gave a presentation at the 2014 IPMA Forum describing how the state agency is adopting Lean principles, while serving hundreds of state, county and local municipalities with a distributed team of auditors and analysts spread out across the state:

Is Kanban a better way to manage support/maintenance work than Scrum?

Agile & Scrum, Kanban & Lean, Kerika, Technology, , ,

Hi folks!

I recently offered my thoughts to the Scrum Alliance group on LinkedIn, on the discussion thread on whether
Kanban is a better way to manage support/maintenance work than scrum. I thought you might find it interesting:

Kanban is generally a better model for support/maintenance: these tasks tend to trickle in, so trying to handle them with a conventional Product Backlog is often awkward.

Support/maintenance tasks are also usually unrelated to each other: one bug fix may have nothing to do with another.

This makes for a different metaphor than Scrum/Product Backlog where there is some presumption that user stories and tasks, while perhaps independent, are at least part of a larger product or release theme.

If you did support/maintenance tasks in a Sprint, that Sprint would have no overarching theme which I strongly believe is essential for success with Scrum teams.

And if any team doing support/maintenance with Scrum will quickly realize their Sprints are unlike those of other teams that are doing product development with Scrum.

I would view your questions about swimlanes as arising from a misfitting metaphor: instead of using swimlanes, you would be better off using tags, and then filtering your board as needed to see all support/maintenance tasks related to a particular subsystem or process or person. E.g. “show me all the tasks related to the database schema”.

We use our own product (Kerika) of course, and we do all of our new product development with Scrum Board, and support/maintenance with Kanban boards since Kerika lets you easily have both kinds of boards.

We use multiple tags on each card on both the Kanban and Scrum Boards, so we can filter and search, e.g. “show everything related to our Google Drive integration”.

These filtered views are much more effective and flexible than trying to organize your board with swimlanes, because each card can have multiple tags, whereas with swimlanes a card would be in only one swimlane at any time.

Also, this arrangement gives us flexibility to move from Kanban to Scrum and back: for example, if a support/maintenance card that originally landed on a Kanban board is later deemed to be significant enough to handle as part of product development, we can just cut-and-paste that card from the Kanban board to the Scum Board, and Kerika brings along all the content, history, attachments, chat, etc.