The original Lean "versus" Agile for knowledge work - or is it "and"?

I wrote recently about why you think your organization wants agility. I also wrote about comparing the Kanbans (including Toyota Kanban), Kanbaning your Scrum, and I started a series on comparing the patterns (or none) for dealing with multiple teams (to be continued this week).

Today I wish to reflect on Lean Vs Agile. I'm referring to Lean Manufacturing vs Agile. Lean has its own principles, and Lean has been divided up into a number of areas, over the passage of time. I am neither referring to Don Reinersten's work, The Lean Startup, Lean UX, Lean Kanban (LKU) nor Lean Software Development. In this article, I am focusing on the original Lean but for knowledge work that is mostly unrelated to software development.

Some people believe that Lean is Agile. Agile is defined by the Agile Manifesto and its principles. Agile originated in software development and is beginning to "go viral" in non-software. The December 2017 update to the Scrum guide made the use of Agile in non-software official. One should always double check if Agile / agility can help in one's own business domain, regardless of what the Scrum Guide says. Afterall Scrum is only one option from the Agile family of methods/frameworks. And there is nothing stopping you from going right back to the Agile Manifesto, although you need to work with people who can operate from principles without rules, unless you made up your own rules/methods/frameworks.

 

I know some methods are categorised as Lean/Agile and I dealt with that in a previous post. I'm talking here about the original Lean Vs Agile. I guess it's more like Toyota Production System vs Agile. Some organizations see Toyota as their role model and to that end mimicking Toyota can seem attractive. "Isn't Toyota agile?" is something I hear every now and again. I guess the right answer depends why you want agility. And to give Toyota credit, they recently announced an investment in Uber, the kings of Jobs To Be Done, to work on the self-driving-car.

Lean or Agile, I would caution about copy & paste. You need what's right for your context.

Nevertheless, there is no doubt about the capability of:

• Value Stream Mapping to identify opportunities,

• flow/process Kaizen events to fix short term problems (3-5 days kaizen events with say 21 day close-our period),

• 5s to improve efficiency,

• Kanban to reduce process lead time by optimizing work in process,

• Single Minute Exchange Of Dies (SMED) for reduction of setup time to add flexibility

• understanding the impact of constraints vs bottlenecks.

• daily huddle boards for focus (see also) not to be confused with this version from the author of ScaleUp or the Daily Scrum

• Obeya or "war rooms" for getting traction on issue management from senior leaders, see also

Being an avid student of change, I also see potential from the Lean Transformation Model to transform the organization.

Lean has been around since the 1990s, kind of like some of the methods that were later grouped under the umbrella of Agile in 2001 when the Agile Manifesto was agreed. But Lean has really been around since the Toyota Production System. So Lean has an edge by having more case studies, not that Agile is short of them either. But there is a scarcity of case studies for Agile in non-software, so people like myself are breaking new ground there. Given the viral contagion of agility in non-software, I expect to hear about many case studies by the end of 2018 /early 2019.

Both Lean and Agile can improve efficiency, flexibility, and quality. Agile is more at home with effectiveness 1st, efficiency later; it primes adaptiveness also, "turning on a dime for a dime". Indeed, one could also argue that about the Lean Startup, which some argue didn't work out for GE, or that it worked really well.

Let's remember we're comparing original Lean vs Agile.

My concerns about using Lean alone for agility are as follows:

 

• This is only a small thing and it can make a difference. - the house of Lean relies on the metaphor of a house. That's very different to the metaphors of a garden and gardening. Pick a misleading metaphor and it can put you off the scent with over-simplification. Agility is about metaphorical gardening to ensure the metaphorical garden grows beautifully. Who knows what metaphorical plants (innovations) we'll end up with? Bigger isn't necessarily better, but can be. It's kind of hard to beat Kew Gardens in London.

 

• the drive for accountability in Lean vs the fuzziness of accountability for agility - I love Yves Morieux's relay race video where he talks about the holy trinity of clarity, measurement, accountability - the bottom line is these three pillars make human efforts derail and Yves advises us to instead "embrace fuzziness" in order to improve cooperation

 

• multi-learning is officially part of Lean, I just don't see it as often as I see it with agility. Indeed Toyota has silos, but it's also like a family. Most patterns for agility require multi-learning, and the deepest forms require a "flipping of the system" (or operating incognito) so that teams are structured to cooperate in a cross-functional organization without silos, where people are measured on the number of materially different skills they have, and the number of skills they can coach others on. For example you could use Beyond Budgeting with Large Scale Scrum or as we say in Ireland "whatever you're having yourself".

 

• innovation - on paper, Lean is lacking is this regard. Toyota brought us the Prius and the Supra is being relaunched (with BMW inside cabin look) so it's not like innovation is zero. Scrum needs help with innovation. In practice, good Scrum folks will add customer/product/Jobs-To-Be-Done research Product Backlog Items (PBIs), avoiding the separation of "test & learn" (Design Thinking / Lean UX) from delivery teams, to reduce handoffs and improve adaptiveness. That's very different to knowing already how to solve problems, problems that are obvious or complicated (but not complex)

 

• complexity according to the Cynefin Sense Making Framework - with unknown unknowns or unknowable unknowns, our work in basically unplannable. Holding people to account for fictitious dates will ultimately lead to a lack of openness in the long run, one of the Scrum values. In relation to incompatibility for complex work and arguably chaotic work (Cynefin), fixed scope with deadlines is not the smartest way to embrace uncertainty (although maybe for building trust where there is none yet). And while Scrum (even with Design Thinking / Lean UX /The Lean Startup /do-it-yourself/pick-your-poison combined) can struggle with chaos, the original Lean is hardly a novel approach and therefore is unsuited to going into chaotic innovation by choice. Scrum is more comfortable than original Lean for complex work given its close-to-probe-sense-respond approach (even if Scrum is in the liminal). Agile has other novel approaches for dealing with chaos. For all of my chaotic problem recoveries in the past, I went back to basics with Scrum as it was novel in those contexts, and it worked well, if I did get more directive than usual.

 

• Current mental models can remain more unchallenged by original Lean, and progress is measured by the prevailing mental model, e.g., Toyota is the role model, and we're . not open to other potential role models. The original Lean is more prone to single loop learning (Toyota Kata aside), instead of Agile's double loop learning. System modelling would be an example where people are attempting to better understand the system, opening themselves up to other mental models.

 

        a better metaphor for growing agility than building a house is gardening

 

"When will it be done?" is a damaging question when dealing with complexity & uncertainty. Leadership needs to be about blaming those who fail to help or who fail to ask for help, over blaming those who fail. According to Richard Hackman's research, over 80% of a team's performance is determined by structure, with <10% from coaching after team setup. Indeed, the counter-measures to the 5 dysfunctions of a team are remarkably similar to the Scrum values. Daily Huddles and War Rooms tend to get facilitated by senior leaders. Lean & Agile can provide alignment , and the level autonomy depends on the level of servant leadership. Taken to the extreme, command & control with blame game is a good strategy to bring about the 5 dysfunctions of a team. I put it to you that the ideal for dealing with complexity 21st century is aligned autonomy, self-managing teams, and Team of Teams.

My concerns for Agile teams (whatever the approach with methods or none) reporting into "war rooms" are as follows:

 

• mindset incompatibility - accountability for dates at Lean "Daily Huddles" Or "War Rooms" no matter what complexity has arisen, if there is a lack of servant leadership, there is potential to embarrass people when deadlines are not met, resulting in less likelihood of discovering truth in the long run

 

• metrics orientation can lead to what agilists worry about most - metrics that get gamed. Agilists prefer trending measures, measures that even if gamed lead to better outcomes, e.g., reducing Product Backlog Item size (as long as PBIs are still valuable to the customer / end user - in other words not setting up PBIs to have meetings:) ) - that said Professional Scrum with Kanban's use of flow metrics is a welcome addition (see Kanbaning your Scrum)

 

• likelihood of dilution of Scrum's definition of done for quality in the chase for deadlines. In Scrum.org, we teach that if you were to summarize Scrum in two words, they would be "done increment", with more words "self-organizing teams and empiricism". The "Definition of Done" in Scrum (the most popular method/framework) fixes quality, and we dare not compromise that if we want Scrum. But by holding people to account, treating Sprint Goal commitments as guarantees, just guess what fallible human beings might do?

An exception to combining original Lean and Agile would be the twist provided by Professional Scrum with Kanban, given that Scrum is "rule 0", and therefore empiricism and quality still rule. Besides, as I cover in my spot the difference article, Kanban for knowledge work is a different beast anyhow.

In addition, due to the Tuckman phases and the difficulty in being Agile initially, I recommend Scrum only for medium to long term teams. If you have a short term problem, perhap use daily meetings, mob/swarm/co-locate, or maybe use a value stream map and a kaizen event. Unless your potential Scrum Team members are highly confident of getting to norming and performing quickly, my advice is don't use Scrum for teams that get together for only a few weeks; performance can get worse in the short term and you won't get to see the benefits as there is no medium term. Even using Lean Kanban (LKU not original Toyota Kanban) in the short term leads to things appearing worse as aged items in progress that were rotting in the system due to re-prioritization of in progress work and resulting flow debt then finally get delivered. These sudden completions clock up horrible lead times before (in the medium term) things get better (even though finally finishing items can be good, providing they don't provide negative value). Limiting work in progress is also a revolutionary change for people.

Cynefin and time-period for the team(s) are central to deciding which approach to take. Here is a reminder for you...