Innovation Arena – prerequisites: The maturity of an idea

Prerequisites and preparations so we can start with an innovation arena run are as following:

1. We recommend that an idea exists about the maturity level of an idea or Innovation (see http://starstoroad.com/blog/?p=175).
2. The existing ideas and potential innovations within our organization must be visible and transparent.
3. We need to fill the arena with a crowd of experts

Let’s have a closer look into these prerequisites.

Maturity of an idea or potential innovation

You could ask: Why does the maturity matter?

Well, easy to answer: your company has a limited amount of money to invest into innovation. So your company power is limited to invest only in a small set of ideas. Statistics show that only one out of ten ideas really reach the state of a product to be sold on the market on once again only one out of ten products sold on the market gains sound profit.

Following the statistics, your company will be more successful on the market if it invests only in five to ten ideas out of a hundred. Additionally most of innovation budget shall go into the products that are just before market launch. That is the most critical time where speed is essential to win against competitors. That implies only a small budget shall go into the selection process that identifies the ninety to ninety-five ideas that are still on hold. And these ideas are on hold of different reasons: Vision is not clear, the market is not clear, the market is not awaiting the product, the company is unable the develop the product, whatever internal or external reason there are.

A simple understood maturity model for ideas is a good way to go. I recommend the “from stars to the road” maturity model by Markus Flückiger and Pete Jones. References are the blog entry by Markus and Pete about stars to the road, their presentation about the maturity levels (and the icons ready for download used for the different maturity levels).

The maturity model is simple. It works with the maturity levels star, cloud, tree and road

Star		The idea is a first sparkling glitter. There is no chance to say if the idea could be developed into something concrete or we do not have any feedback if anybody has interest in that idea
Cloud		We see contures and shapes. We are able to at least communcate a vision for that ideas; the most important features of that ideas and who the personas, the target market is that might have interest in that idea.
Tree		The idea is pretty concrete. We have a vision, we clearly see a potential target market, but there are still some issues and risks before we really are willing to invest a sound budget to develop that idea and turn it into an innovation. We could say we see already the apples hanging in the tree, but still they do not fall off.
Road		No we got it on the road down under our feed. We are willing to invest and we will invest to develop that terrific new thing am make the innovation happen.

There is one important thing in your company I would like to remind of: Please do not establish a detailed and formalistic innovation maturity model with a huge set of criteria in your company. That will not work. That will kill creativity and visionary thinking. These maturity levels have to be defined in discussions, via communication and agreement by the involved persons.

I hope as well there are many of persons involved – more then just the managers of the company, but as well employees, clients, partner, friends or even people out of a cloud. Yes: one side result of the Innovation Arena is as well to agree about these maturity levels.

The second side result is: It shall be transparent and understood to every single one in your company what amount of resources (money, time, …) your company invests into an idea on a specific maturity level. And yes: you should set a limit for the number of ideas that hit the road as the next innovations of your company. Turning these ideas into innovations eats up resources.

...next blog will discuss transparency of an idea....

Innovation Arena - a workshop format to mature innovations: intro

In this blog series I will describe a 2 hours workshop format. A “crowd” of experts, employees and externals will drive the existing ideas that are visible and transparent within an organization to the next level of maturity. If the crowd decides that some ideas made it to the next level of maturity, in maximum two or three ideas are selected by the crowd by a clear crowd selection proceeding. These are the ideas the organization will invest more budget and time to create great innovation.

So the goals of this workshop format we call “Innovation Arena” is:

·         Give idea owners direct feedback to their ideas to improve their ideas

·         Identify the ideas that matured since the last Innovation Arena

·         Select the two or three of the matured ideas that are marked as most valuable

I said: we called “Innovation Arena”. So who is we?

We is a group of people from different places with different backgrounds as there are: Usability, User Experience, Requirements Engineering, Design Thinking, Lean Innovation, Lean & Agile Development, Product Management,  Lean Startup, Management 3.0 and others. We work in different companies with different responsibilities and share ideas – and write about ideas.

Some important references as background reading specific to the “Innovation Arena” are:

From Stars to the Road http://starstoroad.com/blog/?p=175

Companies don’t find it easy to take ideas from the stars and bring them as innovation onto the road. From Stars to the road proposes a generic and agile process to innovation. We think that fruitful collaboration is one of the biggest success factors in innovation. Thus instead of presenting roles, tasks and artefacts, we focus the process on the collaborative structures of a company.

Speed Creation http://www.speedcreation.org/

Speed Creation is a new concept to speed up project incubation time and effort. Goal of speed creation is to create a consistent, confirmed and biased vision about the project. A small and focused expert team work in an intensive 72 hours’ workshop on an idea or innovation, a jury judges and rates the outcome to challenge and improve results.

It is worth to take some time and rummage a bit over these sites.

 

English publication about agile RE

In cooperation with University Mannheim, as part of the initiative "Software for People" the blog series about Agile Requirements Engineering has been published as article in the book Software for People, ISBN 978-3-642-31370-7. The book is in English.

This book is a collection of interesting articles about innovation, usability, requirements engineering an agile and lean. An inspiring publication.

Book Recommendations agile leadership

If you are interested in management and leadership topics related with an agile and lean mind set, I would recommend the following books for reading.

Jurgen Appelo, Management 3.0: Leading Agile Developers, Developing Agile Leaders, Addison-Wesley Professional, ISBN-13: 978-0321712479, English, see: http://www.amazon.com/Management-3-0-Developers-Developing-Addison-Wesley/dp/0321712471.
There are many reviews on Amazon to read, so my personal review would not add anything

Uwe Vigenschow has written three books about social skills. The first one for developers, the second one for IT-management and IT-project manager and the third one for consultants. Unluckily the books are available in German only. I recommend these books as they are good to read, investigated very sound and pragmatic. No esoteric highflyer smalltalk. See: http://www.vigenschow.com/Publikationen/Buecher/buecher.html 

Innovation and Creativity Matters

Well, it’s been a long time since I had the chance (let’s say priority) to write on my blog. The last year I worked with many terrific people in different projects and initiatives. Interesting thing: all the topics, all the ideas, all the discussions ended up around innovation and creativity.

There is the innovation startup scene. Young and fast going ideas, supported by the crowed; getting fast feedback from the crowd, open innovation, crowd sourcing; leaving the conservative, by risk and distrust marked path from hardcore business case towards lightweight approaches of lean startup.

There is the effect in agile organizations that the ever and ever fast turning wheel of sprints is killing creative thinking. The horizon of everything is the next sprint review. Mid-term and long term value creation in form of ideas turning into innovation is claimed to be dying in this agile type of ecosystem. In sports nobody is able to chain up sprint by sprint by sprint by sprint by … well you got the idea… without drain in the end.

Product development is an evergreen. Problem is: There are so many ideas around in the heads of the crowd of terrific individuals in our companies – but money is limited. The lifecycle of ideas – starting in the heads of a group of creative thinking people, maybe at a beer in the evening, maybe under the shower – this lifecycle of ideas needs a new kind of hotbed under the reality of turning agile, the culture of generation Y, social media and changing views on what intellectual property is in society. Interesting is that producing good and many ideas is not an issue. Making ideas visible is the point. To culture and age ideas is the point. To make them visible and tangible towards maturity is the point. To turn ideas into innovation is the point. To invest into the top two or three best innovation proposals is the point. To throw away very good ideas and proposals is the point. To not frustrate engaged individuals is the point.

All that applies not only in the cool and young scene where smartphones and apps are around, catchword: market driven products. I am convinced that applies as well in – I hate that word – legacy environments, old school development of products and services. I am convinced that migrating an existing IT-platform of a large bank, insurance or telco provider into something that is more handy and felxible for the business people needs creativity like hell. These environments are demanding, interesting, complex, so much room to improve! That leads to a last point: Why are these scenarios not seen as place where creativity and innovation helps?! Maybe that is a better approach then just cost cutting actions.

Well – to come to the point: these are the topics that many of my colleagues and me discussed in different engagements, projects, initiatives, workshops in the last year. I learned a lot and discovered – at least for me – a lot of new insights, coherences and interrelations.

So I will start sharing my personal insights with you starting with a new series I call for myself Innovation and Creativity matters.

I am convinced: Innovation and creativity are fundamental elements to be successful. No matter how the term “successful” is defined in a specific context. We have to discover new approaches to combine innovation and creativity with speed, time2market, stress, pressure and limited resources.

Agile RE Blog 10ter und letzter Blog: Zurück zum Start

Meine Behauptung am Anfang des Talks war, dass Requirements Engineering nur ein Hilfsmittel ist, um ein Produkt zu erschaffen. Über den Umweg der Wissensarbeit im Projekt hoffte ich zu zeigen, dass sich die agile Form des Requirements Engineering vorrangig mit dem Erkennen und Schließen von Wissenslücken im Produktwissen und auch im Prozesswissen beschäftigt. Die Optimierung des jeweiligen Kontext spezifischen Prozesses an sich ist hierbei dem Leben des agile Gedankenguts überlassen.

Diese Diskussion lässt – so erhoffe ich mit diesem Beitrag – erkennen, dass eine agile Arbeitsform einen Effizienzbooster für diese Wissensarbeit bedeutet.

Der Effizienzbooster – so hoffte ich zu zeigen – kann auf zwei eng verwobenen Kontextebenen in einer Organisation zur Wirkung kommen, taktisch auf der Produktebene und operativ auf der Projektebene. Auf der Projektebene sollte dies immer möglich sein. Eigentlich, so denkt man, sollte jede Organisation danach streben.

Auf der Produktebene besitzen die Randbedingungen der Organisation erheblichen Einfluss, um über Invest in Agilität einen Wettbewerbsvorteil zu erzielen. Ein bottom-up Ansatz, ideal unter dem Schutz des Top-Managements, ermöglicht das Überprüfen dieser Randbedingungen.

Wichtig ist die Erkenntnis, dass es nicht den agilen Requirements Engineer geben wird, so wie es den klassischen Requirements Engineer gibt, also den Spezialisten, welcher (nur) die Rolle Requirements Engineers einnimmt. Vielmehr ist Requirements Engineering eine der Disziplinen, die ein Mitarbeiter neben anderen Disziplinen, wie zum Beispiel Testing oder das Schreiben des Handbuchs, beherrschen muss.

Spannend für uns ist, dass in agilen Organisationen die Disziplin des Requirements Engineering eine deutlich wichtigere Stellung im Verhältnis der Disziplinen einnimmt, als in klassischen Projekten. Diese Disziplin trägt nämlich durch die kommunikative Komponente sehr viel zum Aufbau und Verbreitung von Wissen bei.

Mit einem Wort und zusammenfassend: Ja, es gibt agiles Requirements Engineering und nein, es gibt nicht den agilen Requirements Engineer, sondern die multidisziplinären Mitarbeiter, die agile arbeiten können und Requirements Engineering als Disziplin beherrschen.


Referenzen

Definition des Begriffs Wissen im Kontext der Informatik, siehe Wikipedia unter http://de.wikipedia.org/wiki/Wissen#Kulturphilosophische_Beschreibungen

Definition des Begriffs Wissen nach Von Alexandra Frisch und Denise Walter, Hochschule der Medien, Institut für angewandte Kindermedienforschung, siehe Link http://www.hdm-stuttgart.de/ifak/medienwissenschaft/wissen_medienereignis/hoerbuch/definition_wissen

Buch: Software entwickeln mit Verstand, Jörg Dirbach, Markus Flückiger, Steffen Lentz, Dpunkt Verlag, erste Ausgabe 2011, ISBN-13: 978-3898646543), eine dringende Empfehlung, um etwas über den Umgang mit Wissen in der Software Entwicklung zu erfahren.

T. Gorschek and C. Wohlin, "Requirements Abstraction Model", Requirements Engineering Journal, Vol. 11, No. 1, pp. 79-101, 2006, der Artikel ist zwar nicht agil, das Gedankengut dahinter ist jedoch sehr wohl agil einsetzbar.