- 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 andMessage 1 of 16 , Jul 11, 2008View Source
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.
Author of: Lean Software Development & Implementing Lean Software Development
recollection is that on good teams, overload / overtime was something
team members did to themselves due to their passion for the 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 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.
with roles – ANY roles – is that they tend to become a laundry list
person is expected to do, instead of a checklist that a team is responsible
>of stuff a
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).
From: firstname.lastname@example.org [mailto:email@example.com] On Behalf Of Mary Poppendieck
Sent: Friday, July 11, 2008 3:07 PM
Subject: RE: [leandevelopment] Re: Lead Toyota Engineer Dies of Overwork.
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.
Author of: Lean Software Development & Implementing Lean Software Development
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.
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)
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
- 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. TheMessage 2 of 16 , Jul 12, 2008View SourceI 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
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
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:
> 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.
Winner of the Agile Alliance Gordon Pask award 2006