Kann ich als Software-Entwickler Kreativität lernen und warum sollte ich?

Ist Innovation gleichzusetzen mit Eingebung?

Das beste Gegenbeispiel zu dieser Annahme ist Isaac Newton. Landläufig gibt es die Meinung, er erfand die Schwerkraft, weil er eine Eingebung hatte, als ihm ein Apfel unter einem Baum auf den Kopf fiel.

In Wahrheit studierte Newton in Cambridge, wurde dort später Fellow des Trinity College und befasste sich sein Leben lang mit der Forschung. 18 Jahre nach den ersten Ansätzen veröffentlichte er 1684 die ‘‘dynamische Theorie der Gravitation’’, indem er die Grundgesetze der Bewegung formulierte. Wikipedia-Artikel über Newton Jeder Mensch vor ihm wusste bereits, dass ein Apfel, wenn man ihn fallen ließ, auf die Erde fällt. Newton war nur der erste, der Mathematik benutzte, um dieses Phänomen zu beschreiben.

Innovation ist also nicht gleichzusetzen mit Eingebung!

Das Wort Eingebung beinhaltet die Annahme, dass etwas von Außen wirkt, damit im Inneren etwas neues entstehen kann. Eine Erfindung kann aber nicht in einem Menschen eingepflanzt werden. Das Wort ‘‘Eingebung’’ impliziert aber auch, dass wir keine Kontrolle darüber haben, wann wir welche Ideen haben. Das ist falsch! Eine neue Idee ist die Verknüpfung vieler vorher gewonnener Erkenntnisse zu einem neuen Kontext. Es liegt bei uns, sich all die Erkenntnisse anzueignen. Den Prozess hierfür können wir optimieren, indem wir uns um bessere Quellen bemühen und uns Techniken aneignen, die Zusammenhänge besser darzustellen.

Aber gibt es nicht trotz der ganzen Stoffsammlung vorab, den einen zündenden Gedanken, der die Innovation ausmacht? Was ist das besondere an dem letzten zündenden Gedanken?

Schlicht die Tatsache, dass es der letzte ist, sonst nichts. Eine gute Analogie ist das Puzzle: Worin unterscheidet sich das letzte Puzzle-Teil von allen anderen bevor man mit dem Puzzle anfängt?

Die Innovation umfasst mehr als die bloße Idee. Innovation schließt die Umsetzung in ein marktfähiges Produkt ein. So definiert Wikipedia den Begriff Innovation wie folgt:

Im allgemeinen Sprachgebrauch wird der Begriff unspezifisch im Sinne von neuen Ideen und Erfindungen und für deren wirtschaftliche Umsetzung verwendet. Im engeren Sinne resultieren Innovationen erst dann aus Ideen, wenn diese in neue Produkte, Dienstleistungen oder Verfahren umgesetzt werden, die tatsächlich erfolgreiche Anwendung finden und den Markt durchdringen.

Drei Phasen im Prozess Innovation:

• Wissen über die Materie anhäufen
• das Problem verstehen (Stunden, Tage, Wochen, Jahre)
• Ausbrüten (mit Experimenten, try and error)
• Pausen und Ablenkungen unterstützen das Brüten, oft führen Ablenkungen zu neuen Verknüpfungen

Folglich ist das Forschen mit der Stoffsammlung genauso wichtig wie das Ausbrüten, die Pausen und die Ablenkung.

Warum sollte sich ein Entwickler mit Innovation beschäftigen? Wann ist Kreativität bei einem Entwickler gefragt?

• bei der Umsetzung
  • bei der Lösung der Spezifikationsaufgaben
  • bei (kurzfristigen) Änderungen von Teilen der Spezifikation
  • beim Erforschen von technischen (architektonischen) Lösungen, z.B. um die Performance zu verbessern
• beim Finden von Fehlern
  • Der Ochs vorm Berg. Man weiß gar nicht, wo man anfangen soll.
  • Seltsame Phänomene.
  • Scheinbar magischer Programmcode.
  • Architekturzwänge verlangen nach einer innovativen Lösung für die Umsetzung - der Spezifikation.
• bei der technischen Spezifikation

Aus einem Backlog (Spezifikations-Katalog) werden Stories für den nächsten Iterationszyklus ausgewählt. Die Tasks der Storys werden geplant, entwickelt und evaluiert (getestet). In einer Retrospektive über den Iterationszyklus gewinnt man formale und inhaltliche Erkenntnisse für die Formulierung der Stories des nächsten Zyklus.

Innovation ist gefragt:

1. auf verschiedenen Ebenen
   Ideen werden beim Erstellen der Storys, der Tasks und der Umsetzung der Tasks gebraucht.
2. zu bestimmten Phasen in der Iteration
   Auf Story-Ebene ist Innovation bei der Formulierung der Backlog-Items (= Stories) und bei der Überarbeitung derselben nach der Retrospektive gefragt. Beim Planen = Erstellen der Tasks auf der Basis einzelner Stories ist Kreativität hinsichtlich der Architektur notwendig. Bei der Umsetzung der Tasks braucht der Entwickler Ideen für den passenden Einsatz der optimalen Programmier-Technologie.

Die Stories werden doch vom Product-Owner (oder Projekt-Manager) geschrieben. Ja, aber dieser ist auf die Zusammenarbeit mit Entwicklern, Testern und Benutzern (UX = User eXperience) angewiesen, die ihn bei der Erstellung und beim Feedback nützliche (oder entscheidende) Hinweise geben.

Was ist eine Story? Als eine “Rolle” möchte ich eine “Funktionalität”, so dass “ein Ziel” erreicht wird.

Manchmal muss man aber auch seinen Usern voraus sein: ‘‘If I had asked people, what they wanted, they would have said, faster horses.’’ (Henry Ford)

In den Stories ist aber auch eine Menge kreatives Potential versteckt:

• Eine Story ist nie ganz eindeutig und verlangt immer eine Menge Kommunikation.
• Eine Story impliziert einen kreativen Wettstreit. Der PO möchte ein kreatives Feature umgesetzt haben, der Entwickler antwortet mit einer kreativen Umsetzung.

Die Stories (Feature-Requests) werden in ein oder mehrere Tasks umgesetzt. Bei diesem Vorgang ist wieder Kreativität gefragt, speziell um folgende Ziele zu erreichen:

• effektive Software-Entwicklung
• Qualitätssicherung
• Nachhaltige Software-Entwicklung

Aus Stories werden Tasks:

• Wie soll eine Story in Tasks aufgeteilt werden (1 Task = 1 Tag = 8h)?
• Im Task muss die Aufgabe (das Problem), die Umsetzung und die Testcases beschrieben werden.
• Was ist alles von meiner Änderung betroffen (muss getestet werden)?
• Sind diese dependencies sinnvoll / notwendig?

1. Kreativitäts-Workshop planen
2. Workshop umsetzen (1 Stunde)
3. Brüten (1 Woche)
4. Team review (1 Stunde)
   • die besten Stories werden ausgewählt
   • Machbarkeit und Validierungs-Möglichkeiten ausloten
5. Story schreiben
6. Story schätzen und im Backlog priorisieren

Möchte man wirklich alle Ideen zunächst einmal zulassen (und nur so profitieren die übrigen Mit-Kreativen davon), dann ist wichtig, dass die einzelne Idee, so abstrus und realitätsfern sie auch sein mag, nicht von den anderen diskriminiert wird.

Scott Berkun hat einmal einen Vortrag zu dem Thema ‘feedback without frustration’ gehalten, dessen Grundsätze hier sehr gut hinpassen.

• falsch
  • Klüngelei (faction), ‘aber da kann man ja gar nicht twittern’
  • Opfer, kein anderer hat einen Vorschlag, daher wird der eine zerpflückt
  • so tun als ob, die wahre Kritik findet unter vorgehaltener Hand statt
• richtig
  • Wenn es Dein Vorschlag ist, liegt die Kritik auch in Diener Verantwortung.
  • Es muss einen Moderator geben. Es könnte derjenige sein, der als erster zum whiteboard geht.
  • Es muss mindestens ein, besser mehrere Ziel(e) für die Kritik geben.
  • Unterscheide ‘mag ich / mag ich nicht’ von ‘gut / schlecht’.
  • Vermeide zu viele Köche, maximal 5 bis 6 Leute im meeting.

Tipps

• die erste Idee muss nicht die beste sein.
• Keine Angst vor Fehlern.
• Verwende alte user stories.
• have fun - Lachen erhöht die Kreativität

• Vorträge auf der OOP2012
  • Workshop “Innovation, Requirements and Agile” von Neil Maiden und Bianca Hollis
  • Vortrag “Thinking Creatively in Agile Projects” von Neil Maiden und Bianca Hollis
• Bücher
  • "Myths of Innovation" von Scott Berkun
  • "Mindfire" von Scott Berkun
• Die OOP2013 stand unter dem Motto ‘Continuous Innovation: The Foundation for Success’