Thoughts on Agile, Scrum, Lean and Kanban

Recently I've been engaged with a couple companies in discussions of whether to use Scrum or Kanban for their work.  I've published a deck on slideshare that I've used in detailed discussions of the subject.  I'll capture a few of the points from that deck here.

Scrum of course is an Agile practice and is based on the Agile Manifesto and accompanying principles.  Kanban is a Lean practice that should be understood in the context of the Toyota Production System (TPS)

I like this diagram illustrating the shared precepts of the perishable nature of knowledge work and continuous improvement.  Outside that shared space are the driving forces behind Lean: eliminating waste and emphasizing throughput; and in the Agile domain: releasing work early and often, and the need for trust and collaboration.

To elaborate further, here's a summary list of similarities I see between Scrum and Kanban:

  • Pull scheduling
  • WIP limits
  • Transparency drives process improvement
  • Deliver finished work early and often
  • Self-organizing teams
  • Break work into small pieces
  • Continuously optimized plans based on empirical observation (velocity in Scrum; lead time in Kanban
And here's a summary of contrasting characteristics:

To determine which approach is best in a given situation, consider the specific context, including these factors:
  1. What experience does the organization have with Agile and Lean already? If there already is a cultural or experiential bias toward one or the other, go with it.
  2. How well aligned is the organizational culture with Agile or Lean principles and values?  It's very difficult to succeed with an approach that is opposed by cultural norms and values.
  3. What's the nature of the work? Scrum works very well with software development.  Kanban seems to work better than Scrum for IT Ops, reporting services, some types of marketing work, etc.
Success with either Scrum or Kanban is highly dependent on a determination to incorporate feedback cycles and to improve the process and outcomes based on the team's own observations and stakeholder satisfaction with the quality and quantity of finished work output.


Popular posts from this blog

Severity, Priority, Impact and Likelihood - Managing Defects and Risks

Enterprise Agile Framework: The Entrepreneurial Operating System (EOS)

Chatbot Code of Ethics