1. No way, they are opposites
2. Kanban is for flow / Scrum batch
3. Yes, Scrum is old school big planning steps
4. Kanban minimal planning / Scrum is heavy planning
5. No, Scrum can reduce to KanBan

As much as we love scrum, even we would have to admit that it’s not perfect. Nothing is.  In  fact, a  large part of our book describes workarounds  for various deficiencies that scrum presents to us in certain circumstances.

One of the more commonly noted deficiencies in scrum is that it plans its work a whole Sprint at a  time.   This “batch” planning process  is often not agile enough  to cope with the actual rate of change of requirements.    In fact, Chapter 4.4 on PlaceHolder Stories, the  discussion  of  the  mid-Sprint  Re-planning  in  Chapter  4.8,  and  the  discussion  of renegotiating the scope of a Sprint in Chapter 4.3 are all about resolving this deficiency.

There  is  another  agile  process,  called  KanBan,  which  solves  this  problem  and  is becoming popular  for  software development projects.  In our upcoming book we will describe the main strength of KanBan and how to integrate it into scrum.

Brief Description of KanBan

The  “KanBan  for  software” movement  is  really gaining some  traction  in  the  agile  community.    The main  idea  of  KanBan  is  very  simple  and based  on  the  Lean  “pull,”  “Just  in  Time”  (JIT),  and  “reduce  inventory”  principles:  eliminate planning inventory by making sure that you don’t commit to doing work until you are actually ready to start the work.

1. The PO says go.
2. The Teams says they are ready.
3. The SM has determined a time box for the sprint.
4. The team and PO agree to a time box
5. The PO understands and is prepared to talk about the stories

Comment: There are a number of things you should do before you can even begin planning.  The most important thing you can do is make sure that your Product Owner is prepared, and understands what the stories are about.  Remember that the Product Owner is a role here, so what we’re actually saying is that someone on the Team knows about each story; that is, each story has its own champion (Story Owner) who represents the Stakeholder’s needs/wants to the Team. This may require that the Product Owner (person) coordinates the efforts of all the Story Owners.

Comment: Changes to work forms an interesting tension.  At a fine grained detailed level it changes all the time. Each person’s individual to-dos often change toreflect their understanding of what it takes to get the job done. As the level of granularity increases to task then it is a change to the team’s plan. If the number of changes is significant and adds up to more than one story’s worth of work then you better stop and adjust your plan, usually you want the product owner in on that discussion. And if there are several new  stories that were  suddenly found and are so important they must be done right now, then call a stop and reset your entire sprint with a sprint planning session. Generally, the commitment by the team to the sprint should not change. Note: definition of team makes this an interesting discussion. Bottom Line: The goal here is to help the team get better at  expressing work they can do and following through on a commitment.

Comment: The idea here is that there can be only one source for Scrum knowledge. I guess that depends on where you get your definition from and what you need. Should there be only one way to think about scrum? Probably not, although,  a rookie mistake is to modify without have deep applied practice and experience under your belt. The 1st common mistake we see people make is modifying scrum without understanding it. They often confuse themselves and their organization.