1

I want to introduce my Scrum team to Kanban and I am not sure how best to approach it.

Does anyone have any good ideas?

  • I tend to think of Kanban as Scrum stripped down to bare bones--if you start from that perspective, it may be helpful. – JDRoger Nov 30 '15 at 17:52
  • 3
    What is the reason behind the change? Is there a particular problem you are trying to address? – Bart van Ingen Schenau Nov 30 '15 at 17:56
  • Two of the questions that are supposed to be asked at a retrospective are "What went wrong in this iteration?" and "What can we do to improve?" If Kanban can provide a solution to a problem or somehow improve the process, it can be brought up at the retrospective. But process change for the sake of process change isn't appropriate. Why do you want to introduce Kanban to your team? What problems are you solving or what do you hope to improve by changing the process? – Thomas Owens Nov 30 '15 at 19:31
  • Thanks @ThomasOwens. I think this is a great response. So I am going to theme my retrospective around issues not around Kanban. – TheLearner Dec 1 '15 at 10:56
  • I'll expand on my comment as an answer, then. – Thomas Owens Dec 1 '15 at 11:03
2

The three guiding questions for a retrospective are:

  • "What went right in this iteration?"
  • "What went wrong in this iteration?"
  • "What can we do to improve?"

The answers to these questions will drive changes to how the team operates. If you tried something new (perhaps even unplanned) and it caused you to be successful, then the first question will identify those things and you can try to incorporate them into your process.

However, the last two questions are more important if you're interested in changing the process and want to evaluate a new process or tool. If Kanban can provide a solution to a problem or somehow improve the process, it can be brought up at the retrospective. But process change for the sake of process change isn't appropriate.

Ask yourself two questions:

  • Why do you want to introduce Kanban to your team?
  • What problems are you solving or what do you hope to improve by changing the process?

If you can present Kanban as a method to prevent problems or improve how your team works, bring it up at the retrospective. Otherwise, don't shoehorn a process change in for the sake of change.

  • How does this answer the OP's question? You highlight how to raise the concept of Kanban but not how to introduce the process or transition into it. I am wondering because in our retrospective this came up, we are now transitioning and the transition process is not clear and your answer does not provide insight. – Jim Dec 1 '15 at 20:33
  • @Jim The question is not about how to transition, but how to introduce it as a solution. This answers that: if you believe that Kanban will solve a problem that you experienced in an iteration or that it will improve your team, then you should talk about Kanban with your team and explain what it is and how it will address a need. If Kanban isn't going to solve a problem or you can't justify how it will improve your team's performance, then you don't bring it up. How you choose to roll it out is another question entirely, and wasn't asked here. – Thomas Owens Dec 1 '15 at 20:37
  • I misread the question. "introduce my team to Kanban" I took to mean "transition" but it is clear from your discussion that you answered the OP's question. Thanks for clarifying. – Jim Dec 1 '15 at 21:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.