Scrum Vs. Kanban

By Pedro Alessandri We have recently incorporated in Hexacta a new agile project management methodology that easily

We have recently incorporated in Hexacta a new agile project management methodology that easily adapts to the project needs when their requirements definition is not given in its initial stage of inception, but occurs during the course of it.
Kanban is a Japanese word that can be translated as “visual cards” (kan: visual, ban: card).  It emerged as a consequence of a methodology called Lean, built by Toyota to improve its production using Just in Time techniques (JIT).  Kanban is not a specific technique for software development and its goal is to manage, in a more general way, how tasks are expected to be completed.

The main three rules are the following:
•    Take into account the phases of the production cycle or workflow.
•    Determine the limit of “work in progress” (or WIP).
•    Measure the time spent in order to complete a task (known as “lead time”).
For a better understanding, here’s a comparison between Scrum methodology, with which we have been working for some time now, and Kanban:

I personally believe that the best strategy to apply depends on how client requirements are managed:
•    Full Scrum: when client participates actively and has a defined number of requirements.
•    Full Kanban: when there are no defined requirements.
•    Mixed: Scrum for development, Kanban for bug fixing.

Share this articleShare on LinkedInTweet about this on TwitterShare on FacebookShare on Google+Email this to someone
Go Back