Flavors of Agile - Lean and Kanban

 

Let me start by saying that I am not going to give you the history of the Toyota Production System (TPS).  If you're familiar with it, great, you know what I'm talking about.  If you're not familiar with it, you should read about it.  Toyota provides several pages of information on both history and current practices of TPS that will give you context to the overview I will be providing.

Even if you are not familiar with TPS, you may have heard of Lean and Kanban.  You've probably heard them used together, more often than not.  I would argue that they represent the original Agile approach, but I have not found any evidence that they were used for software development before Agile became a "thing."  I think this may be, in part, because production processes do not directly translate into development processes.

Using the book "Lean Software Development - An Agile Toolkit," by Tom & Mary Poppendieck, as a reference, Lean gives us the following (highly summarized and subjective, on my part) principles and tools for software development.  I should warn you, some of this may seem counterintuitive at first glance, and could be difficult for people to accept without further discussion:

• Principle - Eliminate Waste: If something does not directly add value as perceived by the customer, it is waste.
  • Tool - Seeing Waste: If it is not analysis or coding, does it add value?
  • Tool - Value Stream Mapping: Map your value stream to start discovering waste
• Principle - Amplify Learning: Involve business people in the learning process; they will recognize business problems as they use the system.
  • Tool - Feedback: Feedback, early and often, will help you to identify problems  sooner.
  • Tool - Iterations: Use just-in-time inventory flows to meet customer demands, as opposed to meeting a schedule.
  • Tool - Synchronization: Make sure that people working on features with a common code base are working closely together.
  • Tool - Set-based Development:  Basing communication on constraints, as opposed to choices, reduces the amount of data that needs to be communicated and defers choices until the last responsible moment.
• Principle - Decide as Late as Possible:  This can be difficult because it also means allowing change as late as possible, which is in direct contrast to the common desire to be decisive and make decisions quickly.
  • Tool - Options Thinking:  Uncertainty can make it difficult to make final decisions early. What can you do to move from predictive processes to adaptive processes?
  • Tool - The Last Responsible Moment:  Not to be confused with procrastination, this involves delaying commitment until the moment at which failing to make a decision eliminates an important alternative.
  • Tool - Making Decisions:  Understand the decision making process and factors that affect decision making.
• Principle - Deliver as Fast as Possible:  Customers like fast delivery.  Providers should too.  The faster you can deliver something, the longer you can delay making decisions.  This sounds counterintuitive, but think of it this way; If you can make a change in a week and have a month until you can deliver, you have three weeks to make a decision about the change.  Remember, this is not procrastination.
  • Tool - Pull Systems:  Let customer need pull the work, instead of having a schedule push the work.
  • Tool - Queuing Theory:  How do you make cycle time as short as possible?
  • Tool - Cost of Delay:  Understand the price tag on time in four areas 1) development cost, 2) unit cost, 3) performance, and 4) introduction date.
• Principle - Empower the Team:
  • Tool - Self Determination: Provide workers with the expectations and let them determine how to achieve them.
  • Tool - Motivation:  There are a lot of factors that affect motivation; purpose is chief among them.
  • Tool - Leadership: Teams need leaders, not just managers.
  • Tool - Expertise:  Make sure your team either has the expertise it needs, or access to it.
• Principle - Build Integrity In:  Product integrity is found in high performing companies.
  • Tool - Perceived Integrity:  The totality of the product achieves a balance of function, usability, reliability, and economy that adds value for the customer.
  • Tool - Conceptual Integrity:  The system's central concepts work together as a smooth, cohesive whole.
  • Tool - Refactoring:  Start with something that works, learn from its weaknesses, and improve the design.
  • Tool - Testing:  Test that design intent is achieved and that the system does what customers want it to do.
• Principle - See the Whole:  A system is not just the sum of its parts - it is the product of their interactions.
  • Tool - Measurements:  Don't measure complex, unstructured work by disaggregation; measure the aggregate.  i.e. measure group performance, not individual performance.
  • Tool - Contracts:  Use contracts to build trust between organizations, not to create barriers.

Kanban fits smoothly into Lean Principles, with the following principles of its own:

• Start with the existing process
• Agree to pursue incremental, evolutionary change
• Respect the current process, roles, responsibilities and titles
• Leadership at all levels

…as well as the following values:

• Visualize the workflow
• Limit Work in Progress (WIP)
• Manage the Flow

Similar to Scrum, in Kanban, visualizing work is done with a board and cards.  One of the primary differences is that Kanban emphasizes WIP, or the amount of work that the available resources can work on at any given time, as opposed to velocity - how much work can be completed in a time-boxed period.  Here are some additional differences, as identified by VersionOne:

While this may change, I currently do not intend to spend a lot of time on hybrid flavors, but I will at least share some links.  Here are a couple of Kanban hybrids you may, or may not, have heard about:

• Leanban
• Scrumban

I'll say this now, and try to remember to repeat it often as I post about agile.  If you're going to adopt a flavor of agile, pick the one that fits your company culture best, to the best of your knowledge, and learn how to do it right.  Once you have it down, apply the final principle of Agile:

"At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly."

Learn and adapt.  Be agile, not just Agile.  If you can't adopt a flavor of Agile, adopt as many of the principles as make sense for your organization.  You're probably already following some, and can easily identify areas where you can improve.