Archive for Oktober, 2011

Innovationen und Unternehmenserfolg hängen eng zusammen – Einige Daten

Die Volkswirtschaftslehre weiß es schon lange – nun spricht es sich auf in der Betriebswirtschaftslehre rum. Der Schlüssel zum Erfolg, und damit die Frage, ob Unternehmen und Wirtschaft wachsen, liegt in ihrer Innovationskraft begründet.

Heute geht es um diverse Studien und Presseberichte, die helfen, diesen Zusammenhang empirisch zu belegen.


Planning Poker und Magic Estimation

Eine wichtige Aufgabe des Produktowners ist es dafür zu sorgen, daß das Team eine angemessene Anzahl von Aufgaben erhält: Nicht zuviel, und nicht zuwenig.

Da der Aufwand eines Entwicklungsprojekts oft nicht einfach einzuschätzen ist, und einem vielfach die notwendigen (kompletten) Informationen fehlen, sind Verfahren notwendig, mit denen man den Backlog schnell abschätzen kann, obwohl die Genauigkeit fehlt.


Requirement versus Specification

Apple hat neulich ein neues iPhone präsentiert, das von der Fachwelt zerrissen wurde. Im Gegensatz dazu ist das Smartphone jedoch von den Konsumenten sehr gut aufgenommen worden. Fragt sich, welche Rückschlüsse aus dieser Fehleinschätzung abgeleitet werden können.

Gerade heute war die übliche Frage mal wieder ein Thema, die da lautet „Was sollen Anforderungen, Spezifikationen, und Design-Dokumente leisten, und wer liefert sie?“. Heute will ich kurz auf die Rolle von Kundenwünschen, und auf die Rolle der Entwicklungsabteilung und damit auf das Thema „Spezifikationen“ eingehen.


Living Specification und Qualität der Software

Bereits an anderer Stelle habe ich über die Rolle von „guten“ Anforderungen im Softwareentwicklungsprozess geschrieben, und bin zu dem Ergebnis gekommen, daß es sich durchaus lohnt, Anforderungen so sauber und detailliert zu beschreiben, wir irgend möglich.

Auch ist es wichtig, professionelle Methoden zu verwenden, um zu prüfen, ob das entwickelte System die Anforderungen auch so abdeckt, wie von ihr verlangt.

Heute habe ich das Konzept der lebenden Spezifikation kennengelernt, das eine wichtige Rolle in der Schnittstelle zwischen Produkt-Owner, Entwicklung und Qualitätsicherung spielt. Dies will ich heute kurz skizzieren.


Focusing is about saying no

Gerade neulich habe ich einen Diskussion verfolgt, was denn wohl die sinnvollste Qualifikation für die Führungsmannschaft einer Technologiefirma sei – kaufmännisch orientiert, oder technisch orientiert? Gleichzeitig hat der Tod von Jobs ein Thema wieder auf die Agenda gebracht, nämlich seinen speziellen Ansatz Produkte zu gestalten, und den besonderen Fokus, den er dabei darauf gelegt hat, daß Produkte einfach zu bedienen sein sollen.

Wenn man genau hinsieht, hängen die beiden Themenbereiche zusammen.


Edwin Land, Steve Jobs und die perfekte Innovation

In den letzten Tagen ist viel über Steve Jobs geschrieben worden, und insbesondere auch die Frage, wo er seine Inspiration hergenommen hat. Hierzu hat die New York Times einen lesenswerten Artikel veröffentlicht, in dem klargestellt wird, das Edwin Land, der Erfinder der Polaroid Kameras eben diese Inspirationsquelle war.

Die Diskussion über den Nutzen und die Grenzen, die die Einbindung von Kunden in den Entwicklungsprozess hat, ist auch immer wieder ein Thema. Daher sind mir in dem Artikel mehrere Statements aufgefallen, die ich heute ebenfalls mit Ihnen teilen will.


Steve Jobs (1955-2011)

Heute morgen kam es bereits im Radio, heute Abend haben ihm die Hauptnachrichten mehrere Minuten gewidmet. Insofern ist es keine Neuigkeit mehr. Steve Jobs ist gestorben.

Wenn man -so wie ich- über Themen wie Technologie, Innovation, oder Produktmanagement schreibt, oder wenn man einfach nur  die Produkte einsetzt, die er erfunden hat, stolpert man häufiger über sein Schaffen, und kommt oft aus dem Staunen nicht heraus.

Daher hat mich die Nachricht genauso tief getroffen, wie die vielen Leute, die hierzu bereits etwas gesagt oder geschrieben haben. Obwohl sein Tod nicht ganz unerwartet kam, hinterläßt mich das Ereignis doch sprachlos.


Fokussieren eines Scrum Teams

Ich denke mal, daß es häufiger vorkommt, daß ein Scrum Team nicht für ein komplettes Produkt verantwortlich ist, sondern Teilbereiche der gesamten Funktionalität verantwortet. Auch ist es sicherlich nicht unnormal, daß ein Team mehr als einen Stakeholder unterstützen muss oder komplexe Technologien verwendet, oder Funktionalitäten in unterschiedlichen Releases unterstützt.

Unter solchen Rahmenbedingungen stellt sich die Frage, was der Produktowner tun kann, damit ein Team nicht in mehrere Teilgruppen zerfällt die dann auch noch unterschiedlich spezialisiert sind.