Scrum v. Kanban

Scrum vs Kanban

There is often a lot of confusion in teams regarding which agile approach to take to execute a project or a set of tasks. The major contenders are always Scrum or Kanban however there is also Scrumban, Scrumfall, etc. In keeping my tradition of blogs with less than 500 words, below are my 2 cents on this topic:

Scrum is an ideal candidate when you are trying to deliver a product, create an asset or have a set goal and would like to deliver parts of it on a regular interval basis. In scrum a "shippable" work product is delivered at the end of every sprint. 

Kanban is ideal in environments like production support or call center or Corporate IT services. Here the work is usually changing on a day to day basis and the journey is the destination. For e.g. in a production support team at the start of your day you wouldn't know how many tickets you will have to resolve or the size and complexity of each.

Sprint Velocity is used to measure how a Scrum team is doing; velocity is a measure of units of work delivered at the end of the sprint. For Kanban, Cycle Time (average time spent on an issue) and Lead time (time between issue created and close) are good KPIs to measure team performance.

Which methodology to use is heavily dependent on the team, project, company culture and your goals. Either of these methods or a combination of them are used in the industry. Understand the project, the corporate culture, the people, the technologies and utilize a methodology that fits and be nimble enough to change it if it doesn't work.