Loading ...
Sorry, an error occurred while loading the content.
 

RE: [leandevelopment] Re: Process or People?

Expand Messages
  • Mary Poppendieck
    The Chief Engineer is a senior manager. He creates a vision - often through metaphor - and spends a lot of time walking around - going to the gemba - making
    Message 1 of 129 , Aug 12, 2007

      The Chief Engineer is a senior manager.  He creates a vision – often through metaphor – and spends a lot of time walking around – going to the “gemba” – making sure that the vision is understood.  When the people working on the design cannot come to an agreement – and this is not often – he will defend his vision with a decision. 

       

      I know how this works because I spend some years as a product champion at 3M.  Believe me, the objective was not to make decisions, but to create the right environment so that the right decision would be made.  After all, many of the key people on my teams were there BY CHOICE, and if they didn’t agree with what was happening, they could very easily find a different way to spend their time, and there was nothing I could have done about it.  My job was to create an environment where all those people choosing to work on my product really believed that it would be successful, because that is why they choose to work on it in the first place.  So yes, I had to sometimes defend the vision so as to make sure the product would be successful in my eyes and in the eyes of the team.  But I avoided making decisions if at all possible, because I wasn’t in a position to make good decisions –all those smart people on my team could do that much better than me.

       

      Mary Poppendieck

      952-934-7998

      www.poppendieck.com

      Author of: Lean Software Development & Implementing Lean Software Development

       

      From: leandevelopment@yahoogroups.com [mailto:leandevelopment@yahoogroups.com] On Behalf Of Alfvin, Peter
      Sent: Sunday, August 12, 2007 11:29 AM
      To: leandevelopment@yahoogroups.com
      Subject: RE: [leandevelopment] Re: Process or People?

       

      Mary,

       

      Re: Senior managers do not make decisions.

       

      As I recall from one of the Liker books or your explanation, the chief engineer for a particular product at Toyota does make decisions about the product, but in many cases has to "sell" their decision to the functional departments.  Is the Chief Engineer not considered a senior manager?  And in selling his product decision to the functional departments, is the chief engineer not dealing with the head of that department?  If so, is the head of the department considered a senior manager?

       

      Maybe we should avoid or define the term "senior manager".

       

      Pete

       

       


      From: leandevelopment@yahoogroups.com [mailto:leandevelopment@yahoogroups.com] On Behalf Of Mary Poppendieck
      Sent: Sunday, August 12, 2007 9:49 AM
      To: leandevelopment@yahoogroups.com
      Subject: RE: [leandevelopment] Re: Process or People?

      To answer your question about extending the concepts that Ohno had across large organizations or projects, all of my instincts and experience call out for breaking the dependencies, because they are causing huge waste.  That, of course, is far easier to say than do.

      One hint, though.  At Toyota they have what is called “True North,” which is an understanding of the direction everyone should head. Kaizen means change for “the better” – so what is “better”?  Some organizations might call this strategy but Toyota calls it “True North” and spends tons of time educating everyone in the principles which constitute “True North.” 

      As you probably know, it is extremely difficult to have an argument with someone who is operating from an entirely different set of assumptions than yours.  Unless you start on common ground, you can’t make much progress.  A paradigm shift occurs when one party or the outer changes their underlying assumptions.  So the idea is to get everyone on common ground regarding underlying assumptions or mental models.  I will bet, for example, that the word “process” evokes very different mental models in people with different experiences.  So it is not enough to use the word, you have to synchronize mental models as well. 

      Back to the size:  Designing, building, distributing, and selling cars is a huge undertaking. I don’t think that putting the Lexus on the market was any smaller “project” than most of the software development projects I run into anywhere.  How does Toyota do this?  There are a lot of explanations, but I think the central one is systems thinking, focus on the “gemba,”  and an understanding that senior managers DO NOT MAKE DECISIONS.

      Cheers,

      Mary Poppendieck

      952-934-7998

      www.poppendieck.com

      Author of: Lean Software Development & Implementing Lean Software Development

      From: leandevelopment@yahoogroups.com [mailto:leandevelopment@yahoogroups.com] On Behalf Of Alfvin, Peter
      Sent: Sunday, August 12, 2007 7:23 AM
      To: leandevelopment@yahoogroups.com
      Subject: RE: [leandevelopment] Re: Process or People?

      Indeed, Mary.  Your insights and writings are a gift.  The essays are short enough that people will read them, yet substantial enough to make a real impact.  I have already forwarded this one as I have forwarded others..

      The quotes from Ohno are priceless in how they approach the subtleties of process improvement and, as you say, the interplay of process and people.  It's amazing (and then again not) how we face the exact same issue fifty years later in another country and culture.

      My main challenge with implementing Deming's and Ohno's principles in this regard is in the area I've already spoken to you about, namely large organizations working on large projects.  In this context, while there is considerable opportunity for local decision making, there are many aspects of Standard Work that need to be consistent across the organization/project.

      I just don't see how the concepts of team and individual ownership of process come into play when decisions have to made which affect hundreds or even thousands of people across the globe.  If a senior manager makes the decisions, how is that not interpreted as "management's process"?  If a senior manager doesn't make the decisions, how do the decisions get made?

      More generally, if we are not to model our organization structure and decision making processes after the military or the church, after whom do we model?  Civil government bodies?  Standards bodies?  Why would we expect any more efficiency or buyin?

      The best I can see we can do is to use transparent and disciplined decision making methods involving a representative approach with respected people.  But even that approach can deadlock or result in acrimony amongst the larger population, as we've seen time and time again in the political arena.

      I guess the one thing that hasn't been tried in the political arena is the real spirit of kaizen.  We seem to be continually taking sides, typically pushing for "our answer" or at best laboring for months for "the answer", rather than viewing each situation as an opportunity for ongoing PDCA and the scientific method.

      In any event, I'm glad that this topic of "management and process" is on the table along with the observation that the mainline agile culture (not Lean/Toyota culture) seems to deprecates both.  And while I'm ok with introducing "system" as a synonym, I don't think we should walk away from the term process, any more than we should walk away (as Scrum has done, in my opinion) from the term "manager".

      Pete


      From: leandevelopment@yahoogroups.com [mailto:leandevelopment@yahoogroups.com] On Behalf Of Alan Shalloway
      Sent: Saturday, August 11, 2007 10:07 AM
      To: leandevelopment@yahoogroups.com
      Subject: [leandevelopment] Re: Process or People?

      Mary:
      I really like this article. It makes me realize I should use the
      term system instead of process - less baggage, but still illustrates
      what I need to convey. It might also make it easier to transform
      people from their negative attitude towards management/process. We
      all need to work together to improve the system we use to produce
      value.

      I also really like coming from the question - what are our
      fundamental beliefs. Are they rooted in Deming or Taylor? What
      beliefs do each have? Which would we prefer? I think all those in
      the Agile community would agree with Deming's belief in the value of
      people. They may not agree with his system of profound knowledge,
      but it gives a place for a conversation to begin. If we agree to
      the value of people then where does system fit in? Do we just let
      people figure it out or do we study systems and take advantage of
      what has been learned by others? Are there set practices that work
      fairly well across a domain? ...

      Thanks again. You never cease to amaze me with your responses. :)

      Alan Shalloway
      CEO, Net Objectives, Gold Sponsor Agile 2007

    • Marina
      I am a new member of this group. I really liked Kent Beck s answer. Indeed, in my experience, accountability can counteract blame. Marina Shalmon Boston, Ma
      Message 129 of 129 , Sep 7, 2007
        I am a new member of this group. I really liked Kent Beck's answer.
        Indeed, in my experience, accountability can counteract blame.

        Marina Shalmon
        Boston, Ma


        --- In leandevelopment@yahoogroups.com, "Kent Beck" <kentb@...> wrote:
        >
        > Dear Kevin,
        >
        > I think "extinguished" is not a responsible description of what
        happens when
        > accountability meets blame. People are perfectly capable of holding
        > themselves in the face of blame, especially if their personal
        integrity is
        > at stake. This is part of what is meant by strength of character. In a
        > blaming culture I might choose not to be accountable, but that's a
        personal
        > choice. To act as if that is the only option is selling ourselves
        short. My
        > experience is that accountability is valuable in far more
        circumstances than
        > my fearful emotional responses would suggest. In a situation where
        someone
        > is trying to avoid responsibility, acting accountable takes much of the
        > sting out of the blame. If what I do is already public,
        finger-pointing does
        > not have much effect. Practicing accountability can be infectious,
        > decreasing the power of blame and can cause long-term changes in an
        > organization.
        >
        > There are definitely situations where bluntly telling all of my
        truth isn't
        > the best choice. Being blunt and vocal is not the only way to act with
        > integrity. If someone is clearly working against my interests then I
        might
        > spend more effort protecting my interest and I might choose to withhold
        > information from an individual that experience has shown is likely
        to use it
        > against me. This is not a comfortable or productive way to work and
        not one
        > I would continue long-term.
        >
        > Regards,
        >
        > Kent Beck
        > Three Rivers Institute
        >
        > _____
        >
        > From: leandevelopment@yahoogroups.com
        > [mailto:leandevelopment@yahoogroups.com] On Behalf Of Kevin Rutherford
        > Sent: Monday, August 27, 2007 1:00 PM
        > To: leandevelopment@yahoogroups.com
        > Subject: Re: [leandevelopment] Process or People?
        >
        >
        >
        > Hi Kent,
        >
        > On 27/08/07, Kent Beck <kentb@earthlink.
        <mailto:kentb%40earthlink.net> net>
        > wrote:
        > >
        > > There are two concepts at work in these discussions, blame and
        > accountability.
        > > [...]
        > > In short, I find accountability--rendering account without blame or
        > excuse--very useful, while
        > > I find blame destructive. Separating the two concepts has been very
        > helpful in my career.
        >
        > Yes, I agree that there are two concepts, and I suspect we differ only
        > through using the terms differently. It is my impression that every
        > organisation I've worked in or with has used the term "accountability"
        > in the blaming sense: "you will be held accountable for your actions."
        >
        > Being accountable (your sense) is different from being *held*
        > accountable, I think. The latter is usually blaming, and the former
        > is usually extinguished by the blaming culture. Is it possible that
        > "rendering account without blame or excuse" can sow positive seeds in
        > an organisation? Or is the typical apathy of learned helplessness too
        > powerful?
        >
        > Cheers,
        > Kevin
        >
      Your message has been successfully submitted and would be delivered to recipients shortly.