innovation BOF

The innovation BOF went both worse and better than I expected. It turned out to be hard to go from the theoretical level to more practical implications. But the audience was great, they came up with some very useful ideas, which I'll go through in a minute.

But first about the questionare I've blogged about and which I would like the KDE contributors to fill in. It measures things which according to lots of scientific articles are important for innovation. This is mostly kind'a vague, think about concepts like 'formalization' which measures the extend to which the organization uses formal structure & rules to get things done or keep ppl in line. The idea is to see if there are area's KDE is doing bad in, and then figure out what we can do to improve. The full questionare takes approx. 30 min in dutch, and I've removed a bunch of questions, but I can't promise it'll take you less than 30 minutes. It has been translated, and most of you take it in another than your native language, which might make it take longer.

It is very important to fill in all questions. I know this feels targeted to commercial organizations, so you might have to think of a way how this applies to you. Please try to do so, because I can't use incomplete questionares. Here it is: questionare.

In the BOF I essentially went through the constructs, explaining what they did and meant. Some nice ideas came out of the resulting discussion. Here are the notes:

To increase input from users and improve our incremental innovation (bringing a more polished user interface):
- get a 'suggest improvement' menu item in the Help dialog. At first this should report a wish, but in time it should probably point to an ideastorm (Ubuntu's site, Dell's site) like page. We should try to make it as easy to add input as possible.
- basket had/has some very cool user-feedback-gathering tools, it would be great if someone would pick that up. It would be useful during alpha's and beta's go gather (statistical) input.

When it came to the importance of psychological safety, autonomy and involvement in decisionmaking:
- forcing usability on developers would hamper innovation as it's bad for psych safety. It is important to keep things very closely ingegrated - integrate usability in the 'normal' tutorials. The ideas about a new development model, 'always summer in trunk' and such are also smart in this regard.
- related would be the rewarding of innovative ideas. Maybe have an interesting-branche-of-the-week article.
- and to improve serendipity we should keep ideas which didn't work very well around - it does often happen that things which didn't work in a certain context are a huge success in another place.

The final idea which came up was to have 'innovation sessions' at akademy for certain innovations. We could discuss ways of improving the application in major or minor ways, brainstorm about issues etc.

Now I have to think of what needs to be done to capitalize on these ideas, make them happen. Stay tuned for another blog, and of course the analysis of the survey data.

All in all, it wasn't as great as it could be, but it did turn out to be useful. And I've learned something (still have to figure out what exactly).

Love!