Kanban prescribes 3 rules:

  • Visualize the workflow
    each workflow state.

It has these properties too:

  1. Pull: The downstream process pulls items from the upstream process.
  2. Self-Directing: It has all information on what to do and makes production autonomous in a non-centralized manner and without micro-management.
  3. Signal: Its visual status signals the next withdrawal or production actions.

It is harder to do than Scrum: since it prescribe less rules it left more degree of freedom that needs to be decided by the team. For example a novice Scrum team can be scared by all the freedom and responsibility and can react discussing the few process rules to avoid taking responsibilities to the hundreds degrees of freedom for example for engineering practices and team standards.

It requires more discipline than Scrum: the few prescribed rules are harder to follow and just breaking 1 single rule means to break 33% of Kanban

- - - -

When the team find hard to follow Scrum rules, when the team is stressed by the adoption of Scrum and when there is lack of people with previous experience in agile software development, probably switching to Kanban could not be the answer.
In this case Scrum training and reducing pressure (more available time or reduced scope) could help.

When the team already have a good Scrum implementation and is ready to customize or evolve his Scrum adoption, that could be a good time to switch to/merge with Kanban.

When the work that team is accomplishing doesn't fits the concept of iterations and releases and instead fits better a continuous flow of work and continuous releases, than Kanban could work better than Scrum.

Read more at: Kanban and Scrum - making the most of both

Tags :   |  |  |

Print | posted @ Monday, May 31, 2010 12:22 AM

Comments have been closed on this topic.