tfnico's blog

So I'm sitting here reading Scott Berkun's  Confessions of a Public Speaker , pretty good book by the way (from the Viaboxx library). I'm just through the chapter about "Working a hard room". And then it hits me:  I actually spend an effort being a good audience at talks . I go to the odd conference and user-group meeting, and whoever is speaking, and even if the talk is not hitting home with me, I always try to... Sit down in the middle, close to the speakers where they can see my face Focus my full attention on them - no smartphone/laptop React to what they're saying with my face, friendly smile when they say something smart, raise my eyebrowsand smile  when they say something surprising Laugh at their jokes (I mean, not fake laugh, but be open to laugh) Ask questions when I wonder about something Hold my criticism till after the talk, if any, and give it in person Think about and note any questions I'd like to ask in the Q&A A good spea...

So I was thinking a bit about frequent releases. There are many agile books and articles that explain how more frequent releases are a good thing. However, to many people in management, this is counter-intuitive. They say "Slow means safe. Slowing down means more time to improve quality, more time to test, and more time to fix bugs. Also slow is cheaper, because it's less overhead costs." I've seen a lot of projects where release frequency slows down, especially after the initial development burst and launch of a product, and I think this is a shame. So how do I go about explaining people that the slow-means-safe line of thought is wrong? I've come up with a little model I'd like to go through here. I start off with defining a  Rate of Development , which we'll assume is constant throughout the model (leaving out factors as motivation and skill). Now, having a high rate of development is not worth anything if we're not Doing  t he Right Thing ....