Bindings, Platforms, and Innovation
This presentation focuses on the Internet and separating myth from fact, history from the future, and the mundane from the imaginative. Bob Frankston presents a vision of what could and should be.
Tracking change and innovation in the enterprise software development community
Posted by Mark Levison on Jul 17, 2008 01:00 AM
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.
Agile Development: A Manager's Roadmap for Success
Give-away eBook – Confessions of an IT Manager
So this is the classic case of the lynchpin guy getting hit by the proverbial bus. Noone ever wants to talk about it, but over-specialization/over-concentration can be a disaster for a project when someone leaves, or in this case, worse.
One person doing too much is also just warning sign that team work on your project is poor. Why is (s)he doing so much more than the others? Is it because they are territorial, or is it because they're terrified?
While its great to see passion, it's like marriage. Passion can only carry you for so long if you try to go full throttle all the time. Sooner or later, your energy level can't be sustained anymore, and if you try, you burn out. You end up hating the work you used to love. Moderation is far better... that's the key to sustainability.
This is just one of the reasons you need to monitor the hours people are truly putting in to ensure it's because they want to be working those hours rather than it's because they feel pressured to work those hours. Overtime is inevitable, but that doesn't mean it needs to be destructive. Quality suffers, your people suffer, and inevitably, you suffer as a consequence.
Jim - I agree. I think the hard part is spotting someone who is pushing too much and too hard.
His timesheet might have been a clue!
True Dave - but that assumes two things the organization keeps time sheets and that he was honest when writing in it.
In some organizations that don't pay for overtime employees don't see the point in filling out the time sheet with their real hours.
In his last few months he worked more than 80 hrs of overtime a month.
Someone was watching his hours. I'm just sayin'...
Jim
I understand where you're coming from but I think that it's not easy spotting the point in which
"positive" enthusiasm turns into compulsive behavior.
speaking as a "passionate" guy, I can tell you that trying to restrain my self from over working
always feels like trying to artificially convince myself that i care less,
furthermore we all want to succeed and it's very easy to say to your self -
work harder and you will have more success!
another angel is that because software development is part art form it's easy to relate to your work on an emotional level which blurs the boundaries that should exist between work and personal life,
making it really hard to find the right balance.
I think that at the end of the day finding the right balance is something that everyone should do for
him/her self, it's not something that your employer can impose on you and the most important thing
to remember is that "karoshi" is not an option.
Asy.
Asy, your comment made me laugh: "remember is that "karoshi" is not an option," because on our first agile team, we had a mascot sock monkey called Karoshi - and he got messed up in all the worst ways. He literally "hit the wall" many times, got hung up in the rafters and one morning was discovered in the paper shredder. I had never thought of these destructive activities in the context of his name, before. :-)
Isn't the chief engineer's role outlined in the "Toyota Way" similar to a surgical team? One quarterback, the others are instruments in the offensive choreography?
Cheers,
Zubin Wadia
CTO
www.imagework.com
"Business Acceleration through Process Automation."
I always knew that agile can bring the worst out of people ;-)
seriously though, I'm happy to hear that I made you lough ...
This presentation focuses on the Internet and separating myth from fact, history from the future, and the mundane from the imaginative. Bob Frankston presents a vision of what could and should be.
This article explores the use of JBoss and jBPM to implement design solutions that effectively address the issue of orchestrating long running activities.
This presentation covers the use of graph databases as an optimal solution for data that is difficult to fit in static tables, rapidly evolving data or data that has a lot of optional attributes.
This session introduces Real Options and shows how it can help in running your project. Real Options is a decision-making process that can be used to manage risk.
This article discusses the use of bindings on services and references (including the instance of non-configured bindings) as the means to implement SCA communications in a Web and SOA environment.
After a short introduction to DSLs, Scott Davis plays with the keyboard showing how to approach the creation of a DSL by typing working snippets of Groovy code that get executed.
IBM Rational and InfoQ present, Scaling Agile with C/ALM, an eBook showing organizations how to become “finely tuned software delivery machines” by enabling team integration and scaling.
Amanda Laucher presents a real life enterprise application written in F#. She shows actual code snippets, explaining design decisions and suggesting how to use some of the F# constructs.
9 comments
Watch Thread Reply