Last month the Japanese labor board ruled that the death of the Chief Engineer on the Camry Hybrid project was ‘karoshi’ (death by over work). In his last few months he worked more than 80 hrs of overtime a month. He died of a heart attack only day before he was due to fly to the Detroit Auto Show.
This story raised a number of interesting issues about what we can learn from Toyota, sustainable effort and why we develop software.
Joe Little points out that “Lean has a principle of not over taxing the system”. He goes on to ask is excessive overtime a fundamental part of Lean at Toyota or is this isolated to a specific group? Finally he reminds us that even though Lean comes from Toyota they are not perfect. Even so we can still learn from them and other lean practitioners.
Robin Dymond says:
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.
Mary, author of Lean Software Development, replies, recalling her time as a Product Champion at 3M:
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.
She goes on to say that any role can become overwhelming as they become a laundry list of things to do instead of a checklist of responsibilities shared with the team.
Finally in response to the problems of hard deadlines and fixed features sets imposed by management Mary comments:
Perhaps the biggest problem that drives the symptoms mentioned 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.
