Never Mind The Buzzwords

Defining Agile, Lean, Kanban, Kaizen, Waterfall, Scrum, Cynefin… & why we need a Multi-Methodology Approach

I wanted to summarise definitions of some of the more popular terms that are becoming ubiquitous in business, and give basic understanding. It used to be mostly specific industries (e.g. software development) that threw these buzzwords around, but now organisations in every sector are realising the benefits of applying one (or more) of these methodologies. I’m not going to go into huge detail on each as there are many good articles which are very comprehensive out there with more depth and nuance, but I’ll go over the basic differences and applications. I’m also not going to include what you should consider for decision making and production (perhaps another article!) – rather, to briefly explain the differences and potential applications of the better-known.

One important factor to note is that the concepts in this article are not really substitutional. Some are concepts, some are processes, some are manifestos and methodologies, and some are frameworks. They may integrate and support each other well; each business situation may use or require one or more simultaneously.

As always, I’ll also treat Cynefin differently, as it is a naturalistic, scientific framework for understanding complexity and achieving coherency which can describe where the others are effective and applicable, rather than act as a tool for a specific process. Cynefin is for sense-making.

Waterfall

This is an older, rigid process which is highly ordered and constrained. It consists of a linear, sequential set of segregated phases which are always achieved in order, in one direction. It always begins at the first phase, and you only move to the next phase when the current is complete. Once the phase is complete, there is no returning to it without restarting everything.

This arose from manufacturing requiring steps done in order to achieve an end goal, so is applicable only to projects or businesses that adhere completely to the Complicated and Obvious Cynefin domains. It is extremely rigid, requiring extensive planning, strict following of steps, thorough documentation and zero role flexibility. Waterfall works in specific, limited instances where strict adherence and no deviation is required – in ordered situations where it is imperative to follow a specific dependent order (pre/post-surgery implement counting, as an example). Outside this, it cannot allow for changes, errors, or incorrect predictions, and the result can be a lack of understanding for stakeholders, bottlenecking, and longer and longer completion times.

It is still a traditional mainstay for management to apply to many situations, as it gives the feeling of control, simplicity, sustained output and logic even where these are not possible in the circumstances. This approach is heavily Process Engineering (ordered and rule based), widely misused in situations which by nature cannot be ordered, and is an example of a process “simplified and transplanted” as a recipe between industry applications.

Waterfall 

Lean

Lean was developed in the manufacturing industry, specifically inside Toyota in Japan, a result of which was the Toyota Production System (TPS), an optimised, Lean manufacturing process. It is a manufacturing and management style which focuses on eliminating operational waste, and removing unnecessary resources and complications; cutting the fat, if you will.

Lean is related to Kanban and Kaizen; the TPS integrates all three (I’ll cover the others separately). It is a lot less rigid than Waterfall, although with the addition of Just-In-Time (JIT) processing can still fall afoul of large errors or bottlenecks. It also de-anonymises stakeholders, instilling respect for those working as a principle, and values evolution of process.

Although less prone than Agile, Lean still has elements of templating and codified certification (for example, Six Sigma) which can be limiting and not apply correctly to individual organisational circumstances. The drift from reducing organisational inefficiency to instead eliminating defects and reducing variation can also introduce its own set of challenges.

Lean can be approached in a number of ways, and is a logical path for a company looking to better understand and refine value streams, production costs, and efficiency from team to organisational level. It is what companies strive to do by cost cutting and other slimming practices, but is often misapplied; it can be ordered, and leans into Systems Thinking approaches over Process Engineering (no pun intended).

Lean

Kanban

Kanban has a foot in both Lean and Agile. It is a methodology to manage and improve work in human systems based on the concepts of limiting Work in Progress (WIP) and flexible throughput – think of it as a Lean approach to Agile.

The word means “signboard/billboard”, and is used in Japan in a number of ways, not as the concept of applying “Kanban”, but often more naturally. The basis of Kanban is to find the weakest bottlenecks in a system and smooth the flow through the chain to allow optimum continuous delivery without buildup at critical points.

In other words, the flow Pulls as capacity of flow permits, rather than Pushing when work is requested.

This was used in production with TPS to augment other Lean practices and ensure the most efficient throughput possible. It is a visual aid in decision making for what, when and how much to produce – Kanban is concerned with limiting resources and work to deliver a smooth and ultimately more productive workflow.

A basic Kanban limited WIP progression

Kaizen

The third part of the TPS triumvirate. Kaizen means improvement, and is taken in business to be “continuous improvement” of a process, which originated in manufacturing but has become very associated with software and DevOps/OpsDev.

Kaizen is as much a culture as a lean practice, not a systematic process applied at a single point; it requires investment from all stakeholders to achieve, and must be implemented from leadership down.

It is not enough to simply fall into a rigid adherence to a single workflow, because circumstances in business change all the time. Kaizen is the ideal of always striving to become better, whatever the circumstances, to reach to optimum throughput of value.

A Kaizen continuous improvement cycle

Agile

Agile as a core concept is a framework based on a manifesto. It is somewhat related to Lean practices, but emerged from a variable, complex environment (software development) rather than a complicated one (a production line or single factory business unit, for example). This makes it uniquely suited as a set of ways of working with industries or business units that are in constant flux.

Agile was conceived to adapt to both changing requirements and customer needs, but also to cut waste, and deliver value faster by using an iterative and incremental approach.

This has seen some success, because an adaptive approach will by nature be able to integrate with many different organisations and situations, but it is also seeing some problems. By its very nature, Agile is an agile concept – flexible, organic, and applicable to a variety of situations. Once over-constrained to try to make it easily repeatable, it ceases to be agile; if you succeed in turning Agile into multiple-choice Waterfall, you have removed everything that makes it effective.

There are a number of approaches with greater or lesser constraint. Scrum is a methodology of applying Agile. Scaled Agile Framework (SAFe) is another; XP, and IBM’s recent push of their Agile Thought Leader certification, yet others. None of these represent the actual core concepts of Agile, but take from those core concepts. They can be effective – or lose effectiveness – in variable amounts and circumstances.

In fact, the further we go into certifying, codifying and constraining Agile for templating, the further we move from agility, and the more concerned we become with dogmatic definition and display over the fundamental principles and application. Not having qualifications in the above doesn’t mean you can’t work or think Agile, and by introducing a restricted path to becoming agile, they may constrain and diminish agility. But what this does is allow humans to feel comfort and grounding.

What is being marketed by many consultants and businesses, then, is not Agility per se, but predictability. Constrained Agile practices (in my view) are designed to give some cessation of uncertainty, not a guarantee of agility of practice. The more certainty humans have, in fact, the less relevant agility they are likely to have, and vice versa. Each situation is different, and that’s what an Agile approach is really all about – preparing for and reacting to change, in context, in whatever way is required.

This is a strange dichotomy, similar to that of security vs accessibility; they are mutually exclusive. To be more secure, something must be definition be less easy to access; to be accessible, it must be less secure. To have certainty and predictability, something must be less Agile; to be more Agile, there is by nature less recipe-template copying possible. The best application will require analysis of a situation and balanced application.

An Agile overview

Cynefin

Cynefin, as seen in previous posts, is a way of understanding human decisions and complex situations scientifically. As is all science, it’s an evolutionary work in progress, constantly refining and being refined. It is concerned with sense-making, which is allowing data to define possible solutions, rather than categorisation, which is forcing data into preconceived constraints to fit expectations and limits possible solutions.

There are several methodologies that consider decisions similarly (the Stacey Matrix is one, albeit different in approach); Cynefin was born from Dave Snowden’s explored processes when he worked at IBM Global Services to help manage intellectual capital, and then developed further into a framework using scientific methods to evolve and comprehend (what ended up being understood as) complexity.

The Cynefin Model

Currently Cynefin consists of a 7-Domain model: 2 Liminal (Open, Complex <-> Complicated, and Closed, Chaos <->Complex), one investigative (Disorder) and 4 main domains (Chaos, Complex, Complicated, Obvious), with each of the 4 having a sub-domain containing 9 distinct areas, only the centreline of which gives coherent transitions to the conjoining domains.

Cynefin Sub-Domains, Liminal Domain Transitions, and the Path of Coherency (Cognitive Edge)

The Obvious domain and the Complicated domain are both ordered domains. Complex and Chaotic domains are unordered. Each domain has unique Practice that is applied, and a different methodology of decision making in order to sense-make. Each has its own action process; each has different numbers and types of constraints that define it.

Cynefin order and un-order

In its simplest form, Cynefin allows you to categorise and understand a situation’s basic state. In its deeper forms, it allows highly detailed understanding and application of concepts to resolve events in the best possible favour.

Scrum, Agile, Lean, Kanban, Kaizen all fit into the liminal domain between Complexity and Complication; methods of transitioning, probing, and resolving from unorder to order (and back, potentially). Waterfall fits into Complicated/Obviousness (order), and is limited precisely to those areas. As soon as a transition occurs away from order, it is not suitable any more.

Cynefin deals with the Social Complexity quadrant of the epistemological matrix, which is unordered and heuristic, reflecting the humans than define, drive, and live within it.

Cynefin Knowledge Management Matrix (Cognitive Edge)

Conclusion

Hopefully this has outlined these concepts! I think it’s interesting that, in every example above where there is a certification track, business nature becomes very quickly more focused on the qualification than the core concepts, because it’s a trackable identifier (even recently when I was asked what I did and I said I was a teacher of teachers, I was (fairly aggressively) asked, what are your qualifications that you can say you’re a teacher?, suggesting the conditioned adherence to an identifier not the years of available results!). The trap here is that a certificate gives only a signal that the consultant/etc is experienced at certain aspects, and a level below that is that the certificate track can actually be a sign of a misunderstanding and misapplication, or to put it better, an ossifying of the core concept.

It is important to understand that a certification or qualification is the beginning of understanding and application, not the end.

For me, as with most things in life, this comes down to a balance; it is possible to achieve a level of agility in some areas and a level of certainty in others, and all of these concepts, as we have seen, have their places (and times) in complexity. You cannot therefore simply template, simplify, condense, and certify (and thereafter not deviate) without running into the undeniable reality of variance (especially when you seek to remove all variance!). No one approach is perfect; a combination of them all is often required, with the understanding that Cynefin and similar frameworks are methods of comprehension.

Every one of these approaches relies on communication, learning, and investment to succeed.

Why we should be Contextually Multi-Methodology

Interpersonal connections, agile management, waste management, resource flow management, continuous delivery and improvement, complexity adaptation and exaptation, value and delivery coherency and teaching and learning patterns all combine into a holistic (or symbiotic) method of understanding, cohering and progressing at every level of an ecosystem. This is something I realised I have an overarching approach to which is contextually multi-metholodogy.

Understanding and choosing when to use any or all of these is critical; all too many organisations pick one they like – a buzzword, or one traditionally used, or a fad, or that worked for another company – and focus on that one, without realising that the entire landscape may require shifts between them (or multiple applications) to maintain effectiveness; contextual multi-methodology is an agility overall, behind the currently accepted variable definition of Agile.

Finally, we need to use the principle to succeed, not be seen to be merely using the name of the principle. The two are not the same.

I hope this has given an interesting overview of the terms; what I use is an ecosystem approach that exists between all of these concepts, and the teaching and learning pattern specialisation binds them all together and allows them to be communicated and understood effectively.

There are plenty more concepts and frameworks out there that are as efficacious as anything here. More on those another time!

All frameworks, concepts and methodologies discussed in this article are the right of the originator.