Scott Berkun – The Myths of Innovation
Scott Berkun has been on my radar since his first book, The Art of Project Management was published (not that I have actually read it yet mind you). As part of the press tour for his most recent book, The Myths of Innovation, Scott was on Technometria.
There is still a lot of room for innovation in the testing / qa space. In fact, Lee Copeland’s CAST2007 Keynote was on Today’s Testing Innovations. Aside from the audio volume needing equalization between Scott and the other participants it is a pretty good podcast with a fair bit of handy tidbits on how to foster innovation in yourself and/or organization. At the end 2 of the hosts admitted to have bought the book during the recording of the podcast, and if I had the time to read it I likely would have too. But that also raises the question of what prep work did they do ahead of time. Anyways, here is my busy-writing-selenium-script-and-need-noise-cancelling-headphones-at-work notes
- Groups need a core idea/person/leadership value to rally around
- The Myth of Epiphany – There is a single magical moments where we can identify that discovery took place or a breakthrough happens. Newton did not get bopped in the head with an apple and ‘discover’ gravity. He used that story as a simplification of years of thinking about gravity in a mathematical context
- Most people define good stories / narratives as having beginnings, middles and ends and can have a clear synopsis of plot / idea
- Creatives (innovative) people they want the real, nitty-gritty stuff about how others failed (in order to learn and avoid potential failures)
- Organizations and management needs to be more tolerant / resilient of failure
- Very few successful companies end up doing what they intended to so. I’ve seen this one first hand; the original purpose of the company which ended up producing HP OpenView SelectAccess was to migrate corporate information into LDAP)
- Failure creates the opportunity of success
- If you dont make mistakes, you are not trying hard enough. Another personal reference; I read a post somewhere on a message board about dirt bikes where someone was complaining that they had blown up their engine pushing it too far. A professional rider then pipped in that if you are not trying hard enough if you don’t ruin 2 or 3 engines a season. Sure, he gets his engines provided from the factory and the original poster has to pay to have it repaired, but the point stands.
- Organizations often state that their goal is to be innovative, but then have punitive policies if you are late on a project (due to innovation) or if you go against established policies (in the name of innovation).
- Innovation is often (always?) a grass roots effort
- Pretty much everyone has heard of Google’s 20% time rule, but I had not heard of Yahoo’s ‘Hack Day’ where you spend all days working on something cool that you like and the best are showcased through the group/organization. There are even apparently prizes too
- Most development projects are broken into three phases; design, build test. Scott proposes a different slicing. Design, Experiment, Build, Test. The Experiment part becomes the innovation location
- The people we hold up as geniuses were allowed to work very hard using very specific kinds of skills showing that dedication and commitment is more important than natural born skills
- As technical people, we need to stop concentrating on the tech, and more on the softskills like disagreeing on something without it becoming religious and how to run meetings. The example of Sun was brought up and how thy fumbled their control of Java because the people who were manning the tiller were all techs but could not come up with a great control-the-world-implementation-plan. Cult of the Engineer is the actual term that was used.
- Of course, to improve or develop those skills, the environment around the person needs to be made safe in order for them to be able to utilize it.
Direct link to audio stream and MP3 can be found here.