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.

Scrum ist Hausverstand – den wir verloren haben

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

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?

Reise zum Mittelpunkt des Sinns

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?

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

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?

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

www.youtube.com/watch?v=znqqoOlsIjM

Related posts:

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

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…

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

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

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