IN  SEARCH  OF  LEADERSHIP  THAT  MATTERS

Why aren't Lean and Agile collaborating?

Debunking the myth that Lean and Agile are the same

To the Agile community this question may seem strange. Many Agile practitioners regard ‘Lean’ and ‘Agile’ as almost synonymous. Yet if Agile people were to move away from their screens into the Gemba world of Levelling, Value Stream Mapping, PDCA Problem-solving, 5S and Andon, then it is hard to believe they would still be saying that Sprints, Scrum, Backlogs, Retro reviews and Done are the same thing. Nothing could appear more different.

Of course this depends on which definition of Lean you take. I use ‘Lean’ as first described by Womack, Jones & Roos in The Machine that changed the World in 1990 to denote the Toyota production and management system. The original advocates of TPS wanted to de-contextualize it from Toyota, to capture its generic principles applicable beyond cars, beyond manufacturing, and so gave it the term ‘Lean’ at the time; sometimes to their regret, as the term has created as many problems as it has solved; the term has mislead many along unintended paths (e.g. Six Sigma), or it has been misappropriated for almost opposite intentions (e.g. as in 'lean and mean').

So why are Lean and Agile not talking to each other? The Agile and Lean communities appear to have quite different personalities. Agile are very active, with an open source orientation, more inclined to share, as is evident on the hundreds of meet-ups and conferences. On the other hand Lean advocates tend to be more secretive, appearing more distanced, with comparatively little in terms of sharing, except with the already initiated. Lean sometimes comes across as an old-schoolboy network, with an engineering penchant, despite it operating in a very hands-on Gemba environment. As a result of it being more publicly active, Agile has thus spread much more quickly within organisations, and appears to have a stronger hand in terms of appreciation in the business community.

Due to Agile’s success and potential in the new world, some leaders are now talking of taking Agile Beyond Software. Yet if Agile is to start spreading beyond software, it will also have to start talking with Lean and those physically adding value in the world. Lean and Agile are probably the two strongest and most tried and tested alternatives to the 20th century plan, command and control bureaucracy approach, so together they could have a major impact on the future of business, the future of organisations and the future of work. But if Agile is to move beyond software or if Lean is to move beyond production, then they do need to be talking to each other.

On the surface Agile and Lean appear to have little in common (except to Agilists who have the Lean Startup in mind, which would better have been called Agile Startup to avoid the confusion it has caused). Agile’s talk of Scrum, Product Owners, Backlogs etc. is pretty meaningless to Lean people, while TQC, Levelling, Andon, is meaningless to Agile people. Some terms are common though, such as Kaizen and Kanban, yet even there the concepts are different, Kanban for instance moving in linear motion in Agile, whereas in Lean the motion is circular (more about that later)!

So what are the differences that prevent the two proponents from talking to each other? And what could bring them together? First of all, it has to be said, they do operate in different worlds: Agile is very much about efficiently developing software coding on screen, a creative process. Lean is about moving, building or healing things or people physically.

Lean is concerned with making or repairing things effectively, partly by removing work that does not add value. This includes reducing wasteful processes, achieving zero defects, maximising feedback loops, working with one-piece production etc. Lean works best for routine, repetitive tasks: hence you will find Lean applied in manufacturing, hospitals, transportation, healthcare, logistics, construction, banking and other business activities which are fundamentally repetitive in nature, where operations are repeated over and over.

Agile is about designing things, primarily software, but in an iterative way, using a try and test approach (as opposed to the grand design, or Waterfall as Agilists call it). Agile is appropriate in non-routine development tasks, where creativity and innovation are key. Applications can be found in software development, the creative industries, broadcasting, marketing and many forms of project management (each project being unique). But it can also be found within basically Lean environments, such as new product development within car manufacturing (indeed as cars contain huge amounts of software nowadays, lean manufacturers are now, ironically, one of the biggest employers of agile software developers).

So the distinction is less about industry and more about the type of work being done - within each business there is usually a predominance of one, with elements of the other. So, for instance, newspapers are completely different each day and highly unpredictable in advance, while at same time there are daily deadlines to meet, which also create a routine element. And of course in car manufacturing, routine repetitive assembly of components to make a car in factories is counter-balanced by the product development engineers designing the next model, which is everything but routine. It is then maybe not so surprising that some of the wording of the Agile Manifesto of 2001, the core of Agile, can actually be found in a Toyota Operations Manual of 1989, albeit as descriptive principles rather than manifesto statements. Lean and Agile do indeed have the common roots!

                                                

But let’s look at a specific example of the differences between Lean and Agile, alluded to earlier. Both Lean and Agile use ‘Kanban’. In Agile ‘Kanban’ are used as a way of tracking progress of various team development tasks. A task is noted on a Kanban and posted in the Backlog, where all tasks can be prioritized into sprints. Once the task is in progress it moves to a Doing or In-progress column, and finally once completed it is ‘Done’. The Kanban moves from left to right in a linear fashion and the card ends up in an archive or in the bin.

In Lean, on the other hand, the classical Kanban (nowadays a lot of this has been replaced by bar-codes readers and computing) move in a circular fashion, as a way of controlling order quantities. The Kanban moves with the part or parts to the assembly line, clearly identifying the part(s) for the operator; once the part is ‘used’ in assembly the 'empty' Kanban (with the empty box or palette) moves through logistics back to the supplier, and this tells him/her to make more of the same parts; these are then delivered together with the Kanban, thus making a full circle, the Kanban is constantly reused.

In the latter case the movement of the Lean Kanban clearly illustrates the repetitive nature of the tasks, hence the circularity - the Kanban is a self-regulating feedback mechanism controlling order quantities and the flow of parts. Whereas the Agile Kanban denotes a one-off nature of each task, hence the linearity, there is no repetition, so no loop (of the task itself). To the Lean practitioner the linear nature of Agile Kanban may appear bizarre, yet it is not ‘wrong’ – after all Kanban just means notice board or information card.

So if Lean and Agile are so different, how can they possibly be related? Where do they overlap? In essence Lean and Agile are quite different technically, in terms of how they manifest in the workplace. Where the two are deeply connected, however, is in the people development and leadership side of things, as follows:

• People before process – hitozukuri (developing people)
• Total focus on customer (direct interaction or internal customer….), again people
• Work in circles or cells using similar tools, e.g. A3 PDCA and backlog & retros
• Continuous Learning & Improvement, adaptive learning organisation
• Jidoka – ‘autonomation’, develop people so can solve own problems
• Teamwork, collaboration, partnerships – and underlying all of this: Transparency
• Common root: Jidoka & Hitozukuri, with the workplace as a place of respect, joy, self-development.

Agile and Lean are also quite complementary. For instance Agile operates well at a team level, but struggles in wider organisational context.  On the other hand Lean is a scaled whole integrated system, made up of different parts and practices, with the whole becoming a system in its own right. In many respects Agile is not only derived from Lean, but is also a special case of Lean, one that works particularly well at a development or project team level. In other words Agile can be seen as a special instance of Lean where standardised routine is irrelevant. Many people say that Agile does not scale, whereas Lean quite clearly does (and indeed must to work properly) operate at a company-wide level.

So while it is clear that Agile is a major driving force that may help organisations to move to a next stage economy, it should also be clear now that if it is to move beyond the team level, and beyond I.T., then will have to take a wider systems view, which is precisely what Lean offers. Lean is a human-centred whole system approach.

Unfortunately, however, Lean is often seen as a production or engineering matter in the West. Most jobs associated with Lean in the UK for instance are advertised as ‘Lean Engineer’, ‘Kaizen Engineer’ (or consultant), ‘Process Improvement Engineer’ and so on, clearly illustrating the view that Lean is an engineering redesign problem rather than a human development one. And this is not without an element a truth – the whole point of self-development and actualisation of all workers in Lean is that it is not something that is done abstractly in self-development workshops outside work, but on the contrary it is done by constantly improving one’s craft on the job itself, in teams through the job in the Gemba of the job, and thus it is connected to the workplace engineering, artistry and craft. However the human development part often gets dropped or forgotten in Western firms, leaving the workers, nurses, clerks, operators and customer service agents largely ignored, and ‘training’ is seen as a technical matter.

Lean thinking in the West needs to shift from purely looking at its technical process-oriented side to the more people-centred one of respecting all those adding value and developing them to become their own problem-solvers, with teams becoming energised, autonomous and self-organising. This represents a fundamental shift in ‘management’ mind-set, one from being planners and commanders to being steward coaches, like gardeners, nurturing the workforce to develop and thrive. This was always part of Toyota’s make-up. Instead of hiring managers to order people around and control them, use resources to invest in people from the bottom shop floor up, and tap into the latent collective holistic talent.

A lot of Agile and Scrum shows up in certain techniques, yet their fundamental philosophy is anchored in the Agile Manifesto, which is not about technique, but about people – putting people first. Like-wise Lean has a technical side: Heijunka, 5S, Pokayoke, SMDC, waste, Pull, TPM, and so on; yet its essence is the other side, Hitozukuri and Jidoka, which are all about people respect and development. Yet in both Agile and Lean it is the people side of things that most Western companies have not comprehended so well - and this has lead to the many Agile or Lean let-downs and disappointments.

Taichi Ohno and Seiichi Toyota talked of building armies problem-solvers. Which is better? A select few of very intelligent people who do the thinking for everyone else, or a whole army of workers connected to the work, given the tools and empowerment to work things out together themselves?

Many Western leaders, focussed on shareholder value rather than customer value as they are, do not get this. The ones who do get it, however, are the Chinese, the Indians, the South East Asians, the South Americans and the Africans. Never mind the many Toyota-likes in Japan, check out Tata or HCL in India, or Haier in China. It should then come as no surprise if we in the West are not soon left behind reeling.

If only we could get Agile and Lean, the two strongest alternatives to 20th century Western shareholder bureaucracy, to talk to each other, at a human level!

Wherein does the difficulty lie? Well in the first instance neither Lean nor Agile seem to recognise each other. They do not even realise they are two separate approaches, both fundamentally different technically, while also being of the same stock. While it is equally important to recognise their commonalities, if they do not understand their differences they fail to recognise how they could complement each other, collaborate and create a force for good.

This failure to recognise each other may partly be because their main places of operation, physically, are quite different. Lean works in production and logistics facilities, on the shop floor, or in the wards of hospitals, or in the aisles of supermarkets, or at the counters of banks and shops, or in customer service call centres, and so on, often places where the workers are the least well paid in the organisation, despite being the ones that make things happen and add value. On the other hand Agile works in computer labs, in digital teams and in project teams, where the information or innovation 'workers’ are actually engineers and software developers, often very well paid. And therein lies a natural rift in mutual attitudes, which is difficult to bridge.

Moreover, the two not talking to each other also reflects the same difficulty that marketing and I.T. have difficulty in talking to each other, or HR with engineering, or Sales with Production. We have been taught to specialise, to think in our specialties as the experts in very narrow silos, and our organisations are highly fragmented, the left arm often not knowing what the right one is doing. It is the same silo schism found between functions in most organisations.

The genuine inability to understand each other, to relate to one another, is a major stumbling block. We operate in different worlds, different mind-sets, different frameworks, using different rules and rituals. This is what has to change. We need to reactivate a Renaissance mind-set. We need to nurture cross-disciplinary thinking. We need to cross cultures, cross functions and other divisions; we need to learn from each other. And in particular we need Lean and Agile to start genuinely talking to each other.

Pan-organisational conversations and mutual understandings are sorely needed, scaled across whole organisations. One way we could initiate this is through two- or three-day cross-departmental Open Space platforms. I invite you to think of other ways. Cross-functional conversations are sorely needed. Lean and Agile together have the best chance of creating collective impact for a better future. Let Lean and Agile really meet!