I spent this morning at a talk by Mary Poppendieck on lean. It was billed as a tutorial, but there were too many people for that, so it ended up as just a talk. As far as I can tell, the main thing that I missed from its not being hands-on was a chance to do my own value stream mapping; too bad, because I think that’s a useful tool and I’ve never tried it out, but I don’t see it as being directly applicable to my situation.
Pleasant enough talk, but pretty familiar, given that I’d read the Poppendiecks’ excellent book. One thought that it did bring to mind: she brought up the fact that 3M and Google both encourage their engineers to spend a fair amount of time exploring whatever suits their fancy, and gave a queuing-theory justification for this. So: should we institute such a policy at work? What would be the effects, both positive and negative? Does the queuing theory justification really hold up; if so, does it hold up for reasons that are applicable to us?
One concrete situation where I think we might benefit is that one of my coworkers recently posted a list of gripes about our house coding practices on our wiki. I think there’s a lot to most of his points, but it’s hard to find time fixing them; if we had a bit of slack, though, perhaps both he and I would spend a bit of time tackling the issues that bugged us the most, which might help our morale and increase general productivity going forward. Hard to say, though, and I don’t think that’s the sort of benefit that Google and 3M get.
The afternoon talk was a workshop by Ron Jeffries and Chet Hendrickson on “Crushing Fear under the Iron Heel of Action”. The first time they’d given the workshop; an interesting experiment. The core of the workshop involved breaking up into groups where we each talked about some sort of fear we had, and dug deeper into it and talked about specific actions we could take to address the fear. Then we talked about what each of the groups had produced, and talked about common tactics (and, to be honest, had a bit of a therapy session): fail early and often, test your fears, hold retrospectives to address your fears, some people skills issues, many other things that I’m forgetting.
Fears are certainly a bit of a theme for me during this conference; I hope that I’m starting to get better about acknowledging and confronting them in productive ways (though I feel a bit too lazy / other to talk about details of that right now), but it was heartening to see all of us come together, address fears, and come up with concrete productive actions to deal with them. It gives me hope that I’ll be able to do so in the future.
(Don’t get me wrong: there aren’t any crushing worries that I’m laboring under or anything.)
There are no revisions for this post.