Choose

  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 this 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  this chapter 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  led by David Anderson1
, and  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.

kanban-flow-scrum-batchAs 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.