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

RE: [leandevelopment] Re: Lead Toyota Engineer Dies of Overwork.

Expand Messages
  • Mary Poppendieck
    Hi Robin, I worked as a product champion for several years at 3M, and these were incredibly fun years. My recollection is that on good teams, overload /
    Message 1 of 16 , Jul 11, 2008
    View Source
    • 0 Attachment

      Hi Robin,

       

      I worked as a product champion for several years at 3M, and these were incredibly fun years.  My recollection is that on good teams, overload / overtime was something that the team members did to themselves due to their passion for the product they were developing.  I also do not see the product champion as an all-knowing all-powerful person - just a person with a vision that can excite passion in a team.  When I was product champion, I certainly never could do all of the things expected of even a product owner all by myself, but I did know how to get the right people on the team and get them engaged in the goal – so all of the necessary technical and marketing things happened. 

       

      The problem with roles – ANY roles – is that they tend to become a laundry list of stuff a person is expected to do, instead of a checklist that a team is responsible for looking into.

       

      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 Robin Dymond
      Sent: Thursday, July 10, 2008 11:06 PM
      To: leandevelopment@yahoogroups.com
      Subject: Re: [leandevelopment] Re: Lead Toyota Engineer Dies of Overwork.

       

      I thought this was sad but interesting. The lean product development model that Toyota uses rolls the product owner, scrum master, and technical lead into one role, the chief engineer. Mary Poppendeick and I have been talking about how this leadership model might apply in software development too. The issue I have is that the Product Owner is already an overloaded role and an achilles heel for a scrum team. Adding the additional technical and process responsibilities has always struck me as being much too heroic, and not sustainable. It looks like that this may be the case.

      Of course I don't have Toyota to blame for my 80 hour weeks, just my OC behavior in trying to be really good at doing lean agile and growing a consulting company. I know I am not the only one on this list who is not practicing sustainable pace... but I should... another opportunity.

      Robin.

      On Thu, Jul 10, 2008 at 5:20 AM, David Carlton <carlton@...> wrote:

      On Thu, 10 Jul 2008 03:00:43 -0000, "Joseph Little" <jhlittle@...> said:

      > PS. Is it fair to hold Toyota accountable for the mental health of
      > every single one of its employees? Still, it may be true that this
      > death is not just one incident, and that Toyota may be (partially)
      > culpable.

      Well, a Japanese labor bureau thought that it was fair to hold them
      accountable in this case; do you see a reason to second-guess them?
      It's certainly not the only story I've heard that makes me think that
      the XP practice of Sustainable Pace isn't in complete harmony with
      Toyota's practices.

      David Carlton
      carlton@...




      --
      Robin Dymond, CST
      Managing Partner, Innovel, LLC.
      www.innovel.net - www.scrumtraining.com
      Ass't Producer, Learning and Education stage, Agile 2008

    • Pankaj Chawla
      Hi Mary ... something ... product they ... Even though I agree with you on this but the opposite is also true and I guess far more prevalant. A lot of people
      Message 2 of 16 , Jul 11, 2008
      View Source
      • 0 Attachment
        Hi Mary
         
        >My recollection is that on good teams, overload / overtime was something
        >that the team members did to themselves due to their passion for the product they
        >were developing.
         
        Even though I agree with you on this but the opposite is also true and
        I guess far more prevalant. A lot of  people I see putting in extra hours are not doing
        that for the passion of it but because of looming deadlines (As is the case with
        the Toyota employee also who sadly got there because of a hard deadline on him)
        which can lead to lost jobs, bad appraisals and n number of other bad things that
        can happen to you as part of the corporate appraisal cycles. I personally
        know of an instance where over a period of 1 year, 6 very very passionate
        employees left because they were asked to put in weekends after weekends to
        meet deadlines where the initial problem was setting up of a wrong deadline
        which came into place because their manager made an aggressive commitment
        to stake holders without consulting the team members. 
         
        >The problem with roles – ANY roles – is that they tend to become a laundry list
        >of stuff a person is expected to do, instead of a checklist that a team is responsible
        >for looking into.
         
        I totally agree with you here because in the case I quoted above, the Manager took
        upon himself to commit to aggressive deadlines and forcing team members to follow it
        because it was an expectation set upon him (maybe by the organization or by himself).
         
        Cheers
        Pankaj
         
         

        From: leandevelopment@yahoogroups.com [mailto:leandevelopment@yahoogroups.com] On Behalf Of Mary Poppendieck
        Sent: Friday, July 11, 2008 3:07 PM
        To: leandevelopment@yahoogroups.com
        Subject: RE: [leandevelopment] Re: Lead Toyota Engineer Dies of Overwork.

        Hi Robin,

        I worked as a product champion for several years at 3M, and these were incredibly fun years.  My recollection is that on good teams, overload / overtime was something that the team members did to themselves due to their passion for the product they were developing.  I also do not see the product champion as an all-knowing all-powerful person - just a person with a vision that can excite passion in a team.  When I was product champion, I certainly never could do all of the things expected of even a product owner all by myself, but I did know how to get the right people on the team and get them engaged in the goal – so all of the necessary technical and marketing things happened. 

        The problem with roles – ANY roles – is that they tend to become a laundry list of stuff a person is expected to do, instead of a checklist that a team is responsible for looking into.

        Mary Poppendieck

        952-934-7998

        www.poppendieck. com

        Author of: Lean Software Development & Implementing Lean Software Development

        From: leandevelopment@ yahoogroups. com [mailto:leandevelop ment@yahoogroups .com] On Behalf Of Robin Dymond
        Sent: Thursday, July 10, 2008 11:06 PM
        To: leandevelopment@ yahoogroups. com
        Subject: Re: [leandevelopment] Re: Lead Toyota Engineer Dies of Overwork.

        I thought this was sad but interesting. The lean product development model that Toyota uses rolls the product owner, scrum master, and technical lead into one role, the chief engineer. Mary Poppendeick and I have been talking about how this leadership model might apply in software development too. The issue I have is that the Product Owner is already an overloaded role and an achilles heel for a scrum team. Adding the additional technical and process responsibilities has always struck me as being much too heroic, and not sustainable. It looks like that this may be the case.

        Of course I don't have Toyota to blame for my 80 hour weeks, just my OC behavior in trying to be really good at doing lean agile and growing a consulting company. I know I am not the only one on this list who is not practicing sustainable pace... but I should... another opportunity.

        Robin.

        On Thu, Jul 10, 2008 at 5:20 AM, David Carlton <carlton@bactrian. org> wrote:

        On Thu, 10 Jul 2008 03:00:43 -0000, "Joseph Little" <jhlittle@mindspring .com> said:

        > PS. Is it fair to hold Toyota accountable for the mental health of
        > every single one of its employees? Still, it may be true that this
        > death is not just one incident, and that Toyota may be (partially)
        > culpable.

        Well, a Japanese labor bureau thought that it was fair to hold them
        accountable in this case; do you see a reason to second-guess them?
        It's certainly not the only story I've heard that makes me think that
        the XP practice of Sustainable Pace isn't in complete harmony with
        Toyota's practices.

        David Carlton
        carlton@bactrian. org




        --
        Robin Dymond, CST
        Managing Partner, Innovel, LLC.
        www.innovel. net - www.scrumtraining. com
        Ass't Producer, Learning and Education stage, Agile 2008

      • Ron Jeffries
        ... Delicious! This is an important mind-twist. Ron Jeffries www.XProgramming.com You have to either laugh or cry. -- Bill Rogers
        Message 3 of 16 , Jul 11, 2008
        View Source
        • 0 Attachment
          Hello, Mary. On Friday, July 11, 2008, at 5:37:00 AM, you wrote:

          > The problem with roles - ANY roles - is that they tend to become a laundry
          > list of stuff a person is expected to do, instead of a checklist that a team
          > is responsible for looking into.

          Delicious! This is an important mind-twist.

          Ron Jeffries
          www.XProgramming.com
          You have to either laugh or cry. -- Bill Rogers
        • Mary Poppendieck
          Perhaps the biggest problem that drives the symptoms that you mention below is that software seems for some reason to get divorced from the overall system and
          Message 4 of 16 , Jul 11, 2008
          View Source
          • 0 Attachment

            Perhaps the biggest problem that drives the symptoms that you mention below is that software seems for some reason to get divorced from the overall system and the overall business purpose of that system.  Then of course, no one can get passionate about it.  We have to stop developing software and start making systems that serve important purposes, so that team members can make valid judgments about how important the schedule really is – how important that difficult feature really is – what test strategy is best for the long run – where the true cost of the system lies.  This kind of knowledge should not be restricted to managers – a team with a good leader should be able to figure out these kinds of tradeoffs based on the overall system objective. 

             

            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 Pankaj Chawla
            Sent: Friday, July 11, 2008 06:27 PM
            To: leandevelopment@yahoogroups.com
            Subject: RE: [leandevelopment] Re: Lead Toyota Engineer Dies of Overwork.

             

            Hi Mary

             

            >My

            recollection is that on good teams, overload / overtime was something

            >that the

            team members did to themselves due to their passion for the product they

            >were

            developing.

             

            Even though I agree with you on this but the opposite is also true and

            I guess far more prevalant. A lot of  people I see putting in extra hours are not doing

            that for the passion of it but because of looming deadlines (As is the case with

            the Toyota employee also who sadly got there because of a hard deadline on him)

            which can lead to lost jobs, bad appraisals and n number of other bad things that

            can happen to you as part of the corporate appraisal cycles. I personally

            know of an instance where over a period of 1 year, 6 very very passionate

            employees left because they were asked to put in weekends after weekends to

            meet deadlines where the initial problem was setting up of a wrong deadline

            which came into place because their manager made an aggressive commitment

            to stake holders without consulting the team members. 

             

            >The problem

            with roles – ANY roles – is that they tend to become a laundry list

            >of stuff a

            person is expected to do, instead of a checklist that a team is responsible

            >for looking

            into.

             

            I totally agree with you here because in the case I quoted above, the Manager took

            upon himself to commit to aggressive deadlines and forcing team members to follow it

            because it was an expectation set upon him (maybe by the organization or by himself).

             

            Cheers

            Pankaj

             

             


            From: leandevelopment@yahoogroups.com [mailto:leandevelopment@yahoogroups.com] On Behalf Of Mary Poppendieck
            Sent: Friday, July 11, 2008 3:07 PM
            To: leandevelopment@yahoogroups.com
            Subject: RE: [leandevelopment] Re: Lead Toyota Engineer Dies of Overwork.

            Hi Robin,

            I worked as a product champion for several years at 3M, and these were incredibly fun years.  My recollection is that on good teams, overload / overtime was something that the team members did to themselves due to their passion for the product they were developing.  I also do not see the product champion as an all-knowing all-powerful person - just a person with a vision that can excite passion in a team.  When I was product champion, I certainly never could do all of the things expected of even a product owner all by myself, but I did know how to get the right people on the team and get them engaged in the goal – so all of the necessary technical and marketing things happened. 

            The problem with roles – ANY roles – is that they tend to become a laundry list of stuff a person is expected to do, instead of a checklist that a team is responsible for looking into.

            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 Robin Dymond
            Sent: Thursday, July 10, 2008 11:06 PM
            To: leandevelopment@yahoogroups.com
            Subject: Re: [leandevelopment] Re: Lead Toyota Engineer Dies of Overwork.

            I thought this was sad but interesting. The lean product development model that Toyota uses rolls the product owner, scrum master, and technical lead into one role, the chief engineer. Mary Poppendeick and I have been talking about how this leadership model might apply in software development too. The issue I have is that the Product Owner is already an overloaded role and an achilles heel for a scrum team. Adding the additional technical and process responsibilities has always struck me as being much too heroic, and not sustainable. It looks like that this may be the case.

            Of course I don't have Toyota to blame for my 80 hour weeks, just my OC behavior in trying to be really good at doing lean agile and growing a consulting company. I know I am not the only one on this list who is not practicing sustainable pace... but I should... another opportunity.

            Robin.


            On Thu, Jul 10, 2008 at 5:20 AM, David Carlton <carlton@...> wrote:

            On Thu, 10 Jul 2008 03:00:43 -0000, "Joseph Little" <jhlittle@...> said:

            > PS. Is it fair to hold Toyota accountable for the mental health of
            > every single one of its employees? Still, it may be true that this
            > death is not just one incident, and that Toyota may be (partially)
            > culpable.

            Well, a Japanese labor bureau thought that it was fair to hold them
            accountable in this case; do you see a reason to second-guess them?
            It's certainly not the only story I've heard that makes me think that
            the XP practice of Sustainable Pace isn't in complete harmony with
            Toyota's practices.

            David Carlton
            carlton@...




            --
            Robin Dymond, CST
            Managing Partner, Innovel, LLC.
            www.innovel.net - www.scrumtraining.com
            Ass't Producer, Learning and Education stage, Agile 2008

          • Steve Freeman
            I think I raised this issue on the list when the story first broke. There s so much we can learn from Toyota, but we also have to understand the context. The
            Message 5 of 16 , Jul 12, 2008
            View Source
            • 0 Attachment
              I think I raised this issue on the list when the story first broke.

              There's so much we can learn from Toyota, but we also have to
              understand the context. The TPS cannot afford to be forgiving and
              requires a certain attitude and character from its staff to implement,
              there's a line (in Ohno's book, I think) about how it drove the
              manager of a supplier into breakdown. Similarly, one Chief Engineer
              (of the Prius?) moved a bed into his office to avoid wasting time
              going home. I expect this is easier in a company town where everyone
              knows how the game works and where people know they can rely on their
              employer absolutely.

              Those of us in the rest of the world have to learn how to apply the
              ideas in other cultures where, for example, we cannot remove quite as
              much waste because we cannot use unlimited overtime to cope with
              demand peaks.

              S.

              On 11 Jul 2008, at 00:49, David Carlton wrote:
              > On the one hand I agree. On the other hand, part of the context to my
              > response to this is seeing stuff like the following:
              > <http://www.evolvingexcellence.com/blog/2008/06/toyota-puts-peo.html>
              > It says that, in the heavy times at this particular Toyota plant, that
              >
              > "During full-production periods, when the plant is running 24-7,
              > employees work incredible amounts of overtime"
              >
              > but this is nonetheless demonstrating Toyota's "respect for people"
              > because, during the slow times, Toyota doesn't fire employees, instead
              >
              > "all employees work on becoming more efficient, brainstorming ways to
              > out-do their competition (they’ll bring in competitors cars and tear
              > them apart, looking for ways to improve their own vehicles), and all
              > become actively involved in seeking ways to save the company money."
              >
              > So, absolutely, you can quit your job rather than work huge amounts of
              > overtime. But if that's the company culture, then it's a part of lean
              > that I don't want to emulate.
              >
              > And (perhaps more relevant to this forum), it colors how I look at
              > parts of lean that I _do_ want to emulate. For example, if I'm
              > remembering correctly, the Poppendieck's books talk about how Toyota
              > always hits their product release dates, and how set-based design is a
              > big factor in that. And that may well be the case, and I'd very much
              > like to learn whatever I can from Toyota in that regard. But I
              > suspect that both set-based design and (perhaps seriously) overworking
              > people are factors in hitting their dates; I suspect that taking an
              > honest look at the latter factor in Toyota's success might give
              > insight into how effective set-based design may be, by giving us a
              > clearer picture into the evidence for that.



              Steve Freeman
              http://www.mockobjects.com

              Winner of the Agile Alliance Gordon Pask award 2006
            Your message has been successfully submitted and would be delivered to recipients shortly.