Das Team ist das zentrale Element in Scrum. Die Chance, über effektive Teamarbeit Synergie zu kreieren, ist allerdings von verschiedenen Variablen abhängig, unter anderem auch von der schnellen und gezielten Entwicklung des jeweiligen Teams. Definierte Teams gestalten immer von sich aus ihren, meist unbewussten, Arbeits- und Sozialprozess, der jedoch durch gesteuerte Teamentwicklung schneller und effizienter verlaufen kann.

Teamentwicklung ist definiert als die gezielte Einwirkung auf die komplexen, offenen und verdeckten Prozesse eines definierten Teams, bezogen auf die Aufgabenstellung, das Struktur- und Beziehungsgefüge und die einzelnen Teammitglieder, zur Optimierung von Arbeitsfähigkeit und Effizienz und der Bearbeitung aktueller Blockaden.

Gezielte Teamentwicklung gehört zu den Aufgaben des ScrumMasters, der zur Gestaltung und Umsetzung differenzierte Modelle und Methoden braucht. Ein effektives Instrument in der Teamentwicklung ist das Modell der „Drei Grundwerte sozialer Systeme“ Dieses Modell eignet sich optimal zur Teamprozessanalyse und kann die zentralen Elemente von Dynamiken und Prozessen im Team darstellen

Es ist ein systemisches „Urmodell“, das in vielen Kulturen in ähnlicher Ausprägung vorkommt, und aussagt, dass in allen vorfindbaren sozialen Systemen (Teams) dieses Set der Grundwerte Wissen/Know-how, Ordnung/Struktur, Vertrauen/Beziehung als vorgegeben existiert: Diese Grundwerte sind von zentraler Bedeutung für den Prozess der Selbstorganisation des Systems (Teams). Die zentrale Botschaft dabei ist, dass jeder dieser drei Werte im Team gewürdigt, gelebt und fließend entwickelt werden muss. Sind diese drei Werte in ausgewogener Balance, bedeutet dies für Teams Stabilität und Lebensenergie im Sinne effektiver Selbstorganisation. Entsteht eine Dynamik von Dis-Balance, d.h. ein Wert dominiert überproportional bzw. ein Wert ist sehr schwach ausgeprägt, erleben Teams diesen Zustand als z.T. massive Störung.

• Wissen/Know how stärkt Teams in der Bewältigung fachlicher Anforderungen, im Umgang mit Arbeitsstrukturen und –prozessen und dient sowohl der Gegenwarts- als auch der Zukunftssicherung.
• Ordnung/Struktur schafft zentrale Regularien zur  Orientierung und Handlungssicherheit. Neben Regeln und Prozessen sind Hierarchie und Führung zwingend notwendige Ordnungselemente.
• Vertrauen/Beziehung gestaltet das soziale Miteinander im Sinne von Klima, Wir-Gefühl, persönlichem Schutz und Sicherheit und Zugehörigkeit.

Der ScrumMaster in der Teamentwicklerfunktion kann daraus ein Prozessanalyseschema ableiten, das ihm und dem Team ermöglicht, z.B. in Retrospektiven oder Teamentwicklungsworkshops den Ist-Stand zu definieren und Entwicklungsfelder abzuleiten.

Ein Teamentwicklungsprofil könnte z.B. folgendermaßen aussehen:

Jedes Team hat ein individuelles Profil, das sich aus der Ausstattung und dem Zusammenwirken der Grundwerte gut ableiten lässt. Dieses Profil kann der ScrumMaster für sich als Beobachtungs- und Diagnoseinstrument entwickeln und nutzen, aber auch mit dem Team gemeinsam er- und bearbeiten. Der Prozess mit einer konsensorientierten Reflexion und Festlegung des Ist- Standes des Teams zwischen den Polen 1 und 10 und der Definition von Entwicklungsfeldern setzt eine fruchtbaren Dialog in Gang und ist damit Teamentwicklung par excellence. Die einzelnen Elemente jedes Grundwertes sind hier beispielhaft dargelegt und können je nach Praxissituation ergänzt werden.

Dieter Rösner, Trainer ScrumMaster Pro

Related posts:

1. Der klassische Projektmanager in Scrum
2. ScrumMaster Pro – TeamDevelopment
3. Was macht Scrum Teams eigentlich hyperproduktiv?

Es kann nicht oft genug gesagt werden: Natürlich ist Scrum ein Framework, um Organisationen, Product Development und Team zu managen und zu führen. Selbstverständlich kann ein Framework nicht Lösungen für jede Organisation, jede Abteilung oder jedes Team haben. Selbstverständlich muss jede Organisation best practices entwickeln, die nur in ihrem Kontext funktionieren. Die besten Beispiele dazu sind die Firmen, die heute nach Jahren sehr erfolgreich mit Scrum, KANBAN oder anderen agilen Methoden und Ideen sind.
Doch den ersten Schritt vor dem zweiten zu tun, also die Anpassung vor der Meisterschaft der eigentlichen Ideen ist meist, nein immer verkehrt. Ein Kind lernt auch nicht das Rennen, Springen, Klettern bevor es das Krabbeln, das Stehen, das vorsichtige wackelige Gehen und dann das sichere Laufen meistert. Das dauert – und ist mit etlichen Fehlschlägen bezahlt. Fehlschläge, die oft wehtun, die frustrieren und die das Kind immer weiter bringen.

Habt ihr mal Eltern beobachtet, die dabei zusehen, wie ihre Kinder laufen lernen? Wenn nicht, sucht euch einmal ein Elternpaar, das ein 8 Monate altes Kind hat oder geht in eine Krabbelstube und schaut zu. Es ist sehr faszinierend zu sehen, dass diese Eltern nicht ein einziges Mal sagen werden: „Oh du bist zu blöd zum Laufen, das wird nie etwas. Du musst das so oder so machen. Wieso hast du denn den Fuß nicht nachgezogen? Jetzt schau aber mal her, ich zeig dir, wie es geht.“ Meistens hört man doch: „Bravo! Das machst du toll. Ja so geht’s. Man, hab ich dich lieb.“
Sie stehen da, freuen sich über jeden noch so kleinen Schritt und sie sind da, wenn das Kind fällt, nehmen es in den Arm und trösten es. Was sie auch tun: Sie sichern ab, sie geben dem Kind Halt, sie geben ihm einen Rahmen, sie passen auf, dass das Kind nicht zu nahe an der Treppe übt, räumen die Tischdecke weg, damit das Geschirr nicht mit runterkippt. Sie umsorgen, aber sie lehren nicht.

Positive Verstärkung bis zum Abwinken. Es ist schon manchmal peinlich anzuschauen. Als gäbe es nichts Wichtigeres auf der Welt. Ganz ehrlich, einige übertreiben es, aber … es ist POSITIV!

Eigentlich merkwürdig. Sind die Kinder im Vorschulalter und sollen malen, zeichnen oder schreiben lernen, ist es mit dieser Art des Umsorgens, des Förderns, des Daseins für Kinder vorbei. Plötzlich wird vorgemacht, ermahnt, gedroht, gestraft und von der positiven Verstärkung ist nicht mehr viel übrig geblieben. Ich bin sicher kein Einzelfall gewesen. Bei mir war das Diktate üben: Horror! (1)

Natürlich ist Laufenlernen etwas, das Kinder instinktiv machen. Sie lernen, dass sie zu etwas hingelangen, wenn sie sich auf den Weg machen. Eltern bestärken sie. Aber dass sie wirklich Laufen lernen, ist nicht gesagt. Ich habe als Kindergärtner während meiner Zivildienstzeit mit Kindern gearbeitet, die über den Boden robbend genauso schnell ein Ziel erreichen konnten, wie jene Kinder, die laufen konnten. Es ging auch gar nicht anders, denn diese Kinder hatten entweder körperliche Gebrechen oder waren einfach zu dick. Sie bekamen ihren Hintern nicht hoch. Es dauerte fast 12 Monate, bis die Muskeln stark genug waren. Tägliches Training – ja, da mussten Therapeuten helfen.

Wie ist das mit Scrum – geht das instinktiv? Nein! Wir haben zwar die Veranlagung, aber die Instinkte, die uns dazu führen würden, unsere angeborenen Strukturen auszubilden, werden durch Erziehung, Sozialisation, Kultur und Organisationen unterdrückt. Wir beginnen sofort, uns verbogen zu verhalten. So wie es Menschen gibt, die künstlichen Orangensaft dem geschmacklich eindeutig spannenderen Naturprodukt vorziehen, so haben wir verlernt, unseren anthropologischen Eigenschaften zu folgen.

Scrum und seine best practices sind, wie Ken immer sagte, “common sense”. Gerade den müssen wir aber erst zurückgewinnen. Wir müssen wieder lernen, dass frischer Orangensaft besser schmeckt als das Industrieprodukt.

Das geht nur, indem wir uns auf den Weg machen und dabei verstehen, dass das Erlernen neuer Fähigkeiten nur durch üben, üben und nochmals üben erreicht wird. So wie das Kleinkind über Jahre zum Meister des Laufens wird und irgendwann überhaupt nicht mehr darüber nachdenkt, dass es nicht laufen könnte. Dieses Lernen gelingt Erwachsenen aber oft nur, wenn sie verstehen, dass sie sich in einem Stufenprozess des Lernens befinden. In der agilen Community war es meines Wissens Alistair Cockburn, der als Erster den Begriff des ShuHaRi in unserer Bewegung einführte: Dieser Begriff kommt ursprünglich aus den japanischen Kampfkünsten, z.B. Aikido.(2) Dort herrscht das Prinzip Shu-Ha-Ri. Dieser Begriff besteht aus drei Silben, bei der jede für eine Phase des Lernens von Aikido steht. “Laut Masayuki Shimabukuro ist “Shu-Ha-Ri” wie ein Kreis in einem Kreis in einem Kreis.” (3)

1. Die erste Phase, Shu, ist das genaue Nachmachen der Kampfbewegungen wie der Meister sie lehrt. Dabei wird vom Schüler die Korrektur durch den Meister dankbar angenommen und akzeptiert. Im Gegenzug schützt der Meister seine Schüler und motiviert sie zum weiteren Lernen, das die Basis für die zweite Stufe, Ha, ist.
2. In der zweiten Lernstufe Ha versteht der Schüler die Hintergründe der Regeln und Techniken und beginnt mit kleinen Anpassungen und Veränderungen.
3. In der letzten Stufe dem Ri ist der Schüler nicht länger Schüler, sondern wird selbst zur Regel. Er beherrscht die hohe Kunst und kann seine Fähigkeiten nutzen und situativ anpassen. Er ist selbst zum Meister geworden und stellt seine eigenen Regeln auf.

“Wie der Meister sie lehrt” – Selbstverständlich weiß der Meister, dass es unzählige andere Wege gibt, den Gegner zu bezwingen und dennoch entschließt er sich, dem Schüler nur eine Weise beizubringen. Genau das ist der Ansatz, den wir beispielsweise vorgeben, wenn wir Scrum bei Kunden einführen. Wir geben eine Art vor, das Sprint Planning durchzuführen. Eine Weise vor, das Daily Scrum zu machen und so weiter. Das schafft auf der einen Seite zwar eine Einschränkung, auf der anderen Seite führt es aber auch zu Sicherheit. Es führt zum Erfolg, weil der Scrum Coach oder auch ScrumMaster weiß: “So wird es sicher funktionieren.”

Die Aufgabe des ScrumMasters und des Scrum Coaches ist es dann, dafür zu sorgen, dass das Team diese kleinen Erfolge hat und diese sofort durch “Bravo!” zu verstärken. Er muss dafür sorgen, dass sein Team sofort POSITIVE Verstärkung bekommen kann. Wer dazu einen sehr bekannten Text lesen will, dem sei das erste Buch der One Minute Manager Reihe empfohlen.

Wer in Wien ist und Lust hat, mit mir mal diese Praxis vollkommen gefahrlos zu üben und sich nicht scheut dreckig zu werden, den lade ich ein, mit mir sonntags eines meiner Pferde zu versorgen. Da kann man zusehen, wie positive Verstärkung zu Erfolgen führt. Da sieht man wie Lernen im Zeitraffer-Tempo funktioniert. (4)

(1) „Young children do not have motivation problems. (…) We never see a 2-year-old who is depressed about how his talking progress is going on and so has decided to quit trying to improve. (…) But at age 6, all this changes. Children try to avoid having to learn, they fear failure, their educational goals are to please authority or do less work. (…) What has happened? The 6-year old has started school.” (Schank 1993/1994, p. 430) aus der Vorlesung “Pädagogische Psychologie” von Prof. Fischer LMU

(2) Alistair Cockburn (2000): Agile Software Development

Die Quellen darin sind:

• Kuroda, Ichitaro: “Shu-Ha-Ri” ;Sempo Spring 1994 pp 9-10.
• McCarthy, Patrick: “The World Within Karate & Kinjo Hiroshi”; Journal of Asian Martial Arts. V. 3 No. 2 1994.
• Private conversations with Nakamura, L. Sensei, Toronto, Spring 1994.

(3) Zitat und Abbildung Shu-Ha-Ri aus http://www.aikido-blog.de/shu-ha-ri-die-lernstufen-im-budo-aikido/

(4) Wer darüber noch mehr lernen will. Dem empfehle ich “Gregory Bateson: Ökologie des Geistes.”

Related posts:

1. Schuldzuweisungen verhindern Lernen
2. Hellseherei – oder die Planung des Unplanbaren
3. Scrum Alliance mal wieder führungslos – Donna Farmer geht

Wer iterativ entwickeln will, hat ein grundsätzliches Problem: Er weiß nicht, ob er in der Zukunft eine Anforderung erhält, die es notwendig machen wird, Grundannahmen umzuwerfen. Das kann im extremsten Fall dazu führen, dass große Teile des Produkts nachträglich verändert werden müssen. Dieses Wissen treibt viele Softwareentwickler zu der Überlegung: Man müsste ein Framework entwickeln, das möglichst robust ist, sodass man möglichst flexibel auf zukünftige Wünsche eingehen kann.

Dieser Ansatz wird immer wieder versucht, immer wieder entstehen neue Frameworks, immer wieder wird zu Anfang eines Projekts in der Produktentwicklung versucht vorherzusehen, was möglicherweise in der Zukunft auf uns zukommen könnte.

Gehen wir das Thema doch mal von einem anderen Standpunkt aus an. Stellen wir uns einfach mal vor, wir müssten heute eine Applikation anpassen. Eine Applikation, die wir nicht selbst geschrieben haben, die wir überhaupt erst zum ersten Mal sehen. Wir wissen nur, dass wir etwas Grundsätzliches an der Applikation ändern müssen, da der Kunde ein vollkommen neue Anforderung hat. Was würde uns in dieser Situation als Entwickler helfen, die Veränderungen an der Software schnell und sicher, zufriedenstellend für alle,  durchzuführen?

Nun – wir müssten die Applikation, mit der wir es zu tun haben, verstehen. Richtig? Wir steigen also in den Keller unserer Applikation, in die Eingeweide und versuchen zu ergründen, was diese Software tut, wie die Dinge zusammenhängen. Grob: Wir wollen die Frage beantworten, wie dieser “Organismus” Applikation im Detail funktioniert.

Vergleichbar ist das mit der Arbeit von Archäologen. Wenn diese zu ergründen suchen, wie vergangene Kulturen gelebt und gearbeitet haben, können sie die Menschen von damals nicht direkt fragen. Wir wollen genauso wie die Archäologen herausfinden, was die Softwareentwickler vor uns getan haben.

Uns als Software-Archäologen würde es

1. helfen, wenn das, was wir vorfinden, möglichst selbsterklärend ist. Es würde uns
2. auch helfen, wenn wir Hinweise finden würden, die uns erklären, wieso die Erbauer dieser Ruinen die Dinge gerade so gestaltet haben, wie sie sie gestaltet haben. Wir bräuchte also ihre damaligen Entscheidungen nicht zu interpretieren, wir bräuchten keine Hypothesen, denn es stünde ja da.
3. Drittens wäre es toll, wenn wir eine Referenz hätten. Wenn wir Vergleiche mit ähnlichen Städten oder Ruinen hätten, die wir schon verstanden haben.

Bei dem Vortrag, den ich vor einigen Tagen vor 80 Softwarearchitekten gehalten habe, fragte ich diese Gruppe, wie ein solcher Zustand in unseren Applikationen zu erreichen sei. Sie gaben mir eine Liste von 5 Punkten:

• Einfachheit: Nur das sollte implementiert sein, was die Software wirklich braucht. Je weniger Code, desto besser. Lieber weniger Implementieren und die nächste Funktionalität in ein anderes Modul stecken.
• Modularität: Das führt natürlich sofort dazu, dass die Applikation möglichst modular aufgebaut sein sollte. Die Schnittstellen zwischen den Modulen sollten ebenfalls klar sein.
• Lesbarkeit: Der Code sollte so strukturiert und geschrieben sein, dass er leicht verständlich und lesbar ist.
• Inline-Dokumentation der Entscheidungen: Es sollte im Code erklärt sein, warum gewisse  Entscheidungen so getroffen wurden, wie sie getroffen wurden. Der Code selbst ist ja die Dokumentation dessen, was der Code macht. Nur wieso man die Dinge so angegangen ist, wie sie vorliegen, wäre wichtig zu wissen.
• Testbarkeit: Der Code sollte eine hohe Testabdeckung haben und der Testcode selbst ist ja auch eine Form der Dokumentation.

Ich stelle mir vor, ich wäre Software-Archäologe und würde diese Situation in der mir anvertrauten Applikation vorfinden. Das wäre doch toll. Ich hätte die Chance sehr schnell zu verstehen, um was es geht. Die Zusammenhänge innerhalb der Software wären leichter erkennbar oder durch Wegweiser ausgewiesen. Ich könnte mich in Baby-Steps durch die Applikation hindurch bewegen. Und wenn ich etwas falsch mache, würde das sofort auffallen, weil ich den Testcode habe.

So und nun schauen wir nicht mehr als Software-Archäologe auf die Situation, sondern von meiner heutigen Situation in die Zukunft. Ich selbst bin es, der möglicherweise die Applikation in der Zukunft verändern muss. Also wieso mache ich es mir nicht selbst einfach in der Zukunft etwas zu ändern. Ja, ich muss dafür möglicherweise heute etwas sorgfältiger und klarer und deutlicher arbeiten, aber das macht sich doch in der Zukunft mehr als bezahlt.

Agile Architektur bedeutet nicht, die besten robustesten Patterns zu benutzen oder alles vorherzusehen.  Ihr Wesen liegt darin, dass man die Applikation so leicht und schnell wie möglich ändern kann.

Related posts:

1. Definition “Done” | Was ist “potential shippable code”?
2. Die Scrum Alliance ist richtungslos
3. Cloud Computing eine Bedrohung für Jobs?

Größte Kreativität entsteht oft, wenn die Möglichkeiten begrenzt sind. Das vielleicht eindrucksvollste Beispiel, das ich 2011 zu diesem Thema gefunden habe, war die Arbeit von Gary Chang. Als Architekt in Hongkong hat er sich mit den Möglichkeiten auseinandergesetzt, Wohnungen auf kleinstem Raum zu gestalten. Wohnungen, die dennoch alles bieten, was man benötigt.

http://www.youtube.com/watch?v=ynVJJLHvF9U

Kreativität braucht ein Problem, das am besten sogar als überlebenswichtig angesehen wird. Nach meiner Erfahrung sind Menschen dann richtig kreativ, wenn sie ein wirkliches Problem unter hohem Druck lösen müssen und die Ressourcen zur Problemlösung tatsächlich haben. Das berühmteste Beispiel dazu findet man in der Verfilmung der Apollo 13 Mission. Die Ingenieure sitzen in einem Raum auf dem Boden, der Chefingineur kommt herein, wirft dem Team alles verfügbare Material in der Kapsel der Apollo 13 auf den Tisch und sagt sinngemäß: “Ihr habt 14 Stunden Zeit, um mit diesen Materialien etwas zu schaffen, das den Jungs das Leben rettet.” Selbst in Lebensgefahr zu sein hilft wahrscheinlich nicht – hier ist oft der Stresslevel einfach zu hoch und man handelt rein instinktiv. Panik und Angst verhindern das systematische Nachdenken.

Der kreative Denkprozess ist aber grundsätzlich systematisch und in Phasen gliederbar. Er ist vergleichbar mit dem kreativen Spielen von Kindern und Erwachsenen. Dave Gray hat daraus eine Methode abstrahiert, lassen wir ihn kurz zu Wort kommen:

“Why games indeed. I asked myself the same question. The idea for knowledge games didn’t come from some inspiration that struck me in some ivory tower, but from watching people at the cutting edges of new disciplines; people who are entrepreneurs, creators, designers and innovators. Watching them work, watching them play, and sometimes having difficulty telling the difference.

“What are they doing?” I asked myself. They don’t work like other people. What they are doing looks chaotic from the outside, but on closer inspection seems to have a hidden order. I’ve observed meetings that aren’t like the kind of meetings most people are used to: meetings that seem to have no order to them, where people seem to come and go at will. And paper. Lots of paper. These are hard-core geeks; some of the most technological savvy people on the planet. Why are they using low-tech tools like flip charts, sticky notes, index cards and whiteboards? It seems they are rejecting the very technologies they are in the process of inventing. At some point I came to realize that the hidden order I saw in these innovative teams was the same order and structure to be found in games of all kinds.” Mehr dazu in seinem Buch “Gamestorming”. Hey, keine Breakthrough-Idee, aber sehr gut aufbereitet.

Kreativität braucht also einen “begrenzten” Raum, ein klar definiertes Problem und einen deutlichen Prozess – wie kommt es nur, dass mir fast wie von selbst unser Scrum Prozess ins Auge springt :-).

Related posts:

1. Scrum in the Games industry | Games Focus 2009
2. Games Focus Hannover 2009 – Professionalization of the Games Industry with Scrum
3. Massive Multiplayer Online Games the Digital Business School of the Next Generation

Sie sind Teamleiter, Scrum-Master, Projekt-Manager und finden sich in nachstehender Annonce wieder?

Suche: Interaktive Tools zur Teambildung

Biete: Kommunikationsbarrieren, Abstimmungsschwierigkeiten, Rollenkonflikte, Intransparenz, Teamnebel, verkrustete Denkweisen, Handlungsroutinen, Langeweile im Berufsalltag

Dann lesen Sie unbedingt weiter!
Der aus meiner Sicht größte Sportler des vergangenen Jahrtausends ist Michael Jordan. Sechsfacher NBA-Champion (National Basketball Association), zweifacher Olympiasieger, Werbefigur, Vorbild, charismatische Persönlichkeit. Mit seiner Spielweise begeisterte er Millionen von Fans und wurde zu einer Legende in der Teamsportart Basketball. Jordan steht allerdings nicht ausschließlich für Superlative und Eintragungen in die Hall of Fame. Nicht wenige sehen in dem Basketballspieler Michael Jordan eine beispiellose Ich-AG, die ihre Teammitglieder durch ihre Art zu spielen zu Nebendarstellern machte und häufig den persönlichen (Korb-)Erfolg offenkundig über den des Teams stellte:

I can remember a game, we were down with about 5 to 10 points, I go off about 25 points, we come back and win the game, we`re walking off the floor. Tex (Winter) looks at me and says: "Michael, there is no "I" in team!"I looked at Tex and said: "There is not. But there is an "I" in win!" Michael Jordan

Die vielen Preise, Auszeichnungen und Erfolge geben Michael Jordan recht. Wer jedoch zwischen den Zeilen liest, erkennt zweierlei. Zum einen war die One-Man-Show “Michael Jordan” nur deshalb möglich, weil sich die Mitspieler diesem Umstand unterordneten und (mehr oder weniger freiwillig) ins zweite Glied rückten. Teampsychologisch spricht man in einem solchen Fall von Ergebnisorientierung: “…was oft zur Folge hat, dass Einzelne nicht mehr berücksichtigt werden und somit der Erfolg den Einsatz aller Mittel heiligt.” (http://de.wikipedia.org/wiki/Team) Zum anderen ist das Phänomen “Michael Jordan” nicht der Normalfall. In der Mehrzahl der Teams, egal ob im Sport oder im beruflichen Kontext, liegen die Leistungsniveaus viel näher beieinander.

Apropos Team? Was ist das eigentlich? Wikipedia definiert den Anglizismus “Team” (= Familie, Gespann) als “einen Zusammenschluss von mehreren Personen zur Lösung einer bestimmten Aufgabe oder zur Erreichung eines bestimmten Zieles.” Mabei und Caird sehen in diesem Zusammenhang u.a. folgende Hauptkriterien als Voraussetzung, damit man von einem Team sprechen kann:

• Ein Team hat mindestens zwei Mitglieder, diese tragen zur Erreichung der Teamziele mit ihren jeweiligen Fähigkeiten und den daraus entstehenden gegenseitigen Abhängigkeiten bei.
• Das Team hat eine eigene Identität, die sich von den individuellen Identitäten der Mitglieder unterscheidet.
• Durch Spezialwissen und die gemeinsamen sachliche/fachliche Herausforderungen soll Kohäsion entstehen.

Viel zu oft hört, liest oder sieht man aber diesen Zusammenschluss mehrerer Personen (siehe oben), der eben noch KEIN richtiges Team ist. Jeder kocht sein eigenes Süppchen, ist verunsichert, hält sich zurück, bleibt auf seinem Wissen sitzen oder kennt seinen Platz im Team noch nicht. Kommt Ihnen das bekannt vor?

Ein gewinnbringendes Mittel, solchen Vermummungseffekten zu begegnen und dafür zu sorgen, dass Menschen intrinsisch motiviert und eigendynamisch an einer Status-quo-Veränderung mitwirken wollen und können, ist das (Team-)Spiel. Schon Goethe hat sich dafür ausgesprochen, dass der Mensch einzig und allein dort ganz Mensch sein kann, wo er spielt. Schenkt man diesem Postulat Glauben, dann gibt es doch nur eins: T – U – N.

Probieren Sie es doch einfach mal mit Ihrem Team aus! TUN Sie.

Zutaten für die „spielerische“ Teambildung

- 1 Rolle Paketschnur

- 1 Rolle Kreppband

- 20 Spaghettis (nicht gekocht)

- 1 Marshmallow

Aufgabenstellung

“Baut aus den Zutaten einen freistehenden Turm, auf dessen Spitze der Marshmallow sitzt. Dafür habt ihr 18 Minuten Zeit. Ziel ist es, den Turm so hoch wie möglich zu bauen.”

Organisationshinweise

Gespielt wird an einem Tisch ohne Stühle (stehend). Halten Sie die Timebox ein und informieren Sie das Team regelmäßig über die verbleibende Spielzeit. Teilen Sie Beobachter ein. Machen Sie Fotos von den Lieferungen und machen Sie diese für alle im Unternehmen sichtbar.

Feedback

Nutzen Sie die Spielenergie für ein ausführliches Feedback. Unterteilen Sie das Feedback in Aussagen zu Planung, Entscheidung, Produktion, Ergebnis. Welche Rollen haben Sie gesehen? Was hat die Produktivität behindert? Welche Verhaltensweisen kommen Ihnen im beruflichen Berufs- und Teamalltag bekannt vor etc.?

David Holzer, Scrum Consultant

Related posts:

1. Scrum & das Team – Rückblick auf den ScrumDay in München
2. Education Paradigms & Softskills
3. Das b!g Portal Team hat einen Grund zum Feiern

So kurz vor Weihnachten durfte ich bei einem der Teams, mit denen ich arbeite, eine wirklich nette „Retro“ miterleben. “Retro” in Anführungszeichen, weil nicht wirklich alle Elemente vorhanden waren, aber in diesem Fall war das auch nicht so wichtig. Was zählte war die Wertschätzung für die geleistete Arbeit der einzelnen Teammitglieder. Für den ScrumMaster steckte eine recht lange Vorbereitungszeit dahinter, aber jeder sollte jedem am Ende des Jahres etwas Nettes sagen. Vielleicht ist das auch eine Idee für eure Teams.

Der Weihnachtsbaum, den ihr hier seht, steht in einer Matrix. Am unteren Rand (Geschenke) und senkrecht an der linken Seite sind die Namen der einzelnen Teammitglieder angeordnet. Zunächst versammeln sich alle „um den Baum“ und machen folgendes:

1. Schritt: Für jedes Teammitglied gibt es eine Kerze (zunächst leer)
2. Schritt: Jedes Teammitglied schreibt in seine Kerze ein paar Punkte zur Frage „Was motiviert mich, frühmorgens aufzustehen und zur Arbeit zu gehen?“ (z.B. in diesem Fall: das tolle Team, der Spaß im Team, der Gedanken- und Wissensaustausch) und erläutert es dann den anderen. Danach klebt jedes Teammitglied seine Kerze an den entsprechenden Platz – also den Schnittpunkt zwischen der Zeile und der dazugehörigen Spalte mit seinem Namen.

Jetzt geht es weiter auf Bild 2.

3. Schritt: Jeder nimmt eine Christbaumkugel und schreibt für die einzelnen Teammitglieder folgendes auf:
Was fand ich an deiner Arbeit toll, was habe ich besonders geschätzt?
Was möchte ich dir im nächsten Jahr schenken, im Sinne von: Was wünsche ich mir mit dir gemeinsam zu tun?
Das klingt dann zum Beispiel so: „Ich fand es klasse, wie engagiert du dich um das Thema Trainings gekümmert hast. Nächstes Jahr möchte ich dich dabei stärker unterstützen und dir einige Organisationsarbeiten abnehmen.“

4. Schritt: Nachdem die Christbaumkugeln beschriftet sind, stellt sich jedes Teammitglied der Reihe nach vor den Baum und erhält seine Geschenke von den anderen. Jeder einzelne liest also vor, was er toll fand und wie die gegenseitige Unterstützung aussehen wird. Anschließend hängt der Vorlesende die Kugel an die richtige Stelle am Christbaum.

5. Schritt: Nachdem ein Teammitglied seine Geschenke erhalten hat, wird nachgefragt, wie es sich jetzt fühlt.
6. Schritt: Kekse essen und Spaß haben!

Sven Blesin, Scrum Consultant

Related posts:

1. Hallo bor!sgloger community
2. Scrum Rollen: Das Team
3. Was macht Scrum Teams eigentlich hyperproduktiv?

Wo kommen neue Produktideen her? Kann man sie einfach so aus sich heraus kreieren? Ich denke schon. Allerdings benötigt es dazu eine Form von Achtsamkeit, die nach innen schaut. Was beobachte ich in mir, welche Stimmen und Stimmungen wollen mir etwas sagen? Welche Träume habe ich, was mache ich aus diesen Träumen? Welche Einfälle habe ich gerade jetzt? Oft muss man diesen Strömungen dann einfach nachgehen und alles andere vergessen.

In diesem Video kommen Autoren zu Wort, die das viel besser ausdrücken können als ich.

http://www.youtube.com/watch?v=znqqoOlsIjM

Related posts:

1. Videos
2. Kommunikation im kreativen Prozess: Interessante Links
3. Ein Teilnehmer | Certified ScrumMaster Training

Letztens habe ich mit meinem Zahnarzt über die Software gesprochen, die er in seiner Praxis einsetzt. Die wurde ursprünglich von einem seiner Kollegen gemeinsam mit einem Programmierer entwickelt und zunächst nur in dessen eigener Praxis verwendet. Meinem Zahnarzt hat der visionäre Kollege die Software seinerzeit am Dachboden mit einer solchen Begeisterung vorgeführt, dass für meinen Zahnarzt sofort klar war, dass er auch in seiner Praxis damit arbeiten möchte. In der Zwischenzeit, bis mein Zahnarzt sich die Software leisten konnte, hatte sich der andere Zahnarzt völlig auf das Produkt fokussiert und war nur noch als Geschäftsführer seiner neu gegründeten Software-Firma tätig.

In dieser Position lud er alle Nutzer der Software ein Mal pro Jahr zu einem kleinen, kostenpflichtigen Kongress ein. Dort gab es zahnmedizinische Fachvorträge, aber auch völlig „artfremde“ Vorträge. Außerdem hielt er jedes Mal eine Session ab, an der die Entwickler teilnahmen, die Nutzer ihre Wünsche äußern und Feedback geben konnten. Über die einzelnen Vorschläge wurde dann in großer Runde diskutiert. Das jeweils folgende Jahr wurde dazu genutzt, die Vorschläge einzuarbeiten und das Produkt aktualisiert zur Verfügung zu stellen.

Ein guter Product Owner versteht seine Kunden

Für mich ist der ehemalige Zahnarzt, der zum Geschäftsführer der eigenen Software-Firma wurde, ein tolles Beispiel für einen Product Owner, der Kundennutzen und Wirtschaftlichkeit gleichermaßen im Blick haben muss, um erfolgreich zu sein. Die Software integrierte alle nötigen Anwendungen, um eine Praxis und ihre Patienten mit einem hohen Qualitätsanspruch zu managen und ließ mehr Zeit für das Wesentliche: Für das Verständnis, WAS dem Patienten fehlt und WIE der Arzt am besten helfen kann. Man konnte in diesem Produkt das Verständnis für die Probleme und Anforderungen der User spüren. Alle bürokratischen und verwaltungstechnischen Aufgaben waren weitgehend auf Knopfdruck zu erledigen. Dafür gab es mehr Möglichkeiten, die Informationen zu den individuellen Behandlungen umfangreich zu dokumentieren, um stets einen aktuellen Überblick zu bekommen.

Ich denke, der Software-Zahnarzt hätte sich selbst wahrscheinlich gar nicht als Product Owner bezeichnet, aber er hatte all das, was ein Product Owner braucht. Hat er doch eine Vision gelebt und es geschafft, seinen Kollegen einen Mehrwert bei ihrer täglichen Arbeit zu liefern, den niemand, der die Software einsetzt, heute noch missen möchte. Er hat es außerdem geschafft, die Kundenbedürfnisse so abzufragen, dass alle gerne zu den Veranstaltungen gekommen sind, auch weil es dabei nicht nur um Software und Zahnärzte ging, sondern vielmehr um einen ehrlichen, offenen Austausch zwischen den Kollegen. Es wurde eine Plattform geschaffen, bei denen man Gleichgesinnte getroffen hat, die laut meinem Zahnarzt auch heute noch seine ersten Ansprechpartner für den kollegialen Austausch sind.
Allerdings hat sich der Zahnarzt-PO dann aus der Geschäftsführung zurückgezogen. Seitdem bemerkt mein Zahnarzt, wie sich die Qualität des Produktes verändert. Fehlerhafte Updates werden ausgeliefert, auf das Feedback von Kunden wird schwerfällig reagiert, und das persönliche Einholen von Feedback wurde komplett eingestellt.
Oder wie es mein Zahnarzt ausdrückte: „Ich habe damals eine Philosophie gekauft. Heute ist es leider nur noch ein Produkt.“

Kristina Kleßmann, Scrum Consultant

Related posts:

1. Wir haben zu wenig gute Product Owner
2. Commitment des Product Owners
3. Wissen, was am wichtigsten ist…

Ich beschäftige mich tagein und tagaus mit Veränderung. Als Gründer und Visionär meiner eigenen Firma und natürlich als Coach für die Menschen, die bei der Einführung von Scrum oder beim Einfinden in ihre neue Rolle meine Unterstützung haben wollen. In beiden Positionen erlebe ich ein interessantes Phänomen: Das manchmal unbewusste Sträuben gegen die Veränderung, die das Management, Mitarbeiter oder ein Coachee eigentlich selbst wollen.

Es gibt darauf einige althergebrachte, aber für meine Begriffe zu platte Erklärungen: Dass Menschen eben Angst vor Veränderung haben, dass sie sich nicht verändern wollen, weil es zu anstrengend ist etc. etc. So einfach ist das meiner Meinung nach nicht und bei meiner Suche nach einer differenzierteren Erklärung bin ich auf das SCARF-Modell von David Rock gestoßen.

SCARF ist ein Akronym für die fünf Begriffe

• Status
• Certainty – Gewissheit
• Autonomy – Autonomie
• Relatedness – Verbundenheit
• Fairness – Gerecht sein

Nach Rock schüttet das Gehirn Neurotransmitter und Enzyme aus, wenn diese fünf sozialen Bedingungen eintreten bzw. sinkt die Menge an Neurotransmittern, wenn diese Voraussetzungen fehlen. Wenn man weiß, dass in einem Mitarbeiter oder Coachee – bzw. in jedem Menschen – dieses Streben nach positiven Zuständen unwillkürlich abläuft, kann man die Arbeit an der Veränderung gleich viel sensibler und zielführender angehen. Besonders deutlich erlebe ich immer wieder Situationen, in denen es um den Status geht, daher greife ich mal diesen Punkt besonders heraus.

Das Streben nach Erhöhung des Status

Wenn ein Mensch eine Statuserhöhung erlebt, schüttet das Gehirn Dopamin aus. Rock schreibt: „Viele Konflikte am Arbeitsplatz wie im Leben wurzeln in der Statusfrage. Je besser Sie Statusbedrohungen zum Zeitpunkt ihres Auftretens benennen können, umso leichter wird es Ihnen fallen, auf der Stelle eine Neubewertung vorzunehmen und angemessener zu reagieren.“ Aber in der Regel geschieht sowohl im Management als auch im Coaching oft das Gegenteil. Der Manager macht dem Mitarbeiter klar, dass er etwas nicht kann, oder er erwähnt vor der Peer-Gruppe des Mitarbeiters, dass der Mitarbeiter nicht genügt. Oder der Coach macht deutlich, dass der Coachee selbst Teil des Problems ist. Beides ist eine Statuserniedrigung, die das Gehirn abwehren will – indem sich der Besitzer des Gehirns gegen die Veränderung wehrt.

Ob auch die anderen vier Punkte des SCARF-Modells in einer Coach-Coachee oder Management-Mitarbeiter-Beziehung zum Tragen kommen, ist meiner Meinung nach eine direkte Folge dessen, ob man den Status einer Person erhöht oder erniedrigt. In meinem Status kann ich mich nur sicher fühlen, wenn mir mein Gegenüber Gewissheit (Certainty) vermittelt und mich zum Beispiel umfassend über meine neue Rolle oder neue Abläufe informiert. Rücksicht auf den Status zu nehmen bedeutet auch, Autonomie zuzugestehen – jemanden selbst entscheiden lassen. Gerade in Situationen des Coachings und des Managements werden diese Gesetze der Autonomie oft verletzt. Häufig überschreiten Coaches die Grenze und entscheiden zu viel. Führungskräfte versuchen, Mitarbeitern nicht einmal das kleinste Gefühl der Mitsprachemöglichkeit zu geben. Noch verhängnisvoller ist es jedoch, wenn die Mitarbeiter glauben, sie dürften mitreden, daher eine Entscheidung treffen und dann wird diese Entscheidung doch nicht respektiert.

Das Hormon Oxytocin ist wichtig für die Bindung zwischen Mutter und Säugling und beeinflusst unsere Fähigkeit zu vertrauen. Auch als Erwachsene suchen wir nach dem Gefühl der Verbundenheit, ob im Privatleben oder am Arbeitsplatz. Den Status zu respektieren ist in diesem Zusammenhang ein Balanceakt zwischen genügend Nähe und angemessener Distanz. Und schließlich wollen wir alle das Gefühl haben, gerecht behandelt zu werden und selbst gerecht zu sein. Kinder teilen gerne, bis es ihnen im Laufe ihrer Erziehung zugunsten des eigenen Vorankommens abtrainiert wird. Das Streben, dass alle das Gleiche bekommen sollen, bleibt in der einen oder anderen Form erhalten, etwa bei der Frage, welche Gehaltserhöhungen „fair“ sind und welche nicht.

Wie weckt man also die Bereitschaft, neue Dinge anzuerkennen, obwohl man sie noch nicht zur Gänze versteht? Wie erzeugt man die Bereitschaft, etwas Neues auszuprobieren, an das man sich vielleicht nicht sofort herantraut? Wie gelingt es als Manager, das Potenzial der Mitarbeiter auszuloten und zu fördern, ohne dass die Mitarbeiter sofort befürchten, beurteilt zu werden – nur weil man ihnen zeigt, dass sie noch etwas zu lernen haben? Auch wenn wir uns für eine aufgeklärte und hoch entwickelte Spezies halten: Bis zu einem  gewissen Grad werden wir immer von grundlegenden Bedürfnissen gesteuert. Das SCARF-Modell beschreibt, dass es notwendig ist, auf diese grundlegenden Bedürfnisse beim Führen von Menschen aktiv einzugehen.

Literatur:

Coaching with the Brain in Mind

Quiet Leadership: Six Steps to Transforming Performance at Work

Related posts:

1. Scrum – Eine Revolution (3)
2. Scrum Alliance mal wieder führungslos – Donna Farmer geht
3. Jetzt ist es raus: Unser Buch zu Scrum & Personalmanagement

“Führung ist, wenn du vorausgehst und die anderen folgen dir!” Dieser Spruch ist in keiner Situation so deutlich wahrnehmbar wie beim Trainieren eines Pferdes. Ein Pferd hat den angeborenen Trieb, hinter dem Leitpferd zu laufen. Dieses Leitpferd muss vom nachfolgenden Pferd allerdings in seiner Rolle als “Anführer” akzeptiert werden. Auch ein Mensch kann so ein Leitpferd sein, allerdings muss dazu zwischen Mensch und Pferd ein klares Führungsverhältlnis aufgebaut werden.

Ist das einmal geschafft, läuft das Pferd ruhig im exakt gleichen Tempo dem Menschen hinterher. Aber jetzt wird es faszinierend: Ist der Mensch unsicher und dreht sich ständig nach dem Pferd um, bleibt das Pferd stehen. Ich muss also darauf vertrauen, dass mir mein Pferd folgen wird. Drehe ich mich um, werde ich enttäuscht und glaube vielleicht auch noch, dass ich das Pferd am Strick ziehen muss (Gewalteinwirkung), damit es mir folgt. Manchmal bleibt ein Pferd, das eigentlich folgt, dennoch stehen. Meistens ist das der Fall, wenn das Pferd etwas gesehen hat und das – anders als ich – als Bedrohung wahrnimmt. Meistens wartet es dann, bis ich vorausgehe und deutlich mache, dass keine Gefahr droht – dann folgt es mir mutig weiter.

Für mich war das sehr sehr lehrreich, gerade in der Frage, wie Führung funktioniert. Führung funktioniert sicher nie ohne Vertrauen in die eigene Rolle und ohne Vertrauen in das Team. Es wird folgen, wenn der Weg, den ich gehe, für das Team sicher genug ist.

Related posts:

1. Führung in Scrum | Manager | Teil 4
2. Führung in Scrum | der Manager | Teil 1
3. Der ScrumMaster – Führung

Letztens besuchten wir beim Treffen einer User Group eine Media- und Software-Agentur, die uns ihre Nutzung von agilen Methoden zeigte. Nicht überraschend war die Geschichte, die wir schon oft gehört haben: Ein großes Projekt mit großem Team, langer Laufzeit und mehreren beteiligten Firmen war in Probleme geraten. Man entscheidet sich für Scrum und alles wird besser. Die Transparenz steigt, die Erwartungshaltung wird angepasst, die Teams gewinnen an Produktivität und das Projekt fängt an zu liefern. Eine schöne Erfolgsgeschichte, wie wir sie uns wünschen.

Spannend war dann, wie man mit kleineren Projekten umging, die nur ein bis zwei Personen über eine kurze Laufzeit benötigen. Diese Projekte wurden mit einem riesigen Kanban Board verwaltet. Sehr beeindruckend. Darüber in großen Lettern die Regeln für das Board, die WIP in (einigen) Spalten markiert, Magnete zum Fixieren der Tasks mit Fotos der Mitarbeiter, die sich den Task genommen hatten und Auswertungen basierend auf den Durchläufen der Tasks. Ich bin sicher, dass diese Form für die Mitarbeiter eine richtig gute Visualisierung der Planung ist und sie durch das Pull-Prinzip ein gutes Maß an Selbstbestimmung und damit Motivation bekommen.

Unsere Diskussion vor dem Board hat aber auch deutlich gezeigt, dass Kanban als Methode keine Vorgaben macht, die der Organisation helfen, agiler zu werden. Auch ein straffer Wasserfallprozess kann super mit einem Kanban Board modelliert werden! Nur wer die Werte von agiler Softwareentwicklung wirklich gut versteht und leben will, wird die Chance haben, mit Kanban diese umzusetzen. Die Organisation muss sich ihre agilen Methoden selbst definieren und dann ein passendes Kanban Board gestalten und die entsprechenden Regeln definieren.

Dazu fällt mir ShuHaRi ein, ein Konzept aus den japanischen Kampfsportarten, das drei Stufen des Lernens beschreibt:

Shu (Gehorche) – folge den Regeln exakt, dann wirst du lernen, es richtig zu machen.
Ha (Weiche ab) – Passe die Regeln an, um deine Arbeit zu verbessern, du weißt ja mittlerweile, worauf es ankommt.
Ri (Verlasse) – Regeln? Was für Regeln? Ich kenne die Werte, lebe danach und mache meine eigenen Regeln.

Eine Organisation, die sich in ihrer agilen Entwicklung auf dem Shu und auch Ha Level befindet, wird durch den Einsatz von Kanban nicht automatisch zu einer Verbesserung der Agilität finden, denn ich muss ja eigentlich meine Regeln selbst machen und das kann man erst mit viel Erfahrung auf dem Ri Level.

Wenn ich aber bei Ri bin, kann ich sicher ein Kanban Board mit Regeln bauen, das mir hilft, meine eigene agile Organisation und deren selbst definierte Abläufe super zu visualisieren.

Christof Braun, Scrum Consultant

Related posts:

1. Wo ist der Certified KANBAN Master?
2. Taylor strikes back … Kanban in action
3. Führung in Scrum | der Manager | Teil 1

Was macht unsere Organisationen so langweilig? Warum findet man sogar in High-Tech-Unternehmen langweilige Büroräume und Orte, die lebensfeindlicher nicht sein könnten? Ein kleiner Hinweis in der aktuellen Harvard Business Review brachte mich dazu, diesem Thema wieder einmal nachzugehen. Dort steht: “Adults are less likely to cheat and more likely to engage in “pro-social” behaviors when reminders of children such as teddy bears and crayons are present.”

Eigentlich sollten Office-Räume ein Ort der Kreativität sein … zumindest in unserer Branche. Wir kreieren neue Produkte, schaffen Innovationen und sitzen dabei aber zum Teil in Räumen, die den Charme von Lagerhäusern, Kantinen und alten Amtstuben haben. In dem sehr lesenswerten Buch “Innovate the Pixar Way” zeigt Bill Capodagli, dass zum Beispiel PIXAR einen ganz anderen Weg geht. Dort gehört das “Spielen”, das Herumprobieren in einem geschützten Raum einfach dazu. “Fun. Play” schreibt er. “The Level of fun and play we have in the workplace is a function of our attitude.” Recht hat er. Teams können sich in einen Stuck-State manövrieren. Sie können aber auch total cool drauf sein und die größten Probleme wuppen.

All das erfordert, dass man Dinge zulässt. Zum Beispiel, dass man den Teddybären seines Kindes mitbringt (natürlich nur, wenn das Kind das erlaubt :-). All jenen, die sich das nicht trauen oder das kindisch finden, sei Steve Jobs’ Zitat empfohlen:

“Your time is limited, so don’t waste it living someone else’s life. Don’t be trapped by dogma – which is living with the results of other people’s thinking. Don’t let the noise of other’s opinions drown out your own inner voice. And most important, have the courage to follow your heart and intuition. They somehow already know what you truly want to become. Everything else is secondary.” Steve Jobs

Es ist nicht wichtig, was die anderen denken – nur der eigene Weg zählt. Wer glaubt, dass der Arbeitsplatz ein Ort sein sollte, an dem man sich vergnügt und deshalb wesentlich produktiver sein kann, der sollte einfach etwas dafür tun.

ScrumMaster, wenn ihr etwas Kreativität in den Alltag eurer Teams bringen wollt – warum verteilt ihr nicht einfach ein paar Plastik-Kameras wie diese hier:

Oder besorgt ein paar Einmal-Fotoapparate. Die legt ihr aus und die Teammitglieder sollen die witzigsten Fotos schießen, die ihnen für einen Sprint einfallen (wäre auch ein guter Input für die Retrospektive). Oder ihr bringt einfach einmal das Marshmallow Challenge mit (dieses Video sollte sich jeder, der mit Scrum Teams arbeitet, unbedingt ansehen).

Viel Spaß beim Spielen, ich geh’ jetzt fotografieren!

Related posts:

1. Der ScrumMaster – Wirklich ein Weichei?
2. Die 3 gröbsten Fehler beim Scrum Implementieren
3. Führung in Scrum | Manager | Teil 5

In unserer täglichen Arbeit als Berater erleben wir einen Mangel an ausgebildeten Product Ownern. Leute, die ein Team führen können um ein großartiges Produkt zu bauen. Eine Person mit den Ideen und Werzeugen von Scrum zu trainieren, macht nicht einen guten Product Owner aus. Er könnte sich nur sehr zu fürchten beginnen, weil man ihm sagt, dass er jetzt eine riesige Veranwortung trägt. Auf meiner Suche nach dem wahren Verständnis von Product Ownership fand ich einige Hinweise in einem Buch von Marty Cagen namens “Inspired“. Cagen hat als Senior Vice President des Product Management bei eBay, AOL und Netscape Communication gearbeitet und als Software Ingenieur bei HP Laboratories. Also weiß er ziemlich viel über Product Management. Was mir am besten an Cagen’s Buch gefällt, ist die Klarheit seiner Vorstellungen darüber, was ein Product Manager braucht, um gute Arbeit zu leisten:

1. Persönliche Merkmale und Einstellung
   1. Leidenschaft fürs Produkt
   2. Kundenempathie
   3. Intelligenz: “Es gibt eigentlich keinen Ersatz für angeborene Intelligenz. Product Management bedeutet Einsichten und Beurteilungen, und beides verlangt einen wachen Geist.”
   4. Arbeitsethik: “Nicht jede Rolle im Product Team verlangt das selbe Niveau an Hingabe und Anstrengung. Aber die Rolle des Product Managers ist nichts für jemanden, der sich vor harter Arbeit fürchtet.
   5. Integrität: “Von allen Mitgliedern des Product Teams, muss der Product Manager am meisten die Werte der Firma und des Produkts reflektieren.
   6. Vertrauen: “Vertrauen ist ein wichitger Zug, weil das ganze Team, das Leitungsteam und Sales schaut auf den Product Manager, der sie überzeugt, dass das, worin sie ihre Zeit, ihr Geld und ihre Karrieren investieren, ein Erfolg wird, und dass die Vision gut ist!
   7. Einstellung: Der erfolgreiche Product Manager ist der CEO des Produkts. Er übernimmt die volle Verantwortung für das Produkt und sucht keine Ausflüchte.
2. Fertigkeiten
   1. Technologie anwenden – er muss die Technologie verstehen
   2. Fokus. Wie man so schön sagt, “Die Hauptsache ist, die Hauptsache Hauptsache zu halten”.
   3. Zeitmanagement
   4. Kommunikationsfähigkeit
   5. Business skills

Ich unterschreibe die obige Liste sofort. Bei Scrum nennen wir Marty Cagen’s Product Manager den Product Owner.

In Beratung, Coaching und Training müssen wir den Product Managern in allen Organisationen zeigen, wie sich sich zu Product Ownern machen können. Zu Leuten, die ihren wahren Wert in der Organisation kennen. ScrumMasters müssen mit den Product Owners/ Product Managern zusammenarbeiten, damit sie verstehen, dass sie viel angestrengter arbeiten müssen, um diese Fähigkeiten zu erlangen.

Product Ownership hat nichts damit zu tun User Stories zu schreiben oder sie in einem Backlog zu ordnen, es ist nicht dasselbe wie Story Mapping zu benutzen um eine Übersicht zu bekommen. Product Ownership heißt, eine coole Idee zu haben und Menschen dahin zu führen, diese coolen Produkte zu schaffen.

Related posts:

1. 5 min Scrum | Product Owner
2. Recipe for a Product Owner
3. Karlsruhe hat 15 neue Certified Scrum Product Owner

Alle wollen die nicht beantwortbare Frage beantwortet haben: Was kostet mein Projekt? Wie kann ich einen Auftrag gewinnen, wenn ich doch am Anfang gar nicht weiß, was ich liefern soll, aber doch einen Preis nennen soll? Vorträge, die diese Frage zu beantworten scheinen, sind immer wieder ausgebucht. Mitch Lacey stellte bei seinem Vortrag auf der Agile Tour Vienna 2011, “Implementing Scrum as a cost saving measure”, mit viel Humor das “Money for Nothing Change for free”-Modell und das Modell, dass der Kunde Sprint by Sprint bezahlt, vor. Aber auch er konnte die brennenden Fragen nicht beantworten.

Was Mitchs Vortrag für mich aber so interessant machte: Die Klarheit mit der er deutlich machte, dass manche Wahrheiten einfach so sind, wie sie sind.

Mitch erklärte, dass die “Cone of Uncertainty” eben so ist, wie sie ist. Es sei nun mal nicht möglich, am Anfang eines Projekts zu wissen, was es kosten könnte. Auch mit Scrum ist es unmöglich, am Beginn eines Projekts etwas Stichhaltiges auszusagen, wenn man noch nichts Genaues weiß und die Dinge noch nicht genau kennt.

Diese Kurvendarstellung ist bereits sehr alt. Und trotzdem verstehen noch immer nicht alle die Aussage dieser Kurve für ihre tägliche Praxis, nämlich dass sie ein Anstoß für die Suche nach anderen  Möglichkeiten für die Projektabwicklung ist. Wenn ich sie in Trainings vorstelle, sehe ich immer wieder erstaunte Gesichter.

Nun ist in der Harvard Business Review ein Artikel erschienen, der diese Tatsache einmal auf vollkommen andere Weise betrachtet. Wenn es doch so ist – so das Argument -, dass jedes große IT Projekt um den Faktor 2 bis 4 zu teuer wird (also das Budget um ca. 200% bis 400% überschritten wird und dabei durch das Projekt in der Regel nur 25% bis 50% des erwarteten Nutzens entstehen), dann kann doch die Lösung nur sein, schon am Anfang des Projekts davon auszugehen, dass das passieren wird. In diesem Fall müsse man, um die Firma abzusichern, einfach genug aushalten können. Das müsse man also vor dem Start eines großen Projektes berücksichtigen. [1] Sie schreiben das ohne jeden Zynismus, aber sie liegen richtig. Wenn etwas ist, wie es ist, dann hilft es nicht, die Augen davor zu verschließen.

[1] Why your IT Project May be Riskier Than You  Think, Bent Flybjerg and Alexander Budzier, HBR, Sept 2011, p. 23ff.

Related posts:

1. Eindrücke eines Teilnehmers an CSM Training mit ScrumCooking
2. “Defining Done” – Mitch Lacey (CST)
3. Design eines großen Systems – Tom DeMarco

Es ist erschreckend: Neueste Forschungsergebnisse zeigen, dass es eine erstaunlich hohe Zahl von IT-Projekten gibt, die außer Kontrolle geraten. So sehr, dass ganze Firmen und Karrieren daran zugrunde gehen. Diese Studien zeigen,

• dass 67% der Firmen es nicht schaffen, erfolglose Projekte einzustellen,
• dass 61% der Manager berichten, dass es “major” Konflikte zwischen der Projektorganisation und der Linien-Organisation gibt,
• dass 31% der Firmen Projekte durchführen, die nichts mit der Firmenstrategie zu tun haben und
• dass 31% der Firmen redundante Arbeiten durchführen, weil ihre Projekte nicht aufeinander abgestimmt waren.

Nun sind diese Erkenntnisse für sich gesehen schon nicht so ohne. Wesentlich erschreckender sind aber die Schlussfolgerungen der Autoren des Artikels in der Harvard Business Review. Sie schreiben: Wenn man den schleichenden Tod durch IT-Projekte vermeiden will, muss man dafür gerüstet sein, dass ein IT-Projekt am Ende 400% mehr als geplant kosten, aber nur 25% des erwarteten Benefits erwirtschaften wird. Wenn man das im Auge behält, kann man eine Firma möglicherweise davor bewahren, von einem IT-Projekt in den Abgrund gerissen zu werden.

Nichts sehen, nichts hören, nichts sagen
Leider wissen auch die Autoren Bent Flyvbjerg und Alexander Budzier nicht so recht, wie man solche Desaster verhindern könnte. Was mich aber wirklich wundert: Diese Dinge sind also bekannt – verschließen Manager in den großen Companies davor einfach die Augen? Wollen sie es nicht sehen? Wollen sie nicht sehen, dass die bekannten traditionellen Methoden, an den ihre IT-Verantwortlichen offenbar festhalten, den Anforderungen nicht gewachsen sind?

Aber vielleicht adressieren unsere Botschaften mit der IT tatsächlich die Falschen, so wie Ken Schwaber in seinem – noch nicht erschienenen – neuen Buch schreibt. Vielleicht dürfen tatsächlich die Kunden von IT, Software Development und Produktentwicklung einfach nicht mehr akzeptieren, dass ihre IT-Abteilungen, QA-Abteilungen und Prozessmenschen es nicht schaffen, alle zwei Wochen ein fertiges, greifbares und messbares Ergebnis zu liefern.

Bis wir das nicht alle verstanden haben, werden Firmen weiterhin Milliarden aus dem Fenster schmeißen und dabei manchmal sogar zugrunde gehen.

Related posts:

1. ScrumDay2009 München, Wrap-Up
2. Enterprise Scrum
3. Scrum im Informatik Spektrum