For decades U.S. and western European car manufactures ignored the production methods used by the Japanese car manufacturers. As Toyota demonstrated incremental and continuous sales gains, eventually the U.S. and western European car manufacturers could no longer rationalize their market losses to other causes. The development of the Toyota Production System (TPS) started in the late 1940s, building on Eli Whitney’s interchangeable parts (late 1890s) and Henry Ford’s Model T continuous flow assembly lines (1910). As part of studying the TPS, in 1987 the western term “lean” was coined to refer broadly to the principles, processes, and practices derived from these learnings about the TPS in a manufacturing context (ex. lean manufacturing). However, my use here refers more to what is sometimes called 2nd Generation Lean (ex. lean management, lean thinking); lean principles, processes, and practices evolved, adapted, extended, and now being applied in digital and software product and service development contexts, and professional services (ex. healthcare).

Regarding “What is agile?”, early I found this description to be helpful: “Agile is a “mindset described by four values and twelve principals of the Agile Manifesto (2001), and manifested through an unlimited number of processes, practices, and tools. Implementing processes, practices, and tools, without the agile mindset the values, and principles of the Agile Manifesto is NOT agile” (see Ahmed Sidky, Riot Games and ICAgile).

Combining the above, I see lean as the philosophy for the foundational principles that guide the creation of business agility. That is, the lean philosophy provides insights into how each organization would adapt their processes and practices in ways that are specific to their business domain and unique business context. 

The concept of “kanban” (visual signal or signboard used to regulate flow) has been around for some time, gaining greater awareness from the study of the Toyota Production System (TPS). TPS, originally simply called “just-in-time production”, used kanban to implement “pull” scheduling (in contrast to “push” scheduling) as a means to developing a JIT capability.

Pull scheduling seeks to balance the intake of work to the measured capacity of a workflow system and is central to the Kanban Method’s demonstrated ability to create smooth (even) and predictable flow of outputs in the development and delivery of quality (fit for purpose) products and services. David J. Anderson (see book titled “Kanban”, 2010) was one of the earliest (2004) to apply pull scheduling concepts to IT related product and service workflows, and this work continues to be developed further by a growing world-wide Lean Kanban community, as an alternative (non-prescriptive) path to enterprise agility.

The Kanban Method’s three agendas, nine foundational principals, and six general (core) properties/practices do not constitute a specific product or service development framework, process, or methodology. Rather, they provide a minimum of guidance in the way of enabling constraints, and controls to create meaningful and needed focus for organizations and their teams on where to effectively direct evolutionary and continuous process improvement efforts on current product and service development frameworks, processes, and methodologies, while allowing the maximum flexibility on how to implement them in their specific context.

The “Agile Manifesto” arrived (2001) with its initial focus on creating an “agile mindset” in the development of software. About this same time lean management and thinking started expanding beyond its manufacturing roots and emphasis on simple waste elimination tools, into product and service development, and professional services and a shift toward a focus on improving value-creation.

The Kanban Method’s general properties/practices reflect this as well with guidance that leads organizations and teams toward first stabilizing their product and service development workflows, then toward establishing a (flow) capability that produces observable, repeatable, measurable, and predictable delivery of value (Stabilize -> Flow -> Pull -> Improve).

An effective implementation of this general guidance would also require organizations and teams incorporate the use of value-adding related metrics (measurements), such as their customer’s experienced end-to-end product or service delivery time (lead time), their current product/service delivery capacity (product/service delivery flow rate), in addition to related quality metrics (ex. return/cancel rates), and customer satisfaction metrics (right product/service, right time/place, right price/quality).

While the words “Iterative” and “incremental” are not explicitly stated in the Agile Manifesto, the notion of iterative and incremental development is definitely embodied in the “agile mindset.” Working in an iterative and incremental manner allows organizations and teams to leverage learning from a previous iteration sooner, or even immediately, in a subsequent one, and the ability to respond to external information that only became available recently. However, nothing in the “agile mindset” limits the notion of iterative and incremental to design/development and build/delivery activities and outputs.

While transitions to using iterative and incremental approaches for the design/development and build/delivery activities at the team levels are frequently observed, it is not uncommon for planning and management activities and their deliverables (ex. budgets, capacity allocations, project funding, delivery schedules) to continue being performed as a one-time (single iteration), big-batch (single increment) immutable outputs, never updated in response to learning or new available information. This “mismatch in frequency” often contributes to an inappropriate application of “just-in-case” thinking during the annual planning events, which in turn swells the intake demand, overloading (congesting) and choking the product and services development and delivery capability of many organizations. The result, as the year-end approaches, is often little or poor value delivered and little or no predictable flow to customers.    

Addressing this “frequency mismatch” is one of the challenges organizations and teams must address to fully leverage the benefits (increased cycles of learning and value delivery, and greater strategic business agility) of an iterative and incremental approach. Pull scheduling and portfolio-based/probabilistic forecasting (vs project-based/average-based estimates) are some of the tools being effectively used to leverage the higher frequency of learning events and opportunities to respond to new just-in-time information.

The foundations of XP (eXtreme Programming), one of the earliest agile software development methodologies, were developed prior to the Agile Manifesto, during the ’80s and into the ’90s. In essence, its early use and development served as a testing ground for applying an “agile mindset” in developing software, and a number of the values and principals later reflected and captured in the manifesto.

It consists of a small set of values, principles, and practices (originally twelve, now thirteen by some counts). Initially, teams were coached to apply all practices (or it wasn’t XP). As its use expanded well beyond the community that developed it, today the advice is typically to start with the small core of practices (test-driven development, pair programming, refactoring, and simple design), then add other practices as proficiency and learning are developed. However, a number of the underlying values, principles, practices are transferable beyond the IT and software development context and can provide significant and similar “lean thinking like” benefits.