Appreciating Systems

Appreciating Systems for Genuine Efficiency
Home » Archive by category 'Lean' (Page 7)

Ernesto Sirolli: Want to help someone? Shut up and listen! | #Video on @TED

This is the most hilarious, serious and extraordinatry video I’ve seen in quite some time on how to change the world and help people.

Drop whatever you’re doing at the moment, and look at it now (less than 20 minutes).

That video speaks about helping people, listening, entrepreneurship, creating successful organizations, making people thrive, and hippos. Yes, hippos.

To me, Ernesto Sirolli holds the keys to successful Lean turnovers… or whatever else is needed by the people that want to thrive in their lives and work.

Ernesto Sirolli: Want to help someone? Shut up and listen! | Video on TED.com.

 

What Taylor did for the work of the hand, Google is doing for the work of the mind (N. Carr) @LinkedIn. Is this really a problem?

December 7th, 2012 Posted in Change, Lean Tags: , , , ,

Here’s a nice discussion launched on the LinkedIn group “Systems Thinking and Lean for Services”: What Taylor did for the work of the hand, Google is doing for the work of the mind (N. Carr) | LinkedIn.

I make my own contribution which I reiter here, since the group’s closed:

The original english article (from 2008) hasn’t been linked. Here is it:
http://www.theatlantic.com/magazine/archive/2008/07/is-google-making-us-stupid/306868/

A remark I just made to myself: we’re changing the way we read, undoubtedly. That we probably are also changing our way of thinking, I can understand it too.

But should it really be viewed as a problem? I mean, if you want to continue to live by thinking the way you thought a few years ago (ie, ‘deeply’), then surely you have a problem. No argument either that deep thinking allowed some fantastic inventions.

But I think there’s an (unspoken) assumption behind the article: that this new zapping way of thinking is worse than the deeper one. Surely the same things can’t probably be achieved using the new way than with the older one.

Yet, again, is it really a problem?

Humans are structurally coupled with their environment (Maturana). Their environment reflects themselves, and this is reflected also in the language they use (and inversely if we agree with the Sapir-Whorf hypothesis – now that I know Systems Thinking, I’d say there’s structural coupling here as well).

So that (new) languaging (Twitter or Facebook short messages), thinking, web surfing, zapping, etc. is the new way life is lived today. Or is going to be lived for years to come (I don’t see it changing soon: ask any teacher for instance about the trends they see).

In the article, Google is assumed to be the equivalent of Taylor. Then I suggest that Tim Berners-Lee was the Ford of Internet (he pulled knowledge online on the web), and now Taylor/Google is organizing it for us. I suspect the Semantic Web will even reinforce that (go think why! 😉

May I remind you that Taiichi Ohno came after Taylor with what was deemed to be known as the Toyota Production System (or Lean, though the latter lacks that Respect for People part, most of the time).

Should we compare the two, I’d say that where Taylor (Google) devised how to work (think), Ohno (? no replacement yet?) devised how to improve that work… without too much deep thinking, instead with constant and continuous improvement of the work.

Where Taylor split the work, Ohno used the small thinking of people to have them improve their small part of the work, then connect the dots (the parts) through A3 thinking and nemawashi (Google these! 😉

I see an enormous advantage in being able to surf knowledge on the web (for instance): it allows to far more rapidly connect concepts and ideas together, which you can only do so slowly when only thinking deep.

So instead of scarce big changes once in a while, we might end up with a flow of continuous small changes and innovations, all the time.

Toyota became the best in manufacturing doing exactly that. Why couldn’t people do the same for their own thinking?

Finding local roots for #Lean – Everywhere (@mbaudin reblog): What about here and there too? #solutionfocus

I found this nice piece of Michel Baudin regarding finding local roots for Lean to improve acceptance of Lean: Finding local roots for Lean – Everywhere | Michel Baudin’s Blog.

But then I wondered about having people “discover” that they already invented some Lean principles themselves? Maybe they just didn’t noticed or maintained them consistently over time?

This is what the Strengh-based approach to Lean is (well, at least using the Solution Focused way).

  • When have you seen this process improving? What did you do that contributed to that improvement? (finding improvements actions that work for the people here; the improvement part of “continuout improvement”)
  • How do you manage actions that you must do repeatedly? (finding ways to remember to to actions all the time; the continuous part of “continuous improvement”)
  • When have your work been easier to do? More interesting? What did you do to help create these conditions? (findings ways to improve the work that work for the people doing it)
  • Tell me about a time where your customers where satisfied with the product or services you delivered. What was it? How did you do it? (same kind of question, but for quality)
  • etc.

 

Using #Scrum, #kanban and #AppreciativeInquiry to Manage #Kaizen? Why not!

I often struggle with management giving only lip service to sustaining kaizen (continuous improvement, the problem being with continuous, not improvements which they heartfully agree to have!).

So I ended up with the strange idea of using a framework to create a culture of improving often and having a clear path forward. When the culture has changed to continuously improve, the framework can probably be ditched for something else (indeed, it should have if they improve their way of improving, see Scrumming the scrum!)

To make the story (!) short, I ended up with using Scrum, an Agile Software Development method, to manage improvements themselves.

I did a quick review of basic Scrum artifacts as per what Wikipedia lists, and it looks nice. The trick is using the team leader or anyone willing to play that role as Scrum Master (though the TL would be best).

Here’s a small file to see what matches to what, though this is quite straightforward: Scrum for Kaizen v1.0 EN.

Of course, if you don’t know Scrum, you’d probably want to have a look to Wikipedia link above and go with one of the introductory files linked such as downloading the Scrum Guide.

How to populate the Product Backlog (list of improvements)? Well, I have another idea: do an Appreciative Inquiry with the team and see what they really want for themselves, then:

  • write the Provocative Propositions from the Destiny phase on top of the Product Backlog
  • dump the result of the Delivery phase in the Product Backlog

and voilà, you have your list of (most and much) desires improvements!

Chances are that your list of AI-based improvements will be big so you might as well use a Kanban to manage all of this… So this is more technically speaking Scrum-ban, but… who cares anyway? 🙂

Someone wants to try it?

#lkfr12 : Strength-based Kanban : slides, interview guide and final handout available!

October 23rd, 2012 Posted in Lean, Strengths Tags: , , , , , ,

This year (2012) was the first edition of Lean Kanban France. David Shaked and myself facilitated a workshop about “strength-based kanban” to be used both as a tool and metaphor to boost one’s own coaching skills (whether to coach Lean or Kanban… or whatever!).

Here are the documents:

  • slides,
  • 1st generation handout (interview guide used for people to interview each other during the workshop)
  • and 2nd generation version of a strength-based kanban which you are encouraged to use, improve

…all the while to keep us informed of what great things you did with it!

Meanwhile, should you like to participate in the strength-based (r)evolution of Lean, feel free to join others on the Strength-Based Lean Six Sigma LinkedIn discussion group.

 

Don’t do #Lean, Build it instead

October 23rd, 2012 Posted in Lean Tags: , , , , , , , , ,

People read a lot of books to try to know all about Lean. Indeed, I did it myself (and sometimes still do it). And that’s OK.

But then, we try to have others do Lean as we’ve read in the books.

It’s an error.

We ought to have others build a Lean organization, not do it as per the books.

Trying to do Lean is trying to push solutions onto people, which is a sure way to have them resist.

Whether trying to build a Lean organization is about helping people find their own solutions toward Lean. As I say, it’s about pulling Lean out of the people. Not the other way round.

Indeed, Taiichi Ohno told us so: we shouldn’t try to replicate the Toyota Production System, we must grow our own. That’s the main reason he didn’t want to write down what TPS was in the first place (other reason was to avoid it becoming fixed).

Why is it, then, that we try to replicate all that Mr Ohno told, except for this one fundamental, point?

 

#TWI used to make Construction more #Lean a @linkedin discussion

In that LinkedIn discussion, the TWI programs have been used with great results (both bottom line AND, more improtantly to me, with respect to the people side of the work). Furthermore, here are three nice questions Mark Warren provided as a sort of quick coaching process to introduce the J programs. Thanks Mark!

The act of going to the work is a “Learning to See” exercise to get people in the habit of looking for problems. Then asking a few questions.

  1. Do you have a process? (No – map the process and develop a job breakdown sheet to train staff doing the job. Yes – question 2.)
  2. Do you follow the process? (No – use JR to understand why. Is it a personal issue, or are they not following the process because of other reasons? Yes – question 3)
  3. Is the process capable? (No – start with JM, however more complex tools may be necessary to resolve. Yes – what did you overlook?)

via Just completed a mammoth TWI implementation on a large construction project in Riyadh, Saudi Arabia. 36% productivity improvement within 6 months. TWI is fantastic in the construction industry. | LinkedIn.

#Lean Five Whys: when do you stop asking? Please answer here:

October 15th, 2012 Posted in Lean Tags: , , , ,

give me five! (CC)Creative Commons License Martin Fisch via Compfight

I have a question to me fellow readers.

On of the most famous Lean tools (or quality tool as well) is the Five Whys. Literature has it that one should ask 5 whys at least and that a further number of whys isn’t a bad thing. Yet, Taiichi Ohno often gives examples where the investigation is stopped at the fifth why despite one could easily have asked some further ones.

Aside from the usual caveats (doing wide whys and forgetting to go deep five levels; assigning blame to other people; etc.), what are your practices regarding five whys, and what’s your criteria for stopping?

Here’s my answer below, but please only read it after you have posted your own in a comment this post (double-click the following paragraph to have it decoded in a pop-up – an alternative way is copy-pasting the text onto www.rot13.com website).

Zl bja pevgrevn sbe fgbccvat nanylfvf vf jura crbcyr raq hc jvgu n pnhfr gung unf abg bgure shegure pnhfr orfvqr “jryy, jr whfg unir gb qb K”.

Mail List

Join the mailing list

Check your email and confirm the subscription