Agile &: Essential Lean - Goal Driven Lean

Goal-Driven Lean

Lean should be goal-driven and not prescriptive. Work optimization - the main purpose of Lean – could be done only by discovering the problems and finding the solutions that are specific for a team's and organization's context. We already have a good goal-driven approach in Disciplined Agile [1] and that could be an inspiration for organizing and essentializing Lean.

The followings are my expectations for such an approach.

Provide a Lean goals map
For each goal, provide guidance including the followings:

Discover concrete problems & root causes description
Recommended “default” practices and possible options
Discussion about options & trade-offs in each specific context
Reference to more detail guidance (as DA toolkit [2])

Principles, practices, and goals - some existing Lean principles are not really principles, but rather practices. For example, the “deliver in small batches” principle is the XP “small releases” practice. DA Manifesto [3] value “Responding to feedback over following a plan” is a proper root principle in this case. Avoiding one significant source of waste (defects, waiting, and others) is the middle ground between principles and practices, and could be a good goal to achieving a lean way of working.

Lean Development Goals

I propose the following list of lean development goals:

Avoiding waste – This means avoiding the main sources of waste (see Essential Lean - Analyzing existent solutions). There exists already a translation of Toyota Production System proposed wastes, initiated by Mary and Tom Pooppendick. There is a “coincidence” here: the described lean solutions are some of the main practices of Extreme Programming (XP). Agile and Lean are convergent [4], and we cannot disregard this aspect. Of course, we can and we should extend [5] this initial set of lean solutions.

Early delivery of value – This is needed for several reasons. While an early delivery could have a higher market value, a delayed delivery would increase the incertitude about its real value. At the same time, early delivery implies managing complexity through more frequent feedback and reducing the work scope at the release level.
Note: this goal has similarities with avoiding Overproduction waste.

Maximizing delivered value - We need to discover, focus, and improve the activities that have an effective contribution to creating and delivering value. Ineffective and unnecessary work is an undesired complexity. Some examples include:

Core agile practices [6] – Helps to avoid unnecessary work, and are proved at the industry level
Adapt to context [7] - Work optimization is context-dependent

Note: this goal is similar to a good understanding/generalization of avoiding Overprocessing waste.

A less known impediment is related to the management of knowledge & skills. It is not only about teamwork versus individual work. We need to collaborate and to share knowledge also at the organization and community level.

When we evaluate the wastes and the workflow of the value we should optimize the whole and not only some local parts. Some examples include:

Assess the whole value stream [8]
Do not rush only for short term results if you want to stay in business

Comment: the first three goals above are covering the current "lean methods" or solutions set. However, we need to add any other aspect related to complexity and incertitude.

Managing complexity – Software development has an inherent complexity that affects work results. Adding undesired and unnecessary complexity will complicate all development aspects, possibly in an exponential manner. We should consider any problem and any solution related to complexity management, not only those related to avoiding main sources of waste, early delivery of value, and maximizing value.
For example, the undesired complexity of a software product is a critical aspect of software development, creates many severe problems and it is an impediment to overall process optimization. Often feedback on all levels is necessary to keep complexity on manageable values. Some examples include:

Reduce the delivery cycle with smaller releases [9], often delivery
Use iterations, working software to slice the work
Use consumable solution [10] increments instead of just working software, to have the full feedback circle with usable and desired software (not just functional)
TDD - automated test could be used more often
Collaborative work - get in time feedback from your collaborators

Managing incertitude – This is a similar discussion with that related to the management of complexity. When incertitude is inherent, we should act accordingly - for example by using more feedback - and stop pretending that we have “predictions”. In many cases, the incertitude is a result of the high complexity of the surrounding context for both the business and the development.
Pull based approach (from Lean and lean inspired Kanban, Scrum) is an also feedback oriented way of working. The command is given in small increments starting with the real needs and not with a big upfront estimation of these needs. Pull based systems are addressing sources of waste such as Waiting, Overproduction, Inventory by reducing the incertitude.

Context!

Context! Waste, late delivery, complexity, incertitude are not our problems. These are just some categories of problems that a lean approach could solve. Concrete problems are always dependent on our situation/context. The "theory" (read: existing experience, in a structured form ~ categories of solutions) could help us not to fail and to succeed earlier in assessing of the current situation or in our intention to build a more effective/efficient way of working.

Essential Lean Series

Read first: Principles of lean thinking (by Mary Poppendieck)

Essentializing Lean - essay

Essential Lean - Searching for a definition

Essential Lean - Analyzing existent solutions

Essential Lean - Goal-Driven Lean
Essential Lean - Avoiding Defects Goal Guidance (example)

Essential Lean - Waste avalanche effect

Essential Lean - Red Flags