Mindmapping: So sprudeln die Ideen für Texte und Projekte

Ob beim Schreiben eines Buchs, bei der Planung von Projekten oder um schnell und einfach Ideen zu generieren: Mindmapping ist eine hilfreiche Technik, um von Beginn an Struktur ins Vorhaben zu bringen. Dabei geht es in erster Linie darum, linke und rechte Hirnhälfte zu verbinden und das jeweilige Themengebiet räumlich-visuell zu erschließen. Mindmapping funktioniert so gut, weil die Technik das Prinzip der freien Assoziation nutzt. Im Video erfahrt ihr, wie das funktioniert und was man in der Praxis beachten sollte. Viel Spaß.

Freewriting – der agile Zugang zum Schreiben

Ob Blog-Beiträge, Artikel in Magazinen oder ganze Bücher – was man auch zu Papier bringen möchte: Am Anfang stellt sich oft die Frage, wie man überhaupt beginnen soll. Man möchte etwas schreiben, aber es fällt einem nichts ein – die meisten von euch kennen das. Wie kann man dieses Dilemma auflösen?

Freewriting ist eine Technik, die viele Gemeinsamkeiten mit Scrum hat, weil man sich schrittweise dem fertigen Text annähert. Diese Herangehensweise eignet sich erfahrungsgemäß sehr gut, um die grauen Zellen in Fahrt zu bringen. Wie das funktioniert und was man dabei beachten sollte? In diesem Video erwarten euch spannende Überlegungen zum Schreibprozess und eine hilfreiche Schritt-für-Schritt-Anleitung. Probiert es aus, es lohnt sich.

Video: Der Manager als Facilitator – Grundlagen

Meetings sind meist gähnend langweilig. Doch gleichzeitig sind Meetings eines der wichtigsten Elemente im Rennen um den produktivsten Executive. Deshalb ist es wahrscheinlich sinnlos, die immer wieder geforderte Idee “No Meetings” ernst zu nehmen. Viel wichtiger ist es, Meetings so produktiv wie möglich zu gestalten.
In diesem Video erkläre ich die Grundlagen erfolgreicher Meetings. Wer diese Grundlagen beherzigt, wird es schaffen, dass die Kolleginnen und Kollegen gerne zu den Meetings kommen – weil sie einfach Spaß machen.
Viel Spaß beim Anschauen
Boris
 

Geheimnisse einer wirklich guten Vision

 

Vision – ein verbranntes Wort.

Doch warum eigentlich? Warum gibt es einen Beißreflex, wenn man als Consultant davon spricht? Schließlich ist die Vision die treibende Kraft eines Unternehmens. Ohne eine klare Vision hätten wir heute kein iPhone. Ohne eine Vision hätten wir heute keine Wikipedia. Ohne eine Vision hätte Neil Armstrong vielleicht nie den Mond betreten.
Eine klare, emotional ansprechende Vision ist auf der einen Seite der Grund, warum sich Menschen aufopfern, warum sie an ihre Grenzen und weit darüber hinausgehen. Sie ist der Grund, warum sie einen Sinn in ihrem Handeln erkennen.
Auf der anderen Seite wird sie verlacht und nicht ernst genommen. „Vision – das haben die da oben sich wieder ausgedacht.“ – Solche Sätze hört man in Unternehmen öfter, als es gesund wäre. Es gibt viele Gründe dafür, warum eine Vision nicht zieht. Einer der gravierendsten Gründe ist aber, dass die Vision für mich als Mitarbeiter keine Relevanz hat: Ich erkenne keinen Sinn darin. Ich will nicht schon wieder die Leier „10% mehr von dem, was wir haben“ hören. Ich will Sinn. Ich will einen Nutzen erkennen und ein Bedürfnis damit befriedigen. Ich will die Welt ein Stück verändern.
 

Ist es wirklich so schwer, eine gute Vision zu entwerfen?

Im Grunde ist es nur notwendig, sich über folgende Punkte klar zu werden:

Eine Vision ist das „Why“, das ich als richtig erkenne. Eine einfache Frage, die viel zu häufig in unserer Kommunikation missachtet wird: Warum tue ich eigentlich, was ich tue?
Hier einige Beispiele von Visionen, die die Welt verändert haben.
John F. Kennedy in seiner berühmten Man on the Moon Speech:
 

“I believe that this nation should commit itself to achieving the goal,

before this decade is out, of landing a man on the moon

and returning him safely to the earth.”

 
Bzw. die Vision von Wikipedia:

“Stell Dir eine Welt vor, in der jeder einzelne Mensch freien Anteil an der Gesamtheit des Wissens hat.”

 
Oder Martin Luther King in seiner berühmten Rede „I have a dream“:

“I have a dream that one day this nation will rise up, and live out the true meaning of its creed: ‘We hold these truths to be self-evident: that all men are created equal.’”

 
Eine Vision ist keine mit Tonnen von Text beladene Powerpoint-Präsentation. Ich verwalte sie nicht, sondern sie ist der Grund, warum ich jeden Tag aufstehe. Ein Satz, ein Bild, ein Gedanke, der mich treibt.
Eine sehr schöne Möglichkeit, um sein eigenes Why herauszufinden, ist diese einfache Übung:
Nimm dir einen Monat lang jeden Tag 10 Minuten Zeit und schreib auf, was dich ausmacht. Was will ich bewirken? Warum handle ich, wie ich handle? Man lernt sich selbst völlig neu kennen – versprochen.
Was man damit dann macht? Nicht nur predigen, sondern handeln. In jedem Gespräch, in jeder Handlung zeigen, was die eigene Vision ist.
 

Die Retrospektive: Alle Jahre wieder …

… kommen die Weihnachtszeit und das Jahresende mit Riesenschritten daher und damit die Frage der ScrumMaster unserer Kunden: „Habt ihr einen Vorschlag für eine schöne Retro zur Weihnachtszeit?“


So geschehen auch vor einigen Tagen. Eine unserer Kolleginnen leitete die Frage an die restliche Mannschaft weiter, um unsere Ideen zu sammeln und an ihren Kunden weitergeben zu können. Da wir bei borisgloger consulting trotz der vielen, teils weltweit verstreuten Projekte sehr gut miteinander vernetzt sind, kamen nach kurzer Zeit viele Vorschläge zusammen. Einige Ideen möchte ich euch gerne vorstellen.

Der Einstieg

Um sich gedanklich auf die Retro einzustimmen, kann sich jedes Teammitglied eine Süßigkeit oder ein Tier aussuchen, die bzw. das den Sprint für sie oder ihn am besten beschreibt. Die Auswahl kann gerne einen Bezug zu Weihnachten haben. Nachdem sich jedes Teammitglied etwas ausgesucht hat, stellt jeder z.B. seine Süßigkeit vor und erklärt mit ein bis zwei Sätzen, warum diese den Sprint symbolisiert.

Der Hauptteil

1. Möglichkeit:

Zunächst stellt ihr euch die Frage: Was war gut? Hier bietet es sich an, dass jedes Teammitglied seine drei Top-Highlights des zu Ende gehenden Jahres auswählt, auf ein Post-It schreibt und auf ein passendes Chart klebt. Im Anschluss erläutert jeder und jede kurz, was diese Highlights zu Highlights gemacht hat.
Als Break können z.B. die zum Einstieg vorgestellten Süßigkeiten oder andere Weihnachtsnaschereien gegessen und/oder getauscht werden.
Dann wird gefragt: Was können wir verbessern? Hier könnt ihr beispielsweise einen „Blick in die Zukunft“ wagen: Was wird zum Beispiel bis zum 14.12.2017 alles passiert sein?

2. Möglichkeit: 
Ihr zeichnet einen bunt geschmückten Tannenbaum inkl. Geschenken, so wie auf diesem Bild:


Ein Tipp: Zeichnet den Baum nicht zu klein, denn er wird jetzt noch weiter geschmückt!
Die Kerzen und ihr helles Licht symbolisieren jene Themen, die im vergangenen Jahr gut gelaufen sind. Jedes Teammitglied schreibt seine (max.) drei Favoriten auf Post-its und klebt sie mit einer kurzen Erklärung an den Baum.
Als Break kann, wie oben beschrieben, jedes Teammitglied seine Lieblingsweihnachtssüßigkeiten mitbringen und diese mit den anderen Teammitglieder teilen. Als weitere Variante kann jedes Teammitglied kurz erklären, warum genau das das favorisierte Weihnachtsgebäck ist.
Die Geschenke unter dem Tannenbaum stehen für die Wünsche, also für das, was im kommenden Jahr verbessert werden kann. Auch hier deponiert jedes Teammitglied max. drei Wünsche unter dem Baum.

Der Abschluss

Eine nette Variante der Tannenbaum-Retro ist es, wenn ihr abschließend noch Danksagungen an die eigenen Teammitglieder oder auch an andere Teams, mit denen ihr eng zusammengearbeitet habt, an die Christbaumkugeln hängt.
Eine weitere Möglichkeit ist der „Weihnachtsmannsack“. Hier hat jedes Teammitglied einen bis maximal drei Wünsche (bei kleinen Teams) frei, die es gerne vom Weihnachtsmann erfüllt haben möchte.

Tausch dich mit anderen ScrumMastern aus – welche Ideen haben sie für die Weihnachts-Retro? Oder frag deinen Agile Coach.

 

Progress not perfection

Was haben der Beruf eines Consultants und agiles Arbeiten gemeinsam? Die Antwort darauf ist: ständiges Feedback auf dem Weg zur Meisterschaft. In Consulting Organisationen kommen neue Kollegen frisch von der Universität in das Unternehmen und lernen das Business von der Pike auf. So schnell wie möglich werden sie ins kalte Wasser geschmissen und mit den Kunden und deren Projekten konfrontiert. Das ist sehr anstrengend, denn natürlich wissen die neuen Kollegen zunächst gar nicht, ob sie sich beim Kunden richtig verhalten. Auf keinen Fall wollen sie den Ruf der Firma ruinieren, gleichzeitig ist ihnen aber klar, dass sie noch viel zu wenig wissen – trotzdem sollen sie so schnell wie möglich eigenständig agieren. Das sollen sie auch tun, aber dabei tappen sie oft in eine Falle: die Falle der Perfektion.

Lernen heißt machen

Wer in unserem Job nach Perfektion strebt, der läuft nicht los. Zu groß ist die Gefahr, etwas Falsches zu sagen, sich dumm anzustellen und schnell beginnt man vor lauter Angst eine Stunde Vorbereitung nach der anderen zu investieren. Das ist löblich, nach den neuesten Studien (u.a. von Daniel Goleman: Focus – The Hidden Driver of Excellence) lernt man aber nur dann effektiv, wenn man Feedback bekommt. Feedback benötigt setzt allerdings das „Machen“ voraus, man muss also etwas tun und sich der Kritik aussetzen. Lernen ist laut Piaget u.a. das Enttäuschen von Erwartungen, also zu bemerken, dass etwas noch nicht so ist, wie man geglaubt hat, dass es ist. Nimmt man dieses Feedback aber ernst, macht man dank des Feedbacks immer mehr Fortschritt (progress). 10.000 Stunden in etwas zu investieren, ohne Feedback durch Kunden, Anwender, Freunde, Kollegen bedeutet nur, dass man 10.000 Stunden etwas tut, ohne besser zu werden, oder? Gut, aber es gibt ja auch noch die Selbstreflexion, mag nun der eine oder andere entgegenhalten. Man tut etwas und schaut sich an, ob das Getane oder Erzeugte so ist, wie man es selbst gerne hätte. Stimmt, doch jetzt schlägt oft der Perfektionist zu, der versteckt in der eigenen Psyche hockt. Man ist so kritisch mit sich selbst, dass man sich nicht mehr den Erfolg des Machens gönnt. Alles, was man produziert, bringt am Ende nur etwas hervor, das bekrittelt wird. Das wiederum erzeugt kein positives, also das Lernen ermöglichende Feedback, sondern nur negative Kritik. Also Folge davon wird das Lernen noch schwieriger.
Dem kann man mit einem Leitsatz entgehen: Progress not perfection! Dieser Leitsatz ist in sich systemisch, denn er sagt, dass es keinen Stillstand gibt. Es gibt kein Ende. Es gibt keine Perfektion, denn es geht noch besser. Mit Hilfe dieses kleinen Sätzleins wird deutlich: Es geht darum, jedes Mal, mit jeder Anstrengung, mit jeder Handlung, etwas besser zu werden.
Als Consultant musste ich das ganz schnell lernen. Immer dann, wenn ich etwas erzeugt hatte, waren meine Kunden und Kollegen nur halb zufrieden. Sie hatten immer etwas zu bekritteln. Das war gut so, ich konnte das nächste Mal, bei der nächsten Iteration etwas verbessern. Das war viel Arbeit und hat viel Mühe gemacht, vor allem dann, wenn eine Deadline zu halten war. Doch kam die Deadline, naja, dann war das Beste fertig, das zu diesem Zeitpunkt fertig sein konnte. Nicht mehr und nicht weniger. Genau so funktioniert auch agiles Arbeiten. Man traut sich, ist mutig, und wagt zu scheitern. Man liefert etwas ab (ob in Sprints oder nicht, ist da ganz egal) und zeigt es her. Manchmal wagt man etwas und muss anschließend zugeben, dass es eine doofe Idee war. Na und? Nur so lernt man etwas. Der Job des Consultants und agiles Arbeiten sind sich in dieser Hinsicht sehr ähnlich und das ist wohl der Grund, weshalb wir alle bei Boris Gloger Consulting so gerne lernen. Wir machen jeden Tag Fehler und lernen daraus. Das Feedback ist wichtig, nur so können wir jeden Tag Fortschritte machen.

Pfingsten – alle verstehen sich

„Als der Pfingsttag gekommen war, befanden sich alle am gleichen Ort. Da kam plötzlich vom Himmel her ein Brausen, wie wenn ein heftiger Sturm daherfährt, und erfüllte das ganze Haus, in dem sie waren. Und es erschienen ihnen Zungen wie von Feuer, die sich verteilten; auf jeden von ihnen ließ sich eine nieder. Alle wurden mit dem Heiligen Geist erfüllt und begannen, in fremden Sprachen zu reden, wie es der Geist ihnen eingab.“ (Apg 2,1-4)
Thomas Assheuer stellt in der Zeit vom 21.5. in seinem Artikel: “Das Ich ist die Sonne”, die Frage: “Was hält eine Welt zusammen, die nur aus Einzelkämpfern besteht?” und schiebt dann eine Deutung von Pfingsten nach, die ich nicht kannte: “Ein `Brausen’ entsteht und plötzlich hört jeder den anderen in seiner eigenen Muttersprache reden. Wildfremde Menschen sprechen mit einer Zunge. `Sie gerieten außer sich vor Staunen: Sind das nicht alles Galiläer, die hier reden?` Jedenfalls sind die Menschen seltsam beseelt und ‘eines Geistes‘. (…) Mit anderen Worten: Die menschlichen Sprachen bleiben zwar immer noch voneinander geschieden, aber sie sind keine undurchdringlichen Universen mehr – sie lassen sich vollständig ineinander übersetzen. Jeder versteht jeden …”
Lasst uns mal darüber nachdenken: Könnte Pfingsten nicht zum Sinnbild des crossfunktionalen, multidisziplinären Scrum-Teams werden? Es gibt die Idee der Hyperspezialisierung, die sich in mehr und mehr Texten durchsetzt. Die Welt wird so komplex, die Produktentwicklung so wissensabhängig, dass immer weniger Leute immer mehr von immer weniger wissen. Also müssen wir in Teams zusammenarbeiten, damit wir gemeinsam Produkte erfinden und entwickeln können, die diese ganze Wissen in sich tragen. Doch nun stehen wir vor einem Problem, wie gelingt es uns, dass wir uns alle verstehen, obwohl wir alle ungleiche Disziplinsprachen (Soziolekte) sprechen? In der biblischen Geschichte geschah das, weil alle durch den “Geist” beseelt wurden. Der “Geist” bildet das gemeinschaftsstiftende Dritte”, schreibt Assheuer.
Der “Geist”, was ist das? Meine Antwort darauf: Die Werkidee, der Funke der Vision, die Verkörperung dessen was wir gemeinsam erreichen wollen. Scrum-Teams, alle Teams brauchen einen Product Owner, einen Visionär, der das leisten kann. Claudio Abbado soll gesagt haben: “Ich muss die Musik sein, die ich vom Orchester hören will.” Das ist universell – die Kraft, die von der Begeisterung eines Menschen ausgeht, die von seiner Präsenz ausgehen kann, die kann vereinen und alle auf ein gemeinsames Ziel ausrichten und die Grenzen der Disziplinen überschreiten. Der Product Owner, der von seiner Idee “beseelt” ist, ist in der Lage, auch das Entwicklungsteam mitzureißen. Dann entsteht der gemeinschaftliche Geist des Teams, alle arbeiten trotz unterschiedlicher Auffassung miteinander und verstehen sich auch. Interessenskonflikte werden beiseite geschoben und man fühlt sich wie elektrisiert, wenn man in einem solchen Team mitarbeiten darf.
Euch allen ein paar schöne Feiertage.
Boris

Mein persönliches Taskboard: Rettungsleine in komplexen Umfeldern

Als Consultant und ScrumMaster prasseln auf mich jeden Tag Unmengen an Anforderungen ein, die meine Aufmerksamkeit fordern. Ich bin die Schnittstelle zwischen Management und Team, gleichzeitig arbeite ich daran, die Teams voranzubringen und sie beim Erreichen ihrer Ziele zu unterstützen. Meine Kollegen und ich arbeiten an agilen Transitionen und nebenbei sollten wir auch noch das eine oder andere für die eigene Firma erledigen. So komme ich jeden Tag auf einen Katalog von 50 Dingen, die auf mich warten und mir im Kopf herumschwirren. Um bei dieser Menge an Tasks nicht die Übersicht zu verlieren, orientiere ich mich an meinem eigenen Taskboard.
Wenn ich Montag früh um 6.00 am Flughafen Wien sitze und auf meinen Flieger warte, hole ich mein persönliches Notizbuch heraus und erstelle mein Taskboard. Ich orientiere mich dabei immer an den Tasks der letzten Woche, schreibe sie aber jede Woche neu und filtere dabei automatisch Dinge aus, die nicht mehr relevant sind. Anschließend ergänze ich Dinge, die dazugekommen sind und durchforste die Mails der letzten Woche danach, ob mir etwas entgangen ist. Prinzipiell unterteile ich meine Liste in zwei Bereiche: Small Tasks und Big Tasks.
personal_taskboard
Small Tasks soll ich im Laufe der Woche erledigen. Big Tasks hätte ich am liebsten gestern fertig gestellt, aber ich bin mir bewusst, dass diese mit größeren strukturellen Veränderungen verbunden sind und ich nur kleine Schritte in die richtige Richtung gehen kann. Abschließend priorisieren ich nach dem A,B,C Schema:

Die A-Punkte sind meine Leuchttürme, an denen ich mich orientiere. Dabei suche ich Synergiemöglichkeiten, um die B-Punkte mitzunehmen. Bei den C-Punkten bin ich mir bewusst, dass sie wahrscheinlich nicht erfüllt werden können.
Während der Woche lebt diese Liste: Neue Dinge kommen hinzu, erledigte Dinge werden durchgestrichen. Wenn ich das Gefühl habe, den Überblick zu verlieren, reicht ein Blick in meine Liste aus, um wieder zu wissen, was diese Woche wichtig ist. Das Taskboard hat aber noch einen weiteren wunderbaren Nebeneffekt: Am Ende der Woche, wenn ich in meinem Flieger heimwärts sitze und das Gefühl habe, nicht genügend bewegt zu haben, nehme ich mein Taskboard und lasse meinen Blick über die erledigten Tasks schweifen. Dadurch wird mir bewusst, wie viel in der letzten Woche in die gewünschte Richtung gegangen ist. Ein überaus beruhigendes Gefühl, das mich auf ein zufriedenes Wochenende einstimmt.
Noch ein Tipp am Ende: Verwenden Sie für das persönliche Taskboard ein klassisches Notizbuch und kein elektronisches Tool. Probieren Sie es einfach eine Woche lang aus und Sie werden die Vorteile des altmodischen Mediums schnell erkennen, sobald Sie eine Grafik bei einem Task hinzufügen wollen.

Konzentration – der Weg zum Erfolg

Welches Ihrer letzten Vorhaben war erfolgreich? Oder können Sie sich noch an Ihr letztes on time, in budget verwirklichtes Projekt erinnern?
Hoffentlich mussten Sie nicht gerade minutenlang erfolglos überlegen. Ich musste bei dieser Frage auch zunächst schlucken, vor lauter Angst, ich wüsste kein Beispiel. Aber zum Glück mache ich agile Produktentwicklung und so konnte ich mindestens ein, wenn nicht mehrere Projekte nennen, die ich mit Hilfe von Scrum erfolgreich abschließen konnte.
Aber dann habe ich überlegt, welche „Projekte“ ich in meinem Privatleben erfolgreich abgeschlossen habe.
Und woran liegt es, dass ich noch etwa 3-5 offene Privat-Projekte habe, die bis auf Weiteres kaum zu beenden sind?
Wieso verzeichne ich in teilweise aussichtslosen Situationen Projekterfolge mit Scrum-Teams, während mein eigener, persönlicher Erfolg in manchen Punkten ausbleibt?
Anfangs dachte ich, das liege an mir, ich sei nicht kompetent genug, es falle mir schwerer als anderen, etc. Doch im Grunde waren das nur Ausreden, die mein Gewissen beruhigen sollten, um mir zu sagen: “Alles ist gut.”
Letztendlich sind aber jene Personen erfolgreich, die auch mit etwas fertig geworden sind. Stellen Sie sich vor, Steve Jobs hätte die Idee des iPods aufgegriffen und in der Mitte aufgehört, um mit dem iPad fortzufahren und hätte dann wiederum damit aufgehört, weil das Mac Book wichtiger geworden wäre. Können Sie erkennen, was das Ergebnis gewesen wäre? Ein großes Nichts. Wir hätten vielleicht nie einen iPod in der Hand gehabt, weil er nicht fertig gewesen wäre. Das ist aber das Schicksal vieler großer Ideen, die wir haben und die uns für ein paar Wochen wichtig erscheinen. Doch dann haben wir eine neue Idee oder uns fehlt – wie immer – die Zeit für unsere Vorhaben. Aber woran liegt das? Die Natur des Menschen strebt eigentlich danach, Dinge fertigzustellen. Wenn ich mir mich selbst, meine Kollegen und Freunde ansehe, sehe ich allerdings großartige, gute Arbeiten, die zwar angefangen, aber nie fertiggestellt werden.
Und genau in dieser Sekunde wusste ich auch warum: Wir konzentrieren uns einfach nicht!
In einem Scrum-Team sorge ich als ScrumMaster dafür, dass das komplette Team an einer Sache arbeitet, an einem Product Backlog, mit allen Ressourcen, die es benötigt. Das Team arbeitet konzentriert an einer Sache und siehe da: das Team wird tatsächlich fertig. Viele Teams wissen gar nicht mehr, wie es sich anfühlt, ein Projekt zu beginnen und auch zeitnah abzuschließen. Meistens arbeiten sie an zehn Projekten, von denen vielleicht eines pro Jahr fertig wird. Umso glücklicher, motivierter und erfüllter sind sie, wenn sie mit Hilfe von Scrum ein Projekt beginnen und zeitnah beenden können.
Wenn ich mir nun erneut mich selbst, Kollegen und Freunde ansehe, sehe ich oft wenig Konzentration auf eine Sache, aber umso mehr Konzentration auf zehn Sachen. Wir machen Sport, aber natürlich nicht nur Radfahren, sondern auch Tennis, Joggen, Golf und Schwimmen. Genauso “verteilen” wir uns gleichzeitig auf Projekte, Trainings, Workshops, Konferenzen … und und und. Doch je mehr man macht, desto weniger macht man etwas tatsächlich. Wenn man sich dann wieder mal zu viel vorgenommen hat und es wieder mal kurz vor dem Schluss bemerkt bzw. es sich eingesteht, kommt meist noch der Versuch, To Do’s an andere zu delegieren. Ich glaube, jeder von uns kennt es, dass uns Vorgesetzte oder Kollegen kurzfristig absolut dringende Aufgaben auf den Tisch werfen und wir dann das Vergnügen haben, ihre unfertigen Aufgaben zu beenden. Noch schlimmer ist es, wenn sie mit dem Ergebnis der Delegation unzufrieden und wir einfach nur frustriert sind.
Dabei zeigt uns die Geschichte immer wieder, wie erfolgreiche Menschen arbeiten. Beethoven hat selten fünf Symphonien gleichzeitig komponiert. Fast alle Genies haben eines gemeinsam: Sie konzentrieren sich auf ein Thema, verfolgen es beinahe bis zur Besessenheit und beenden es letztendlich. Die meisten anderen Menschen sterben leider, ohne ihr wahres Genie jemals gezeigt zu haben.
Nun gut, das war jetzt wieder einmal viel Erkenntnis, aber was lerne ich daraus? Ich persönlich nehme mir vor, mich zu konzentrieren, auch privat. So wie ich es in meiner täglichen Arbeit tue, denn ich begleite und coache immer nur ein Team und nicht fünf auf einmal. Genau so versuche ich es jetzt mit allen meinen anderen Zielen: Ich werde sie nun abarbeiten, eines nach dem anderen.

Einer von uns beiden spinnt – ich bin mir nur nicht sicher, ob du oder ich

Sehr geehrte Leser und Leserinnen, ich hoffe Sie sitzen gut, Ihre Rückenlehne ist aufrecht und Sie sind angeschnallt. In diesem Beitrag bewegen wir uns nämlich durch die Turbulenzen der Emotionen. Zumindest schneiden wir diese kurz an, für viel mehr reicht so ein Blog leider nicht aus.
In meiner Arbeit mit Menschen in den letzten Jahren und in meinen privaten Beziehungen ging mir dieses, in der Überschrift erwähnte Statement schon unzählige Male durch den Kopf. Erleichtert bin ich darüber, dass die erweiterte Form die schlichte Formulierung “Der spinnt“ abgelöst hat. Daran merke ich, dass die Jahre der Reflexion nicht spurlos an mir vorbeigegangen sind. Denn die Frage, wer spinnt und wer also die betreffende Situation vollkommen falsch einschätzt, ist nicht so einfach und oft nur mit “es kommt drauf an” zu beantworten.
Die Krux liegt in den unterschiedlichen Bedürfnissen, An- und Absichten einzelner Menschen. Diese entstehen durch Prägungen aus unserer Vergangenheit. Psychologen haben dazu ein gut gehütetes Geheimnis, dass ich Ihnen heute verrate und dass Ihnen vielleicht ein langwieriges Psychologiestudium erspart: Jeder Einzelne von uns ist, auch als Erwachsener, nur ein kleines verletztes Kind. Es gibt alte Muster, die heute noch immer wirken, und die sich auf unsere (Arbeits-)beziehungen verheerend auswirken können. So hat das Kind, dessen Eltern Abends zu spät nach Hause kommen, irrsinnige Verlustängste entwickelt und wird so als Erwachsener möglicherweise zutiefst verletzt sein, wenn ein von ihm geschätzter Kollege zu einem bestimmten Arbeitstermin nicht erscheint. Die übertragene Emotionalität aus der Kindheit wird dann die Arbeitsbeziehungen zwischen diesen Personen belasten. So viel zur schlechten Nachricht.
children-drawing-375615_1280
Kommen wir nun zur guten Nachricht: Jeder Einzelne von uns Menschen hat die Möglichkeit, diese Muster zu verändern. Einzige Voraussetzung dafür ist, dass wir uns diese alten Muster eingestehen und sie akzeptieren. Mit der Akzeptanz kommt auch die Lösung.
Wie kommt man aber an diese Muster heran? Eigentlich ganz einfach und daher unheimlich schwer und langwierig: Reflektieren Sie und seien Sie dabei ehrlich zu sich selbst. Methoden gibt es unzählige. Meditieren Sie, gehen Sie ins Kloster oder in Supervison (falls Ihnen der Begriff Psychotherapie zuviel Angst macht). Wenn Ihnen das jetzt zu anstrengend ist, kann ich als Motivation noch vom Goldtopf am Ende des Regenbogens erzählen, der auf Sie wartet, wenn Sie diesen Weg gehen: Sie erhalten Freiheit. Die wirkliche und wahrhafte Freiheit zu entscheiden, was Ihnen gut tut. Sie befreien sich davon, Dinge tun zu müssen, weil Sie ein inneres unbefriedigtes Bedürfnis nach Anerkennung, Wohlstand, Macht oder Beziehungen haben. Dadurch gewinnen Sie eine Lebensqualität, die Ihnen anders nie zuteil werden kann und Sie bekommen die Möglichkeit, Ihr Leben mit einem wachen Auge zu betrachten.
Um den Kreis zu schließen: Wenn Sie das nächste Mal wieder sagen wollen „Der spinnt”, werden Sie vielleicht darüber nachdenken können, welches Bedürfnis bei Ihnen gerade nicht erfüllt wird und welches Bedürfnis beim anderen gerade getriggert wird. Und mit diesem Verständnis der Situation können Sie auch Lösungen für Ihre Beziehungen finden, die Ihnen anders nie zugänglich wären.
In diesem Sinne hoffe ich, Sie haben den Flug gut überstanden und ich entlasse Sie durch die Kabinentür wieder ins Freie. Welchen Weg Sie nun wieder einschlagen, bleibt Ihnen überlassen, aber vielleicht hinterfragen Sie zukünftig, WARUM Sie genau jenen Weg einschlagen wollen. Damit gewinnen Sie ein wenig mehr Freiheit für sich.

Wie man mit Transparenz ein Produkt zum Fliegen bringt – das Projekt-Cockpit

Man streitet sich immer wieder darüber, was Scrum eigentlich ist. Ist es ein Management-Framework? Oder doch ein Mindset? Oder gar eine Projektmanagementmethode? Vielleicht doch eher ein Prozess? Für mich ist es all das und noch viel mehr: nämlich auch eine Methode, um Probleme ans Tageslicht zu bringen. Durch die Transparenz, die in Scrum-Projekten gegeben ist, kann man Risiken und Hindernisse schnell erkennen und darauf (hoffentlich) frühzeitig mit einer Lösung reagieren.
Doch wie stellt man diese Transparenz in Scrum eigentlich her? In den unterschiedlichsten Projekten versuche ich stets, das gesamte Produkt bzw. Projekt an einem Ort haptisch abzubilden, um einen kompletten Überblick zu bekommen. Und ja, wir reden hier von Flipcharts, Brownpaper und Post-Its an der Wand. In diesem Blog möchte ich einen kurzen Überblick über eine für mich optimale Form eines „Projekt Cockpits“ geben.
Was?

Wie?
All diese Boards, die man in der skalierten Scrum-Umgebung typischerweise vorfindet, würde ich an einem Platz zusammenhängen. Je nachdem, wie die Teams strukturiert sind und ihre Meetings leben, kann man die Reihenfolge der Boards anpassen, gewisse Boards zusammenlegen oder überhaupt andere Boards nutzen. Ob man die Wände eines Büros, eines Ganges oder eines Aufenthaltsraumes nutzt, ist letztendlich egal – wichtig ist nur, dass es ein zentraler Ort ist, damit die Macht der Transparenz über die Lieferung auch wirklich genutzt wird.
Wer?
Am besten ist es, wenn jedes Team sein Board selbst gestaltet und sich überlegt, wofür es dieses nutzen möchte, welche Informationen darauf abgebildet sein sollten und wie es gepflegt werden wird. Generell bedarf es hier eines Commitments und der Mitarbeit aller Projektbeteiligten.
Wozu?
Einer der wesentlichen Benefits von Scrum ist die verbesserte Kommunikation innerhalb von Projekten und Organisationen. Dieses Projekt Cockpit verbindet Kommunikation mit Transparenz auf zwei Arten: Erstens wird hier die erledigte Kommunikation abgebildet (z.B. Impediments aus dem ScrumMaster- bzw. Tasks aus dem Transition Team Daily werden aufgeschrieben und aufgehängt) und dadurch entsteht eine Art Protokoll für die restlichen Mitarbeiter. Zweitens passiert es regelmäßig, dass jemand dort einen Task oder ein Impediment vorfindet, bei dem er selbst schon einmal etwas gemacht hat bzw. das er lösen könnte, wenn er nur davon gewusst hätte. Im Sinne der Nutzung von Synergien und Lieferung kann einem Projektteam doch nichts Besseres passieren!
Kleiner Hinweis: Anfangs dauert es meist ein wenig bis das Cockpit ins Laufen kommt, doch wenn es dann von allen genutzt wird, hilft es ungemein. Probiert es doch mal aus oder habt ihr selbst auch schon (andere) Erfahrungen mit dieser Art von Projekttransparenz gemacht?
Zum Schluss noch ein Beispiel-Cockpit aus einem aktuellen Projekt:
IMG_6038

Was kann die Generation Y von Scrum lernen?

An der Generation Y wird gerade wieder diskutiert, was die Wahlfreiheit mit uns macht. Einerseits wollen wir sie nicht mehr missen und anderseits gehen wir unter ihr in die Knie. Hier ein Beispiel:
Es gab mal eine Studie, bei der den Probanden auf der Straße ein Eis geschenkt wurde.

Sind Wahlmöglichkeiten also mehr Fluch als Segen?

Es kommt darauf an
Zunächst einmal hängt das davon ab, welcher Typ ich bin. 
Persönlichkeitsprofil-Modelle wie das MBTI, oder die Lehre von Motivationsprofilen, besagen, dass es Menschen gibt, die durch permanente Wahlmöglichkeiten motiviert sind und sich wohler fühlen je mehr Optionen zur Auswahl stehen. Und andere Typen halten es in undefinierten Situationen schwer aus und sind bestrebt, die Türen schnell wieder zu schließen, einen Haken dran zu machen. Lieber irgendeine Entscheidung als keine.
Und dann hängt es von meiner Kompetenz ab, mit Wahlfreiheit umzugehen.
Schauen wir uns an, welche Antworten das Scrum-Universum auf dieses Dilemma hat.
In Scrum hat alles seine Zeit. Türen öffnen hat seine Zeit und Türen schließen hat seine Zeit.
Beim Review, bei der Retrospektive und beim Backlog-Grooming mache ich den Raum auf für neue Ideen und Möglichkeiten. Bei den Sprint Plannings schließe ich die Tür wieder, indem ich mich entscheide, was ich in den nächsten zwei Wochen machen will. Und im Sprint drehe ich den Schlüssel vom Sicherheitsschloss zweimal rum. Jetzt gehe ich mit meiner Entscheidung und verwandle sie in eine Erfahrung. Am Ende der zwei Wochen weiß ich, ob das eine gute Entscheidung war.
Was kann die Generation Y daraus lernen?
Für Antworten brauche ich Erfahrungen*. Ohne Entscheidung kann ich keine Erfahrung machen. Und ohne Erfahrung gibt es keine Kurskorrektur.
Ich schließe mit einer kleinen Geschichte.
Ein Bauer kommt zum weisen König und fragt ihn, ob er ihm erklären kann, was Freiheit ist. Der König fragt den Bauern: “Kannst Du ein Bein heben?”
“Ja”, sagt der Bauer.
“Gut, welches Bein willst Du heben?”
Der Bauer überlegt kurz und sagt dann: “Das linke.”
“Gut”, sagt der König, “dann hebe Dein linkes Bein.”
Der Bauer hebt darauf sein linkes Bein.
“Jetzt heb Dein rechtes Bein”, sagt der König daraufhin zum Bauern.
Der Bauer schaut ihn verdutzt an und sagt: “Aber das kann ich nicht.”
“Siehst Du”, sagt der König, “jetzt weißt Du, was Wahlfreiheit ist.”
In diesem Sinne, viel Spaß beim Entscheiden.
*”Und Dich hat man wieder mal ausgelacht, weil Du für Antworten Erfahrungen brauchst” – aus dem Lied “Antworten, Erfahrungen” von Felix Meyer

Pliiing, Gong & TickTack: Timeboxen beenden

Dass Timeboxing toll ist, weil es uns ermöglicht, fokussiert und priorisiert zu schnellen Ergebnissen zu kommen und komplexe Umfelder zu stabilisieren, habe ich schon im Blogbeitrag “Was ist so cool an Timeboxing?” geschrieben. Dieses Mal möchte ich meine beiden Lieblingswerkzeuge vorstellen, die mir beim Timeboxing helfen.

Der Timer

Eines der wichtigsten Hilfsmittel, das ich in meiner Arbeit als Design Thinker kennengelernt habe und nicht mehr missen möchte, ist der Timer mit Zeitscheibe zur Visualisierung der Restzeit. Die Restzeit wird dabei durch eine immer kleiner werdende Farbfläche sichtbar gemacht. Das erzeugt positiven Zeitdruck und hilft, Meetings „in time“ zu einem produktiven Abschluss zu bringen. Der Vorteil gegenüber unsichtbaren Timern (z.B. Countdown auf dem Smartphone) ist, dass die Restzeit die ganze Zeit über im Raum sichtbar ist – nicht als abstraktes Zahlenwerk, sondern einfach und plakativ.
Probieren Sie es in einem Daily aus! Der Nutzen für den ScrumMaster ist groß: Es ist die Zeit, die das Meeting nach 15 Minuten beendet, nicht der „böse“ ScrumMaster, der sein Team zur Eile drängt. Es genügt ein Einwurf wie: „Ihr seht, dass wir nur noch 5 Minuten haben?“ und nach Ablauf der Zeit: „Es tut mir leid, aber unsere Zeit ist rum! Ich hatte das Gefühl, ihr zwei wolltet noch etwas sagen? Können die anderen wieder an die Arbeit gehen und wir besprechen das jetzt gleich noch?“ Schauen Sie dazu auch in den Blogbeitrag über Smart Timeboxing.
Unter Begriffen wie TimeTimer und ZeiTimer finden Sie unterschiedliche Varianten am Markt. Es gibt elektronisch gesteuerte Timer: Diese benötigen eine Batterie und haben ein elektronisches Piepsen, das bei manchen Modellen eine Lautstärkenregelung bietet. Kleinere Varianten sind meist rein mechanisch und haben daher durchgängig ein tickendes Geräusch – das kann in längeren, sehr ruhigen Meetings stören. Der Vorteil dieser Varianten ist, dass sie keine Batterie benötigen, sehr gut in das Handgepäck von uns Consultants passen und oft eine magnetische Rückseite haben, mit der sie einfach an jedem Whiteboard halten.
Laszlo Stein

Klangschale und Gong

Mein zweitliebstes Werkzeug nach dem Timer ist der Gong. Bei meinem elektronischen Timer stelle ich gerne die Lautstärke aus und nutze dafür den Gong. Bereits 1-2 Minuten vor Ende der Timebox schlage ich ihn ganz sanft, so dass ein kaum hörbarerer Ton meine Kollegen auf das Ende dieser Phase vorbereitet. Am Ende dann kommt dann ein lauter Schlag.
Es dauert maximal einen halben Tag (5-8 Einsätze des Gongs), bis Menschen auf dieses Signal trainiert sind und Sie damit die Aufmerksamkeit einfach und ohne ein lautes Wort steuern können. Große Gongs und Klangschalen haben eindeutig die schöneren, tieferen Töne. Damit sind auch leise Schläge möglich. Ich persönlich bevorzuge Gongs mit gebogenem Rand, die flachen Gongs (Windgongs) scheppern mir bei den lauten Tönen zu sehr. Aber wie die großen Timer sind sie für des Consultants Handgepäck nicht geeignet. Ich habe deshalb eine sehr kleine Klangschale angeschafft – daher das „pling“! Denn je kleiner die Klangerzeuger, desto höher der Ton. Sanfte leise Töne sind damit nicht möglich, das hohe „pling“ ist sehr durchdringend. Auch Zimbeln können den selben Zweck erfüllen.
Mein Tipp: Gehen Sie in ein Musikgeschäft (oder auch einen Esoterik-Laden, neben Räucherstäbchen und Traumfängern gibt es dort auch oft Klangschalen) und probieren Sie Ihr zukünftiges Hilfsmittel unbedingt aus. Sie werden erstaunt sein, welche Vielfalt sich beim Vergleich der Instrumente auftut und Sie werden irgendwann den Ton hören, den Sie  gerne mitnehmen möchten.
Die Kraft dieser beiden Werkzeuge liegt in der regelmäßigen Benutzung. Sorgen Sie dafür, dass der Einsatz so schnell wie möglich „normal“ wird und Sie werden ein sehr viel leichteres Leben als ScrumMaster haben.
Pliiing…

Teamcooking – ein funktionaler Event zur Teamentwicklung

Teamarbeit und kochen haben eine Gemeinsamkeit: Beide sind in der öffentlichen Wahrnehmung hoch aktuell. Ein agiles Modell wie Scrum stellt selbstorganisierte Teamarbeit ins Zentrum und die TV-Sender liefern täglich eine bunte Vielzahl von Kochshows ab. Da liegt es nahe, über den Einsatz von Kochevents in der Teamentwicklung nachzudenken. Und tatsächlich bietet gemeinsames Kochen im Team beste Möglichkeiten, Teamentwicklungsprozesse und kreativ-kulinarisches Erleben zu verknüpfen.
Für ein Teamcooking bieten sich verschiedene Optionen in der Umsetzung an:

  1. Der Einsatz professioneller Event-Veranstalter, die alle Vorarbeiten und den Ablauf gestalten und den Schwerpunkt auf den Kochprozess setzen. (Profikoch, Profi-Location, bei Bedarf Hilfskräfte und einen Moderator zur Auswertung, wenn gewünscht.)
  2. Einsatz eines koch- und teamentwicklungserfahrenen Moderators (z.B. ScrumMaster).
    1. Vorbereitung, Durchführung und Auswertung durch den Moderator (Menü erstellen, einkaufen, Location, Ablaufplanung). Das Team konzentriert sich auf den Kochprozess.
    2. Einsatz eines Moderators (z.B. ScrumMaster), der ein hohes Maß an Selbstorganisation durch das Team steuert und von Anfang an eher als Prozessbegleiter fungiert.
  3. Denkbar sind auch Mischformen aus allen drei Varianten.

Als Teamentwickler habe ich alle Varianten mehrfach moderiert und bevorzuge je nach Ausgangslage Variante 2a oder eine Mischform aus 2a und 2b.
Zielsetzungen im Teamcooking


Kriterien für einen erfolgreichen Ablauf von Teamcooking-Maßnahmen

Hinweise zur Auswertung von Teamcooking-Prozessen
Teamcooking ist als ein ausgesprochen ressourcenorientiertes Modell der Teamentwicklung zu verstehen, d.h. der Blick liegt nicht auf Defiziten, sondern auf Stärken. Die Auswertung sollte daher niemals den Spaß verderben und die Leistung, die das Team erbracht hat, grundsätzlich in Frage stellen und abwerten.
Kritische Situationen, die sich durchaus ergeben können (aber eher selten sind, wenn: siehe Kriterien) sind im Sinne von Entwicklungsmöglichkeiten ressourcenorientiert aufzugreifen und zu steuern. Es bieten sich unterschiedlichste Methoden und Techniken zu Auswertung an, z.B. Gruppendiskussionen, Kleingruppenreflexion mit Austausch, Einzelarbeit mit Moderationskarten und anschließender Präsentation und Reflexion, Malen der Erfahrungen usw. Vereinbarungen und Maßnahmen für einen Praxistransfer sind empfehlenswert
Zusammenfassung
Teamcooking bietet eine echte Chance, funktionale Teamentwicklung und Kreativität, Lebendigkeit und Spaß optimal zu verbinden. Es bietet sich für Teams im Anfangsstadium (Teambuilding) an, aber auch für erfahrene Teams, die sich in einer nicht alltäglichen Situation erleben wollen. Teamcooking bietet viele kreative Variationsmöglichkeiten, z.B. als Grill-Event, in Verbindung mit Rollenspielen (Rittermahl), als Wettbewerb usw. Ein Beispiel aus meiner Teamentwicklungspraxis zeigt ein Menü für ein Führungsteam mit 14 Personen, die sehr wenig Kocherfahrung mitgebracht hatten. Das Menü und die Zutatenliste wurden von mir als Moderator erstellt. Suche nach der Location, Einkauf, Zusammenstellung der Kochteams für die 5 Gänge lagen in der Selbstorganisation des Teams.

Teamcooking-Menü für 14 Personen

Einkaufsliste

Amuse Geule
Lachsröllchen mit Wasabi-Frischkäsefüllung Zutaten:

  • 3 Packungen milder Räucherlachs à 150g 
  • 3 Teelöffel Wasabi Creme 
  • 2 Becher Frischkäse (Philadelphia o.ä.) à 200 g 
  • Salz, Pfeffer

  • Lachsscheiben knapp übereinanderlegen, sodass 3 Rouladen entstehen. 
  • Wasabi-Creme mit Frischkäse gut verrühren, mit Salz/Pfeffer abschmecken und auf die Lachsflächen streichen.
  • Lachs nun vorsichtig, aber fest aufrollen und in Klarsichtfolie verpacken, kurz in den Kühlschrank legen. 
  • Zum Servieren Lachsrollen auswickeln und in gleichmäßige Scheiben schneiden. Zu Toastbrot-Dreiecken servieren.

 

Vorspeise
Kürbissuppe mit Kokosmilch Zutaten:

  • 1,5 kg Muskatkürbis ungeputzt (evtl. Hokkaido) 
  • 2 l Hühnerbrühe (Instant) 
  • 800 ml süße Sahne
  • 100 g eiskalte Butter 
  • Salz, Pfeffer, Zucker
  • 1 EL mildes Currypulver 
  • Ein Bund Petersilie (wenn möglich Koriander) 
  • Eine Dose Kokosmilch (400 ml) ungesüßt
  • Kürbis putzen und in Würfel schneiden. 
  • Hühnerbrühe zubereiten und in einen Topf geben, aufkochen lassen. 
  • Kürbis dazugeben und bei mittlerer Hitze weichkochen (ca. 15 min). 
  • Suppe pürieren und Sahne zugießen, aufkochen lassen. 
  • Die heiße Suppe nun mit der eiskalten Butter stückchenweise aufkochen und mit Salz, Pfeffer, Zucker und Curry abschmecken. 
  • Kleingeschnittene Petersilie (oder Koriander) zugeben. 
  • Je Teller 2-3 Esslöffel Kokosmilch vorsichtig darüberträufeln (wenn Zeit und Material vorhanden, evtl. Zimtcroutons dazugeben).
Hauptgang
Hähnchenbrüste mit Fetakruste Zutaten:

  • 3 kg aromatische große Tomaten 
  • Salz, Pfeffer
  • 4 TL getrockneter Oregano 
  • Olivenöl 
  • Pro Person eine Hähnchenbrust ohne Haut und Knochen 
  • 400g Schafskäse (Feta) 
  • 6 Schalottenzwiebeln, 2 Bund Basilikum 
  • 1 Glas schwarze Oliven entsteint zur Deko, Ciabattabrot o.ä.
  • Backofen auf 200 Grad vorheizen. 
  • Tomaten in kochendes Wasser tauchen, abschrecken, häuten, halbieren, entkernen und grob würfeln. 
  • Tomaten in einer großen feuerfesten Form verteilen. 
  • Salzen, pfeffern, mit 8 Esslöffel Olivenöl beträufeln. 
  • Im heißen Backofen, mittlere Schiene, unter dem Grill 15 Minuten garen. 
  • Hähnchenfleisch waschen, trocknen, salzen und pfeffern. 
  • In heißem Olivenöl von jeder Seite 4 Minuten braten. 
  • Schafkäse reiben und mit Oregano und klein gehackten Schalotten mischen.
  • Hähnchenbrüste nun auf die Tomaten legen, Fetamischung darauf verteilen und ca. 5 Min übergrillen, bis der Feta leicht geschmolzen ist.
  • Zum Servieren mit gehacktem Basilikum bestreuen. Einige Oliven dazugeben und mit Ciabattabrot reichen.
Dessert
Weißer Schoko-Himbeer-Schaum Zutaten:

  • 400g weiße Schokolade 
  • 800 g süße Sahne 
  • 750g Himbeeren (kann auch Tiefkühlobst sein) 
  • 8 EL Himbeergeist 
  • 4 EL Puderzucker
  • Schoko in kleine Teile zerbröckeln. 
  • Sahne in einem Topf erhitzen. 
  • Schoko zufügen und bei milder Hitze schmelzen lassen. 
  • Sahnemischung 1 Stunde kalt stehen lassen. 
  • Himbeeren abbrausen, abtropfen und mit Himbeergeist und Puderzucker mischen.
  • Sahne-Schokomischung mit dem Handrührer zu einer schaumigen Creme aufschlagen.
  • Die Himbeeren auf die Dessertgläser aufteilen und servieren.

TIPP: Noch mehr Ideen für besseres Teamwork gibt es bei den Scrum Supplements mit Dieter Rösner.

Tut Feedback eigentlich weh?

Nein, so meine klare Antwort. Vielmehr brauchen wir es händeringend, um voranzukommen. Natürlich bedarf es einiger Rahmenbedingungen, damit Feedback auch das bewirken kann, wozu es imstande ist – nicht nur auf der “Nehmerseite”.
Ein Fallbeispiel:
Ein wirklich guter Topmanager neigt dazu, in seinen Meetings viel zu schnell zu sprechen und seinen Redefluß ca. 15 mal pro Minute mit einem „ähm“ zu unterbrechen. Ich habe es mehrmals gezählt und gestoppt. Dadurch besteht die Gefahr, dass die Zuhörer wichtige Informationen im Laufe eines längeren Vortrages verpassen, weil sie akustisch irgendwann nicht mehr folgen können. Ich selbst habe mich des öfteren dabei erwischt, dass meine Gedanken bei seinen Vorträgen abschweifen.
Was tut man nun mit so einer Erkenntnis, die durchaus unangenehm sein kann, wenn sie falsch rübergebracht wird. Klar ist, dass insbesondere der Feedbackgeber aus seiner Komfortzone heraus muss, um seinem Gegenüber einen Gefallen zu tun. Mit dieser Sicht fällt es schon mal etwas leichter. Wenn wir Feedback also als Zeichen absoluter Wertschätzung betrachten, so hilft es uns auch, selbst das unangenehmste Feedback zu überbringen (Körpergeruch, Hosenstall offen…). Wertschätzung deshalb, weil es unserem Gegenüber hilft, sich zu verbessern. Würde ich ihn nicht wertschätzen, würde ich das Feedback für mich behalten. Darüber hinaus gehe ich davon aus, dass das Thema Feedback immer magerer ausfällt, je höher ein Mitarbeiter gestellt ist. Aber auch der Topmanager ist ein Mensch und hat konstruktives Feedback verdient, erst recht dann, wenn er einen Berater dafür bezahlt.
Im genannten Fallbeispiel habe ich mein Feedback genau so eingeleitet: Dass ich Feedback als Zeichen meiner Wertschätzung empfinde. Und es wurde mir mit den Worten gedankt: “Danke, das ist mir noch nie aufgefallen und es hat mir noch keiner gesagt.” Ich sehe das als Bestätigung, dass sich bisher nur keiner getraut hat.
Wenn wir zusammengefasst das Thema Feedback als Wertschätzung betrachten und folgende Rahmenbedingungen beachten, so wird es leichter fallen und auf dankbare Ohren stoßen:

Abschließend möchte ich euch raten, mal selbst zu hinterfragen:

Dies sollte euch helfen, offener, konstruktiver und positiv mit Feedback umzugehen.

Stand up – it might be worth it!

Für ein Konzert von Bodo Wartke hatte ich Karten geschenkt bekommen. Da er leider am Wochenende nicht in Berlin auftritt, fuhren wir nach Luckenwalde, um ihn zu sehen. Zu unserer Verwunderung war der Saal, der rund 700 Plätze hatte und beim Reingehen den Charme einer Turnhalle verströmte, ausverkauft. Zwar waren wir nicht die einzigen Berliner, die die einstündige Fahrt auf sich genommen hatten, es waren aber auch viele im Publikum, die man nicht unbedingt dort vermutet hätte. Eine ältere Dame vor mir genoss sogar während der Vorstellung ihren „Kurzen“, den sie wohl noch von der organisierten Busfahrt zum Konzert übrig behalten hatte.
Nichtsdestotrotz war die Stimmung toll. Das Publikum spiegelte zu jedem Moment die vom Künstler erzeugte Stimmung wider und ließ sich auf jede Frage, Mitmachaufforderung bzw. Interaktion mit Bodo Wartke ein. Nach seiner – ich glaube – dritten Zugabe, bei der er sich bei seiner Crew und beim Publikum bedankte, weil er auch diese noch spiele durfte, fasste ich kurzerhand einen Entschluss.
Ich war mir ziemlich sicher, dass es die letzte Zugabe sein würde und mir hatte der Abend sehr gut gefallen. Warum also nicht aufstehen und dem Künstler die Freude einer Standing Ovation bereiten? Klar, die Gefahr, dass ich alleine stehen würde, war natürlich vorhanden. Aber das war mir egal. Schließlich „stand“ ich ja zu meinem Aufstehen. Ich fand es klasse, was er gemacht hatte und wollte es ihm zeigen. Als er sich zum letzten Mal verbeugte, stand ich also schwungvoll und klatschend auf!
Es dauerte eine laaaaaange Sekunde bis mir jemand folgte. Ich konnte es sehen, weil es eine Person schräg hinter mir war. Und dann noch jemand, direkt neben mir. Und dann spürte ich, wie ein Movement durch den Raum ging. Hunderte von Personen standen gleichzeitig auf. Eine Wahnsinnsenergie und Dynamik. Ein tolles Gefühl irgendwie und auch ein bisschen unbeschreiblich.
Während er sich tief und lange verbeugte, machte seine Crew das Licht im Saal an. Als er wieder hochblickte, sah er den kompletten Saal stehen. Und man sah in seinen Augen die Freude, aber auch die Verwunderung! Unter Standing Ovations und von einem Ohr zum anderen grinsend verließ er, selber klatschend, rückwärts den Saal.
Mein Freund drehte sich zu mir und sagte: “Wow, you created a Movement! Und außerdem sind jetzt alle viel schneller draußen, weil sie ja schon stehen!”
Wie gesagt, natürlich wusste ich nicht, ob es funktionieren und somit den gewünschten Effekt haben würde. Aber ich bin aufgestanden, weil ich überzeugt war, dass es einen Unterschied macht. Egal, ob mir jemand folgt oder nicht.
Steht auf! Macht einen Unterschied – wenn auch nur für euch. Most likely wird jemand folgen!

Teamgeist beim Münchner Staffelmarathon oder was gute Zielsetzungen bewirken können

Für mich begann alles im Mai, als ich eingeladen wurde, an der Winquadrat Zukunftskonferenz des Uni Management Clubs in Österreich teilzunehmen. Ich saß in der 5. Reihe im wunderschönen Haydnsaal des Schlosses Esterházy und hörte dem Extremsportler Gerhard Gulewicz bei seinem Visionärstalk „Erfolgsstrategien im Sport und der Wirtschaft“ zu, wie er von der Wichtigkeit von Zielsetzungen erzählte. Wie so oft im Leben, hat bei ihm alles mit einer Wette angefangen. Doch wie eher selten im Leben, hat er sich mithilfe seiner unwahrscheinlich starken persönlichen Motivation und sehr klaren Zielsetzungen bis auf das Podium beim Race Across America hochtrainiert.
Seine Präsentation hieß nicht umsonst Visionärstalk. Noch während er auf der Bühne stand, war ich motiviert, meinen Körper mal wieder richtig zu fordern und auf ein hoch gestecktes, aber doch erreichbares Ziel hinzuarbeiten. Diese Gedanken schwirrten noch in meinem Kopf als ich ein paar Wochen später beschloss, mich gemeinsam mit einigen Kollegen des bor!sgloger Teams für eine unserer zwei Staffeln beim Marathon in München anzumelden.
Heute frage ich mich zurecht, wie wir es eigentlich geschafft haben, an diesem traumhaft schönen Herbstsonntag nach 04:03 Stunden tatsächlich gemeinsam ins Ziel einzulaufen?! Es ist kein Geheimnis, wenn ich sage, dass wir verdammt hart und viel arbeiten. Wir reisen quer durch Europa, verbringen eine Menge unserer Abende bzw. Morgen im Taxi, Flugzeug, Bus, Zug oder Auto und richtig gesundes Essen sehen wir auch nur am Wochenende, wenn wir uns dazu aufrappeln können, aus den Inhalten unserer leeren Kühlschränke ein halbwegs vernünftiges Gericht zu kochen.
Ich denke jedoch, dass ich meine Frage selbst beantworten kann. Einerseits durch die klare Zielsetzung à la Gerhard Gulewicz, denn die war wirklich SMART:

Ja, unsere Zielsetzungen waren klar. Doch andererseits hat auch die gegenseitige Motivation, die man nur als Team fördern kann, dazu beigetragen, diese Zielsetzung zu erreichen. An dieser Stelle möchte ich mich retrospektiv bei meinem Team bedanken! Ohne die monatelange Motivation (gemeinsames Joggen in den Abendstunden, gegenseitiger Ansporn zum frühen Aufstehen) bis hin zur letzten Sekunde (danke an meinen Kollegen Karl für die lustigen Anekdoten aus deinem Leben, die du mir erzählt hast, um mich während der letzten Kilometer bei Laune zu halten), hätte ich meinen Körper wohl kaum dazu mobilisieren können, diese Leistung zu erbringen. Mein schönster Moment war, als ich ca. 500 Meter vor dem Ziel mit heraushängender Zunge meine restlichen Teammitglieder vom Straßenrand auf mich zulaufen sah. Das hat einerseits dazu geführt, dass wir alle noch einmal einen Zahn zugelegt haben, andererseits, dass wir geschlossen als Team über die Ziellinie gelaufen sind. Danke dafür 🙂
Der Staffelmarathon hat mich gelehrt, noch mehr an die Kraft der SMARTen Zielsetzung und des Teamgeistes zu glauben. Sowohl beruflich als auch privat. Nur so kann man sich wirklich kontinuierlich verbessern. Was heißt das jetzt für alle Scrummler da draußen? Ich denke schon, dass man das ganz einfach in die Agile Welt übertragen kann. Z.B. lieber ScrumMaster: Wie genau lautet dein Ziel, das du mit der Lösung eines Impediments erreichen möchtest? Lieber Product Owner, bitte achte darauf, dass du ganz klar definierte Sprintziele kommunizierst und SMARTe User Stories schreibst. Liebes Dev.Team, achtet darauf, dass ihr gemeinsam die User Stories abarbeitet. Nur mit einem gemeinsamen Ziel könnt ihr auch wirklich aus der vollen Motivationsquelle schöpfen!

Nachsatz: Da wir in unserer Profession täglich von der kontinuierlichen Verbesserung sprechen, konnten wir uns jetzt natürlich nicht einfach auf die Schultern klopfen und wieder getrennte Wege gehen. Nein. Nachdem wir ersteres getan hatten, haben wir uns mittlerweile zum größten Staffelmarathon der Welt in Wien für Frühjahr 2014 angemeldet. Und dieses Mal werden wir definitiv unter der 4-Stunden-Grenze liegen!

IMG_3540

First, let's fire all agile coaches

Eine spannende Debatte ist ausgebrochen: Was bringen agile Coaches? Auf Think Different argumentiert Bob Marshall gegen den Einsatz agiler Berater: Zum einen, schreibt er, versprechen sie das Blaue vom Himmel und machen damit Unternehmen falsche Hoffnungen. Zum anderen führen sie zu lokalen Optimierungen innerhalb des Unternehmens, indem bestimmte Gruppen (meist Scrum-Teams) erhöhte Ressourcen und Aufmerksamkeit bekommen.
Bob Marshall wirft damit die Frage nach dem Selbstvertändnis von agilen Coaches und ScrumMastern auf. Sind wir dazu da, agile Luftschlösser zu bauen und die Rosinen für unsere Scrum-Teams herauszupicken? Dass diese Wahrnehmung entstehen kann – und auch häufig ensteht – sei geschenkt. Das ist ja auch einer der Gründe, warum Scrum-Implementationen scheitern: Die Differenz zwischen Anspruch und Wirklichkeit wird zu groß: Unternehmen fangen an zu glauben, Scrum sei für andere genau das Richtige, nicht aber für sie selbst.
Ich durfte als ScrumMaster und Coach einige Projekte über längere Zeit begleiten. Die Erwartungen, die dabei an meine Rolle herangetragen wurden, waren nie gleich. In manchen Projekten wurde vom ersten Tag an erwartet, dass ich Verantwortung für den Projekterfolg übernehme. In anderen sollte ich bereits bestehende Rollen und Verantwortungen in ihrer Arbeit unterstützen oder bestehende Prozesse optimieren.
Mein Selbstverständnis als Berater kann ich bei der ersten Art von Projekten (volle Verantwortung vom ersten Tag an) leichter ausüben. Denn ich kann mit Scrum von innen heraus arbeiten. Es geht dann in erster Linie um das Meistern von alltäglichen Herausforderungen und nur in zweiter Linie um Scrum. Anders gesagt: Ich kann dann einen bestehenden Prozess mitgestalten und im Zuge dessen an seiner Agilisierung arbeiten.
Und da ist er auch schon, der springende Punkt: Wenn der Beraterjob sich darauf begrenzen soll, Ratschläge, Empfehlungen und Anstöße zu erteilen, dann sind agile Coaches meist schlecht investiertes Geld. Lernen geschieht nur durch Vormachen. Ein guter Berater ist dazu da, vorzutanzen – und das heißt, die Arbeit so lange selber zu machen, wie es eben nötig ist. Ein einfaches Beispiel: Das Scrum-Team soll User Stories schreiben, weil das in Scrum eben so ist. Nun kann man dem Product Owner von Mike Cohn und den drei Fragen der User Story erzählen. Ein fleißiger Product Owner wird dann etwas daraus basteln und im nächsten Sprint Planning mit einem Stapel lustiger Sätze aufwarten.
Wir können aber auch ganz anders vorgehen: Warum nicht im Sprint Planning die klassischen Anforderungen durchgehen und dort, im Gespräch mit dem Team, eben diese drei Fragen stellen? Dann werden User Stories aus der Arbeit heraus, im Kontext ihrer Verwendung, entstehen. Die Puristen unter uns werden einwenden, dass Stories im Planning ja gar nicht geschrieben werden dürfen (Story Readiness!). Aber wie soll ein Scrum-Team darauf kommen, wenn es noch nie ein Backlog Grooming hatte? Auch hier ist es wichtig, die Besserwisserei im Schrank zu lassen und stattdessen dem Team ganz konkret aufzuzeigen, welches seiner Probleme ein solches Meeting lösen kann.
Dieser Umgang mit Scrum ist deflationär, denn er hält sich nicht mit großen Einführungen und Glaubenssätzen auf, sondern orientiert sich strikt am Bedarf der Personen und Gruppen im Unternehmen (und das nicht nur für die Scrum-Teams).
Wir Berater erzählen gerne von Scrum, weil wir uns damit am besten auskennen. Stattdessen sollten wir uns viel mehr mit dem auseinandersetzen, was nicht im Lehrbuch steht. Wir müssen besser verstehen, wie Unternehmen ticken, was ihre Produkte ausmacht, wo ihre Probleme sind, und was sie jetzt gerade brauchen. Nur dann haben wir eine Chance, Scrum als Rahmenwerk aufzuspannen, das im Unternehmen verankert ist. Ansonsten wird unsere Arbeit als Berater und/oder SMs sich auf das Verteilen von agilen Sahnehäubchen beschränken.

Kommunikation ist nichts für Feiglinge

Was ist nur los mit den Menschen? Was hält uns davon ab, eine Person, an der uns etwas stört, darüber in Kenntnis zu setzen und mit ihr einen Weg zu finden, wie eine bessere, achtsamere Kommunikation gemeinsam erreicht werden kann? Stattdessen geht man zu einer anderen, vollkommen unbeteiligten zweiten Person und fängt an, dort seinen Ärger abzuladen und nach Bestätigung für seinen Standpunkt zu suchen. Man erzählt, beschwert sich, philosophiert, suhlt sich in den Fehler des Anderen und der Hybris der eigenen Unfehlbarkeit.
Was sind die Gründe dafür, einer direkten Konfrontation und damit der Aussicht auf eine Aussprache aus dem Weg zu gehen? Was erwarten wir uns von dieser anderen Person und wieso können wir unserem Unmut dort offensichtlich erfolgreich Luft machen? Wie kommt es, dass sich diese destruktive Kommunikationskultur gegen offenes Feedback und gemeinsamen Austausch durchsetzen kann?
Angst, Faulheit oder doch Unwissen?
Ist es die Angst vor einem Streit, der durch die „Wahrheit“ entbrennt und die Situation nur noch schlimmer machen würde? Ist es die Faulheit, Energie in eine konstruktive und gewinnbringende Diskussion zu investieren, die kräftezehrend werden kann und hinter der die Gefahr lauert, für den hohen „Preis“ eines Kompromisses von seiner eigenen Meinung abweichen zu müssen? Oder ist es einfach Unwissen, welche schädlichen, vernichtenden Neben- und Rückwirkungen ein Unterlassen dieser direkten Kommunikation haben kann? Wahrscheinlich ist es von allem etwas. Nein, ich gehe davon aus, dass es so ist.
Es bleibt die Frage nach dem Warum. Ganz gleich, aus welchem Grund man sich gegen eine direkte und klärende Auseinandersetzung entscheidet: Die Motivation es zu unterlassen, entsteht dadurch, dass man als Ergebnis ausschließlich den Verlust und damit Schmerz (threat) vermutet: Was kann schiefgehen? Was habe ich zu verlieren? Welche Reaktionen habe ich zu befürchten und was folgt danach? Die Möglichkeit, durch Offenheit, Direktheit und Mut einen Gewinn einzustreichen, der zu einem Mehr an Vertrauen und Verbundenheit beiträgt, wird mehr als selten in Erwägung gezogen. Lieber bildet man sich seine exklusive Meinung voller fadenscheiniger, haltloser Interpretationen und schafft sich ein verklärtes Bild seiner subjektiven Wahrheit, das zumindest hilfreich genug ist, ausreichend Argumente zu sammeln, die dem Mut und der Aufrichtigkeit einen wirkungsvollen Riegel vorschieben.
An dieser Stelle würde unter normalen Umständen eine Liste der drei bis fünf besten Techniken folgen, die euch dabei unterstützen sollen, ein aufrichtiger, mutiger Kommunikationspartner zu werden. Ich habe mich gegen die Norm entschieden. Ich möchte einen anderen Weg beschreiten, einen unkonventionellen. Den eigentlich normalen.
Ist euch klar, was ihr tut oder vielmehr unterlasst? Einen Menschen zu schützen, indem man ihm die Wahrheit aus erster Hand ersparen möchte, bedeutet, diesen Menschen zu entmündigen. Man traut es ihm nicht zu. Man stellt sich über ihn, entscheidet für ihn und gibt ihm ohne sein Wissen zu verstehen, dass er es nicht wert ist. Man richtet offensichtlich Schaden an.
Ich frage noch mal. Ist euch das klar? Auf einer Skala von 1 bis zehn, die nach eurem Mut fragt (1 = feige, 10 = mutig), wie viel Mut habt ihr, wenn es darauf ankommt? Findet ihr euch in meinen Zeilen wieder?
Meine Fragen richte ich an niemanden im Speziellen. Ich frage dich. Ich frage jeden, der durch seinen Mut, Kommunikation schon heute hochleben lassen kann und sich damit gegen die Sorte Mensch erhebt, die sich selber für zu wichtig nehmen und unberührt bleiben von dem, was ich mit meinen Zeilen versuche zum Ausdruck zu bringen. Es ist keine Anklage. Es ist kein Vorwurf. Es ist ein Hilferuf.
Was möchtest du sein? Held oder Feigling? Was bist du? Es ist ein bisschen, wie der Besuch beim Zahnarzt. Die Ungewissheit vor dem Besuch ist immens groß und lähmt bis zur Handlungsunfähigkeit. Fluchtgedanken und Panikattacken sind an der Tagesordnung. Nach der überstandenen “Tortur”, die zu unserem großen Erstaunen harmlos und unspektakulär verlief, fragt man sich, wovor man eigentlich Angst hatte. Es war nicht halb so schlimm, wie gedacht! Zurück bleiben Gefühle der Leichtigkeit und des Glücks. Man hat überlebt.
Im 21. Jahrhundert sind Helden selten geworden. Du kannst einer sein. Schon heute.

Die KITA-Bewohner spielen wieder!

Sieben frisch aufgesetzte Scrum-Teams arbeiten derzeit eine klassische Releasebeauftragung eines halben Jahres ab. Mitten im Release ging der Überblick darüber verloren, was tatsächlich schon ausgeliefert worden war, was bereits fertig entwickelt war und auf den Releasewechsel wartete und was noch zu tun war. Jedes Team für sich konnte dazu zwar Auskunft geben, aber die Zuordnung zum Company Backlog war mehr als schwierig aus den elektronischen Tools, aber auch vom Releaseboard abzulesen.
Dort sah man zwar ca. 100 Stories und Epics, allerdings konnte man nicht erkennen, was zu welchem Item aus dem Company Backlog beitrug bzw. ob es überhaupt im Company Backlog auftauchte. Die klassische Beschriftung mit Zahlen brachte uns leider auch kein Stück weiter. Also gingen wir auf Textmarker-Jagd, um möglichst viele unterschiedliche Farben zu ergattern. Als wir mit dem ersten Product Owner anfingen, die Stories aus seinem Backlog den unterschiedlichen Company Backlog Items zuzuordnen, gingen uns aber zu schnell die Farben aus. Was in der Theorie so schön aussieht, war bei uns im aktuellen Release absolute Theorie und hatte nichts mit dem tatsächlichen Releaseboard zu tun.
Nach kurzer Ratlosigkeit kam ein ScrumMaster auf die Idee, nicht nur Farben, sondern zusätzlich Symbole einzuführen. Ich gebe zu, ein Workaround! Wir sind einfach noch nicht bei thematischen Releases.
Aber immerhin half uns dieses Vorgehen zu identifizieren, was im Company Backlog alles fehlte und bei welchem der hoch priorisierten Epics im Backlog die Arbeit noch nicht mal gestartet worden war. Außerdem hatte es den schönen Nebeneffekt, dass sich die POs selbst Symbole und Farben aussuchen durften, mit denen sie ihre Stories kennzeichneten. Ich freue mich schon, wenn wir im Grooming demnächst über das Sonnenepic sprechen 😉
Da die Visualisierung initial einiges an Zeit beanspruchte, bekamen wir von den Büro-Bewohnern in unmittelbarer Umgebung des Releaseplans bei jeder Gelegenheit zu hören: “Ach, die KITA-Bewohner spielen wieder.” Für mich war es toll zu sehen, wie das Arbeiten an den Wänden, auf dem Boden und im Stehen zu sehr viel Interaktion und Aktion führte. Stifte wurden hin und her geworfen, über blöd gemalte Symbole gelacht, sich gegenseitig beim schnellen Ausmalen geholfen…
Meine Hypothese, warum es funktioniert hat? Weil es einfach war und jeder sofort mitmachen konnte!
Und trotzdem: Wir haben zwar jetzt eine Zuordnung der “User Stories” und Aufgaben zu einer übergeordneten Liste. Ein Company Backlog ist das allerdings noch nicht. Ein rhythmisches Liefern erst recht nicht! Es hat aber deutlich gemacht, dass wir etwas ändern müssen, wenn wir anfangen wollen, gemeinsam zu liefern!

Erfolgreiche Scrum-Teams ziehen an einem Strang

Du bist auf der Suche nach einem Aperitif für deine Retrospektive? Du möchtest das komplette Team ins Tun bringen und zum Teamerfolg beitragen lassen? Du willst zeigen, dass Selbstorganisation Führung braucht und zwar eine ganz bestimmte Art und Weise von Führung? Du suchst nach einer Gelegenheit, dein Team an einem Strang ziehen zu lassen und gleichzeitig Spaß zu haben?
Dann probier mit deinem Team das „Communication Race“ aus. Um loszulegen brauchst du:
Zutaten
Schnur (je Spieler ca. 1 Meter), Quadrat aus Pappe (zugeschnitten auf 20×20 cm), zwei unterschiedlich farbige Filzstifte mit dünner Stiftspitze, 1 Flipchartbogen, ein schwarzer Neuland-Flipchart-Marker, Tisch
Teilnehmer
mindestens vier bis maximal 10 pro Team (bei mehr Spielern Teams teilen)
Zeit
45 Minuten (inklusive Debriefing)
Vorbereitungen für das Spiel
Zuschneiden eines Quadrates aus Pappe (20×20 cm), Filzstift mittig durch die Pappe stoßen und mit Tesafilm von beiden Seiten fixieren. Jedes Teammitglied hat sein Seil in der Pappe fixiert, der Parcours ist auf den Flipchart-Bogen aufgemalt.
Ablauf
Jeder Spieler nimmt sich ein Seilende. Der Stift wird am Startpunkt angesetzt. Das Team versucht nun, den vorgegebenen Weg zu überwinden und die Stiftelinie ans Ziel zu führen. Dieses ist erreicht, wenn eine ununterbrochene Linie vom Start zum Ziel gezogen wurde, die an keiner Stelle über die durch den Parcours vorgegebenen Linien hinausgegangen ist. Kommunikation unter den Teammitgliedern ist erlaubt. Es darf immer nur eine Hand das Seil berühren und nur am Seilende. Es gibt kein zeitliches Limit. Übermalt das Team auf seinem Weg die vorgegebene Strecke, muss es sich zum Ausgangspunkt (Start) zurückbegeben. Alle Teammitglieder müssen in jedem Moment des Spiels eine Hand am jeweiligen Seilende haben.
Mehr zum Communication Race findet ihr unter:  http://tastycupcakes.org/2013/04/communication-race/
Tipps
Ihr könnt bei längeren Strecken Zwischenziele benennen, damit ihr nicht immer wieder zum Anfang zurück müsst. Bereitet das Spielmaterial (Stift, Seil in der Pappe) vor. Der Parcours sollte ebenfalls bereits gemalt sein. Ist das Team sicherer, kann es sich auch später seinen eigenen Weg malen und Schwierigkeiten einbauen.
Varianten
Ihr könnt das Spiel genauso mit einem Team wie mit mehreren Teams in einem Wettbewerb gegeneinander spielen. Ihr erhöht den Schwierigkeitsgrad, wenn das Spiel auf dem Boden gespielt wird oder ihr ein Zeitlimit setzt. Wer denkt, dass er mit seinem Team in der Champions League angekommen ist, der kann das Spiel auch blind spielen lassen (ein Sehender als Kompass, der Rest des Teams kann nichts sehen).
Debriefing
Wer meine Blogs regelmäßig liest, weiß, dass ich ein fanatischer Fan des Debriefings bin, nicht zuletzt, weil nach dem Spiel eben vor dem Spiel ist. Damit das Spiel nicht alleine für sich steht und dadurch mögliche Synergien verloren gehen könnten, ist es wichtig, Leitfragen vorzugeben, die – je nach Thema – richtungsweisend den Spielprozess paraphrasieren und einen Transfer in den Alltag sicherstellen.
Mögliche Fragen können sein:

Spielanlässe
Retrospektive (Einstieg), Rollendefinitionen im Team, ein neues Team findet sich, innere Antreiber im Team (Zeitlimit), Rollenkonflikte, Selbstorganisation braucht Führung, etc.

Trusting. Connecting. Hitchhiking.

Two weeks ago I took part in the XP2013 meeting new people, listening to knowledgeable Agilists, learning new games, and generally enjoying the positive hype that surrounds these kinds of conferences. One of the conference‘s underlying, yet distinctive themes spanning across those five days seemed to generally be trust or better yet the lack of trust amongst people. The wish for regaining a deeper connection between people. Gitte Klitgaard‘s presentation “Be Brave“ resonated this theme beautifully and gave advice on how to overcome this issue. David Anania spoke about it in his keynote when clarifying the differences between hearing and listening and the importance of doing the latter. On top of that, I heard Amanda Palmer‘s TED talk “The Art of Asking“ and her wish to really connect with people mentioned more than once during the coffee breaks.

 
Halfway through the week, it came to me. I believe that I know a solution to this issue. It is simple. It is cheap. It is doable in most countries of the world. It is fun. It is hitchhiking.
 
As a professional hitchhiker, I can only say that this form of transport covers all of these topics. Both the hitchhiker and the driver have to overcome the issue of trusting a complete stranger. Both of them cannot escape connecting with each other while sitting together for a varying amount of time. Whether they can speak each other‘s language or simply gesticulate their way towards non-verbal communication, they share something special.
 
I have hitchhiked around England, Scotland, France, Luxembourg, Italy, Austria, Switzerland, Belgium, the Netherlands, Spain and Morocco. I have been picked up by professionals, students, unemployed, immigrants, Ferraris, driving school cars, lorries, goths, police cars, single women, families with crying babies, music bands, old ladies, lonely men, convertibles, and people who had never in their lives even considered picking up a hitchhiker. They have offered me a place to sleep, breakfast, a shared walk in the French countryside, homegrown food, sightseeing tours, money. With each one of these drivers, I share a special memory. No, I don‘t hitchhike alone. For my own and the driver‘s safety, I am always with a friend. Yes, there are certain rules that should be abided to when hitchhiking (http://hitchwiki.org/en/Safety). But they simply make the whole experience of hitchhiking and picking up hitchhikers even more enjoyable.
 
This is my message to you. Take a friend and try it. It will be rewarding. For a brief time-box, you will be made a part of somebody else‘s life. You will connect. You will experience what trust really means. And if you‘re still not convinced to try it yourself, maybe the next person sticking out his or her thumb by the side of a road will convince you.
 
Perhaps I will host an open space session on what hitchhiking teaches us about communication in our personal and professional lives at next year‘s XP2014 in Rome.
 
What is your opinion on this?!

Produktivität mal anders

Als ScrumMaster hat für mich die Produktivität meines Entwicklerteams die höchste Priorität. Impediments, sprich Blockaden, zu identifizieren und aus dem Weg zu räumen ist dabei meine hauptsächliche Tagesaufgabe. In einem meiner Projekte lief das mal auf ganz andere Art und Weise.

Ich seh etwas, das du nicht siehst

Ich drehte wieder einmal meine Runden durch unser Großraumbüro und da fiel mir plötzlich auf, dass einige Entwickler Schwierigkeiten mit dem Sehen zu haben scheinen. Das merkt man zum Beispiel an  verkniffenen Gesichtern, unnatürlichen Kopf- und Körperhaltungen oder gar gerötete Augen.
Als ursprünglicher Augenoptikermeister war ich gleich wieder in meinem alten Element und betrachtete das Thema Software-Entwicklung einmal mit ganz anderen Augen. Ich stellte mir die Frage, wie ein Entwickler wohl produktiv sein kann, wenn ihn aufgrund der nicht idealen Brille für den Arbeitsplatz brennende Augen, Rücken oder Kopfschmerzen plagen. Denn häufig ist dem so. Passt die Brille nicht zum Arbeitsplatz oder die Stärke der Brillengläser ist nicht mehr die aktuelle, hat das die eben beschriebenen Folgen.
Viele Menschen klagen darüber. Oft müssen sich Menschen am PC-Arbeitsplatz sogar täglich die Frage stellen: „Will ich gut sehen oder bequem sitzen?” Das eine darf im Idealfall das andere natürlich nicht ausschließen. Mit der richtigen Brille. Abhilfe muss also her.
Über alte Kontakte organisieren wir nun eine „Sehtest-Initiative“, in der ich den Entwicklern eine Augenüberprüfung anbieten möchte, um daraufhin mit einer Messbrille die ideale Korrektion der Sehschwäche direkt am Arbeitsplatz zu simulieren. Dem Entwickler kann der Nutzen einer optimalen Versorgung auf diese Art und Weise direkt vor Augen geführt werden. Im wahrsten Sinne. Und dies direkt an seinem Arbeitsplatz.
Lassen wir uns überraschen. Die Aktion wurde von den Team-Mitgliedern mit Vorfreude aufgenommen und wir organisieren derzeit das nötige Equipment für die Messungen über einen ortsansässigen Optiker.
Das formulierte Ziel ist jedenfalls klar: Produktivität bei gutem Sehen und bequemer Kopf- und Körperhaltung.

Wann ist ein Impediment ein Impediment?

Impediments sind häufig gar nicht so sichtbar und es ist eine Herausforderung , diese letztlich doch immer wieder zu identifizieren. Lange habe ich mich gefragt, wann ist ein Impediment wirklich ein Impediment und wann nur eine Kleinigkeit? Letztlich habe ich für mich und meine Arbeit herausgefunden, dass tatsächlich alles, was das Team davon abhält produktiv zu sein, ein Impediment darstellt. Und sei es nur die defekte Schreibtischlampe, deren Neubeschaffung in großen Konzernen leider Tage und zig Unterschriften bei Einkauf, Management etc. in Anspruch nimmt.
Also arbeite ich nach dem Motto: “Nichts ist zu klein, um ein Impediment zu sein.”

Sonntagsbrunch – Done ;-)

Da ich die Woche über unterwegs bin, verpasse ich leider ständig die wöchentliche Dinnerrunde mit Freunden. Dem wollte ich mit einem sonntäglichen Brunch entgegenwirken. Eine gute Idee, wie ich fand… bis Samstag Nacht, als es dann doch etwas später wurde.
Zwar hatte sich freundlicherweise jeder dazu commited etwas mitzubringen, aber ich hatte mir dennoch ein paar besondere Schmankerln vorgenommen, die ich meinen Gästen anbieten wollte. Jedes Schmankerl extra bedeutete allerdings früher aufstehen (traurig)
Da ich weiß, dass ich morgens noch nicht 100% zurechnungsfähig bin, bereitete ich mir noch abends ein Taskboard mit den Aufgaben vor, die ich nur am nächsten Morgen erledigen konnte…

sauber priorisiert, was die ersten Gäste an der doch recht spärlichen Deko erkennen konnten. Da jedoch für alle am Kühlschrank erkennbar war, dass ich nicht mehr dazu gekommen war, konnten auf Wunsch eines Gastes gezielt ein paar Kerzen aufgestellt werden – schnell gemacht, User mit einbezogen und doch noch alles auf DONE!
Obwohl ich recht früh aufgestanden war, hätte ich es alleine nicht geschafft. Umso besser, dass ich nicht auch noch schlaftrunken meine Vorstellungen erklären musste, sondern diese bereits auf den Post-Its am Kühlschrank hingen. Mit kleineren Nachfragen konnte ich dann gerade noch umgehen bzw. mich nur noch freuen, als die tatsächliche Durchführung und Ausgestaltung dann auch noch meine Vorstellungen und eigenen Fähigkeiten bei Weitem übertrafen.
Wenn jetzt jemand meint, ich würde unter einer Berufskrankheit leiden, der sollte sich mal das Video von Bruce Feiler (http://www.ted.com/talks/bruce_feiler_agile_programming_for_your_family.html) angucken. Ich finde, es macht Spaß, die kleinen Hilfsmittel in den Alltag zu integrieren, oder kann mir durchaus vorstellen, dass, wie von Feiler beschrieben, auch Kinder und Eltern ihre Freude an der Selbstorganisation haben. Zumindest beschreibt er sehr plastisch, wie chaotische Morgen auch reibungslos ablaufen können und Feiertage mit Familiendinner in Harmonie verbracht werden können. Außerdem beschreibt er an der eigenen Familie, was für einen Effekt Retros haben können: Kinder selbst kreieren die besten Ideen für die Verbesserungen – nicht etwa aus Ratgeber-Büchern oder durch die allwissenden Eltern!!!
Sein agiles Familien-Manifesto:

Mir fallen noch einige weitere Beispiele ein, aber vielmehr interessiert mich: Was habt ihr schon versucht?

Scheitern und der Umgang damit

Auf dem Weg vom Hotel zur Arbeit sehe ich ihn. Er läuft nicht weit vor mir, zwanzig oder dreißig Meter. Er ist älter, um die fünfzig. Sein Gang schwankt, er läuft leicht gekrümmt. Ich habe es eilig, der Termin fängt in zehn Minuten an. Ich kenne den Mann von der Arbeit. Ich mag ihn. Wenn ich ihn jetzt überhole, dann muss ich zumindest ein paar Worte wechseln. Ich kann nicht einfach an ihm vorbeilaufen. Aber zögerlich darf ich auch nicht sein. Der Termin ist wichtig.
Ich nehme Tempo auf. Die Sonne scheint, am Himmel hängen vereinzelte Wölkchen. Die Luft steht still. Es riecht nach Frühling. Eltern bringen ihre Kinder in die Schule. Eine Frau dreht mit ihrem riesigen Hund eine Runde vor dem Haus.
Jetzt nicht zu schnell laufen. Ich will nicht gehetzt wirken. Lange, feste Schritte. Die Schuhe schlagen fest auf dem Bordstein auf. Ich komme dem Mann gleich näher. Ich komme dem Mann gleich näher. Ich komme dem Mann gleich näher.
Ich lege einen Gang zu. Und überlege, was ich dem Mann sage, welche Worte ich wählen soll, wenn ich ihn erreiche. Etwa: “Du hast ja ein Tempo drauf, ich musste eben in den höchsten Gang schalten!”
Er bewegt sich. Ich bewege mich. Aber wirklich nahe bin ich immer noch nicht. Ich denke mir: “So langsam ist der ja gar nicht unterwegs. Wenn ich ihn erreicht habe, kann ich sogar ein Stück mitlaufen. Den Termin schaffe ich auch so.”
Er erreicht die Straße und überquert sie diagonal. Als ich dort ankomme, ist er schon bei der Fußgängerampel, die gerade auf Grün schaltet. Meine Schritte werden schneller, mir wird warm. Ich muss nach Luft schnappen. Dann springt die Ampel auf Rot und der Mann ist um die Ecke verschwunden. Ich sehe ihn nicht mehr.
Für den Rest des Tages bin ich vorsichtiger unterwegs. Ich versuche, weniger zu unterstellen, weniger zu bewerten. Denn ich habe mich überschätzt, bin an meinen Ansprüchen gescheitert: Auf dem Weg zur Arbeit dachte ich, dass meine Kondition zehnmal reichen müsste, um einen zwanzig Jahre älteren Kollegen zu überholen. Deshalb bin ich die Herausforderung auch so locker angegangen, um dann zu merken: Verdammt, du schaffst es doch nicht.
Wie oft passiert uns so etwas? Wir haben eine klare Soll-Vorstellung: Über uns selber, unsere Familien, unsere Freunde, unsere Arbeitskollegen, unsere Projekte. So möchten wir sein, das möchten wir erreichen, dort sehen wir uns in ein, zwei Jahren. Dummerweise kommt es eher selten genau so, wie wir uns das gedacht haben. Das Leben steckt voller Enttäuschungen. Es gibt diverse Möglichkeiten, damit umzugehen. Aber die schönste ist für mich der Humor.
Ich habe eine ScrumMasterin gekannt, die das große Talent hatte, ihrem Team genau im richtigen Augenblick den Spiegel vor das Gesicht zu halten. In einer völlig verkorksten Situation am Ende eines schlechten Sprints, in der es vor Frust und Aggression nur so qualmte, konnte eine einzige Bemerkung von ihr die gesamte Szenerie entschärfen und gestandene Entwickler zum Grinsen bringen.
Humor ist damit auch eine Form der Selbsterkenntnis: Ja, ich bin mit meinen Plänen gescheitert. Ja, ich habe mein Ziel nicht erreicht. Und trotzdem kann ich mich darüber erheben, Distanz dazu gewinnen, es mit einem Lächeln kleinschrumpfen, und damit meine Energie zum Aufstehen und Weitermachen frei schaufeln. Diese Fähigkeit – sie ist Gold wert.
[quote author = “Oscar Wilde auf seinem Sterbebett”]”This wallpaper is atrocious. One of us has to go.”[/quote]



Wie viel Standing braucht ein ScrumMaster?

Der Stare down, das Blickduell, ein spektakuläres Ritual. Zwei Boxer stehen sich Tage vor ihrem Kampf für ein paar Augenblicke gegenüber. Auge um Auge. Kein Ausweichen. Elektrisierende Spannung. Regloses Anstarren, keine Miene verziehen. Wer den Blick senkt, hat sich eine Blöße gegeben und gilt als der Schwächere. Über dem anderen stehen, ihn im Status überragen, ihm zu verstehen geben, dass man überlegen, besser, mehr ist und bereit, den Kampf jederzeit aufzunehmen.
 
Das Thema “Status” (= Stand, Stellung in einer Gruppe oder Gesellschaft) und im wahrsten Sinne des Wortes seinen Mann oder seine Frau stehen, spielt ähnlich wie in dem Beispiel oben auch im beruflichen Alltag eine tragende Rolle. Fragen wie “Wer steht über wem?”, “Wie viel bin ich, wenn ich wie viel Menschen führe oder plötzlich nur noch halb so viele?”, “Hab ich einen eigenen Firmenparkplatz?”, “Ist mein Bürostuhl in meinem Einzelbüro mit Lehne ausgestattet oder noch ohne?” Petra Klapps umschreibt “Status” in ihrem Buch Das Kolibri-Prinzip – leicht und spielerisch Ressourcen stärken als “soziales Niveau. Das ist die Art und Weise, in der wir unseren eigenen Wert zu anderen Menschen in Beziehung setzen. Status ist immer von Werten und Spielregeln einer Gruppe oder einer Kultur abhängig. Nicht nur im Berufsleben, auch im Alltag stellen wir zu Menschen unbewusst oder auch sehr gezielt ein Statusverhältnis her. Dieses Verhältnis beeinflusst gravierend, wie wir (…) uns zueinander verhalten. Wir platzieren uns ständig auf einer Werteskala im Verhältnis zu unserer Umgebung. Wir nehmen keinen festen Platz ein auf dieser Werteskala, sondern wir wechseln unseren Status und unser Sozialverhalten (…). Jeder Mensch verhält sich anderen Leuten gegenüber entsprechend seinem eigenen Status. Wir signalisieren die ganze Zeit über unseren Platz in der Hierarchie, indem wir anderen gegenüber einen höheren oder einen niedrigeren Status einnehmen” (a.a.O., S. 136). Klapps postuliert, dass beinahe jede Kommunikation mit unserem Gegenüber etwas mit Konkurrenz zu tun hat und der Klärung der Frage, die einem (Status-)Kampf gleich kommt: Wer wird wen verändern?

Verhaltensweisen, die Status sichtbar machen können – ein Must für gute ScrumMaster

Ich halte es für eine herausragende Fähigkeit, Statusverhalten wahrzunehmen. Gerade ScrumMaster in ihrer besonderen Rolle als Servant Leader, als Führungskraft ohne Anspruch auf Autorität, brauchen hierfür äußerst sensible Antennen. Wie wirke ich in der Rolle als ScrumMaster? Wie sehen mich andere? Was verschafft mir meinen Status im Team, gegenüber anderen ScrumMastern, gegenüber dem Linienmanagement? Es gibt eine Vielzahl von Informationsquellen, die sich ein ScrumMaster zunutze machen kann, wenn er herausfinden möchte, welchen Status er in einer Interaktion gerade einnimmt. Dazu sollte er den Fokus seiner Wahrnehmung in erster Linie auf sich richten und überprüfen, was seinen Status wirklich ausmacht. Alles hat und zeigt eine Wirkung und kommt beim Gegenüber an.
 
So logisch das klingt, so wichtig ist es, es sich bewusst zu machen. Dabei geht es auch weniger darum, ob man mit seinen Verhaltensweisen richtig liegt. In erster Linie zählt die Selbstwahrnehmung und die mögliche Wirkung auf andere. Ich verstehe dabei insbesondere die Wahrnehmung des eigenen Handelns als echten Quantensprung. Wie ist mein Gang? Wer berührt wen (Körpernähe – oftmals ist nur der Person mit dem höheren Status gestattet, berühren zu dürfen)? Wer nimmt mehr Raum ein (Sitzposition, Redeanteil, etc.)? Wie wird mit dem Thema Zeit verfahren (wer lässt wen warten, werde Zeiten eingehalten, wer überschreitet die Timebox)? Wie ist der Tonfall in einem Gespräch, wie ist die Wortwahl, gibt es Unterbrechungen und wer unterbricht wen? Wie stehe ich im Raum (über anderen, weit entfernt)?
Wie ist nun mein Standing im Team? Welchen Status genieße ich als ScrumMaster? Informationen gewinnt man darüber am besten, indem man konsequent und ehrlich hinterfragt, mit welcher Haltung man anderen Menschen begegnet und wie die Art und Weise von Kommunikation gesehen wird. Man unterschiedet hierbei

  • einen positiven/natürlichen Hochstatus, mit dem man Begriffe verbindet wie Freundlichkeit, Klarheit, Einfühlvermögen, Bescheidenheit, Kompetenz, Vertrauenswürdigkeit oder Geduld. Vereinen sich viele dieser Attribute in der inneren Haltung und der Art und Weise der Kommunikation, dann wird diesen Menschen oftmals Anerkennung, Wertschätzung und Respekt von ihren Interaktionspartnern entgegen gebracht.
  • einen negativen Hochstatus, mit dem man Attribute wie Egoismus, Eitelkeit, Arroganz, Ungeduld oder Launenhaftigkeit verknüpft, erzeugen eher Widerwillen und (versteckte) Aggressionen beim Gegenüber.
  • einen positiven Niedrigstatus, der sich in Hilfsbereitschaft, Flexibilität, Zuverlässigkeit oder Kreativität wiederfindet oder
  • einen negativen Niedrigstatus, der das Ergebnis von Unzuverlässigkeit, Gleichgültigkeit, Widerwillen, Unnachgiebigkeit oder Sturheit ist.

Natürlich stehen diese vier Statuserläuterungen und die beschrieben Typologien nicht für stereotype Definitionen und kommen darüber hinaus fast immer in Mischformen vor bzw. sind ebenso situationsabhängig. Es sind dennoch Orientierungspunkte, die eine Idee vermitteln sollen, welchen Einfluss Verhalten auf den Status innerhalb einer Gruppe, einem Team haben kann. Wer nun einen Vorgeschmack darüber erhalten möchte, welches Standing Teammitglieder untereinander oder aber ein ScrumMaster im Team hat, vielleicht auch, welches Standing man selbst genießt, dem empfehle ich als Startpunkt die nachfolgende Übung.
 

Wie ist mein Standing? 

Teilnehmerzahl: je mehr umso besser
Vorbereitung: Es braucht eine kleine Freifläche, die als Bühne genutzt werden kann. In der Mitte der Bühne wird ein X auf dem Boden markiert. Alle Teilnehmer sitzen mit Blick zur Bühne (Kinobestuhlung). Neben der “Bühne” ist eine Sitzgelegenheit (Warteposition). Darüber hinaus braucht es einen Moderator.
Material: Kreppband für Markierung, Kinobestuhlung
Ziel: Die Teilnehmer
 
Ablauf: Der erste Teilnehmer betritt die Bühne und nimmt auf dem Stuhl neben der Bühne (Warteposition) Platz. Wenn er/sie für sich selbst entschieden hat, bereit zu sein, tritt der Teilnehmer auf die Bühne und stellt sich auf das markierte X. Er nimmt mit seinem Blick Kontakt zum Publikum auf und steht dort solange bis der Moderator nach 30 bis 40 Sekunden zu dem Teilnehmer gewandt sagt: “Ja, bitte?” Der Teilnehmer nennt seinen Namen. Im Anschluss daran applaudiert das Publikum und der Teilnehmer nimmt wieder auf dem Stuhl neben der Bühne Platz.
Das Publikum gibt dem Teilnehmer zu seinem Auftritt bzw. “Standing” Feedback. Das Feedback sollte wertschätzend sein und keine Negationen enthalten (z.B. du sollst nicht mehr). Sprecht euer Feedback in Ich-Form aus (z.B. ich habe beobachtet/wahrgenommen, dass…).
 

Das Wichtigste kommt meist zu kurz: das Debriefing in sechs Schritten

Die Übung soll natürlich nicht für sich alleine stehen, sondern einen gewinnbringenden Abschluss haben. Auf der Bühne stehen ist das eine, ein Feedback erhalten inkl. Debriefing das andere und ebenso Wichtige (= die gemeinsame Beschreibung der Erfahrungen, die das Team in der Übung gemacht hat. Dies beinhaltet ebenso die Auseinandersetzung mit deren Gedanken, Gefühlen und Reflexionen zur Umsetzung ins Business). Häufig kommt genau das in Übungen viel zu kurz. Eine Übung sollte nie für sich alleine stehen.
 
Eine gute Struktur für ein aufschlussreiches Debriefing kann so aussehen:
 
Schritt 1: Wie hast du dich gefühlt? (Beschreibung der Emotionen während der Übung. Es wird deutlich, wie unterschiedlich die gleiche Situation empfunden und/oder bewertet werden kann)
Schritt 2: Was ist geschehen? (Austausch von Wahrnehmungen und Beobachtungen)
Schritt 3: Was hast du gelernt? (Identifikation der Erkenntnisse und Schlussfolgerungen)
Schritt 4: Wie hängen die Übung und die Realität zusammen? (Transfer zwischen Übung und Realität. Achtung! Unterscheidung, ob das Verhalten aus der Übung zufällig oder einmalig war oder in Beziehung zur Realität und dortigen Handlungsmustern steht)
Schritt 5: Was wäre gewesen, wenn? (hypothetische Szenarien – optionaler Schritt: Spekulation über hypothetische Szenarien)
Schritt 6: Wie geht es nun weiter und was mache ich mit den neuen Erkenntnissen? (Festlegung von eindeutigen, machbaren, messbaren Zielen und Maßnahmen für das zukünftige Verhalten inkl. Mechanismen für Feedback und/oder Follow ups)
 
Viel Spaß beim Ausprobieren. Eure Kommentare zum “Standing”, wenn ihr euch mal in eurem Team ausprobiert habt, würden mich brennend interessieren.
 
 
Literatur
Klapps, P. (2012). Das Kolibri-Prinzip. Leicht & spielerisch Ressourcen stärken. Kreuz

How internationally distributed Teams can improve their Sprint Planning 2

Interview with the bor!sgloger expert panel on the subject of internationally distributed Teams (Part 7)
Part 1: Does distance cancel out efficiency of internationally dispersed Teams?
Part 2: Should internationally distributed Teams be avoided?
Part 3: Scrum Spaces of internationally distributed Teams – the Do’s and Don’ts
Part 4: The Pros and Cons of Electronic and/or Physical Taskboards
Part 5: How internationally distributed Teams can improve their Daily Scrum
Part 6: How internationally distributed Teams can improve their Sprint Planning 1
Stephanie G.: Having discussed Sprint Planning 1, let us continue with your tipps & tricks for Sprint Planning 2. How would you conduct this design meeting?
Ina K.: I would actually say that it‘s quite similar to Sprint Planning 1, apart from the Product Owner not being present. Sometimes the meeting is off to a slow start. If that‘s the case, the ScrumMaster should get involved and start filming people (see Christof’s answer in How internationally distributed Teams can improve their Sprint Planning 1) as well as make sure that the Team members who document the meeting rotate. Once the Team members properly get going, the ScrumMaster can retreat  and remain in a position of observation. Watch the Team – are they interacting enough? Do they seem to have a common understanding? Is everyone adding to the conversation? It‘s important to keep an eye out for such things, as the DevTeam members usually don‘t. Once they actually start looking out for it by themselves, the ScrumMaster has achieved wonders.
Hélène V.: The most important aspect of Sprint Planning 2 is that the common design solution that the Team has agreed upon is visualized and can be seen by all Team members. Only if this has happened, can the distributing of Tasks on a cross-location basis begin. Some Teams think that they do not need any visualisation … all I can say is that distributed Teams who believe this myth have a much higher chance of forgetting important aspects to their design.
Kristina K.: My Team had this issue. The fact that they typed up the Tasks into an electronic tool didn‘t help either, since it sometimes seemed that only the one who did the typing also did the thinking. The fact that the know-how was so unevenly distributed was an impediment in Sprint Planning 2, too. The lack of drawing meant that there was no real common Team understanding of the design – they didn‘t talk about how to implement the User Stories, but rather talked about what singular steps were necessary to implement them.
Bernd K.: We didn‘t really have what you can call a design session either. Sometimes the Team members used the flip charts for drawing, but then I had to take a picture (since the quality of our webcam was not good enough) and send it to the other Team members. This alone would take 5 minutes, by which time the moment for entering in the design discussion was over.
Generally, I did not enjoy Sprint Planning 2 – it often stretched out over three to four hours, which is two hours longer than a Sprint Planning for a two-week sprint should be. The problem was that our electronic tool did not have a word limit for Tasks, meaning that the Team often spent ages on writing them. This did not help to bridge the geographical gap either: the Team members in Romania were rather pragmatic, while the ones in Germany could be called the „philosophers“ – wishing to specify their Tasks and over-thinking the why what, when and where. While the Team dynamic of a co-located Team would have quickly eliminated this discrepancy with smiles or a nervous look, the Romanians were hidden behind a microphone and nobody knew what they were thinking.
Kristina K.: Oh dear, that sounds quite irritating. What I started implementing after a while was to ask the various locations to prepare several design options and to then challenge each other during Sprint Planning 2. In the end, we used the best idea out of all of them and wrote Tasks for it. This ensured that everyone on the Team had actually thought about the Stories, even if they‘re no expert.
Hélène V.: Yes, that‘s what I would recommend, too. After Sprint Planning 1, the Team should do a short mapping of the areas and topics that need discussing. You could then divide up the topics for each location i.e. location A takes the module on the database approach, location B focusses on another solution etc.
Christof B.: I agree with both of you, but I think that the decision of splitting up a Team for or in preparation of Sprint Planning 2 really depends on the Team constellation. If all roles are represented at all locations, I do think that the Sprint Planning 2 can be conducted as group work – meaning that each location grabs its own User Story, does its own mini-Sprint Planning 2 and then presents it to the rest of the Team after 30 minutes. After reviewing the outcome, the entire Team writes the Tasks together. However, this is only possible if both front-end and back-end are present at all locations. This option is not possible if i.e. testers and developers are in different locations.
Stephanie G.: It is so interesting that you all recommend splitting up the meeting, since I actually used to do the same. Only I did not split it in the way of one Story in each location, but rather one person from each location formed a Team, which would together work on one Story (see Pre-SP2 Design Sessions or How to use your Time during a Sprint Change?).
Christof B.: Sprint Planning 2 should not be underestimated. It is certainly not trivial, as it can be chaotic due to the necessary interaction between the Team members. After all, it is not only a meeting, but a creative process, design thinking, architectural brain-storming etc. A lot happens during SP2. I don‘t believe that its doable over the phone. It‘s even nearly impossible to do via video conference. I really think it‘s best if each location works on its own concept during Sprint Planning 2, which is only interrupted by SoS-like coordination meetings where the whole Team gets together again. For example, a design session for 30-45 minutes, followed by 10-15mins of presentation by each location including feedback.
Deborah W.: Funny. I never had any difficulties with Sprint Planning 2, meaning that I could always really enjoy this meeting. I thought it was one of the simpler ones when dealing with distributed Teams. Maybe it was an exception, but my Team members got really involved – even across locations. It was easier than SP1, since there was always less to show. Yes, we did draw a few diagrams and design the architecture, but not for too long. The topic was pretty clear to everyone, so the meeting was concise and short.
Stephanie G.: I love it when opinions diverge as much as yours right now. So before you all get jealous of Deborah‘s Team, let me quickly sum up the main points of advice:

 

Mr. Change, könnten Sie meine Gefühle bitte etwas weniger aufwirbeln?!

Liebe alle Scrum Coaches da draußen,
geht es euch auch wie mir?!
Ich sitze im Zug nachhause nach einer gefühlt sehr langen Woche beim Kunden und bin mental sowie physisch komplett erschöpft. Ich habe das Gefühl, dass in diesem Business kein Tag dem anderen gleicht. Wenn ein Tag ohne größere Ereignisse abläuft, kann ich garantieren, dass der Schein trügt. Denn hinter der nächsten Ecke lauert schon irgendetwas, das einen in hochjauchzendes Lachen versetzen bzw. zu Tode betrübt zu Boden werfen möchte.
Anfangs dachte ich mir, das läge an mir. An der Macht meiner Stimmungen. An Unsicherheiten. An Charaktereigenschaften. Mehr und mehr jedoch merke ich, dass diese Belastung nicht nur von mir aus kommt. Selbst Angestellte in der Organisation, die ich berate, haben mir von ihren persönlichen und täglichen Achterbahnen der Gefühle berichtet. Erst da habe ich realisiert, dass dieser Zustand keine Beraterkrankheit ist. Nein. Es ist ganz einfach der Cocktail der Gefühle, der in jedem Unternehmen gemixt werden kann und wird, das eine umfassende Veränderung durchführt. Und auf einen Scrum Consultant wird jede dieser Emotionen direkt abgeladen. Hier. Bitte. Danke. Jetzt schau, wie du damit umgehst. Na servus.
Es hat eine Weile gebraucht, doch mittlerweile weiß ich, wie ich mit dieser oft ungewollten Ladung umgehe. Ganz einfach. Ich mache jeden einzelnen Abend eine persönliche Retrospektive. Was ist heute passiert? Was habe ich heute gut gemacht?! Was könnte ich verbessern?! Wie werde ich das nutzen, um mich zu verbessern?! Sich ein paar Minuten Zeit zu nehmen, um diese tägliche Übung durchzuführen, kann ich jedem nur wärmstens empfehlen. Man muss es ja nicht unbedingt auf Flipcharts und mit Post-Its machen…ein einfaches Revue-Passieren lassen und persönliches Brainstorming im Zug bzw. auf dem Rad nach Hause reicht auch oft aus.
Genau so eine Retrospektive habe ich soeben abgehalten. Jetzt erkenne ich auch, dass egal wie k.o. ich mich jetzt fühle, es eine tolle Woche war. Woran ich erkenne, dass sie toll war?! Daran, dass ich wahnsinnig viel gelernt habe und konstruktives Feedback erhalten habe. Jetzt kann ich mich weiterentwickeln – hin zu einem besseren Consultant, einem besseren Scrum Coach, einem besseren Menschen. Das hätte ich ohne diese emotionalisierenden Momente nicht geschafft.
Ich wünsche noch ein schönes Wochenende,
Eure Stephy

GUTEN RUTSCH ins Jahr 2013!

Das Jahr neigt sich dem Ende zu. Zum Jahreswechsel heißt es noch mal zurück zu blicken und sich zu erinnern, an Gelerntes, an Gelesenes, an Gesehenes. Mit meinem ganz persönlichen GUTEN RUTSCH möchte ich mit euch einige meiner Highlights aus 2012 teilen, weil sie mich in meinem agilen Tun geführt, begleitet, inspiriert, berührt oder nachdenklich gemacht haben.

G wie “Gloger”. Boris Gloger und seine Co-Autoren Andreas Opelt, Wolfgang Pfarl und Ralf Mittermayr haben es mit ihrem neuen Buch „Der Agile Festpreis“ geschafft, eine Wissenslücke auf dem IT-Markt zu schließen. Sie schenken IT-Projekten auf der Grundlage agiler Festpreisverträge die verdiente Aufmerksamkeit und setzen dabei das Mindset von Scrum bildhaft, kompetent und kompromisslos fort: anders denken, anders handeln. Ab 20. Mai 2013 auch auf Englisch, erscheint bei John Wiley & Sons.

U wie “User Stories”. Mike Cohns „Suceeding with Agile“ gehört aus meiner Sicht zu den Top 5 in der Scrum-Literatur. Mit seinem Buch „User Stories für die agile Software-Entwicklung mit Scrum, XP u.a.“ reicht es eher zu einer Art Ergänzungswerk. Das soll die Qualität dieses Buchs nicht schmälern. In meiner Bücherliste taucht es aber eher auf, weil „User Stories“ eine zweite (bestätigende) Meinung bietet. Ich würde es aber tatsächlich eher als Sekundärliteratur sehen, als Ergänzung für die ganz Fleißigen.

T wie “The Innovator`s Dilemma”. Drei absolute Schwergewichte der Managementlehre, Clayton M. Christensen (Harvard Business School), Kurt Matzler (Universität Innsbruck) und Stephan F. von den Eichen (Managementberatung IMP) widmen sich einem der spannendsten und zugleich schwierigsten Handlungsfelder im heutigen Management: der Innovation. Warum scheitern führende Unternehmen, obwohl sie offensichtlich alles richtig machen? Was unterscheidet evolutionäre von disruptiven Innovationen? Ich empfehle „The Innovator`s Dilemma“ jedem, der mit Produktentwicklung zu tun hat. An anschaulichen Beispielen aus unterschiedlichen Branchen wird das unlogische Verhalten disruptiver Innovation entschlüsselt und gibt dabei Unternehmern Orientierung auf neuen, unvermeidbaren Wegen.
E wie “Estimating”. Übers Schätzen wurde auch 2012 wieder hinlänglich debattiert, diskutiert und philosophiert. Am Ende des Jahres bleibt, was am Anfang auch schon feststand: wir können keine Aufwände schätzen. Wir können es schlichtweg nicht. Darin sind wir schlecht. Meine Empfehlungen lauten daher: reduce your batch size, keep it simple stupid, frage deinen Bauch und dann schätze Funktionsumfänge. Es geht viel leichter, schneller, freudvoller und mindestens genauso „korrekt“ wie die Schätzung nach einem … Nein, ich schreibe das Wort nicht mehr! Lest nochmal die Blogs von Kristina und Sven zu diesem Thema: Ich schätze was, das du nicht schätzst und Flighty Estimation.

N wie Nonaka und Takeuchi. Innovation ist in aller Munde. Bevor man jedoch innovativ tätig werden kann, braucht es das dafür nötige Wissen, um es zu seinem eigenen (Wettbewerbs-)Vorteil nutzen zu können. Während die Ressource Wissen in der westlichen Welt lediglich zur Informationsverarbeitung genutzt wird (Verbreitung von Daten und Informationen, also explizites Wissen), stellt das Werk „Die Organisation des Wissens“ von Nonaka und Takeuchi den japanischen Ansatz der Wissensschaffung vor. Der japanische Ansatz verfolgt die Idee, vor allem das implizite Wissen jedes Mitarbeiters für alle anderen zugänglich zu machen. Dies geschieht unter anderem dadurch, dass ein Unternehmen, in dem Wissen implizit (in jedem Einzelnen) zugrunde liegt, als lebender Organismus (ganzheitlich) betrachtet wird. Innovation geht nun mal nicht ohne Wissen – nachzulesen auf über 300 lohnenswerten Seiten.

R wie “Radikal führen”. Nach seinem Bestseller „Mythos Motivation – Wege aus einer Sackgasse“ ist Reinhard K. Sprenger mit „Radikal führen“ erneut ein Durchbruch der inhaltlichen Schallmauer gelungen. Statt eines gelangweilten Stöhnens, weil mal wieder ein Buch über Führung geschrieben wurde, ist es eher ein demütiges Innehalten (was tue ich) und ungeduldiges Weiterlesen (was kann ich dagegen unternehmen, was ich bisher getan habe), das auf euch wartet. Sprenger geht, wie das Wort „radikal“ schon sagt, zur Wurzel, dem Ursprung von Führung zurück und blickt in fünf Kapiteln (Zusammenarbeit organisieren, Transaktionskosten senken, Konflikte entscheiden, Zukunftsfähigkeit sichern und Mitarbeiter führen) auf die tatsächlich zu erledigende Arbeit eines (erfolgreichen) Managers von heute. Bitte lesen – ganz egal, ob ihr schon agil unterwegs seid oder euch erst auf den Weg macht.

U wie “Unfair Game”. Erzählt wird im Film „Moneyball“ von Billy Beane (gespielt von Brad Pitt), dem als aktiven Baseballspieler gescheiterten General Manager des Major Baseball Association-Teams der Oakland A`s. Beanes Team gehört zu den Teams in der Liga, die mit einem niedrigen Jahresetat ausgestattet sind: mittelklassige bis eher schlechte Spieler und die wenigen guten (teuren) Spieler werden von den reichen Teams gekauft. Moneyball gehört aus mindestens fünf Gründen zu meinen Highlights 2012 und wird dadurch zu einem Must-read/Must-watch für jeden, der bereits agil denkt oder 2013 noch vorhat, agiler zu werden:

  1. Neue Perspektiven erschaffen ungeahnte Denkwelten.
  2. Anders Denken bedeutet, zu einer Bedrohung der alten Werte zu werden und geächtet zu sein.
  3. Mut, Offenheit und Leidenschaft als gelebte Werte können Berge versetzen.
  4. Mit Geld kann man nicht alles kaufen.
  5. Nicht (nur) die besten Spieler machen Erfolg aus, sondern das System mit den dafür richtigen Spielern.

Lasst euch überraschen und schaut den Film mit euren Scrum-Teams. Absolut sehenswert!
T wie “Two” oder zweimal T. Während ich jedem ScrumMaster (und agilem Manager) Daniel Mezicks „The Culture Game“  ans Herz lege, empfehle ich allen Product Ownern „The Principles of Product Development – Flow. 2nd Generation Lean Product Development“. Mezick geht dem Heiligen Gral der Agilität auf den Grund: der Lernenden Organisation. In 16 Praktiken und Mustern sieht er einen Erfolg versprechenden Weg hin zum Tribal Learning. Donald G. Reinertsen, dessen Training ich 2012 besuchen durfte, bringt uns durch seine ganz eigene Umschreibung eines Flows die Produktentwicklung näher. Wer ein Faible für Mathematik und kleine Experimente hat und als Produktmanager oder Product Owner Herr seiner Ladeliste werden will, der möge sich schnellstens mit diesem Buch bewaffnen – etwas spröde im Abgang, aber der Inhalt ist äußerst wertvoll.
S wie “Scrum. Produkte schnell und zuverlässig entwickeln”. Dieses Buch gehört in jedes agile Bücherregal und sollte an wirklich jeden Projektmanager weitergegeben werden. Ein Muss für den Agile Leader von gestern, heute und morgen. Die 4., überarbeitete Auflage erscheint übrigens am 17. Jänner 2013.
C wie “Certainty”. Certainty heißt übersetzt Sicherheit oder in diesem Fall vielmehr Gewissheit. Gewissheit ist eine von fünf sozialen Dimensionen, die unser Handeln kontrolliert, indem sie entweder eine negative (Gefühl von Bestrafung) oder eine positive (Gefühl von Belohnung) Reaktion im Gehirn hervorruft. Die Dimensionen S wie Status, A wie Autonomy, R wie Relatedness und F wie Fairness ergeben das Akronym SCARF. Das von David Rock stammende SCARF-Modell gibt meines Erachtens eine vollkommen neue Perspektive auf das Verhalten von Menschen und ihren Wunsch, es ändern, anpassen oder verbessern zu wollen – insbesondere in der Mitarbeiterführung. David Rocks „Your Brain at Work“ ist nicht nur deshalb ein wirklicher Hingucker.
H wie Heath & Heath. Mit „Switch – how to change things when change is hard“ machen die beiden Brüder Dan und Chip Heath Lust auf Veränderung – Veränderung an uns, an anderen, an Unternehmen – nicht zuletzt, weil Veränderungen immer einem gemeinsamen Muster folgen. Die zwei Autoren verwenden anschauliche Beispiele, die sie entlang von drei Metaphern untersuchen: Der Elefant steht für die Macht der Gewohnheit, der Reiter versucht den Elefanten zu steuern und den Weg, den sich der faule Elefant oft einfach trampelt, um weiterhin seinen alten und tradierten Gewohnheiten nachgehen zu können. Der Reiter hingegen möchte ihn gangbar machen, um seine Ziele zu erreichen. Heath & Heath laden dazu ein, die Veränderungen am eigenen Leib auszuprobieren. Ein Geheimtipp für Berater auf der ganzen Welt, um langweilige Zugfahrten zu verkürzen, unnötige Wartezeiten an Flughäfen sinnvoll werden zu lassen oder einsame Abende in tristen Hotelzimmern zu einem echten Event zu machen. Inspirierende Lektüre von Anfang bis Ende.
Einen GUTEN RUTSCH ins Jahr 2013 für euch alle und eure Liebsten. Bin schon gespannt, was dort auf uns wartet.

Das Ideenkorbprinzip: Schnelle Problemlösungen im Team, die Spaß machen!

Eine Alltagssituation in der Teamarbeit. “Ich habe da mal ein Problem/eine Frage und brauche kurz eure Hilfe.” Schnell wird das Problem oder die Fragestellung in der Gruppe hin und her diskutiert. Lösungen werden vorgeschlagen, Tipps und Ratschläge gegeben, wieder verworfen, jeder meint es ja nur gut. Der Fragesteller gerät irgendwie plötzlich in den Hintergrund, ja manchmal regelrecht ins Abseits, weil heftig um richtig oder falsch debattiert wird. Jeder nimmt sich und seinen Vorschlag besonders wichtig und ist überzeugt, dass nur mit seiner Lösung dem Kollegen geholfen ist. Der wollte eigentlich nur einige Ideen und gar keine Ratschläge, die ja manchmal auch „Schläge“ sein können. Die Zeit vergeht, man kommt nicht so recht weiter, Frust oder gar Ärger machen sich breit.
Eine Möglichkeit, solche oft wenig funktionalen Debatten zu vermeiden, ist das Vorgehen nach dem Ideenkorbprinzip zur kollegialen Problemlösung. Dieses kollektive Problemlösungsverfahren ist sowohl eine Methode als auch eine Grundhaltung. Er bietet methodisch ein ressourcenfokussiertes Vorgehensmodell, das nach dem sogenannten “Hebammenprinzip” funktioniert. Die Hebamme ist die entsprechende Metapher für die Haltung der Teilnehmer zur Realisierung des Ideenkorbs. Die Mutter, nicht die Hebamme bringt ja das Kind zur Welt. Letztere bringt ihr Know-how und ihre Unterstützung als Dienstleistung ein. Der Ideenkorb gibt eine klare Ablaufstruktur vor und wirkt über einfache Regeln und Rollen. Er bietet sich immer dann an, wenn ein Einzelner eine Problemfrage an eine Gruppe oder ein Team hat und sozusagen “Hebammen” für seine schnelle Problemlösung braucht.

Die Rollen im Ideenkorb

  1. Die Hauptperson informiert die anderen über das Problem/Thema und liefert den anderen die notwendigen Informationen für das Verständnis der Problemlage.
  2. Die Helfer agieren als “Hebammen” und liefern ihr Know-how als Ideen und Lösungsvorschläge in den imaginären “Ideenkorb”.
  3. Bei Bedarf kann ein Visualisierer unterstützen und der Prozess kann durch eine Zeitvorgabe reguliert werden.

Der Ablaufprozess

  1. Die Hauptperson bringt ihr Thema möglichst präzise und ausführlich ein.
  2. Die Helfer stellen (bei Bedarf) gezielte Informationsfragen zum noch genaueren Verständnis und halten sich an dieser Stelle  mit Ideen oder Vorschlägen noch bewusst zurück.
  3. Die Helfer liefern nun im spontanen Brainstorming Ideen und Lösungsvorschläge für die Hauptperson. Diese sollte sich in dieser Phase möglichst zurückhalten, um den Kreativprozess nicht zu stören. Grundsätzlich sollten hier Bewertung, Kritik und Diskussionen keinen Platz haben. Ebenso gilt erst mal das Prinzip “Quantität vor Qualität”. Hier ist es oft sinnvoll, die Ergebnisse des Brainstormings zu visualisieren, wenn das entsprechende Equipment vorhanden ist.
  4. Die Hauptperson wählt nun die für sie passende Idee/Lösung aus. Sie alleine entscheidet, was sie brauchen kann. Die üblichen “Für und wider Debatten” sind nicht nötig und damit unbedingt zu vermeiden.
  5. Evtl. kann zum Abschluss noch über mögliche Maßnahmen zu Umsetzung der Lösung reflektiert werden, wenn die Hauptperson dies wünscht. Auch hier gilt: Die Hauptperson entscheidet, was für sie passt und ihrer Realität entspricht.

Wenn diese strukturierte Vorgehensweise von allen Beteiligten mit Disziplin,Dienstleistungsbewusstsein und im guten Dialog praktiziert wird, ist das Ideenkorbprinzip in der Regel eine effektive Bereicherung kollektiver Problemlösung und Ideenfindung. Anfangs erfordert es evtl. etwas Übung, um die entsprechenden Grundhaltungen zu integrieren, kann dann aber erfahrungsgemäß meist schnell in die Teampraxis integriert werden.
Unzählige Tipps und Tools für den Teamalltag gibt es in den Trainings mit Dieter Rösner. Weitere Informationen gibt es hier.

Der Weg zur Enterprise 2.0 oder die Stärke schwacher Beziehungen

In meinen ScrumMaster Advanced Trainings verwende ich eine umfangreiche Zeit darauf, gemeinsam mit den Trainingsteilnehmern Eigenschaften eines guten ScrumMaster zu erarbeiten. Hierbei beziehe ich mich allzu gern auf die von Mike Cohn vorgeschlagene Skill-List. Cohn erkennt einen guten ScrumMaster unter anderem an dessen Einfluss im Unternehmen. Bis heute habe ich Cohn vor allem so verstanden, dass ein ScrumMaster dann „gut“ ist, wenn er sowohl intern (in seinem Team), als auch extern (z.B. zum Management) ein enges Beziehungsgeflecht aufgebaut hat, das ihm ein hohes Maß an Reputation verschafft und wenn er auf dieser Grundlage seine Interventionen ausrichten kann. Damit verkörpert der ScrumMaster meines Erachtens ein Stück Produktivität für sein Unternehmen, das er nur noch steigern könnte, wenn er die Maschen seines Netzwerks noch intensiver, noch enger spannen würde. Gerade lese ich allerdings einen Artikel, der einen Effekt beschreibt, der neben der Vertiefung der bestehenden internen wie externen Arbeitsbeziehungen einen nicht minder starken Einfluss auf das Beziehungsgeflecht eines ScrumMasters und damit auch seine Produktivität für das Unternehmen haben soll: „The Strength of Weak Ties“.

Auch lose Kontakte haben ihren Sinn

Der bereits 1973 verfasste Artikel von Mark Granovetter*, einem US-amerikanischen Organisationswissenschaftler und Soziologen an der Stanford University, postuliert, dass ein signifikant größerer (Produktivitäts-)Effekt zu erzielen sei, wenn ein Unternehmen nicht nur enge (starke) Arbeitsbeziehungen verstärke. Mindestens in dem gleichen Maße solle man auch für eine Intensivierung der weniger engen (schwachen) Arbeitsbeziehungen sorgen. Insbesondere diese (schwache Arbeitsbeziehungen) können eine hohe und Gewinn bringende Bedeutung für die Unternehmensentwicklung haben. Granovetter versteht unter weak ties so genannte „lose Kontakte“ (Buhse & Stamer, 2010, S. 12). Er vertritt die Ansicht, dass derjenige, der überwiegend in einem vertrauten Umfeld mit vertrauten Personen agiert, in dem diese sehr stark (und manchmal fast ausschließlich) aufeinander konzentriert sind, viel zu selten neue Impulse von außen erhält. Haben die Personen A und B eine starke Arbeitsbeziehung zueinander, ist es eher wahrscheinlich, dass sie zu vielen Mitgliedern des jeweils anderen Netzwerks ebenfalls starke Beziehungen haben (i. S. v. Gleiches und Gleiches gesellt sich gern). Und eben in der Überschneidung des Bekanntenkreises liegt das Problem. Benötigt Person A ein Wissen, das sie innerhalb des eigenen Beziehungskreises nicht finden kann, ist es eher wahrscheinlich, dass der Beziehungskreis von B ein eher redundantes Wissen hat und ebenso kaum neues Wissen beitragen kann.
 
Ein loser Kontakt zu einer Person C (schwache Arbeitsbeziehung) hingegen hat, laut Granovetter, den Vorteil, dass man durch ihn – und noch stärker durch dessen Netzwerk – einen schnellen Zugang zu einem bis dato unerschlossenen oder vernachlässigten Beziehungs- bzw. Wissenspool bekommen kann und somit eine geeignete Ressource auf im Bestreben nach Informationen. Lose Kontakte versteht Granovetter daher als Brücken zwischen Netzwerken, die helfen können, Probleme zu lösen, Informationen zu sammeln und neue Ideen aufzugreifen. Auf diese Weise tragen lose Kontakte in Unternehmen zu einem verstärkten Knowledge-Sharing und können damit auch zu einer Erhöhung der Innovationsgeschwindigkeit beitragen.
 
Granovetters Artikel habe ich in dem Buch „Die Kunst, loszulassen – Enterprise 2.0“ gefunden. Willms Buhse und Sören Stamer gehen dort den Fragen nach, wie sich Web-2.0-Technologien als Werkzeug gewinnbringend nutzen lassen und welche Veränderungen das jeweilige Unternehmen dazu vornehmen muss, um als Enterprise 2.0 zu bestehen. Die Botschaft der informationsreichen und praxisbezogenen Fachaufsätze namhafter Autoren wie Andrew McAfee, Don Tapscott oder David Weinberger lautet: Wendet euch nach mehr als 100 Jahren vom arbeitsteiligen Produzieren und Ford oder Taylor ab und unterwerft euch einem neuen Prinzip. Dieses Prinzip
 
sucht die schöpferische Kraft der Mitarbeiter umfassend zu nutzen, indem es ihnen die Möglichkeit bietet, jenseits eines engen Aufgabengebiets freiwillig mehr Verantwortung zu übernehmen, Meinungen kundzutun und sich im beruflichen Alltag stärker als bisher von persönlichen Neigungen leiten zu lassen. Freie Zusammenarbeit von möglichst vielen Benutzern ist gewollt – weitgehend ohne Einschränkungen durch Organisationen, Prozesse oder Techniken.“ (Buhse und Stamer, 2010, S. 10)
 
Irgendwie erinnert mich das an Scrum. Was meint ihr!?
 
*Nice to know: Granovetters Artikel „The Strength of Weak Ties“ (übersetzt: Die Stärke schwacher Beziehungen) wurde laut Google Scholar weltweit mehr als 5.000 Mal zitiert.
 
 
Literatur:
Buhse, W. & Stamer, S. (2010). Die Kunst loszulassen – Enterprise 2.0. Rhombos Verlag.
 
Granovetter M. (1973). The Strength of Weak Ties. In: American Journal of Sociology, 78 (May), p. 1360-1380. Zu beziehen über die Online -Datenbank JSTOR: http://tinyurl.com/2s9ck

Vorweihnachtsretro

Hat etwa noch jemand nicht genug von dem vorweihnachtlichen Trubel und ist noch auf der Suche nach einer Idee für die letzte Retro vor Weihnachten? Das Thema Tage bis zum Fest, der Weihnachtsbaum und Silvester drängen sich da quasi auf. Ich habe mir die Retro vom letzten Jahr noch einmal vorgenommen und versucht, auch für die Elemente Timeline und Verbesserungsmöglichkeiten vorweihnachtliche bzw. endjährliche Übertragungen zu finden. Vielleicht liefern die nächsten Zeilen ein paar Ideen. Je nach Team und Situation kann natürlich mit den Fragen, bzw. Beschriftungen der Kerzen und Kugeln etwas variiert werden.
Fragt doch mal euer Team, ob es die Kreise für die Retro nicht etwas erweitern will. Mit wem wird eng zusammengearbeitet? Wen könnte man zu einer etwas größeren Rückschau einladen? Wen möchte man  besser kennenlernen? Vielleicht wäre es ausnahmsweise auch mal an der Zeit, den ScrumMaster zur Retro einzuladen? Bestimmt auch für das PO- oder SM-Team mal eine schöne Abwechslung.
Zugegeben, es braucht etwas Vorbereitungszeit, aber es lohnt sich bestimmt.

Timeline – 24 Zeiteinheiten bis Weihnachten

Gemalte oder echte Weihnachts-Socken, Kärtchen, Geschenke, Zweige, Candy Canes etc. mit den Zahlen von 1 bis 24 beschriften und der Reihe nach im Raum aufhängen. Je nachdem, wie lange der betrachtete Zeitraum ausfallen soll, steht jede Zahl für einen bestimmten Zeitraum (z.B. eine Woche – halbes Jahr Rückschau, zwei Wochen – Jahresrückschau, zwei Tage – die letzten Sprints). Das Team sammelt Fakten und hängt sie an den entsprechenden Platz.

Was lief gut – Licht und Schmuck am Baum

Weihnachtsbaum_mit_Namen    Weihnachtsbaum_mit_Kugeln
Einen großen Weihnachtsbaum auf ca. 4 Flip-Charts malen (je nach Größe des Teams). Namen der Teammitglieder einmal unter den Baum auf Päckchen und einmal von oben nach unten am Baum auf Socken schreiben und so mit den Namen eine Matrix aufbauen.
Für jedes Teammitglied leuchtet eine Kerze in dem jeweiligen Feld der Matrix, an dem sich seine Namen treffen. Jedes Teammitglied schreibt nun auf, was für ihn oder sie z.B. ein erleuchtender Moment war, was ihn/sie am meisten motiviert, was für Ihn/sie in diesem Jahr besonders gut gelaufen ist in Bezug auf die Arbeit / Scrum Einführung / neues Team etc.
Weihnachtsbaumkugeln
Der Schmuck ist Symbol für gute Zusammenarbeit mit den Kollegen. Wieder wird die Matrix genutzt und jeder klebt für die Kollegen eine Kugel mit Beschriftung an den Baum, als Antwort auf z.B. die Fragen: 

Break / Separator
Jeder bringt seine Lieblingsweihnachtssüßigkeit mit, teilt mit den anderen und erklärt, warum er genau das so gerne zu Weihnachten isst. Oder vielleicht möchte jemand lustige Weihnachtspannen zum Besten geben? Ein kleines (!!!) Tischfeuerwerk sorgt bestimmt auch für den nötigen Break zwischen den beiden Teilen.

Was kann verbessert werden – Feuerwerk guter Vorsätze für das nächste Jahr

Das Team gestaltet das Feuerwerk des nächsten Jahres (an einer Metaplanwand oder einer mit Papier beklebten Tapete). Wie sieht das Gesamtbild aus? Welche Soundeffekte gibt es? Welche Farben? Was wird heller als dieses Jahr? Was lassen wir weg? Was nehmen wir neu dazu? Womit wollen wir experimentieren? Welche Kompetenzen brauchen wir dafür in unseren Feuerwerksexperten-Team? Wer soll das Feuerwerk sehen?
In diesem Sinne: Lasst die letzte Retro im Jahr zu einer schönen Rückschau, einem prachtvoll geschmückten Festbaum und einem aufregenden Ausblick auf das neue Jahr werden.

Berater-Identität oder wo stehe ich im Spannungsfeld zwischen Rolle, Auftrag und Kunde?

Ein wunderbarer Beitrag von Bernd Krehoff („Vom Glauben und sich einlassen“) hat mich angeregt, auf dieses spannende Thema noch mal von einer anderen Perspektive aus einzugehen. Berater, aber auch Change Manager aller Art, haben, bezogen auf ihre Aufgabe, eine spezifische Rollenidendität. Diese Identität ist gespeist und geprägt von bewussten und unbewussten Wertvorstellungen, Glaubenssätzen und biographischen Erfahrungsinhalten und steuert Handeln und Verhalten. Rollenidendität ist somit zum einen definiert durch die faktischen Rollenanforderungen (erworben größtenteils in Ausbildungen) und zum anderen durch individuelle Vorprägungen. Diese Konstellation erfordert es von Beratern oder ähnlichen Dienstleistern, ihr Rollenverständnis immer wieder subjektiv zu reflektieren, zu hinterfragen und ggf. zu modifizieren. Berater werden zuallererst eingekauft, um Probleme zu lösen und Entwicklung (mit) zu gestalten, Wissensvorsprung einzubringen und trotzdem den Kunden „mitzunehmen“.

Die Rolle des Beraters bewegt sich permanent im Spannungsfeld zwischen der Orientierung an Menschen und der Orientierung an der Fachlichkeit. In den vier Feldern der Abbildung kann man seine  jeweils individuelle Rollenidentität im Sinne von vier Rollenmustern einordnen. Diese Struktur bietet sich damit als ein brauchbares Modell zur Selbstreflektion für Beraterrollen an.

Wer bin ich?

Ist die Orientierung an den Menschen/Kunden sehr aus geprägt, die Fachlichkeit gegebenenfalls zurückgestellt, definiert dieses Modell die Beraterrolle als “Freund”. Die Rollenmuster zeigen sich in einem starken Interesse an gutem Kontakt zu den Kunden und einem hohen Maß an Empathie, Geduld und Flexibilität. Die Ausgangslage, Bedürfnisse und Wünsche des Kunden werden in hohem Maße respektiert und eigene Konzepte ggf. (auch wenn man’s besser zu wissen glaubt) modifiziert und zurückgestellt. Grundsätzlich ist die “Freund-Identität” eher auf Konfliktvermeidung, Harmonie und Kompromisse ausgerichtet. In den Interaktionen spielt auch Emotionalität ein wesentliche Rolle
Zeigt die Ausprägung im Rollenverständnis stark in Richtung Fachlichkeit und ist der Fokus auf Menschen eher gering, definiert dies die Rollenidentität als “Fachspezialist“. Hier dominiert das  spezifische Wissen und Know-how und der starke Glaube an der Richtigkeit der eigenen Vorstellungen und Konzepte. Die (fachlich-sachliche) Welt wird in “richtig oder falsch” eingeteilt. Widerstände werden als feindselig wahrgenommen und als Fachspezialist mit z.T. missionarischer Überzeugungskraft gekontert. Das berufliche Handeln ist sehr rational ausgerichtet.
Sind sowohl Fach- als auch  Menschenorientierung gering ausgeprägt definiert sie die Rollenidentität  als “Delegierer“. Im Beraterkontext ist dieses Haltungselement eher als situative Komponente denn Identität zu sehen. Die Haltung als „Delegierer“ zeigt sich in der Weitergabe von Aufgaben und Verantwortung, in hoher Distanz zu Kunden und Aufgaben. Bewusstes „Delegieren“ kann in Ablösungsprozessen sinnvoll sein, dort wo eigene Fachkompetenzen nicht ausreichen. Oft wird versucht, dem Berater stellvertretend Führungsverantwortung zu übertragen. Hier ist die Kunst der (Rück) Delegation sinnvoll. Allerdings sollte dann wieder in die „Coach-Identität“ gewechselt werden können, um die Situation angemessen zu bearbeiten.
Das sicherlich anspruchsvollste Rollenmuster zeigt sich in der Funktion “Coach” im oberen rechten Feld. Die Werte- und Handlungsorientierung bezieht sich sowohl auf hohe Fachlichkeit als auch auf die Menschen/Kunden. Das bewusste Agieren in diesem Spannungsfeld erfordert hohe Bewusstheit bezogen auf das eigene Handeln und das permanente Wahrnehmen und Einbeziehen der vom Veränderungsgegenstand betroffenen und beteiligten Menschen/Kunden. Die „Coach-Identität” setzt professionelle Kommunikationsfähigkeit, Flexibilität, Fähigkeit zur Distanz (auch zu sich selbst) und Orientierung am Dialog/Konsens voraus. Die Ressourcen des Kunden sind ein wesentlicher Fokus und der Glaube daran, dass Betroffene aus diesen Ressourcen heraus mit beratender Unterstützung des „Coaches“ optimale und für ihn passende Lösungen findet. Die „Coach-Identität“ stellt die höchsten Herausforderungen an Berater und Change Manager, bietet aber auch die Chance, dem Spagat zwischen fachlichen Konzepten, Modellen und Menschen und sozialen Systemen am ehesten gerecht zu werden. Getreu der systemischen Prämisse, dass man ein soziales System nicht von außen steuern, sondern nur anstoßen kann.
In diesem Beitrag ging es mir zum einen darum, die Komplexität von Rollen wie Berater, Change Manager, ScrumMaster usw. im Umgang mit ihrer Rollenidentität darzulegen. Zum anderen sollen es Anregungen sein, sich mit den eigenen Identitätsmustern auseinander zu setzen, sich im Modell zu verorten, um bewusst und professionell in seiner Rolle agieren zu können.

Die Weisheit der Vielen

Als der britische Gelehrte Francis Galton im Herbst 1906 von seiner Wohnung in die Stadt Plymouth zur alljährlichen West of England Fat Stock and Poultry Exhibition, einer regionalen Viehmesse, aufbrach, war er sich ganz bestimmt nicht bewusst, dass er an diesem Tag über ein Phänomen stolpern würde, das die Wirtschafts- und Sozialwissenschaftler des 21. Jahrhunderts noch immer spaltet: Unter den richtigen Umständen sind Gruppen bemerkenswert intelligent und das Kollektiv meist klüger als die Gescheitesten in ihrer Mitte.
 
Galton, Wissenschaftler und besessen vom Messen körperlicher und geistiger menschlicher Eigenschaften, kam beim Flanieren über die Messe zu einem Wettbewerb, bei dem die Besucher das Gewicht eines massigen Ochsen schätzen sollten. Für eine geringe Summe bekam jeder Wettende eine nummerierte Karte mit Stempel, auf der der Name, die Adresse und das Schätzgewicht notiert wurden. Die genauesten Schätzungen sollten ein Preisgeld erhalten. An der Schätzung nahmen rund 800 Leute teil und versuchten ihr Glück. Die Teilnehmergruppe setzte sich sowohl aus Menschen mit Insiderwissen wie Bauern oder Metzgern, als auch aus Laien wie beispielsweise Büroangestellten zusammen. Galton erkannte in diesem Wettstreit eine Analogie zu einer demokratischen Gesellschaft, in der Menschen mit vollkommen unterschiedlichen Fähigkeiten und Interessen die Möglichkeit bekamen, freies Wahl- bzw. Schätzrecht auszuüben. Galton kam es aber nun darauf an, eine Antwort zu erhalten, wozu der Durchschnittsschätzer befähigt ist. Er borgte sich also nach der Auszählung die Wettkarten und unterwarf sie diversen statistischen Tests. Er addierte unter anderem die Schätzwerte aller Wettkandidaten, um den Mittelwert der Schätzung zu erhalten; also die Zahl, die die kollektive Weisheit der Masse darstellte. Galton hatte fest damit gerechnet, dass der mittlere Schätzwert weit daneben liegen würde. Er hatte sich geirrt. Der Schätzwert der Gruppe und der Realwert lagen gerade mal ein Pfund auseinander! Die Gruppe hatte mit ihrer Schätzung genau ins Schwarze getroffen.
 

Gibt es nur den einen Experten?

Die Erkenntnis, dass die Lösung von Problemen im kollektiven Wissen liegt, stieß und stößt allerdings nicht nur auf Zustimmung – im Gegenteil und nicht zuletzt, weil viele von uns der Meinung sind, dass wichtiges (zur Lösung beitragendes) Wissen nur in wenigen Köpfen vorhanden sei. Man geht dabei davon aus, dass die Problemlösung ausschließlich von der einen, richtigen Person gefunden werden kann. Deshalb macht man sich häufig auf die verzweifelte und oftmals aussichtslose Suche nach dem einen Experten. Diese Auffassung kommt nicht von ungefähr, wenn man sich die Literatur ansieht. Bereits 1841 verfasste der Schotte Charkes Mackay ein Buch mit dem Titel “Extraordinary Popular Delusions and the Madness of Crowds” (Ungewöhnliche populäre Irrtümer und Massenwahn), in dem er vollends in Frage stellt, ob eine Menschenmenge überhaupt mit Wissen ausgestattet sein kann. In die gleiche Kerbe schlagen Aussagen wie “Jeder Mensch ist, für sich genommen, einigermaßen vernünftig und rational – als Mitglied einer Menge wird er prompt zum Dummkopf ” (Bernard Baruch, Börsenspekulant) oder “Die Masse erreicht niemals das geistige Niveau ihres herausragendsten Mitglieds, sondern sinkt vielmehr auf das unterste individuelle Niveau in ihren Reihen” (Henry D. Thoreau). Selbst prominente Vertreter stellen eine mögliche Weisheit der Vielen in Frage. Friedrich Nietzsche postuliert: “Der Irrsinn ist bei Einzelnen etwas Seltenes – aber bei Gruppen die Regel.”  All diese Aussagen und Denkrichtungen haben gemeinsam, dass sie nicht daran glauben, dass Gruppen imstande sind, klug zu handeln und einen hohen Grad an Geschicktheit beim Lösung von Problemen innehaben.

Oder ist die Gruppe klüger?

Jetzt steht Meinung gegen Meinung. Allerdings präferiere ich, weil ich es selbst schon gesehen und am eigenen Leib erfahren habe, Francis Galtons Ansatz. Er und viele seiner Erben, wie James Suroiecki („Die Weisheit der Vielen – warum Gruppen klüger sind als Einzelne und wie wir das kollektive Wissen für unser wirtschaftliches, soziales und politisches Handelns nutzen können“) und Jochen May („Schwarmintelligenz im Unternehmen – wie sich vernetzte Intelligenz für Innovation und permanente Erneuerung nutzen lässt“) erbringen in unzähligen Beispielen den Beweis, dass Gruppen geradezu prädestiniert sind, die richtigen Entscheidungen zu treffen und Probleme mit Erfolg zu beheben. Trotz des Faktums, dass ihre Einzelmitglieder weder über eine hohe Intelligenz noch über andere herausragende Fähigkeiten verfügen.
Ich erlebe eben genau das tagtäglich im agilen Umfeld. Gruppen, Scrum-Teams genannt, treffen ständig (gute) Entscheidungen und tun dadurch viele Dinge richtig. Schaut euch nur ein Estimation Meeting an. Jedes Mitglied der Gruppe schätzt auf der Grundlage des eigenen Verständnisses den Funktionsumfang einer User Story und übersetzt die Entscheidung in eine Zahl, die lediglich eine Relation aussagt (“also so ungefähr und in Relation zu anderen User Stories”). Und interessanterweise macht das jedes Teammitglied für sich. Das Resultat ist (fast immer) eine Schätzung, die die Grundlage einer Planung (SP1 und SP 2) ist, die in einem eindeutigen Versprechen (Commitment) für eine Lieferung mündet. Großartig!

Vom Glauben und sich Einlassen

Neulich standen zwei übertrieben freundliche und korrekt gekleidete Menschen vor meiner Tür. Auf meine Frage, ob sie jemanden suchten, kam die Antwort: „Wir suchen Sie!“
Ich mag es nicht, wenn Menschen mit dem einen Ziel das Gespräch suchen, den anderen restlos für seine eigenen Überzeugungen zu gewinnen. Zugleich finde ich es bemerkenswert, dass diese zwei Missionare einen herrlichen Samstag Nachmittag für das Putzen von Türklinken opferten und darin ganz offenbar einen Sinn sahen. Die Straßen und Parks waren an jenem Nachmittag voll mit fröhlich-unbefangenen Menschen, die mit einem Spaziergang oder einer Radtour ihrem Leben nachgingen.

Missionarische Berater, ungläubige Kunden

Als Berater sind wir immer wieder versucht, unseren Erfolg an der Nachmacherquote zu messen. Macht der Kunde es genau so, wie wir ihm das gesagt haben? Abweichungen werden dann oftmals von uns als Rückfall in alte Verhaltensmuster interpretiert. Der Kunde sieht das meist ganz anders: Er versucht, Scrum an seine Realität anzupassen und dabei seinen eigenen Weg zu gehen. Er glaubt nicht, dass die Erfolgsstories von anderen bei ihm funktionieren können und geht dann im Zweifelsfall lieber einen Kompromiss zuviel ein.
Beide Positionen sind problematisch. Der missionarische Berater überhebt sich in seiner Rolle. Indem er das Verhalten seines Kunden bis in letzte Detail festnageln will, nimmt er ihm das letzte Stück Freiheit. Der skeptische Kunde hat indes ein anderes Problem: Er will nicht so recht an das glauben, was sein Berater ihm erzählt. Er lässt sich auf Veränderungen nur so weit ein, wie diese seinen gewohnten Standpunkt nicht zu sehr in Frage stellen. Damit versperrt er sich den Weg zu der Veränderung, die er mit Scrum erreichen kann.
Es gibt keinen dümmeren Satz als jenen, der besagt, alles sei relativ. Natürlich sind wir in unseren Überzeugungen und Verhaltensweisen von unserer Subjektivität geprägt. Das, was ich glaube, ist meinen Erfahrungen und meinem Charakter geschuldet.
Das muss aber noch längst nicht bedeuten, dass unsere Glaubenssätze und Überzeugungen nur für uns Gültigkeit haben. Jeder von uns hat Erfahrungen gemacht, in denen er über seinen eigenen Schatten gesprungen ist. Situationen, in denen Menschen Schlechtes tun und wir aufrichtig darüber empört sind. Eigene Handlungen, die wir zutiefst bereuen. Menschen, die wir lieben. In solchen Situationen glauben wir nicht zaghaft, sondern zeigen Haltung. Wir tun das, was wir tun, in der Überzeugung ihrer intersubjektiven Richtigkeit.
Einen starken Glauben: Das wünsche ich  allen, die sich und ihre Welt verändern wollen. Sich auf etwas Neues einlassen kostet Kraft und ist alles andere als selbstverständlich. Wer da erstmal alle Zweifel und Einwände ausräumen will, der wird kaum über seine eigenen Grenzen hinauskommen. Deshalb ist es manchmal gut, einfach glauben zu können, ohne alles wissen zu müssen.
Wie  geht es dir heute und jetzt? Machst du einen Veränderungsprozess durch, der viele Fragen aufwirft? Hast du den Prozess vielleicht sogar selber angestoßen? Wie gehst du mit Zweifel um? Mit der Skepsis, die jedem einmal entgegen schlägt? Unser Coach, Dieter Rösner, hat mir einen wunderbaren Trick beigebracht: Wenn jemand etwas in Frage stellt, ohne sich darauf eingelassen zu haben, dann bitte ihn oder sie, es einfach mal auszuprobieren, und dir danach zu sagen, ob es Sinn gemacht hat oder nicht. Allein schon die Erfahrung – es ausprobiert zu haben – führt dazu, dass die Kritik konstruktiv wird.
Und ja: Es gibt einen Unterschied zwischen festem Glauben und blindem Glauben. Der blinde Gläubige folgt anderen und will sich dabei selber aufgeben. Der standhaft Gläubige folgt anderen, um mehr über sich und seine Welt zu lernen. Während der eine in immer größere Abhängigkeit gerät, kann der andere eines Tages den Hut packen und eigenständig weitermachen.
[quote author = “Ludwig Wittgenstein”]Denn um dem Denken eine Grenze zu ziehen, müssten wir beide Seiten dieser Grenze denken können (wir müssten also denken können, was sich nicht denken lässt).[/quote]

Kreativitäts-Fitnessplan

Der Titel suggeriert das Versprechen, dass man die eigene Kreativität trainieren kann. Stimmt auch. In diesem Beitrag verbergen sich einige Empfehlungen und Übungen von mehreren Autoren, die zwar weder Fitnessstudio noch Geräte gebrauchen, aber wohl eine gewisse Disziplin abverlangen.

Routine durchbrechen

Die einfachste Übung besteht darin, die eigene Routine zu durchbrechen. Tragen Sie paar Wochen die Uhr auf der rechten Hand, und schreiben Sie statt mit der rechten mit der linken Hand. Trinken Sie den Kaffee statt in der Früh erst am Nachmittag, erforschen Sie ALLE möglichen Wege zum Büro, gehen Sie zu einem anderem Zeitpunkt ins Fitnessstudio, stehen Sie mal 1 Stunde früher auf und so weiter. Es sollen keine großen Sachen sein – nein, Kleinigkeiten. Dabei sollte man sich selbst beobachten. Sie werden überrascht sein, wie oft man über eigenen Automatismen stolpert. Der physische Routinebruch kann sich auch auf gedankliche Routinen übertragen, sodass man bei Problemen auf andere Lösungsmethoden kommen kann.

Gehirnjogging

Holly G. Green empfiehlt in ihrem Blog, sich täglich eine Rätselaufgabe und ein paar Minuten Zeit zu nehmen, um sie zu lösen. Zudem kann man den Rest der Firma daran beteiligen, indem man in öffentlichen Bereichen wie der Kantine wöchentlich ein Puzzle publiziert und für die richtige und/oder originellste Antwort einen Preis verleiht.
Beispiel für die Kopfknibbelei von Holly G. Green: Ein Mann steht auf einer Seite eines Flusses, sein Hund auf der anderen. Der Mann ruft sein Hund, der sofort den Fluss überquert, ohne nass zu werden und ohne eine Brücke oder ein Boot zu verwenden. Wie hat der Hund das gemacht? Nehmen Sie sich einfach paar Minuten Zeit. Antwort am Ende dieses Beitrags.

Abseits der eigenen Interessen „schwimmen“

Empfehlungen, sich auf regelmäßiger Basis mit interessensfremden Themen zu beschäftigen, werden von mehreren Experten ausgesprochen. Eine Empfehlung lautet, jeden Tag eine halbe Stunde zufällige Inhalte aus dem Internet zu lesen und die interessanten Fakten zu notieren. Die aufgeschriebenen Informationen sollte man zu einem späterem Zeitpunkt nochmals anschauen. Das erweitert den Horizont und schafft neue Verknüpfungen.
Die oben erwähnte Holly G. Green liest wöchentlich ein Magazin oder einen Blog, das oder der nichts mit der eigenen Industrie zu tun hat. Zudem liest sie monatlich ein Buch, das nicht in den „üblichen“ Interessenbereich fällt. Oder man besuchte eine branchenfremde Messe/Convention besuchen und fokussiert sich darauf, was man daraus lernen kann. So hat sich Peter Drucker, Pionier der modernen Managementlehre, rund 2 Jahre Zeit genommen, um sich mit bestimmten Themen zu beschäftigen – zum Beispiel mit japanischer Dichtung. Wohl gemerkt: neben seinen hauptberuflichen Aktivitäten.

Denk – kata

Eine Kata ist eine Übungsform, „die aus stilisierten Kämpfen besteht, welche jedoch im Karate ausschließlich gegen imaginäre Gegner geführt werden“. Kombiniert man die Idee der Kata mit der Methode der „6 Hüte“ von DeBono, die ursprünglich für die Gruppenarbeit gedacht war, entsteht eine andere mögliche Anwendung. Man nimmt also ein Problem und übt den Lösungsweg mit dem systematischen Aufsetzen von allen 6 Hüten, die für bestimmte Denkrichtungen stehen (kritisch, kreativ, neutral, etc).
Antwort auf die Kopfknibbelei, die Ms. Green angibt ist „Der Fluss ist gefroren“. Aber es gibt auch andere Möglichkeiten. Es kann ja sein, dass es sich um einen engen Fluss handelt, sodass der Hund einfach drüberspringen kann. Fragen Sie Ihre Freunde & Kollegen, könnten Sie von Sprachjongleuren Hinweise bekommen wie „kann ja sein, dass der Hund schon vorher nass war – beim Zurückschwimmen war er gar nicht trocken“. Geht ja auch.
Ich wette, es sind noch einige andere Antworten möglich – probieren Sie es aus!

Eine Erleuchtung: Scrum als Coaching-Tool!

Und als ich hinauszog, die Welt zu bescrummen, so erkannte ich, wie vielseitig einsetzbar es tatsächlich ist. Jeden Prozess können wir mit Scrum optimieren und jedes Scrum-Team wird effizienter und hat Spaß bei der Arbeit. Mit strahlenden Augen sitze ich in jeder neuen Situation da, die ich als mögliches Scrum-Einsatzfeld erkenne. Und gerade las ich ein Buch über Coaching- und Interventionsmethoden, als ich plötzlich aufstehen, die Tür des Zugabteils aufreißen und rufen wollte: „Leute – ich habe etwas entdeckt! Scrum ist eine Coaching-Methode!!! Ja, wir machen Coaching und ja, wir machen Scrum. Und wir begleiten Menschen, die Scrum machen und nennen es Scrum Coaching. Das ist nichts Neues, das gibt es schon lange. Aber ich meine Scrum selbst als Coaching-Methode!”

Wissen, was man will

Um ein glücklicher Mensch zu sein, muss ich wissen, was ich will, das Ziel positiv formulieren und mir auf dem Weg zu meinem Ziel immer klarer werden, wie es denn tatsächlich aussehen wird. Je klarer meine Vorstellung von dem Ziel heute schon ist, desto leichter erscheint mir der Weg dorthin. Genau das ist es ja, was wir in Scrum erreichen wollen. Liebe Leute, wenn ihr ein Produkt entwickeln wollt, braucht ihr ein Ziel und eine klare Vorstellung davon. Sprecht ganz viel darüber, macht euch zunächst klar, was ihr wollt und überlegt euch dann, wie ihr es erreichen könnt! Dann, wenn Klarheit herrscht, geht die Umsetzung fast wie von selbst. Wir merken das in den Sprint Plannings – je klarer der PO die Story an das Team kommuniziert, desto einfacher wird die Bearbeitung. Heruntergebrochen auf einzelne Schritte kann ich dann nachvollziehen, wie nah ich meinem gesteckten Ziel schon gekommen bin und kann meine Anstrengungen am Taskboard sehen.
Scrum-Coaching bekommt für mich nun eine ganz andere Bedeutung, wenn ich meine Entwicklungs- und Lebensziele damit erreichen möchte. Als Selbstcoaching-Tool beispielsweise. Also nicht IN Scrum, sondern MIT Scrum coachen. Ich meine damit: ob ich eine Software entwickle oder ein anderes geistiges Produkt – mit Scrum sollte das doch funktionieren. Angenommen, ich setze mir als Ziel, mehr mit meiner Familie zusammen zu sein. Dann stelle ich mir die Frage: “Was will ich eigentlich genau, was will ich erreichen, was sind Rahmenbedingungen, die mich einschränken? Und wie finde ich am Ende heraus, dass ich mein Ziel auch tatsächlich erreicht habe?” Ich gehe also einmal im Geiste oder auf Papier die PO Checkliste durch. Und dann überlege ich mir, welche Schritte nötig sind, was muss ich tun: Mit meinem Chef über neue Arbeitszeiten sprechen, einen Homeoffice-Platz einrichten, etc. Mit dem Unterschied, dass ich selbst mein eigener PO und Teil des Umsetzungs-Teams bin. Zusammen mit meinen Kollegen, meiner Familie und Freunden, die mir bei der Erreichung meines Ziels helfen können. Aber ich brauche einen ScrumMaster, meinen Coach, der mich daran erinnert, dass ich an meinem Ziel arbeiten muss. Wenn ich einen Coach habe, der mich unterstützt, ist das wunderbar. Wenn ich selbst auch noch mein eigener Scrum Master sein muss, wird es schwierig. Da stecke ich in zu vielen Rollen gleichzeitig und muss sehr diszipliniert bleiben. Aber dann kann ich mir mit Scrum Artefakten oder Tools helfen. Zum Beispiel kann ich an einem Taskboard die Umsetzung organisieren und mich fokussieren. Am Ende kann ich dann reviewen, ob ich mein Ziel erreicht habe und den Prozess reflektieren.
Heureka! Scrum ist überall!

Inspiration

Viele von euch kennen meine Impulse, Zitate oder Videos, die ich mit euch per Mail oder Twitter teile. Ich wurde gefragt, ob ich meine Top 5 mal hier posten könnte. Da mir eine Menge einfällt, fällt mir die Wahl ziemlich schwer. Aber ich will mal thematisch vorgehen.
Hiermit meine Top 5 und ein paar Wörter zum Thema „INSPIRATION“.

Der Flügelschlag eines Schmetterlings

Habt ihr schon mal einen Weitspringer in seiner Vorbereitung auf einen anstehenden Wettkampf beobachtet? Akribisch genau misst er seinen Anlauf ab. Er hat seine Schrittzahl im Kopf, die er vom Absprungbalken aus abgeht und bis dorthin abzählt, wo er seinen Anlauf beginnen wird. Exakt dort platziert er ein persönliches Erkennungszeichen, damit er weiß, wo sein Anlauf startet. Wenn der Athlet an der Reihe ist, begibt er sich zu seiner Marke, geht den gesamten Sprungablauf noch mal in seinem Kopf durch, motiviert sich, läuft los und … übertritt (manchmal). Der Springer nimmt Blickkontakt mit seinem Trainer auf, der den Sprung beobachtet hat. Die beiden tauschen sich mit Zeichen aus. Der Springer nickt, geht zu seiner Marke und verschiebt sie um wenige Zentimeter nach hinten. Er nimmt wieder Anlauf, springt, trifft das Brett und landet: Bestweite!
 
copyright Dolores Omann
 
Eine kleine Intervention kann zu einer großen Veränderung führen. Natürlich ist das nicht der Normalfall und auch nicht planbar. Tritt ein solcher Effekt jedoch ein, dann spricht man vom Schmetterlingseffekt: In einem komplexen, nichtlinearen dynamischen System besteht eine große Empfindlichkeit auf kleine Abweichungen in den Anfangsbedingungen. Geringfügige Interventionen in den Anfangsbedingungen können im langfristigen Verlauf zu einer signifikant anderen Entwicklung führen.
In einer meiner letzten Retrospektiven, die ich als ScrumMaster begleiten durfte, kam mir spontan eine Intervention in den Sinn, die in ihrer Wirkung einem Schmetterlingseffekt nahe kommt. Schritt 3, die Beantwortung der Frage „Was lief gut“ war abgeschlossen. Nach dem Separator, einer kurzen Verschnaufpause, wollten wir uns der Frage „Was könnte verbessert werden?“ widmen. Mir war bereits im gesamten Sprint und auch in der Retrospektive aufgefallen, dass die Teammitglieder wenig Eigeninitiative und Selbstverantwortung übernommen hatten. Immer wieder klagten sie über Impediments, die sie an mich abgaben und die Schuldigen fanden sie ständig in anderen Teammitgliedern, den widrigen Umständen und/oder der verkrusteten Organisation.
 
Ich entschied mich spontan, die anstehende Frage leicht zu verändern bzw. eine Differenzierung vorzunehmen. Statt die Teammitglieder „nur“ mit der Frage zu konfrontieren, „Was könnte verbessert werden?“, bat ich sie, außerdem Antworten auf die Frage zu finden:
 
Was könntest DU als Teammitglied verbessern?


Ich habe schon viele Retrospektiven begleitet, beobachtet oder selbst durchgeführt. Ich habe allerdings selten eine so tiefgreifende Veränderung im Denken und Reflektieren erlebt. Die Zentrierung auf die eigenen Ressourcen, Möglichkeiten, Chancen und Sorgen hatte zu einer Perspektivenerweiterung beigetragen. So entstand eine spürbar intensivere Auseinandersetzung mit der eigenen Rolle im Team und der Verantwortung mit dem individuellen Beitrag. Die Formulierung von Ich-Botschaften (statt der üblichen Man-Botschaft) kann als großer Erfolg verbucht werden. Das intrinsisch motivierte Übernehmen von Verantwortung ist ein großer Schritt auf dem Weg zu einer wirklichen Veränderung im Denken und Handeln.
 
Ich kann euch ScrumMaster nur einladen, diese Intervention auszuprobieren. Vielleicht hat sie ja die Kraft des Flügelschlags eines Schmetterlings.

The Art of Non Conformity – FUCK IT!

Lebe dein Leben, so wie DU es WILLST. Aber – Moment, da muss man ja zunächst wissen, was man will. Ich habe eine Freundin, die eigentlich den ganzen Tag nichts zu tun hat. Sie arbeitet wenig und sie hat außer des Managements ihres eigenen Lebens keine weiteren Verpflichtungen. Sie ist todunglücklich, depressiv und immer am Limit ihrer Leistungsfähigkeit. Auf die Frage, was sie vom Leben will, kommt keine klare Aussage. In seinem Buch “The Art of Non-Conformity” beschreibt Chris Guillebeau, dass es zunächst wichtig sei herauszufinden, was man im Leben erreichen will. Nun ja, das ist ehrlich gesagt langsam langweilig. Das haben uns Lothar Seiwert, Stephen Covey [The 7 habits of high effective people], und was weiß ich wer noch alles erzählt. Zu wissen, was man will. Die wohl einfachste Frage der Welt, oder? Und was ist, wenn man weiß, was man will, es aber so einfach nicht erreichen kann?
Gibt es vielleicht einen Weg für all die Leute, die sich gerade mit dieser Frage schwer tun? Die diese so wichtige Lebensfrage gar nicht beantworten wollen, weil sie selbst bereits so viel Stress aufbaut?Wie wäre es also mit einem anderen Ansatz? In “Fuck It” beschreibt John C. Parkin den Weg “Loslassen, Entspannen, Glücklich sein”, indem man die Dinge einfach ganz anders, nämlich durch Loslassen erreicht. Also nicht ständig hinter den Dingen herzurennen, sondern die Dinge durch Loslassen zu erreichen. Das ist an sich ein gar nicht so schlechter Rat. Wie soll sich etwas in uns entfalten, wenn wir “krampfhaft” darauf zu steuern? In dem Buch “Muße. Vom Glück des Nichtstuns” wird genau dieser Ansatz vollkommen neue gedacht. Es geht darum, zu entspannen.
Wir arbeiten alle zu viel, wir wollen zu viel in der Arbeit und in unserem Leben. Auch das soll noch perfekt sein. Wenn wir in den Urlaub fahren, auch der muss perfekt sein. Wir brauchen mittlerweile Coaches, die den normalen Business-Menschen zur Seite stehen, damit der normale Mensch überhaupt noch funktionieren kann. Die Arbeitszeit von Menschen, die in unserer Gesellschaft etwa zum Bruttosozialprodukt beitragen, steigt ständig. Wer etwas erreichen will, muss heute bereit sein, wesentlich mehr als 40 Stunden in der Woche zu arbeiten (ja, das ist auch bei bor!sgloger so!).
Aber ist das gut? Mehr und mehr Kinder erkranken an ADHS. Aber es ist noch gar nicht wirklich klar, wieso das in unserer Gesellschaft passiert. Bekommen diese Kinder einfach viel zu früh zu viele Eindrücke, dann hat sich doch der Versuch, unsere Kinder noch perfekter an unsere Umwelt anzupassen, mittlerweile pervertiert.

Werft die Ratgeber weg!

Ein Grund für diese Pervertierung sind die Ratgeber: Sie schüren die Hoffnung, dass wir alle unsere Ideale, unser ganzes Leben selbst bestimmen können. Sie alle wollen uns zeigen, wie man es denn nun richtig machen kann. Wir müssen endlich aufhören, die Ratgeberbücher dieser Welt über unser Leben bestimmen zu lassen. Das Lesen eines Buches darüber, wie man sein Leben zu leben hat, ist nichts anderes als die Sucht danach, das Leben zu leben, ohne es zu leben. Es ist wie das Lesen von Büchern über das Schreiben, anstatt zu schreiben. Das Lesen von Büchern über das Fotografieren, ohne zu fotografieren.
Das machen gerade Ratgeberbücher, wie das von Parkin klar und sind damit eigentlich ein Paradoxon. Sie sagen uns, finde heraus, was DU willst. Einerseits der richtige Rat, andererseits liegt in diesen Büchern der tiefe Glaube begraben, dass genau das ginge.
Die postmoderne Version des “American Dreams”, der unerschütterliche Glaube, man kann alles erreichen. Aber leider ist das gar nicht so. Wir sind nämlich auch, und das ist etwas, was uns die Ratgeber zumeist nicht erzählen, viel stärker vom Zufall abhängig, als wir oftmals akzeptieren wollen. Diese narzisstische Kränkung, dass unsere Leben auch eine Folge der Zufälligkeit unserer Begegnungen, des momentanen Zeitgeistes, der aktuellen Mode, der Entscheidungen unserer Freunde, der derzeitigen Zwänge der Kunden ist – diese Erkenntnis führt unweigerlich zu der Folgerung, dass wir nicht für alles verantwortlich sein können. Hätte ich meine Frau kennengelernt, wenn ich diesen Event nicht organisiert hätte? Würde ich heute Pferde halten, wenn ich sie nicht kennengelernt hätte? Ehrlich gesagt: Ich denke nein! Wäre ich heute mit jemandem anderen zusammen,  wäre ich glücklich? Keine Ahnung, aber wieso nicht. Es wäre ein komplett andere Geschichte, aber ja … sie wäre auch mein Leben.
Wäre also nicht die logische Konseqenz, dass ich das Schreiben dieses Posts ebenfalls lassen sollte, denn auch ich gehe natürlich davon aus, dass du ihn liest. Dass du ihn liest ist mein Ziel, aber eigentlich will ich dir sagen:

Don´t read! Do! Try!

 
Sei ein Versucher, sei ein Mensch, der Dinge ausprobiert und auf diese Weise herausfindet, was er wirklich http://www.wordsoverpixels.com/will. Der Titel: “The Art of Non-Conformity” – ist für mich genial. Ein Buch, ja eine ganze Website darüber zu schreiben, was man eigentlich nicht tun sollte, nämlich das tun, was einem andere sagen – schon genial. Aber es läuft im Grunde auf das Eigene, das Selbst-Versuchen heraus.
Jetzt werden einige sagen … hm, aber was soll ich denn tun? Leben! Sich spüren, herausfinden, welche Bedürfnisse du hast. Was turnt dich an? Ist es etwas künstlerisch Kreatives oder eher etwas Geschäftliches? Ist es Menschen zu helfen oder ist es einfach, etwas zu machen, was nur du tun willst. Das Faszinierendste, was ich dazu derzeit gefunden habe, sich in der Stadt selbst zu spüren: Parkour [http://en.wikipedia.org/wiki/Parkour]. Tu, wozu du jetzt Lust hast. Guillebeau hat einen wichtigen Aspekt in seinem Buch erkannt: Er schreibt darüber, dass dazu gehört, keine Angst zu haben. Nimm dein Leben und dich selbst dabei nicht so wichtig! Nicht jede Entscheidung ist lebensentscheidend, und selbst wenn es so wäre … du kannst sie doch alle korrigieren. Jederzeit!
Das Leben zu leben … also loszulassen und dennoch seinen Weg zu gehen, dass ist der wirkliche Weg zur Non-Conformity. Und für einige wird das bedeuten, sie bleiben genau da, wo sie jetzt sind. In ihrem Beruf, in ihrem Job, in ihrer Welt. Entscheidend ist nur, dass dieser Weg rational gegangen wird. Also nicht vernünftig, sondern “bedacht”, im wahrsten Sinnde des Wortes. Mit Bedacht, nicht überlegt, sondern achtsam, auf sich hörend. Frage dich: “Will ich das jetzt gerade? Treffe ich jetzt, hier in diesem Moment die Entscheidung, die mir entspricht? Ist es die Entscheidung, die zu mir passt, zu dem wie ich mich im Moment fühle?”
Das geht nur durch nachspüren. Wenn das so ist … dann … Do it! Denn dann ist es auf jeden Fall das Richtige! Dann bist du auf dem Weg zu deinem eigenen Leben.

Die besten ScrumMaster sind gute Zuhörer

Krösus war der letzte König von Lydien. Er regierte von etwa 555 bis 541 vor Christi Geburt. Der griechischen Sage nach befragte Krösus seinerzeit das Orakel von Delphi, ob er einen Sieg davontragen würde, wenn er gegen die befeindeten und mächtigen Perser marschiere. Das Orakel antworte dem König mit den folgenden Worten:
[quote author = “Orakel von Delphi”]„Wenn du den Halys überschreitest, wirst du ein großes Reich zerstören.“[/quote]
Krösus frohlockte und dachte sich gleichzeitig, welches Reich wohl mächtiger als das der Perser sein könne und zog mit seinem Heer, motiviert von den Worten des Orakels, hochmütig und siegesgewiss in den Kampf. Schließlich hatte ihm das Orakel praktisch garantiert, dass er einen großen Sieg davontragen würde. Die Geschichtsbücher besagen jedoch, dass Krösus die Schlacht gegen die Perser verlor. Was war passiert? Hatte das Orakel von Delphi gelogen? Mitnichten. In seinem Wunsch nach einem epochalen Triumph hörte Krösus nur noch, was er hören wollte. Was er überhörte, wenn nicht gar ignorierte, war die Rückfrage, welches Reich das Orakel mit der Prophezeiung wirklich gemeint hatte. So besiegelte Krösus seinen eigenen Untergang.
Krösus erinnert mich mit seiner fatalen, aber durchaus bei uns Menschen gängigen Art der Entscheidung an die vier blinden Gelehrten, die herausfinden wollten, wie ein Elefant aussieht. Der erste ertastete den Rüssel des Elefanten und meinte, dass ein Elefant wie ein langer Arm aussehen müsse. Der zweite Weise ertastete das Ohr und meinte, ein Elefant sei wie ein großer Fächer. Der dritte Gelehrte, der die Beine ertastete, meinte, ein Elefant sei wie die Säulen eines Palastes. Der vierte Weise, der den Schwanz ertastete,
 beschrieb den Elefanten schließlich als ein dickes langes Seil.
Natürlich ging jeder der vier weisen Männer davon aus, dass seine Erklärung der Realität die richtige sei und gleichzeitig schlossen sie damit andere denkbare Beschreibungen aus. Krösus war von dem Bild der Zerstörung eines großen Reiches – dem der Perser – so überzeugt, dass er vollkommen blind für andere mögliche Interpretationen bzw. Konstruktionen seiner Wirklichkeit war. Er hörte, was er hören wollte.

Ein guter ScrumMaster,

„eine Führungspersönlichkeit, die verändern will, (…) ein Change Agent, der die Macht, die Gegebenheiten zu ändern, nicht aus seiner Position bezieht, sondern aus seiner Überzeugung und aus dem Rückhalt, den er von Menschen bekommt, für die er sich einsetzt“ [1], darf unter keinen Umständen so blind oder vielmehr taub wie Krösus (re-)agieren. Sie/er muss sich darüber bewusst sein, dass sich sowohl verbale als auch nonverbale Botschaften durch Indirektheit, Mehrdeutigkeit, Ungenauigkeit, Unvollständigkeit, Widersprüchlichkeit oder Parallelität auszeichnen. Um diesem besonderen Anspruch zu genügen und seine besondere Verantwortung „from the Position of No-Power“ gewinnbringend und im Sinne einer Veränderung auszuüben, bedarf es der besonderen Fähigkeit des Zuhörens. Ein guter ScrumMaster muss ein guter Zuhörer sein.

Fünf Formen des Zuhörens

Die enorme Bedeutung des Zuhörens und die unzähligen Veröffentlichungen zu diesem Thema führten dazu, dass die verwendeten Begrifflichkeiten wie Kraut und Rüben durcheinander gerieten, synonym oder in ihren Bedeutungen falsch verwendet wurden. Selbst für das von Carl Rogers vor fast sieben Jahrzehnten beschriebene aktive Zuhören finden sich diverse Definitionen. Ich möchte dieses Wirrwarr ein wenig entzerren und ScrumMaster mit einem übersichtlichen Zuhör-Portfolio ausstatten. Denn wie schon Calvin Coolidge, 30. Präsident der Vereinigten Staaten von Amerika, sagte: „Zuhören können ist der halbe Erfolg.“
Aus meiner Sicht gibt es fünf Formen des Zuhörens:

Probieren geht über studieren. Nicht selten gibt es auch Vermischungen bei den Formen des Zuhörens. Ich kann jeden ScrumMaster nur einladen, sich auszuprobieren und sich regelmäßig zu hinterfragen, ob man auch richtig zugehört hat. Zur Vertiefung des Zuhörens möchte ich noch zwei Übungen, die einen ScrumMaster zum guten Zuhörer machen, anführen:

Der Voice Mirror – die besondere Zuhör-Technik für erfolgreiche ScrumMaster

Beim Voice Mirror sprechen wir Wort für Wort bei den Ausführungen unseres Gegenübers mit. Das Nachsprechen geschieht jedoch lautlos und ist von außen nicht offensichtlich wahrnehmbar. Diese Zuhör-Technik unterstützt dabei, die eigene Aufmerksamkeit vollkommen und nahezu ungestört auf den Kommunikationspartner zu fokussieren. Eigene Gedankengänge werden auf diese Weise ausgeblendet.
So kannst du den Voice Mirror in drei Schritten üben

Schritt 1

Schalte den Fernseher oder das Radio an und wähle eine beliebige Stimme aus. Flüstere anfangs synchron mit dem Sprecher Wort für Wort mit (Tipp: Nachrichtensendungen bieten sich hierfür besonders an).

Schritt 2

Wenn du bereits etwas vertrauter mit dem synchronen Flüstern bist, dann stelle den Ton leiser und bewege nur noch deinen Mund zu dem Gesprochenen mit.

Schritt 3

Sprich das Gesagte nur noch in Gedanken Wort für Wort mit.

Adler – Ameise – Stier

Wie wir am wenig nachahmenswerten Beispiel von Krösus erfahren haben, erscheint es sinnvoll, eine (Problem-)Situation oder ein Verhalten aus verschiedenen Blickwinkeln zu betrachten. Das Ziel des Adler-Ameise-Stier-Konzepts besteht in der Dissoziierung des Gehörten unter Nutzung so genannter Metapher-Tiere.

[1] Boris Gloger: Scrum – Produkte zuverlässig und schnell entwickeln. Hanser, 3. Auflage, 2011.

Kreativitätstechniken

Ich sitze an meinem Schreibtisch und möchte für mein Scrum-Team eine neue Retromethode entwerfen. Die Zeit vergeht und vor mir nur das leere Blatt. Schon drei Mal habe ich angefangen etwas aufzuschreiben. Drei Mal wieder gelöscht. Was soll ich mit ihnen machen? Was interessiert mein Team, die Leute sind doch alle so unterschiedlich? Womit begeistere ich sie?
 
Na, kommt euch die Situation bekannt vor?
Ich möchte was Cooles machen, um mein Team aus seinem Alltag herauszuholen und den Leuten eine frische Retro anbieten. Weg von 08/15 … Natürlich kann ich googeln. Mit Retrospektiven haben sich schon viele auseinandergesetzt. Aber ich möchte etwas Individuelles anbieten. Etwas, das die Persönlichkeit meines Teams herausstellt …
 
Was hindert uns daran, auch mal unsere Ideen zu sammeln. Und das ist gar nicht so schwer. Hier einige Möglichkeiten, um der eigenen Kreativität auf die Sprünge zu helfen:

  • Klingt simpel, aber hilft ungemein: einfach mal aufstehen. Im Büro oder noch besser im Grünen spazieren gehen. Die Gedanken vom eigentlichen Problem lösen und neue Eindrücke sammeln.
  • Ein Flipchart oder Brownpaper an die Wand hängen und einfach mal anfangen zu malen. Aber auch hier gilt: einfach die Gedanken fließen lassen. Es geht hier ja nicht um den neuen Picasso, sondern um das Fokussieren auf neue Gedanken.
  • Habt ihr Playmobilfiguren rumliegen? Ich stelle die Figuren in verschiedenen Konstellationen auf und überlege, wie sie in Interaktion treten können.
  • Eine klassische Methode ist das Mindmapping. Hier schreibt man das Thema/Problem in die Mitte eines Blattes und legt Äste von der Mitte aus an, um einfach alle Ideen unbewertet zu sammeln.

Und was ist aus meiner Retro geworden? Die Flipchartmethode hat meine Kreativität angespornt. Quasi die Idee in der Idee: Ich lasse mein Team malen. In Kleingruppen lasse ich sie zeichnen, was gut gelaufen ist. Die Kunstwerke werden vorgestellt, indem die jeweils anderen Gruppen erraten, was das Gezeichnete darstellt. Diese Übung bringt auf jeden Fall Spaß und Abwechslung zum Standardprogramm.

Agiles Risikomanagement mit Scrum – empört euch!

Eine der spannendsten Definitionen für Risiko, die ich in der letzten Zeit gelesen habe, kommt von Peter Sandman: “Risiko = Gefahr + Empörung”. Im öffentlichen Leben, leider aber auch in vielen Organisationen bleiben die meisten Leute in der Empörung stecken und schüren negative Emotionen, statt sich mit der eigentlichen und drohenden Gefahr zu beschäftigen.
So kann es schnell passieren, dass man sich über eine große Gefahr zu wenig empört oder eine kleine Gefahr mit viel Empörung zu sehr aufbauscht. Sehen wir uns das Beispiel der Brent Spar aus dem Jahr 1995 an: Der Konzern Shell wollte einen schwimmenden Öltank in der Nordsee versenken. Greenpeace besetzte die Brent Spar und sorgte dadurch für großes Medienecho, das von der Bevölkerung stark aufgenommen wurde. Im Nachhinein stellte sich heraus, dass die Empörung stärker war als die angenommene Gefahr. Aber erst die große Empörung führte dazu, dass das Risiko für die Entsorgung so groß eingeschätzt wurde, dass der schwimmende Öltank nicht mehr versenkt wurde.
Vor allem, wenn wir über Zukünftiges diskutieren, empören wir uns schnell und werden emotional. Wir wissen nicht, was kommen wird. Diese Unsicherheit zwingt uns zu Vermutungen und bringt unsere Befindlichkeiten ins Spiel. Und während wir Zeter und Mordio schreien, verlieren wir den Kontakt zu den Tatsachen und geben einem Risiko manchmal mehr Macht, als es tatsächlich hat.
Viele der Risiken, die uns bei der Produktentwicklung begleiten, entstehen während der Entwicklung des Produkts. Dass man zu diesem Zeitpunkt genau hinsieht, ist umso wichtiger. An dieser Stelle befassen wir uns in Scrum, dank eines empirischen Prozesses, mit Fakten – wir brauchen also keine Vermutungen mehr. Denn oft sind es, neben Time to Market, die Probleme der Organisation, die die Produktentwicklung gefährden.
“Wie geht Scrum eigentlich mit Projektrisiken um?”, ist eine der Fragen, die in diesem Zusammenhang gerne gestellt wird. Hier 6 Punkte, die uns in der Agilen Software-Entwicklung und vor allem in Scrum helfen, effektiv mit Risiken umzugehen:

  1. Agile Werte und Prinzipien
  2. Impediment Backlogs und der ScrumMaster
  3. User Stories und die Frage “Wozu?”
  4. Schätzungen (Estimates)
  5. Schnelles Feedback durch End-User
  6. Potentially Shippable Increment

Agile Werte und Prinzipien

Durch einen offenen und mutigen Umgang mit Impediments gehen wir gemeinsam Risiken der Produktentwicklung an. Wir begrüßen Veränderung, sowohl organisatorisch, als auch auf das Produkt bezogen. Unseren Erfolg messen wir allein am Fortschritt des Produkts und setzen Kooperation an die Spitze unseres Handelns.
Wir sind uns also des Risikos bewusst, dass eine zu genau geplante Zukunft ein sehr großes Risiko ist. Stattdessen arbeiten wir in kurzen Zeitspannen (Sprints) und reagieren frühzeitig auf die Veränderungen der Geschäftswelt. Wir berücksichtigen die Kundenwünsche, nehmen sie auf und gehen sie zum richtigen Zeitpunkt an – und zwar zum Zeitpunkt der Umsetzung. Somit widmen wir uns immer nur den wichtigen Anforderungen und unterscheiden zwischen wichtig und unwichtig.
Ein offener und mutiger Umgang mit Herausforderungen, Fortschritt und Hindernissen hilft uns dabei, die Risiken aus dem Weg zu räumen.

Impediment Backlogs und der ScrumMaster

In Scrum beschäftigen wir uns an mehreren Stellen mit Hindernissen und Problemen (Impediments). Dabei handelt es sich um die Risiken, die während des Projekts auftreten und das Produkt gefährden. Wir sammeln und verwalten die Impediments transparent und öffentlich in Impediment Backlogs.
Aus dem Impediment Backlog können wir sehr gut ablesen, welche Risiken im Projektverlauf in der Praxis auftreten. Hier findet man bspw. die zwischenmenschlichen Probleme und organisatorischen Hindernisse, die während der Zusammenarbeit entstehen. Wir unterteilen Impediment Backlogs nach Kontroll- bzw. Einflussbereichen:

  1. Kann es vom Team gelöst werden, liegt die Verantwortung in der Zusammenarbeit zwischen den Teams oder in der Organisation. Folglich zeigt das Impediment Backlog des Teams die Hindernisse auf, die das Team betreffen und bei der Arbeit behindern.
  2. Abhängigkeiten zu anderen Teams findet man in der Skalierung auf dem Company Board.
  3. Im ScrumMaster Impediment Backlog verwalten die ScrumMaster gemeinsame, organisatorische Impediments und koordinieren über das Board ihre Vorgehensweise.

Dadurch, dass wir in Scrum echte Boards verwenden, machen wir Impediments für alle sichtbar. Damit können wir zum einen zeigen, dass Impediments vorhanden sind (Push-Prinzip), zum anderen steigert es die Empörung und es wird notwendig, einer Gefahr ins Auge zu sehen.
Der Umgang mit Impediments und der Organisationsentwicklung bekommt in Scrum einen besonderen Stellenwert: Der ScrumMaster ist organisatorisch eingesetzt, um die Veränderungen an der Organisation voranzutreiben, damit sie schnell den Anforderungen gerecht wird. Er muss den Status Quo der Organisation angreifen, damit sich die Organisation in punkto Zusammenarbeit und Kultur positiv verändert. Er stößt also mit den Anforderungen der Gegenwart an die Grenzen des organisatorischen Rahmens, der ja auf den Kenntnissen der Vergangenheit beruht. Aus der Erfahrung heraus wissen wir, dass das größte Risiko bei Veränderungen darin liegt, zu langsam zu sein. Dass Veränderung nicht fehlschlägt, weil sie zu früh kommt, sondern weil wir zu lange gewartet haben – weil es nur wenige gibt, die die Veränderung nach vorne tragen. Bei einem ScrumMaster steht das in der Jobbeschreibung, er wurde für den Wandel angestellt.

User Stories und die Frage “Wozu?”

User Stories fordern und fördern Diskussionen. Dadurch verteilen wir das Wissen um Domäne und Anwendungsfall im gesamten Team. Durch Diskussionen schaffen wir den Raum für Fragen, Mitdenken und Kritik, lösen die Mehrdeutigkeit der Sprache leichter auf und vervollständigen das gemeinsame Bild der Story. Sobald wir als Team diskutieren und wir den Zweck der Funktion kennen, entwickeln wir eine gemeinsame Verantwortung (Ownership).
Warum Diskussion zur Dokumentation? Mike Cohn bringt es auf den Punkt: “If you write them down, users will get exactly what they want. That’s not true. At best, users will get exactly what was written down, which may or may not be anything like what they really want.” (Mike Cohn, Succeeding with Agile, Addison-Wesley, 2010).  Durch Diskussion nutzen wir das Potential der Gruppe, wir schaffen ein gemeinsames Verständnis und geben jedem eine Stimme. Denn erst durch die Bilder aller Beteiligten erkennen das komplexe System, in dem wir uns bewegen.
Wozu das wozu?
Die Anforderungen an unser System ändern sich. Ich weiß nicht, wie oft ich das schon gesagt, gelesen, geschrieben, gehört, gesungen, getanzt und… okay… in jedem Fall hilft uns das “wozu” auf mindestens drei Arten:

  1. Es ist wertorientiert und der Wert ist beständiger als die beschriebene Funktion. Zudem lässt sich nur anhand eines Wertes bestimmen, ob die Funktion noch benötigt wird.
  2. Der Wert kommuniziert das benötigte Verhalten besser als die Funktion selbst. Versteht ein Team, wozu die Funktion notwendig ist, so kann es diese anhand des Wertes kontrollieren. Ist nur der Wert bekannt, so kann das Team die Funktion entwickeln. Sind Funktion und Wert bekannt, kann das Team die Funktion in Frage stellen und ein besseres Ergebnis liefern.
  3. Werte lassen sich anhand von Business Value vergleichen. D. h. Werte verstehen wir, sie sind eindeutiger und lassen weniger Spielraum für Interpretationen. Bei Funktionen muss jeder den Wert meist erst interpretieren, ihn sich “laden”. Im Gegensatz dazu ist meist jedem klar, wie ein Wert durch eine Funktion erreicht werden kann. Durch Werte engen wir den Interpretationsspielraum einer Funktion ein.

Letztlich entzerrt die Frage nach dem “wozu” die Anforderung von der Implementierung und hilft uns, den Wert der Story zu verstehen. Wir schränken dadurch im Vorfeld nicht unseren Lösungsraum ein, sondern lassen die Art der Implementierung frei. Wir benennen die Funktion, zeigen den Wert auf und geben diese Anforderung dann weiter. Jetzt kann das DevTeam seine Expertise einbringen.

Schätzungen (Estimates)

Wenn wir User Stories und Anforderungen betrachten, dann stolpern wir immer wieder über Probleme beim Verständnis und Detaillierungsgrad, sowie der technischen Umsetzung der Stories. Um die richtige Größe zu finden und Risiken bzgl. der technischen Umsetzung zu identifizieren, schätzen wir in Scrum regelmäßig unser Product Backlog.
Mit Schätzungen (Estimates) identifizieren wir die Stories, die fachlich zu ungenau oder technisch zu schwer zu realisieren sind. Wir schätzen und erarbeiten gemeinsam im Team die Stories und bilden dadurch die Grundlage für einen Releaseplan. Schätzt das DevTeam, dann bekommen die Spezialisten eine gewichtige Stimme. Dadurch adressieren sie Risiken bzgl. Verständnis oder Ungewissheit der Umsetzung. Sind solche kritischen Stories identifiziert, untersuchen wir sie schnellstmöglich durch Experimente (Sprints). Wir schaffen somit eine faktenbasierte Entscheidungsfindung durch Inspektion. Anhand der Ergebnisse können wir unser weiteres Vorgehen abstimmen, da wir die riskanten Punkte bereits getestet haben.
Ein wichtiger Punkt ist, dass wir nicht einmalig schätzen, sondern kontinuierlich. D. h. wir schätzen eine Story mehrmals und bringen sie in ein Größenverhältnis zu anderen Stories. Außerdem verändern sich Stories in ihrer Größe über die Zeit, auch das wird berücksichtigt (bspw. wird ein Prozess  für ein Audit relevant und muss nachverfolgt werden). Letztlich sind unsere Schätzungen die Grundlage für die Arbeit am Produkt in der Zukunft und auch hier kann wieder der Faktor Empörung eingesetzt werden, um besonders gefährliche Stories in einem Backlog auszumachen. Die Stimme der Experten im DevTeam müssen ein Gewicht für die strategische Entwicklung des Produkts bekommen. Umso wichtiger ist es daher, dass Estimation Meetings regelmäßig durchgeführt werden.

Schnelles Feedback durch End-User

Plan – Do – Check – Adapt: der Regelkreis der Qualitätssicherung nach William E. Deming ist die Grundlage kontinuierlicher Verbesserungsprozesse und die Hintergrundmusik von Scrum. In Scrum führen wir jedes dieser Elemente in Form von Arbeits-Meetings aus, denn Qualität ist die Grundlage der Risikominimierung.
Risiken sind wahrscheinlich eintretende Fehler. Um zu erkennen, ob ein Risiko eingetreten ist, müssen wir schnell und regelmäßig die Ergebnisse unserer Arbeit prüfen. Dazu brauchen wir Feedback vom Kunden und von End-Usern, die das Produkt einsetzen. Das Feedback holen wir am Ende eines Sprints im Review ein. Hier inspizieren wir die neuen Funktionen und verifizieren, ob wir das richtige Produkt gebaut haben. Wir verifizieren also nicht nur: “Läuft das Ding?” – nein, wir prüfen/validieren, ob es auch so läuft, wie es ursprünglich gewünscht war.
Konkret ist das Review der Zeitpunkt, an dem das DevTeam wieder mit dem End-User zusammenkommt. Hier tanken die Beteiligten Wertschätzung und Motivation für die eigene Arbeit, tauschen sich über den Nutzen der Funktionen aus und lernen, einander besser zu verstehen. Meines Erachtens lassen sich viele Risiken bei der Zusammenarbeit alleine dadurch auflösen, dass man Menschen zum einen zusammenbringt und dem Gegenüber ein Gesicht gibt, und zum anderen ein Ergebnis schafft, über das diskutiert werden kann.
Abstrakt gesehen führt uns das Review dazu, dass wir unsere Ergebnisse sichtbar und greifbar machen. Wir schaffen anschauliche Fakten, die eine konkrete Diskussion zulassen. Wir unterstützen das Verstehen der Beteiligten mit einer gemeinsamen Grundlage und erden das theoretische Verständnis durch praktisches Erfassen.
Das Review zeigt uns Folgendes frühzeitig auf: Große Empörung = frühes Scheitern, frühes Erkennen von Fehlern. Und auch frühe Erfolge mit und ohne Scheitern. Denn Scheitern und Fehler sind Entdeckungen, die wir im Vorfeld nicht erkennen konnten. Oft erkennen wir erst durch die neuerlangten Ergebnisse den nächsten Schritt für unser Produkt.

Potentially Shippable Increment

Besonders bei Neuentwicklungen steckt ein großer Teil der Arbeit bei klassischen Projekten in der Planungs- bzw. Erfindungsphase. Wieviel unnötig dokumentiert und wieviel Information auf Halde produziert wird, lässt sich oft nicht sagen. Solange kein Ergebnis im Sinne eines Produkts fertiggestellt wird, bleibt der geschaffene Wert von Dokumentation und Information unsichtbar. Darüber hinaus besteht die Gefahr, dass zu viel Dokumentation und Information gesammelt wird und dabei hohe Kosten ohne direkten Gegenwert entstehen. Seth Godin schreibt in seinem Buch Tribes dazu:  “The safer you play your plans for the future, the riskier it actually is.”
Priorisierung, kurze Sprints und dazu ein Potentially Shippable Increment am Ende jedes Sprints (Deliver every Sprint) helfen uns sehr, solche Risiken zu minimieren. Wir bekommen in jedem Sprint lauffähige, anwendbare Software, die Features mit dem höchsten Business Value liefert. Im Fall eines Projektabbruchs ist unsere Software lauffähig und kann eingesetzt werden. Funktionen sind durch alle Schichten hindurch implementiert und funktionsfähig. Wir können bspw. auch, sobald die wichtigsten Funktionen implementiert sind, die Entwicklung einstellen oder unmittelbar umschwenken. Dazu ist es wichtig, sich während des Sprints zu fokussieren. D. h., liefere Story für Story nach Business Value. Dadurch erhält man nach jedem Sprint ein System in einem lauffähigen Zustand.
“Liefere jeden Sprint” heißt auch, dass wir tatsächlich eine niedrige Time to Market haben und kurzfristig unser Produkt an neuen Kundenwünschen ausrichten können. Wir bekommen die Flexibilität, die wir benötigen und das bei konstanten Kosten. Zusätzlich können die End-User das Produkt frühzeitig nutzen, was wiederum auf die finanzielle Risikominimierung einzahlt.

Fazit

Die agile Produktentwicklung ist ein Baukasten, der stark darauf ausgerichtet ist, die Wahrscheinlichkeit von Fehlern bzw. Gefahren (Risiken) zu minimieren. Genauer gesagt haben wir damit einen Prozess für aktives Risikomanagement. Die Wahrnehmung von Risiken hängt sehr stark am Faktor der Empörung, der für die verbundenen Gefahren entstanden ist. Dazu kommt die Wahrscheinlichkeit, mit der ein Fehler eintritt, der die Gefahr auslöst.
Scrum trägt dazu bei, Fehler frühzeitig zu erkennen und wertvolle Ergebnisse zu schaffen. Erreicht wird das dadurch, dass frühzeitig Ergebnisse geschaffen werden, Unsichtbares visualisiert wird, Empörung an den wichtigen Stellen verstärkt wird und wichtige Erkenntnisse von Experten frühzeitig anhand von Fakten diskutiert werden. Denn komplexe Systeme benötigen ein Vorgehen, das Entscheidungen aufgrund von Fakten trifft. Mit Scrum haben wir zusätzlich eine Methode, die erfolgreich den Status Quo angreifen kann und uns dadurch überdurchschnittliche Gewinne beschert. Wenn wir in kurzen Zyklen Funktionen mit Produktreife liefern und unsere Ergebnisse verifizieren, vermeiden wir Fehler und wandeln Risiken in Wettbewerbsvorteile um. Und das alleine durch entschiedenes Handeln. In jedem Management-Magazin der letzten Jahre wird empfohlen: Lassen Sie sich auf Experimente ein und versuchen Sie, durch schnelle Erfolge oder schnelles Scheitern zu lernen. Scrum hilft dabei, diese Experiment durchzuführen. Experiment und Scrum bieten Rahmen und Raum, den Menschen benötigen, um effektiv zu arbeiten und setzen die notwendigen Kontrollpunkte, um Risiken zu minimieren. Viel Erfolg!

Entscheidungshilfen aus dem Alltag

Letztens, beim Scrum Breakfast in Wien, erzählte eine ScrumMasterin von ihren Kollegen, die Schwierigkeiten haben, Entscheidungen zu treffen. Und von ihrem Lösungsansatz: Sollte die Entscheidungsfindung ins Stocken geraten, bietet sie normalerweise eine Reihe von Antworten an:

  1. ja
  2. nein
  3. keine Ahnung
  4. habe Angst

In besonders schwierigen Situationen hat sie auch noch eine zusätzliche Alternative:
5. ich muss Mama fragen
Dieses Erlebnis spornte meine Kollegin Ina Kurrek und mich an, nach weiteren alltäglichen „Entscheidungshilfen“ zu suchen. So entstand diese Liste, die keinen Anspruch auf Vollständigkeit erhebt.
0-1-Variante

Gremium- und Gruppen-geeignet

Esoterische Ecke

Beratungsfreudige Entscheidungsunterstüzer

Technischen Hilfen

 
Selbstverständlich fehlt auf der Liste noch das Bauchgefühl.
Aber egal, wie man zu der Entscheidung kommt: Wichtig ist, sich überhaupt zu entscheiden und dann –  einfach mal machen … Just do it!

Der Sinn des Dilettantismus in der agilen Produktentwicklungswelt

“Für sinnkonstituierende Systeme hat alles Sinn.“ (N. Luhmann)
Soll heißen: Auch der scheinbare Unsinn besitzt eine sinnstiftende Funktion.
In dem Artikel “Dem Amateur ist nichts zu schwör” aus dem Magazin der Süddeutschen Zeitung (Nummer 24/ 20120615), wird der Scheinwerfer auf die Dilettanten in der Politik, Wirtschaft und Wissenschaft gerichtet und auf das Faktum, dass nervige und zunächst substanzlos wirkende Fragen oftmals zum Nach- und Neudenken bewegen.
Berichtet wird unter anderem über das in New York beheimatete “Genspace”. Dabei handelt es sich um ein Labor, dessen Team aus Künstlern, Programmierern und einem einzigen Biologen besteht, das an zunächst sinnfrei erscheinenden Themen/Produkten forscht/entwickelt. Zum Beispiel möchte man, dass Zellen das tun, was man ihnen befiehlt oder dass Bakterien bei Schwarzlicht bunt leuchten. Zur Vorbereitung bekommen die Laien einen Einführungskurs in Genforschung und dann … werden sie losgelassen.
Es existieren nicht viele Gesetze, best practices, Rituale (auch verhaltensbasiert) dazu, was und wie man “es” tut. Dadurch existieren auch die in der Vergangenheit von den “ausgebildeten Experten” aufgestellten Denkblockaden – oder nennen wir es “creative thinking in a jail” (Kreativität des Denken in einer Gefängniszelle) – nicht. Einen Beweis, dass ein Dilettantenteam etwas Gehaltvolles liefert, ist am Anfang nicht möglich. Es braucht Pioniere mit Mut, Courage und Verstand die es: einfach mal machen.
Naja die Süddeutsche würde aber nur ungern so etwas ohne Bewies veröffentlichen und hat bis heute gewartet, um ihre Leser mit Sicherheit einzulullen:
Vor Zwei Jahren wurde ein Artikel in Nature, dem wichtigsten Wissenschaftsmagazin der Welt, veröffentlicht, dessen Ergebnisse teilweise von Amateuren stammten, die in einer Art Computerspiel die Struktur von Proteinsträngen analysiert hatten.”

Tipps vom Dilettanten?

Ich erlebe in meiner Arbeit häufig Meetings, bei denen vermeintliche Dilettanten Feedback und Verbesserungstipps zu einem hochkomplexen Produkt geben, das soeben von – zumindest für dieses Produkt – gestandenen Professionellen gebaut wurde. Es sind die Reviews, in denen das Scrum-Team auf die User und Stakeholder trifft, um aus dem Meeting Input & Improvements mitzunehmen. Nun erlebe ich im Anschluss der Vorstellung eines ProduktInkrements öfters, wie Wünsche, Fragen, und Feature-Ideen aus dem Dilettantenkreis auftauchen, an die die Entwickler keinen Gedanken “verschwenden” und direkt abwinken: “absurd”, “unmöglich”, “epic lol”…
Warum?
Sie bedienen sich des manifestiert Erlernten, bewegen sich somit in ihrem “creative thinking in a jail”, das genug Gesetze, Rituale, best practices kennt, um diese Ideen lebenslänglich in Einzelhaft zu nehmen. Mit viel Glück bekommt man noch ein “Jaaaa, in 10 Jahren vielleicht…” und sofort darf ich eine Frage stellen: “Was müsste denn bis dahin geschehen?” Das ist eine typische Frage, die in Startup-Unternehmen der Trigger ist, um innovative Produkte mit kreativen Lösungen für die Welt zu finden. Es ist die Freiheit, den Sinn der Gegebenheiten einmal zu ignorieren und seiner Kreativität dabei zu helfen, auszubrechen. Lösungen tatsächlich “out of the box” finden zu müssen.

Dilettanten sind Erneuerer

Die Süddeutsche erinnert an folgende Tatsache: “In der Kulturgeschichte galten Dilettanten lange Zeit als Erneurer.” Es ist nicht einfach, die Sinnfreiheit und den Dilettantismus zu nutzen, aber damit wir bei agiler Produktentwicklung wirklich etwas Neues schaffen, sollten wir es einfach mal machen.
Es war ja auch schon immer sinnfrei Jazz und elektronische Musik zu vereinen. Fragt dazu den ehemaligen Electromusic-Dilettanten Klaus Waldeck.
Es war ja auch schon immer sinnfrei, Klassik und elektronische Musik zu vereinen. Fragt dazu den ehemaligen Klassik-Dilettanten Henrik Schwarz.
Oder hört einfach mal in eure Produkte hinein. Um der Süddeutschen zu huldigen: Die beiden haben sich heute schon bewiesen und ihre Produktionen werden teilweise auf den wichtigsten Labels der Welt veröffentlicht.

Warum wir eigentlich alle Freelancer sind

Neulich beim Kunden fragte mich ein Teammitglied, ob der Scrum-Ansatz eigentlich von Freelancern stammt. Nach all dem, was er bisher gehört und erlebt habe, sei er sich sicher, dass der Ansatz von Freelancern stammt und auch für Freelancer gedacht ist. „Weswegen?“ fragte ich ihn. „Weil das Team seine eigenen Technologien verwenden darf. Hauptsache, der Kunde bekommt die gewünschte Funktionalität. Und weil jeder viel Verantwortung trägt und viel mit dem Kunden kommuniziert.“ Ich sagte ihm, dass der Ansatz tatsächlich die Eigenverantwortung und Loyalität so steigert, dass man sich auch als Teammitglied wie ein Unternehmer im eigenen Unternehmen fühlen kann. Und dass das auch gut so ist. Er fand das auch gut und war begeistert von seiner Idee. Er ließ nicht locker und sagte: „Und dass wir dann ein Review machen und Feedback vom Kunden einholen und das im nächsten Sprint Planning einfließen lassen. Das machen Freelancer doch auch! Wir kitzeln aus dem Kunden heraus, was er denn eigentlich von uns haben will und überlegen uns im Nachgang, wie wir es dann umsetzen werden.“ Obwohl Scrum nicht dezidiert für Freelancer und auch nicht von Freelancern entwickelt wurde, so gab ich ihm dennoch Recht, was die genannten Parallelen angeht.
Ziel von Scrum ist es ja, dass jeder innerhalb des Scrum-Teams sich stärker mit dem Produkt identifiziert und entsprechend wie ein Unternehmer handelt: Was will eigentlich der Kunde? Was bringt den höchsten Business Value? Wir müssen hohe Qualität liefern! Wir wissen, wo die Reise mit dem Produkt hingeht!
Ja, im Prinzip hat er Recht. Letztendlich sind alle Scrum-Team-Mitglieder wie viele Freelancer, von denen jeder Einzelne bemüht ist, seine Aufgabe bestmöglich abzuliefern, um ein gutes Produkt und eine hohe Kundenzufriedenheit zu erreichen. Nur mit dem Unterschied, dass letzten Endes die Gesamtleistung der Teammitglieder zählt und wir uns im sicheren Schoß eines Unternehmens befinden.

Sich zu verstehen ist auch Teamarbeit – ein Warm-up für das Sprint Planning

Mit einer anderen Person zu sprechen, dieser etwas mitzuteilen, sich mit ihr zu unterhalten, sich argumentativ auszutauschen, hat häufig zum Ergebnis, dass die beiden Gesprächspartner auseinandergehen und genauso klaffen ihre Bilder der Situation vollkommen auseinander. Bereits im Kindergarten machen wir beim Spielen erste Erfahrungen mit dieser Kommunikationsprämisse. Jedes Kind kennt „Stille Post“. Ein Kind flüstert einem zweiten eine Botschaft ins Ohr. Das zweite Kind gibt das, was es gehört bzw. verstanden hat, an ein drittes Kind weiter. Die Nachricht wird bis zum letzten Empfänger weitergegeben. Was am Ende der Kommunikationskette rauskommt, lässt die Spieler meistens in schallendes Gelächter ausbrechen. Denn es ist inhaltlich etwas vollkommen anderes als das, was kurz zuvor auf die Reise geschickt wurde. In der Kinderwelt ist es einfach ein lustiges Spiel. In der Kundenwelt und im Management von Wünschen und Anforderungen ist es ein Graus und trägt oftmals zu Missverständnissen und Fehlschlägen bei.
Der Anspruch zu “verstehen, was der Kunde haben möchte” und die sich daraus ableitende Forderung “sicherzustellen, dass er genau das auch bekommt” (Colin Hood, Experte Systems Engineering) sind hoch – insbesondere dann, wenn wir uns vor Augen führen, was es bedeutet, einen Anderen (in diesem Fall den Kunden) zu verstehen.
“Verstehen hat seinen eigentlichen Ort in menschlichen Gesprächen. Sofern wir eine Sprache zu sprechen gelernt haben, wissen wir (…) zu unterscheiden, ob wir jemanden verstanden zu haben glauben, oder ob wir, was jemand gesagt hat, verstanden haben, wenn er oder sie uns etwas mitteilt (das ist die Grammatik des Ausdrucks mitteilen: jemand teilt jemandem etwas unter Verwendung von Mitteln mit). Und wir sagen dann, wir  hätten ihn oder sie verstanden, wenn wir nicht nur das Gesagte (den ‚Inhalt’, die Proposition), sondern auch die bestimmte Art und Weise, in der uns jemand etwas mitteilt, richtig aufgefasst haben, und das heißt zunächst: Wenn unsere Auffassung unwidersprochen bleibt. In metaphorischer Annäherung: Wir haben verstanden, wenn wir sagen können, dass wir das, was uns jemand mitgeteilt hat, miteinander teilen. Wir beurteilen unser Miteinander-Sprechen  dann unter Verwendung des Ausdrucks ‚verstehen’, wenn wir, was und wie mitgeteilt wurde, gemeinsam haben.”  (Jan Müller, 2008)

Richtig verstehen und richtig weitergeben

Ein Product Owner ist bei der Erstellung seines Product Backlogs für das Erfassen der Kundenbedürfnisse und die Beschreibung der damit verbundenen Anforderungen verantwortlich. Um dies im Sinne des Kunden angemessen leisten zu können, gehört es zu seinen Aufgaben, die Bedürfnisse der Kunden, Enduser und anderer Interessenvertreter richtig zu verstehen und kontinuierlich zu bearbeiten. Verstehen zu wollen, was ein Kunde haben möchte, ist allerdings alles andere als einfach (und das nicht nur aufgrund des oben beschriebenen Verständnisses von “Verstehen”). Oft spricht man mit den falschen Personen, nicht selten weiß der Auftraggeber gar nicht, was er wirklich will oder der Kunde teilt uns bereits Lösungen mit, anstatt Anforderungen zu beschreiben. In jedem dieser genannten Fälle erhöht sich das Risiko, dass die Entwicklung eines Produktes in die falsche Richtung läuft und so eine “falsche” Lösung gebaut wird. Der Product Owner besitzt hoffentlich die Kraft der Unterscheidung und lässt es in die Anforderungen einfließen, die er schließlich an sein Entwicklungsteam kommuniziert.
Ist euch was aufgefallen? Wer genau gelesen hat, wird feststellen, dass das Aufgabenspektrum des Product Owners eine große Ähnlichkeit mit dem Stille-Post-Spiel hat. Der Kunde sagt dem Product Owner, was er will. Der PO überführt diese Wünsche in sein Product Backlog. Den wichtigsten und am höchsten priorisierten Ausschnitt des Backlogs bringt der Product Owner zum Entwicklungsteam ins Sprint Planning und dort wird dann geplant, was und wie die Anforderungen (übersetzt in User Stories) umgesetzt werden sollen. Wohl dem, der jetzt weiß, wie man richtig versteht. 
Ich habe eine gute und eine weniger gute Nachricht. Die weniger gute Nachricht ist, dass das mit dem Richtig-Verstehen nicht leicht ist. Das kann ich euch mit diesem Beitrag lediglich bewusst machen (Erkenntnis als erster Schritt der Verbesserung). Die gute Nachricht allerdings ist, dass es etablierte Mittel und Methoden gibt, das Richtig-Verstehen zu üben und besser darin zu werden.

Sprach-Übungsfeld Baustelle

Eine spielerische Methode möchte ich euch vorstellen. Oft scheitert Kommunikation, weil zu viel Information auf einmal weitergegeben wird und/oder nicht die gleiche Sprache gesprochen wird. Sprache ist ein nicht genormtes Ausdrucksmedium! Jeder Mensch ist in der Verwendung von Sprache von seiner (Alltags-)Umwelt, seinem fachlichen Hintergrund, seinen sonstigen Kenntnissen und seinen persönlichen (Lebens-)Erfahrungen geprägt. Sprache bringt das alles individuell zum Ausdruck. Missverständnisse in der Kommunikation sind quasi vorprogrammiert und nahezu unvermeidlich. Ein Widerspruch in sich: Es geht (scheinbar) nicht mit, aber (wohl auch nicht) ohne Kommunikation! Um sich dieses Dilemma vor Augen zu führen und am eigenen Leib zu erleben, empfehle ich, das Planspiel „Auf der Baustelle“ vor einem Sprint Planning Meeting auszuprobieren. Es wird euch Augen und Ohren öffnen – versprochen!

Auf der Baustelle – die Aufgabe und die fünf Rollen

Die Aufgabe ist es, mit verteilten und klar definierten Rollen ein Lego-Modell nachzubauen. Die fünf Rollen sind

Der Informant

Der Informant sieht das Modell und beschreibt es dem Boten. Er hat Kontakt zum Boten und zum Rückmelder.

Der Bote

Der Bote gibt die Informationen, die er vom Informanten erhält, an den Baumeister weiter. Er sieht weder das Modell noch den Nachbau des Baumeisters. Er hat Kontakt zum Informanten, zum Baumeister und zum Rückmelder.

Der Baumeister

Der Baumeister (Product Owner) baut nach den Informationen des Boten das Modell nach. Die dazu benötigten Teile besorgt er sich beim Materialverwalter. Er hat Kontakt zum Boten, zum Materialverwalter und zum Rückmelder.

Der Materialverwalter

Der Materialverwalter gibt dem Baumeister die Steine, die er anfordert. Er sieht weder das Modell noch den Nachbau des Baumeisters. Er hat Kontakt zum Baumeister und zum Rückmelder.

Der Rückmelder

Der Rückmelder darf sowohl das Modell wie auch den Nachbau sehen. Er hat Kontakt zu allen anderen. Seine Kommunikation beschränkt sich jedoch darauf, dass Fragen, die ihm gestellt werden, nur mit JA oder NEIN beantworten darf. Jede weitere Äußerung ist ihm untersagt.

Die Planung

Die Planungsphase dauert vom Zeichen „Start“ an 15 Minuten. Entscheidet ein Team, vor Ablauf der Zeit mit der Planung fertig zu sein, kann es früher mit dem Bau beginnen. Folgende Anweisungen sind in der Planungsphase vom Team umzusetzen:

Die Zutaten

Tipps zur Durchführung

Nach dem Spiel ist vor dem Spiel – Fragen für ein After Action Review

 
Viel Erfolg beim besseren Verstehen! 
Literatur
Peter Dürrschmidt et. al. Methodensammlung für Trainerinnen und Trainer. 2009. managerSeminare.

S wie Scrum

Nehmen wir an, ihr wollt euch bewusst machen, was euer Gehirn mit einem Begriff oder einem Ziel verbindet, welche Informationen, Ideen und so weiter es dazu gespeichert hat. Dafür gibt es ein Kreativitätsübung bzw. -methode: Die ABC Liste.
Schreibt dazu zunächst das Alphabet von A bis Z auf. Nehmt dann jeden Buchstaben und überlegt, was euch zu ein bestimmte Begriff einfällt, welche Assoziationen der Buchstabe also in euch auslöst. Schreibt  einfach auf, was euch ganz spontan zu einem Buchstaben durch den Kopf geht. Ihr könnt die Buchstaben der Reihe nach bearbeiten oder wild springen. Sie könnt zu jedem einzelnen Buchstaben etwas schreiben oder – wenn euch nichts einfallen sollte – auch einige weglassen. Wie ihr genau vorgeht, ist egal. Lasst es fließen.
Was läuft in eurem Kopf ab, wenn ihr an SCRUM denkt? Welche Assoziationen habt ihr persönlich zu SCRUM?
Macht mit!
Übrigens kann das auch ein gute Kennenlernen-Übung für die Retrospektive sein. Jedes Teammitglied zieht den Namen eines anderen und schreibt ein ABC Liste über ihn oder sie!Agile!

A Agile!
B Backlog – Begeistern – “Böööcks” (so klingt es, wenn ich “Bug” sage)
C Commitment
D Done – Design
E Effizienz – Emotionen
F Fehlertoleranz
G Goals
H (ich benutze allgemein diese Buchstabe nicht! Französin :))
I Initiative
J jubeln
K Kultur – Kommunikation – Kreativität
L Liefern – Lernen – Leadership
M Mindset – menschlich
N natürlich
O Offenheit – Ownership
P Produkt
Q Qualität
R Rolle – Respekt
S Sprint – Selbst-Organisation
T Timebox – Team
U User
V Veränderung – Vertrauen
W Wände – viele Wände
X Xperience
Y (da bin ich überfragt, so viele Wörter mit Y gibt‘s nicht. Es ist doch schlimmer als Scrabble!!)
Z Zusammen – Ziele

Der Product Designer als rechte Hand des Product Owner?

Die Anforderungen an den Product Owner sind immens hoch. Je nach Produkt und Zuständigkeit übernimmt er eine große Verantwortung: Einerseits aus der Sicht des Business Value und der Steigerung der Produktattraktivität für den Kunden, anderseits aus der organisatorischen Sicht. Er muss den Überblick über die Termine mit Kunden halten, Kundenkontakt halten, um Anforderungen entgegenzunehmen und entsprechend im Backlog zu verorten. Schon allein die Pflege des Backlogs und der dazugehörigen Formierung der Anforderungen an das Team ist eine hohe Belastung. So fangen immer mehr Unternehmen damit an, ihre „ehemaligen“ Product Designer (PD) als „rechte Hand“ des PO einzusetzen. Die PDs schreiben Feinkonzepte, halten den Kontakt zum Kunden und arbeiten dem PO zu.
 
Vom Gedankengang her gar nicht so falsch. Der PD als Sparring Partner – als jemand, der mitdenkt, überprüft und gestaltet. Gleichzusetzen mit der Zusammenarbeit, die wir ja auch in den ScrumTeams finden. Aber kritisch zu sehen: Durch das Zuarbeiten des PD führen wir eine unnötige Hierarchieebene ein.
Die Verantwortlichkeit des PO verändert sich: Er ist „nur noch“ derjenige, der auf dem Backlog sitzt und die Zuarbeiten kontrolliert. Wie könnte eine Lösung aussehen? Beispielsweise kann man darüber nachdenken, wie man das Produkt in einzelne Komponenten oder Projekte aufteilt, um die Arbeit für einen PO „mundgerecht“ zu machen. Dabei bleibt unbestritten, dass die Verantwortlichkeit des PO hoch ist und er auch mit dem Abspecken seiner Rolle ein Workaholic ist und bleibt.
 
Wir reden von Selbstorganisation und Emanzipation der Teams: Also auch Teammitglieder können Storys schreiben. Eine große Entlastung für den PO.

Die Macht der 48-Stunden-Regel

Als ich neulich etwas zu spät zum Scrum-Stammtisch dazustieß, war die Diskussion um Schätzungen nach halben Tagen, Stunden, schon in vollem Gange. Ich musste mit einem Schmunzeln an meinen Blog zum Schätzen nach Funktionalitäten denken. Ich bereitete mich innerlich also auf eine spannende Diskussion über das Dauerbrenner-Thema vor, musste aber schon bei meiner Frage nach dem Grund für die Schätz-Problematik feststellen, dass es eigentlich um etwas ganz anderes ging.
Alle Anwesenden beteiligten sich an der Diskussion und fragten eifrig, wie denn die Rahmenbedingungen in der Firma und die Einstellungen der Mitarbeiter seien. Die Details würden für das, was ich sagen will, zu weit führen. Wir hatten es allerdings mit einem ScrumMaster zu tun, der nur noch den letzten Anstoß brauchte, um damit anzufangen, das ganze Potenzial aus seinem Team, dem PO, der Firma und schließlich sich selbst rauszuholen.
 
Und wieder einmal hatte mich Scrum als Problemanalyse-Prozess nicht im Stich gelassen.
Im Laufe der Diskussion erwähnte er fast beiläufig und mit einer gewissen Leichtigkeit, was man alles tun könnte, um die aktuelle Situation zu verbessern. Der Haken war nur: Er sah sich noch nicht offiziell als ScrumMaster – und das primär, vor allen anderen Verpflichtungen. Als der erste Scrum-Stammtischler fragte, ob dem ScrumMaster die Diskussion, die wir geführt hatten, weitergeholfen hätte, witterte ich meine Chance, Nägel mit Köpfen zu machen. Mit einem geliehenen Stift und auf der Rückseite einer Visitenkarte (die Nutzung des Bierdeckels wurde als Beschädigung fremden Eigentums angesehen) bat ich den ScrumMaster aufzuschreiben, was er in den nächsten 48 Stunden konkret von dem umsetzen werde, was er im Gespräch sowieso als sinnvoll erachtet hatte.

  • Eigene Entwicklungstätigkeit planen
  • Konzept für Retro und Sprint Plannings für das Team vorbereiten

Ich bat um eine Nachricht nach 48 Stunden, denn ich war gespannt darauf, was der ScrumMaster über seine Erfolge mit der Umsetzung zu berichten haben würde.
 
Die E-Mail kam tatsächlich und versüßte meinen Start ins Wochenende ungemein. Dem ScrumMaster war es über die geplanten Tätigkeiten hinaus gelungen, mit dem Geschäftsführer zu reden. Offenbar rannte er bei ihm offene Türen ein mit seinem Vorhaben, sich voll und ganz auf die Tätigkeit als ScrumMaster zu konzentrieren. In dieser Rolle sah der Geschäftsführer die Fähigkeiten seines Mitarbeiters am besten für die Firma eingesetzt. Außerdem hatte er bereits ein Gespräch mit dem Team geführt, um den Mitgliedern übers Wochenende eine Hausaufgabe zu geben:
 
Eine Rückmeldung dazu, was passieren müsste, damit sie motiviert sind und sich gut fühlen. „Damit wir gemeinsam das Unmögliche möglich machen!!!“

Emotionen als Wegweiser

Oscar-Preisträger Javier Bardem sagte einmal in einem Interview mit GQ (April 2011): „(…) Gefühle sind gut, für uns alle, sogar dann, wenn sie Tränen, Schmerzen und Leid mit sich bringen. (…) Erst Schmerz lässt dich reagieren, sei es physisch oder emotional. Glück hingegen lässt dich nicht reagieren, es lässt dich stillstehen.“ Schmerzen, Leid und Tränen lassen uns leben. Wieso vermeiden wir sie denn dann ständig? Wieso haben Menschen so viel Angst davor, dass Schmerzen in ihrem Leben auftreten? Was macht uns so anfällig dafür, lieber als emotionslose Wesen zur Arbeit zu gehen, anstatt gegen das anzugehen, was nicht passt? Muss es Immer erst so schlimm werden wie zu Anfang der industriellen Revolution, als die Arbeiter ihre „Sabbats“, ihre Holzschuhe in die Maschinen warfen, weil sie es nicht mehr ertragen konnten, nichts mehr zu essen zu bekommen? Müssen Schmerzen also erst unerträglich werden, bevor wir reagieren?
Moment: Die Menschen zu Beginn der industriellen Revolution waren viel näher an ihren Affekten. Sie waren vielleicht sogar eher in der Lage zu „leiden“, kannten und empfanden ihre Emotionen viel intensiver.
Mein Philosophieprofessor Gernot Böhme schreibt dazu, dass wir Menschen von heute nicht mehr in der Lage sind, die Gefühle, die Menschen noch zur Zeit der frühen Industriellen Revolution hatten, in ihrer Intensität zuzulassen. Sie seien wegreduziert, nicht mehr so intensiv. Das tragische Moment des postIndustriellen Menschen sei, dass wir in dieser unseren Gesellschaft die Emotionen verdrängt, als unwichtig markiert und anschließend wegreduziert haben.
Wir alle können das sehen, wenn wir uns anschauen, wie in der Schule die musischen Fächer, die eigentlich den Ausdruck von Emotionen lehren könnten, aus dem Lehrplan gestrichen werden. Wir haben die Rationalität so sehr internalisiert, dass wir das Leiden, aber auch die schönen Empfindungen an unserem Leben nicht mehr empfinden. Schauspieler wie Javier Bardem erinnern uns daran, dass es diese Emotionen gibt. Doch alleine diese Beobachtung bringt noch nicht die Erkenntnis, dass wir derzeit eine Trendwende erleben.

Doch diese Trendwende ist da.

Immer mehr Autoren schreiben über Emotionen. In den USA wird die Forschungen zu Glück und Emotionen stärker. Ein Klassiker dieser Strömung ist bekanntlich der EQ (Emotionaler Intelligenzquotient) von Goleman. Immer mehr „Propheten“ der Management-Literatur trauen sich, Emotionen hochzuloben und selbst Männermagazine schreiben von den Emotionen im Mann. Diesmal nicht als ein Hindernis, sondern als die Kraft im Mann.
Was ist die Ursache dieser neuen Emotionalität? Machen wir uns nichts vor: Wir sollen noch besser an unsere Ressourcen, an unsere Fähigkeiten herankommen. Es geht wieder um die Steigerung unserer Leistungsfähigkeit als Wissenarbeiter. Versteht mich nicht falsch, diese Autoren, all diese Forschungen sind per se gut. Sie sind als Grundlagenforschung absolut notwendig. Aber wir dürfen nicht zulassen, dass aus dem Verständnis, dass wir emotionale Wesen sind, dass wir wieder lernen müssen diese Emotionen wahrzunehmen und dass wir sie vor allem zulassen sollten, nicht nur das wird, was für viele ein neuer Produktionsfaktor ist.
Zunächst dachte man ja, dass die Emotionen schädlich sind … das war für das Zeitalter der industriellen Arbeit auch korrekt. Ein Arbeiter, der die Maschinen betreuen soll, eine Näherin, die 12 Stunden am Tag Stoffe zusammennäht, sind sicher produktiver, wenn sie nicht emotional sind. Obwohl das unmenschlich und unnatürlich ist. Aber das Arbeitsmodell der Industriearbeit hat ja zunächst auch für die Arbeit des Wissensarbeiters Pate gestanden. Erst jetzt nach 60 Jahren wird ja immer deutlicher, dass der Wissensarbeiter eben ganz andere Arbeitsbedingungen benötigt, als wir es von der Industriearbeit her kennen. Der Raum für Emotionalität wird entdeckt.
Bisher war bekannt, dass der Wissensarbeiter einen Raum benötigt, in dem man mit Menschen kommunizieren kann, in dem Menschen gemeinsam eine Aufgabe verfolgen können. Dem Wissensarbeiter einen Ort zu geben, in dem er durch die Art der Gestaltung des Raums dabei angeregt wird, um die Ecke zu denken. Einen Raum, in dem er neue Lösungen dadurch finden kann, dass er aus dem Schema des prozessualen Denkens austreten kann.
All das ist bekannt und wenn wir mit Kunden über die Rahmenbedingungen für Arbeitssituationen in Firmen reden, dann sagen wir auch, dass Teams den emotionalen Raum brauchen, in dem sie sich entfalten können. Teams so zusammensetzen, dass sie möglichst viel miteinander zu tun haben – sie möglichst viele Chancen haben miteinander zu kommunizieren und ihre Grundinformationen visuell an die Wände hängen können. Räume müssen also für Teams strukturiert sein, das geht hin bis zu schallschluckenden Teppichen. All das ist für uns bereits Realität und langsam, aber sicher beginnen mehr Firmen auch auf diese Ideen in ihren Raumkonzepten einzugehen. (Leider viele noch überhaupt nicht.)
Ihr werdet jetzt entgegnen:

Raum Zeit

Zum einen brauchen Teams den emotionalen Ort, an dem sie sich kreativ entfalten können. Andererseits benötigen sie Raum in Form von Zeit. Emotionen zuzulassen heißt in erster Linie, sich ihnen in zwei Arten zu widmen: Durch das zeitliche Zulassen. Ihnen also auch im Arbeitsleben durch Gespräche, durch Zuhören, durch einfach Zeit miteinander verbringen den notwendigen Raum geben. Andererseits durch das Aushalten und Verständnis zeigen für Emotionen. Das kann bis hin zu „unprofessionellen“ Wutausbrüchen gehen. Das Dampfablassen kann aber auch einmal genau der richtige Impuls sein, um mit einer Situation umzugehen, dem anderen zu sagen: So, jetzt habe ich gerade meine Grenzen erreicht!
Wutausbrüche sind das eine, aber die Emotionen des anderen im Team zu sehen, sie zu würdigen, sie auszuhalten, das ist das Befremdliche. Als ich in einem Coaching einmal meinen Coachees sagte “Ja, ihr als ScrumMaster müsst auch mit den Emotionen eurer Teammitglieder umgehen”, sah ich blankes Entsetzen. Das wollte man nicht, auf gar keinen Fall. Ja, es ist befremdlich und macht Angst. Denn, und da schließt sich dann der Kreis, wir haben in dieser Gesellschaft der Emotion keinen Raum gelassen. Wir lassen in Familien und in den Beziehungen für ehrliche Gefühle keinen Raum. Sie werden unterdrückt oder als nicht existent deklariert. Emotionen werden als Bedrohung gesehen, denn wir lernen als Kinder in den wenigsten Fällen, wie man mit ihnen umgeht. Vor allem dann, wenn es schmerzhafte Emotionen sind, oder dann, wenn sie uns verunsichern. Wenn sie unserem Verstand nicht sofort sagen, wohin die Reise geht. Aber wieso ist das so? Wieso hören wir nicht auf sie, wieso hören wir nicht in uns hinein? Warum geben wir nicht zu, dass wir wütend sind, dass wir uns zu jemandem hingezogen fühlen, dass wir verunsichert sind, dass wir Freude empfinden, den anderen zu sehen?
Meine Antwort darauf: Weil wir verlernt haben, oder was noch wahrscheinlicher ist, weil wir nicht gelernt haben, ihnen zuzuhören und ihnen zu vertrauen. Wenn Eltern ihren Kindern, wenn diese sich gerade die Knie aufschlagen erzählen: „Das tut nicht weh!“, „Ein Indianer kennt keinen Schmerz!“ oder etwas ähnlich Schwachsinniges, dann bringen wir dem Kind bei: “Ich kann meinen Empfindungen nicht trauen.” Das ist das Gleiche, wie wenn sie ihrem Kind erklären: “Du musst aufessen”, oder “Iss das, das ist gesund für dich”, obwohl das Kind keinen Hunger hat. Auch in diesem Fall wird dem Kind erklärt: “Hör nicht auf deinen Körper, nimm deine Empfindungen nicht wahr und ignoriere sie, denn sie müssen falsch sein.”
Nun transportiert diese Erkenntnis auf Emotionen in Teams. Welcher erste Arbeitgeber oder welcher Lehrer hat Teams in ihrer Teamarbeit erklärt, wie sie mit ihren Emotionen, ihren Konflikten, ihren Verunsicherungen uva. in Teams umgehen dürfen? Wer hat euch bei den ersten Teams, in denen ihr vielleicht gewesen seid – Fußball, Handball, Pfadfinder – erklärt, wie wichtig das Emotionale ist, und noch wichtiger: Wie man damit umgehen kann?
Ja, wenn ihr euch auf eure Emotionen einlasst, sie zulasst und dann in der Situation auch loslassen könnt! Dann wird das dazu führen, dass ihr leistungsfähiger und damit produktiver werdet … gut für euren Arbeitgeber, aber viel wichtiger: Es wird euch eine Richtung geben, die viel dichter an dem ist, was euch entspricht, als das viele Nachdenken, ob man auf dem richtigen Weg ist. Emotionen lügen nämlich nie!

Widerstand ist … Feedback

“Die Welt ist im Wandel. Ich spüre es im Wasser, ich spüre es in der Erde, ich rieche es in der Luft. Vieles was einst war, ist verloren, da niemand mehr lebt, der sich erinnert.”
So beginnt die Erzählung von Galadriel in “Der Herr der Ringe” und ein wenig später sagt sie: “Doch einige leisteten Widerstand.”
Wir wissen, dass der Widerstand, von dem Galadriel spricht, der des letzten Bündnisses von Elben und Menschen ist. Ein Widerstand, der hocherwünscht ist und für das Gute steht. Alle, die Wandel in Organisationen vorantreiben und begleiten, erleben Widerstand meist als das Gegenteil: als harsche Kritik an der eigenen Idee, als persönlichen Affront oder politisches Spiel, bei dem man teils verborgenen Mächten ausgesetzt ist. Selten erlebt und nutzt man Widerstand als das, was er auch sein kann: ein Feedback und wertvolle Information!

Warum ist Widerstand eine wertvolle Information?

Weil er uns die Grenzen unserer Idee aufzeigen kann, sofern wir zuhören: Unsere Ideen und Konzepte sind nicht perfekt und passen nicht gleich gut in jede Organisation. Es gibt immer Punkte, an denen sie anecken und an diesen Stellen besteht meist weiterer Bedarf zur Veränderung. Widerstand eignet sich dazu, diese Stellen zu identifizieren, um den Wandel möglichst effektiv voranzutreiben. Meist erkennen wir erst durch Widerstand, wo der Schuh in der Organisation wirklich drückt.

Was müssen wir tun, damit wir die Information erkennen?

Offen sein, mutig sein, sich dem Widerstand stellen. Respektvoll zuhören. Widerstand nicht als persönliche Kritk sehen, sondern als Information erkennen und anerkennen. Die Menschen abholen, sie ernst nehmen. Die Information, die uns gegeben wird, annehmen, respektvoll damit umgehen, denn wir reden meist von Sorgen, Ängsten oder berechtigten Einwänden. Die Information mitnehmen, hinterfragen, weiter fragen, reflektieren – darüber nachdenken, gut und schlecht unterscheiden, in Lösungen denken – und sich nicht zu sehr mit dem Problem beschäftigen. Für mich persönlich ist es sehr wichtig, mit den Personen zu reden, die kritisch hinterfragen, denn in den wenigsten Fällen handelt es sich um eine harsche Ablehnung, sondern eher um ein vorsichtiges Interesse und um gute Hinweise, wo uns Weisheit oder Wissen fehlen und wir Standpunkte einer anderen Wahrheit erkennen können.

Wie gehen wir mit der Information um?

“Was man nie anpackt, dauert am längsten”, sagt Samweis Gamdschie zu Frodo – und beschreibt auch den Kern unseres Problems: Wir müssen anpacken, zupacken. Nur wie?
Eine unserer natürlichen Reaktionen auf Widerstand ist das Ausweichen – die Flucht. Wir suchen Ablenkung dort wo unsere Idee auf offene Ohren stößt und meiden die Ablehnung. An den Stellen, an denen wir mutig genug sind nicht auszuweichen, gewinnen wir viel – wir sind bereits im Gespräch. Nun ist es wichtig wie wir weiter damit umgehen, denn das entscheidet über Erfolg und Misserfolg. Viele Menschen reagieren auf Konfrontation mit einem Gegenangriff und versuchen so den Widerstand zu brechen. Alternativ und meist übersehen, eröffnet sich uns auch eine andere Perspektive: Wir machen uns den Widerstand zu eigen und leiten ihn in geordnete Bahnen, d. h. wir nehmen die Information auf und setzen diese zum eigenen Nutzen ein. So können wir bspw. Schwachstellen erkennen und ggf. schnell auflösen oder uns auf unangenehme Fragen vorbereiten. Kampf ist zwar ein sehr hartes, für mich aber auch ein sehr anschauliches Bild: Im Aikido nimmt der Kämpfer den Angriff auf und setzt ihn zum eigenen Nutzen ein, indem er dessen Kraft und Schwung nutzt, ihn führt und ihn bspw. in eine Position der Kontrolle überführt. Man spricht bei Aikido auch von einer “defensiven, verantwortungsbetonten geistigen Haltung”, die, wie ich finde, sehr passend beschreibt, wie man mit Widerstand umgeht, wenn man ihn ernst nimmt.

Was gilt es zu beachten?

Um mit  der Information Widerstand umzugehen und aufzuzeigen, dass einem selbst der Perspektivenwechsel gelingt, ist es von Vorteil, wenn man seinem Gegenüber die Vorteile der Veränderung deutlich macht. Wichtig dabei ist, dass man auf den konkreten Nutzen für die Person eingeht und nicht ein abstraktes Bild zeichnet, das schwer greifbar mit einem Schulterzucken getadelt werden kann.

Gut zu erkennen

Manchmal löst nicht die Idee, sondern der Überbringer der Nachricht den Widerstand aus. In solchen Fällen hilft es, um Unterstützung von jemandem zu bitten, der akzeptiert wird. Diese Person kann als Vermittler auftreten und Brücken bauen, wo ansonsten das Fundament für Akzeptanz und Offenheit fehlt.
Letztlich kann nicht jede Ablehnung aufgelöst werden. Die Kunst liegt darin zu erkennen, wann das der Fall ist, um die eigene Energie dann anderweitig besser einzusetzen.

Fazit

Wir müssen erkennen, dass kein Plan perfekt ist: Oftmals fehlen uns wichtige Informationen, wir stoßen an organisatorische Grenzen, uns fehlt ein Blickwinkel, die Wahrheit einer anderen Perspektive. Jeder Wandel ist wie ein Puzzleteil, das sich in das große Ganze fügen und es verändern muss – so passt der Wandel zuerst nur zum Teil in die Umgebung, in der wir ihn gerne realisiert sehen. Alles in allem ist Widerstand ein Feedback, das genutzt werden sollte, bevor es einen selbst schwächt oder ausbremst. Indem man wichtige Rahmenbedingungen erkennt, Menschen mitnimmt, deren Meinung wertschätzt und in die eigene Umsetzung mit einbezieht, überführt man den Widerstand in eine Lösung. Denn anhand von Widerstand erkennen wir Handlungsbedarf und bekommen die Chance, Veränderungen effektiver zu gestalten.
Seid mutig und nutzt den Widerstand, der euch begegnet! Euer Gegenüber wird es euch danken – im besten Fall gewinnt ihr einen neuen Verbündeten. Oder frei nach Gandalf dem Graurock: “Du musst nur entscheiden, was du mit der Zeit anfangen willst, die dir gegeben ist.”

Management – ein Reminder

In dem wirklich spannenden Kommentar „Manager müssen eine neue Offenheit lernen“ von Karl-Heinz Büschemann in der Süddeutschen Zeitung plädiert der Autor anhand des Abschieds von Infineon-Chef Peter Bauer für mehr Ehrlichkeit in den Chefetagen. Bauer räumte in seiner Abschiedsrede Schwächen ein. Etwas, das man nicht oft in einer Abschiedsrede hört und überhaupt “untypisch” für einen Chef.
Das Bild des unfehlbaren und allwissenden Managers hat sich im Laufe der letzten Jahre selbst überholt. Komplexe Systeme wie Unternehmen können nicht von einer Person allein geführt, gesteuert und in die Zukunft getragen werden. Ohne kontinuierlichen Austausch (zwischen ALLEN Hierarchien) werden Entscheidungen auf Grundlage wackeliger Informationen getroffen. Dass auf dieser Grundlage vom Management auch Fehlentscheidungen getroffen werden, ist unvermeidbar. Denn wie auch Büschemann schreibt: „Niemand ist unfehlbar.” Aber genau das ist es, was das Management heute lernen muss (und man sollte hier nicht einmal so weit gehen, von einem Management 3.0 zu sprechen). Manager von heute sollte sich im Klaren sein, dass auch sie Fehler machen können (und auch müssen?!). Büschemann schreibt gegen Ende seines Kommentars: „Nur wer in der Führungsetage zeigt, dass er keineswegs alles selbst und besser weiß, kann seinen Mitarbeitern ein Vorbild sein.“
Ein Vorbild zu sein, bedeutet zu seine Fehlern zu stehen und diese ggf. auch zu revidieren. Unter Umständen auch den Dialog mit den Mitarbeitern zu führen, Transparenz in den Entscheidungen zu erzeugen. Die Angst des Managements ist es oft, dass  Gesicht zu verlieren und in den Augen der Mitarbeiter weniger “Bedeutung” zu haben. Ein Manager, der Fehler zugibt, erweist sich als fehlbar und somit als menschlich. Fehler eingestehen zu können, bedeutet  auch eine entsprechende Unternehmenskultur zu führen. Nur in einer Kultur, in der Fehler gemacht werden dürfen, werden auch welche zugegeben. Und gehen wir vom humanistischen Menschenbild aus, können wir sagen, dass jeder Mitarbeiter sein Bestes in der bestehenden Situation gibt und somit keine Fehler bewusst erzeugt werden.
Um sich die Bedeutung noch einmal zu verdeutlichen: Mitarbeiter sehen krasse, mit tiefschürfenden Konsequenzen verbundene Entscheidungen oft als eine Fehlentscheidung des Managements an. Das hat oft die Konsequenz, dass darauffolgende Entscheidungen mit viel Widerstand “durchgeboxt” werden und von den Angestellten nicht getragen werden.
Und an dieser Stelle zur Erinnerung: Scrum gibt dem Team die Macht der Selbstorganisation. Je organisierter das Team ist, desto weniger unsichere Entscheidungen muss das Management tragen. Je mehr Beteiligung der Mitarbeiter, desto verstärkter werden Entscheidungen auch von den Mitarbeitern getragen. Und noch mal zu Erinnerung: Ein Management kann nur ein Management sein, wenn es Mitarbeiter hat, die produzieren. Management ist KEIN Selbstzweck, sondern Management bietet Ressourcen, damit das Team produzieren kann.

Teamgeist, immer und überall

Teamgeist und Kommunikation werden mittlerweile überall großgeschrieben – keine Frage. Aber wie konsequent sind wir in der Umsetzung?
Vielleicht kennt ihr folgende Situation auch aus eurem Unternehmen: Ein unerwartetes Ereignis tritt ein – ein gravierender Fehler aus dem laufenden Betrieb, ein dringender Wunsch der Geschäftsführung, eine nicht aufschiebbare Kundenzusage. Und plötzlich wenden sich alle Augen auf die Person(en) im Unternehmen, denen die größte Kompetenz in diesem Themenbereich zugesprochen wird. Die Gesetze eines zuvor noch selbständig arbeitendes Teams gelten nicht mehr, sie weichen dem Druck, schnelle Ergebnisse liefern zu müssen und dem Wunsch nach “klaren Ansagen”. Kollektive Entscheidungsfindung, wie sie in Scrum-Teams gelebt wird, gilt plötzlich als unnötige Zeitverschwendung.
Ist an dieser Notfall-Strategie vielleicht etwas dran? Wie erfolgsrelevant ist Kommunikation im Vergleich zu anderen Faktoren wie fachliche Expertise oder analytische Fähigkeiten?
Eine Forschungsgruppe des Massachusetts Institute of Technology (MIT) hat dazu ein spannendes Experiment durchgeführt, das in der Mai-Ausgabe 2012 des Harvard Business Managers veröffentlich ist. Dafür haben die Forscher über sieben Jahre hinweg das Kommunikationsverhalten von 2500 Menschen in 21 Unternehmen und Organisationen aufgezeichnet, darunter Bankfilialen, Krankenhaus-Teams und Call-Center. Jede Person wurde mit einem kleinen, diskreten elektronischen Gerät ausgestattet, das über 100 Datenpunkte pro Minute aufzeichnet. Tonfall, Körpersprache, Häufigkeit der Kontaktaufnahme – das sind einige der soziometrischen Daten, die damit erhoben wurden.
Das Ergebnis der Untersuchung ist ebenso spannend wie aufschlussreich. Es zeigt, dass für die Aufstellung von erfolgreichen Teams eine gute Kommunikation wichtiger ist als alle anderen üblicherweise herangezogenen Faktoren, wie z.B. die Intelligenz oder Kompetenz der Teammitglieder.
Wie aber sieht ein gut kommunizierendes Team aus? Aus der Studie kristallisieren sich Eigenschaften heraus, die erfolgreiche Teams gemeinsam haben:

Ihr macht schon Scrum? Schaut euch doch mal ein Daily Scrum an und beobachtet in diesen fünfzehn Minuten, inwiefern die oben genannten Merkmale zutreffen. Ihr werdet auch ohne aufwändige Aufzeichnungsgeräte schnell ein Gefühl für die Kommunikationsmuster in euren Teams bekommen.
Wir von bor!sgloger glauben, dass Teams nicht dadurch erfolgreich werden, dass sie dazu angehalten werden. Ein Meeting kann angeordnet, ein Leistungsziel vereinbart werden. Aber wie kriegt ihr Teams dazu, auch beim Mittagessen und in der Kaffeepause das Gespräch zu suchen? Wie schafft ihr es, dass eure Teammitglieder montags zur Arbeit kommen und ihren Kollegen von einem Wochenenderlebnis – einer Lektüre, einem Gespräch, einem Geistesblitz – erzählen, der das Team weiterbringt? Das sind Dinge, die aus der inneren Dynamik eines Teams heraus geschehen müssen. Das ist Teamgeist.
Deshalb ist es auch so wichtig, Teams wachsen und gedeihen zu lassen. Dazu braucht es zum einen die richtigen Rahmenbedingungen – vom geeigneten Teamraum bis zu einer Unternehmenskultur, die Gruppen- über Einzelleistung stellt. Zum anderen braucht es eine Führungsrolle, die weiß, was das Team in sechs Monaten und in einem Jahr erreichen kann, und es entsprechend fördert. Wir nennen diese Rolle ScrumMaster.
Die Rolle des ScrumMasters wird gerne unterschätzt – viele sehe in ihm bloß eine Mischung aus Organisator, Erbsenzähler und Wachhund. Ein guter ScrumMaster vermag indes dem Team Atem einzuhauchen und es auf eine gemeinsame Reise zu schicken. Er gibt dem Team ein “shared sense of purpose” und schafft es, dass sich die Teammitglieder darauf freuen, den Tag mit ihren Kollegen bestreiten zu dürfen. In Scrum merken wir das am Pull-Prinzip. Nicht der Product Owner muss die Teams dazu bringen, Stories in den neuen Sprint zu nehmen. Nein, die Teams selber “ziehen” sich die Stories aus dem Product Backlog und committen sich darauf, weil sie Lust darauf haben, sie umzusetzen. Diese Umkehr im Denken – weg vom Drängeln und Vorschreiben, hin zum Ermuntern und Machen lassen – gilt es zu vollziehen.
Wie werdet ihr beim nächsten Notfall reagieren? Werdet ihr den Teams zutrauen, die Situation selber in den Griff zu bekommen? Oder werdet ihr als Experten einmal mehr einsame Helden im Kampf gegen die Windmühlen der Komplexität sein?
Alex Pentland: Kommunikation ist der Schlüssel. In: Harvard Business Manager, Mai 2012, S. 36-48.
Gilda Feller: Es muss schnell gehen, heute machen wir kein Scrum
ScrumMaster Pro Training TeamDevelopment

Manager in a Networked Organization

In my previous posts I have shown how to describe organization structures in a way different from the typical hierarchical line management top-down tree. Because communication is at the heart of any organization that wants to be agile, with self-organizing teams and an innovation culture, the communication paths are the primary feature of the organization structure. Companies become networks of interconnected persons and teams.
So far I had left out the manager in these networked org charts. Why, you may ask? Well, because it is not easy to place him or her in a structure without reverting back to reporting lines. But they should not be important and should rarely come into use. The line in line manager is the least of a managers tasks.
What does the line represent in a typical org chart? The person on the top end of the line has command power over the person on the bottom and reporting has to come back up the line. In other words: command and control. But in an agile organization, we want the manager to focus on very different things:

And, yes, some form of control / reporting will be there as well – however, primarily to measure how good the manager himself is doing with the bullet points above.
So I think we need to eliminate the reporting line entirely from the org chart. Here is an example of how it could look like:

Of course, management will have communication paths to their assigned employees. Just like for the communities of practice, this communication is color-coded rather than represented by lines. This makes the chart much easier to read.
It is imperative that the managers form a cluster (the management team) themselves. In the example above we have teams that are formed of people with different managers. This should not be an issue if the management team works together with a common goal so that all teams will get an agreed goal from the entire management team. Remember that setting goals is one of the important tasks for managers in an agile organization.
There are many issues that are still open and to be discussed. What about bigger organizations with more managers and more management levels? What about service teams that help the others but do not actually produce the product?  What about distributed organizations or even distributed teams? I will try to tackle these questions in my next posts, although I do not promise that perfect solutions will be forthcoming. And you can help me by commenting on my ideas.
Christof Braun, Trainer Management 3.0 & Management Consultant

Was der Berliner Flughafen mit agilen Werten zu tun hat

Die Schlagzeile des heutigen Tages, die Deutschland, Airlines und Passagiere weltweit nervös macht: Die Eröffnung des neuen Berliner Flughafens wird  auf unbestimmte Zeit verschoben. Der 3. Juni als Eröffnungstermin ist Geschichte. Niemand kann sagen, wann der Willy Brandt-Flughafen bereit sein wird, sich den Reisenden zu stellen. Man hört von sechs Wochen Verschiebung. Der Prestige- und Vorzeigebau wird nicht fertig. Deutschland ist (mehr oder weniger) schockiert. Und eine der Fragen, die sich die Medien stellen, lautet: „Warum hat niemand früher gesagt, dass es länger dauert?“ Denn drei Wochen vor Start wird doch schon abzusehen gewesen sein, dass dieses nicht kleine Bauvorhaben nicht fertig wird …
So die momentane Situation – zumindest soweit sie aus der Informationsflut, die uns zu diesem Thema derzeit umspült, nachvollziehbar ist. Aber mal ehrlich: Kennen wir das aus unserem Berufsalltag nicht auch? Projekte die nicht fertig werden? Ampeln, die den aktuellen Projektstand darstellen sollen und die dann doch ausgehebelt werden, wenn das Ende näher rückt?
In vielen Unternehmen reißen Projekt-Deadlines und es muss nachgearbeitet werden. Eigentlich ist es eher die Regel, dass die geplanten Zeiten nicht eingehalten werden. So weit nicht schlimm. Denn wir sind Menschen und können nicht in die Zukunft gucken. Das gilt auch für den Bau des Willy Brandt-Flughafens. Ein Projekt in dieser Größenordnung ist nur schwer zu greifen – irgendwas vergisst man immer …  Um auf Veränderungen schnell reagieren zu können und Gefahren wie eine Nicht-Fertigstellung möglichst früh erkennen zu können, machen wir Scrum. Iterative und überschaubare Zeiten, in denen man genauer planen kann. Ich möchte mich nicht zu weit aus dem Fenster hängen  und sagen: Berlin hätte sein Bauvorhaben mit Scrum machen sollen. Aber ist doch eine spannende Fantasie … erste Ansätze waren mit dem Passagier-Testbetrieb auch schon da.

Offen kommunizieren!

Ich möchte an unsere Offenheit appellieren. In Scrum bemühen wir uns, offen zu kommunizieren.
Wenn es länger dauert, können wir (je länger das Projekt läuft, desto genauer) bestimmen, wann wir fertig sind. Dass das in der Realität oft schwierig ist, will ich nicht verleugnen. Das Team in Berlin, das den Flughafenbau steuert und den Termin nicht geschafft hat: Verständlich, dass es erst drei Wochen vor Start mit der unangenehmen Wahrheit rausrückt, die Situation ist ärgerlich und die Reaktion der Medien und der Öffentlichkeit schwierig. Wir sollten an dieser Stelle nachsichtig sein, uns an der eigenen Nase nehmen und es in Zukunft besser machen. Wenn wir offen kommunizieren, dass wir etwas nicht schaffen, hat das nichts mit Versagen zu tun. Es hat damit zu tun,  dass wir nicht detailliert in die Zukunft sehen können. Dass es jetzt Konsequenzen für den  Flugverkehr hat, ist ärgerlich und kostenintensiv. Nicht jeder von uns setzt gleich einen ganzen Flughafen in den Sand, klar. Aber Verzögerungen und Schwierigkeiten treten nun mal auf. Es sollte nicht passieren, aber es kann passieren – uns allen, in den unterschiedlichsten Größenordnungen.

Agile and Organizational Structures

Putting up a Kanban board or holding daily Scrum meetings does not make an agile organization. Neither does the adherence to all the Scrum or Kanban – or whatever else – rules. You may even succeed in becoming really agile on a micro basis in your organization: The teams get a beautifully groomed backlog from their Product Owner, they deliver software at the end of each iteration and they inspect and adapt to get better in their own processes. And, I am sure, it already helps a lot with their productivity and motivation.

But then comes along the boss

And it is usually not a pointy-haired one that we all laugh about from a well-known comic strip. He (or she) has been the best developer in the organization and was outspoken for a long time, so he naturally got the promotion when the company grew and felt the need to introduce a new management layer of team leaders. Now he has the responsibility for what the team delivers, and, of course, he knows best what to deliver and how to do it. So, he will let the team be agile but when he realizes they are not using the framework of his choice he must intervene! Let’s create a task force to investigate what frameworks to use with a decision due at the end of the sprint. And he will be part of the task force. Guess what the outcome will be? And one of the committed stories of the sprint didn’t get done again!
You get the picture… No, I do not mean to say that all management is evil. Certainly mostly they have the best intentions. But all too often managers cannot rid themselves off the good old “manager knows best – manager must make decisions” logic. And the higher up the manager, the better he knows.

Leadership is necessary. But …

I am convinced, that we need managers around. Leadership is necessary. But we need to curb the inflation of managers in organizations. The natural career path is still to become a manager at some point. But does the organization really need yet another manager? And then there is the hierarchy in an organization where we all automatically think – the higher, the better, the smarter, the more money…
I believe herein lies a big problem for most organizations when they try to become agile. A hierarchical organization implies a command structure top-to-bottom that makes empowered and self-organized teams or departments so much more difficult to implement. So I propose to look at organizations in a different way.
In the following weeks I will put my thoughts on this into a small series of blog posts I will call Blueprints for Agile Organizations. I will examine the necessary minimal structures for organizations of different sizes and I will look into ways on how to describe the structures other than in hierarchical organization charts. I consider this one of many important steps to get away from command & control management to true agile leadership. Also, I want to investigate how such structures can organically grow and shrink over the lifetime of a company. I do not have the answer to all this but I have some ideas and this will hopefully help me to put some more structure into the ideas and get feedback for them.
Christof Braun, Trainer Management 3.0 & Management Consultant

Spielerisch für Veränderungen sorgen

Um einen Tisch sitzen sechs Product Owner und ein ScrumMaster. Die POs sind mit Post-its und Stiften bewaffnet. In der Mitte des Tisches liegt eine Spielkarte. Sie ist verdeckt. Der ScrumMaster dreht die verdeckte Karte um. Darauf ist eine Kreidetafel mit folgendem Inhalt zu sehen: „Wegen Zu geschlossen! Neueröffnung März 2007“. Der ScrumMaster gibt die kurze Anweisung: „2 Minuten Zeit. An die Stifte, fertig, los!“ – und die Product Owner beginnen mit dem Schreiben.
Ihr fragt euch, was hier gerade passiert? Hier spielt ein Product Owner Team „Happy Aua“. Das ursprünglich von Bastian Sick entwickelte Bilderspiel aus dem „Irrgarten der deutschen Sprache“ dient leicht abgewandelt als Kreativitätswerkzeug und soll Product Owner auf spielerische Weise dabei unterstützen, das Formulieren von Produktvisionen zu üben. Je origineller und lustiger der Kommentar zur Karte formuliert ist, umso besser. Die Abstimmung, welcher der Kommentare der jeweils Beste ist, erfolgt gemeinsam.

Spiele bei der Arbeit?

Führen und spielen? Veränderung und Spaß? Schließt das eine das andere nicht aus? Aus meiner Sicht sollten Arbeiten, Lernen und Spielen nicht voneinander getrennt werden. Spielen steht für eine Interventionsform, die Menschen in eine Welt entführt, in der alles passieren kann. Auch, wenn noch immer überwiegend die Meinung in der Arbeitswelt vorherrscht, dass Spiele für die Freizeit reserviert oder lediglich Kindern gestattet sind, finden Menschen wie Arne Gillert, Autor des Buches „Der Spielfaktor. Warum wir besser arbeiten, wenn wir spielen“, in Unternehmen immer stärker Gehör. Er behauptet: „Wer spielerisch an die Arbeit geht, gelangt ernsthaft zu neuen Lösungen.“ Trockene Arbeitsthemen oder schier unlösbare Situationen bekommen durch spielerisches Denken und Handeln neue Impulse, weil dabei eine Quelle (fast) vergessener Ressourcen angezapft wird.
Wann habt ihr das letzte Mal Kindern beim Spielen zugesehen?  Kinder lernen in ihrer frühen Entwicklung so viel und so schnell – und seid euch sicher:  Lernen ist Arbeit – wie nie mehr wieder in eurem Leben. Wie tun sie das? Sie spielen. Sie spielen den ganzen Tag lang. Dabei befinden sie sich in einer Welt, in der ihr Geist fokussiert, hochkonzentriert und 100% aufnahmefähig ist. Die gewonnenen Erkenntnisse und Erfahrungen, das Neue, werden so wirksam im Gedankengut verankert. So sind sie für den Rest des Lebens abrufbar und es kann wiederum Neues damit assoziiert werden.
Bürotätigkeiten, Meetings, Seminare, Schulungen, Workshops oder Vorträge – all das ist Arbeit. Und allzu oft beschäftigt sich diese Arbeit nur mit Begriffen von Dingen und eben nicht mit den Dingen selbst und ihren Beziehungen zur Umwelt. Der Mensch aber braucht Entfaltungsmöglichkeiten seines individuellen Lern- und Arbeitsstils. Um dabei jedem auf seine eigene Weise gerecht zu werden und gleichzeitig für den zu vermittelnden Lernstoff Aufmerksamkeit zu bekommen, müssen Möglichkeiten geschaffen werden, die Information in die jeweilige Individualsprache, die Assoziationswelt jedes Einzelnen zu transferieren.

Spielen kann das.
Spielen erhöht nicht nur die Aufnahme- und Lernbereitschaft. Spielen ist uns allen vor allem vertraut. Schließlich waren wir alle mal spielende Kinder. Und Vertrautes schenkt uns die Freude des Wiedererkennens. Freude steuert wiederum Aufmerksamkeit, öffnet unsere Bereitschaft, (Lern-)Energien zu mobilisieren und ein Gefühl zu erleben, das uns im Kontinuum des Arbeitsalltags häufig verloren geht, nämlich die kindliche Gier nach neuen Erfahrungen: die Neugier. Neugierde kompensiert nicht nur die Angst vor Fremdem, sondern ist der Schlüssel zu in uns schlummernden Handlungsräumen wie Kreativität, Experimentierfreude, Freigeist oder Spontaneität.

Spielen braucht Handlungsräume

Spielen findet überall dort statt, wo die Folgen des eigenen Handelns begrenzt sind – also dort, wo ein Fehlverhalten keine Katastrophen oder Repressalien nach sich zieht. Schon die Bereitstellung eines sicheren Rahmens (z.B. Hier darf heute wirklich alles passieren) sorgt dafür, dass Menschen Neues ausprobieren wollen/werden.
Das schönste Spiel im Rahmen eines Sprints ist die Retrospektive. Sicher fragt ihr euch jetzt, ob ich die gleiche Retrospektive meine wie ihr. Ja und nein. Fragt doch mal euer Team: „Was lief gut?“ und fragt es ebenso „Was könnte verbessert werden?“ Allerdings probiert  zum Einstieg mal das „Spinnennetz“ aus (vermutlich kein Scrum-Team, aber hier gibt es ein kurzes Video zu einer Outdoor-Variante):

Sorgt für (Spiel-)Räume, die eine ungestörte Erarbeitung individueller Lösungen ermöglicht und ihr werdet sehen, dass die Teammitglieder dabei bereitwillig Verantwortung übernehmen.

Spielen ist Handeln, Spielen ist nicht Planen

Vor kurzem habe ich ein Kind beim LEGO-Spiel gefragt: „Was wirst du jetzt bauen?“ Ohne aufzusehen, zuckte es mit den Schultern und murmelte: „Das weiß ich nicht.“ Eine halbe Stunde später stand dort ein kleines Kunstwerk. Ich hätte das SO niemals hinbekommen! Das Kind hatte keinen Planungsworkshop belegt, bevor es mit dem Bauen anfing, sondern legte einfach los.
Natürlich ist es wichtig, einen Plan in der Tasche zu haben, weil die Ausrichtung unseres Handelns auf ein größeres Ziel nun mal dazugehört, um so den besten Weg zu diesem Ziel herauszufinden. Aber wie gut sind Pläne wirklich? Eigentlich sollten wir es aus den Erfahrungen der abertausend gescheiterten Projekte, denen scheinbar wasserdichte Pläne zugrunde lagen, besser wissen.
Versteht mich nicht falsch! Spielen bedeutet nicht, dass Planen überflüssig ist. Es ist sogar essentiell. Allerdings geht es darum, über das Maß nachzudenken. Wie viel Planung ist tatsächlich nötig, um anfangen zu können. Nicht selten ist weniger wirklich mehr. Erfolgreiche Beispiele dafür sind die Schätzspiele „Magic Estimation“ und „Planning Poker“. Traditionelle Aufwandsschätzungen funktionieren nun mal nicht und verschwenden nicht nur Zeit, sondern sind relativ zu ihrem Effekt gesehen vollkommen übertrieben. Deshalb traut euch und spielt!

Spielen fängt im Kopf an

Wenn ich in meinen Trainings mit den Lerngruppen spiele, stelle ich – zwar in unterschiedlichen Ausprägungen – aber trotzdem immer wieder das Gleiche fest: Ist das Spiel erstmal angefangen, dann machen die Spielenden kaum bis keinen keinen Unterschied zwischen der Realität und dem, was Spiel ist. Wer spielt, der stellt sich etwas vor und taucht ab in seine (Spiel-)Welt. Die Vorstellungskraft gehört mitunter zu den mächtigsten Denkwerkzeugen des Menschen.
Nehmt das Daily Scrum als Versuchsballon. Schenkt jedem Teammitglied ein Überraschungsei. Die Schokolade ist euer Geschenk an jeden aus eurem Team. Der jeweilige Ü-Ei-Inhalt definiert das individuelles Motto des Tages oder der Woche oder des aktuellen Sprints. Lasst das Team immer wieder einen Bezug herstellen. Analogien, Metaphern, Geschichten lockern die Stimmung im Team auf und sorgen für ein Mehr an Leichtigkeit im Tun.
David Holzer, Trainer & Scrum Consultant

Scrum baut keine Fertighäuser

Bei der Umstellung vom Wasserfall auf agile Softwareentwicklung wird vor allem bei architektonischen Aspekten oft das Bild des Hausbaus bemüht. Natürlich sind Änderungen am entstehenden Objekt – zum Beispiel Wände einreißen, Rohre neu verlegen – nach grundsätzlich getroffenen Entscheidungen nur noch mit großem Aufwand möglich. Die Betonung liegt dabei jedoch auf: grundsätzlich möglich! Die Entscheidung es zu tun, fällt jedoch immer erst, wenn die Wand schon steht oder zumindest angefangen ist.
Mein Vater ist Architekt und von ihm weiß ich, dass Architekten in der Planungsphase nach jeder Anpassung oft stundenlang mit den Bauherren wieder vor den Plänen sitzen. Häufig fallen die Worte: „Ich kann mir das gar nicht richtig vorstellen, ich muss das erst sehen und durchlaufen können.“ Vielleicht werden deshalb auch Fertighäuser immer beliebter. Bei Fertighäusern habe ich noch nie erlebt, dass die Bauherren das Haus erst sehen, wenn die letzte Badezimmerfliese verlegt ist – schlüsselfertig, wie es so schön heißt. Und noch weniger sind alle Beteiligten von Änderungen während der Bauphase – auch nach detaillierter, gemeinsamer Planung – befreit. Sei es wegen unvorhergesehener Schwierigkeiten beim Bauen selbst, wegen Änderungswünschen der Bauherren oder neuen Ideen des Architekten.

Der Kunde darf nerven

An der Softwareentwicklung mit Scrum gefällt mir so gut, dass es von dem Anspruch Abstand nimmt, ein schlüsselfertiges Produkt abzuliefern. Der Kunde darf bei der Entwicklung mit Scrum den Rohbau bewundern, das Richtfest feiern UND sich bei der Teppichauswahl zehn Mal umentscheiden. Und obwohl sie diese Dinge tun, werden die Architekten nicht arbeitslos oder hören gar auf zu planen – ebensowenig wie Entwickler, Softwarearchitekten, Tester oder Product Owner. Ganz im Gegenteil, sie reagieren bestmöglich auf alle diese neuen, veränderten Anforderungen. Ja und manchmal ärgern sie sich auch darüber, dass die Bauherren das nicht früher gewusst haben. Aber schließlich müssen sie darin wohnen, nicht der Architekt selbst. Anders bei Fertighäusern: Da ärgert sich meist nur der Bauherr, weil er im Endeffekt die kleinen Anpassungen doppelt bezahlt – nur dass wir in der Softwareentwicklung selten ein Produkt zwei Mal bauen.
Doch was tun, wenn wir keine Fertighaus-Software einsetzen können oder wollen? Was wenn der User genau wegen der individuellen Anpassungen und Mitgestaltung den Wert der Software erkennt?
Nehmen wir uns ein Beispiel am neuen Willy-Brandt Flughafen in Berlin. Hier wird vor dem Live-Betrieb mit immer größer werdenden Gruppen die Funktionsfähigkeit der Architektur, der Services, der Nutzerführung etc. geprüft. Die Tests fingen so früh an, dass auch grundlegende Änderungen gemäß dem Nutzer-Feedback noch möglich waren. Test-Passagiere sind mit allem ausgestattet,  was es im normalen Betrieb braucht und sollen sich wie ganz normale Passagiere verhalten. Inklusive Beschwerden, Hektik, Mitführen verbotener Gegenstände, Drängeln und Orientierungslosigkeit. Meckern ausdrücklich erwünscht!
Ich warte schon gespannt auf meinen ersten Flug vom neuen Flughafen Berlin aus und werde sicherlich Punkte erkennen, bei denen ich sagen kann: Hätten sie doch nur mich gefragt! Und obwohl ich weiß, dass es viel Nerven kostet, werde ich mich nicht für ein Fertighaus entscheiden.
Kristina Klessmann, Scrum Consultant

Wie erstellt man eine Persona?

Letztens habe ich in meinem Blogbeitrag vorgeschlagen, die User-Rolle mit Leben zu füllen, indem man sich tatsächliche Menschen vorstellt, die hinter diesen Rollen stecken. Schaut euch mal die Reportage von ABC über IDEO an. Die zeigt wunderbar, wie das Design-Team herauszufinden versucht, welche Menschen einen Einkaufswagen benutzen und vor allem wie sie diesen Einkaufswagen nutzen. Das Team von IDEO verwendet also offensichtlich das Element der Persona, um sein Produkt den Notwendigkeiten anzupassen.

Natürlich sind die wenigsten Produkt-Entwicklungsteams so aufgebaut wie ein IDEO-Team, aber welche Elemente können wir dennoch nutzen und was können wir von IDEO lernen? Hier meine 10 Tipps:

Lasst die Personas auch an eurem Entwicklungsprozess teilhaben! Sie sollten bei Meetings – dem Sprint Planning 1 und 2, während der Reviews, aber auch bei allen Design-Entscheidungen – mit im Raum sein.
Fragt euch immer: Wie würde die Persona das Feature sehen, das ihr gerade entwickelt bzw. entwickeln lasst?
 

Die User-Rolle ist tot, es lebe die Persona

Die XP-Community hatte vor etwa zehn Jahren die Idee, User Stories zu benutzten, um die Essenz einer Funktionalität aus der Sicht des Anwenders aufzuschreiben.
Zu Erinnerung:
Als User-Rolle
möchte ich eine Funktionalität
so dass ich den folgenden Nutzen habe. [1]
Eine super Idee, die dann von Mike Cohn aufgegriffen und durch sein Buch „User Stories applied“ populär gemacht wurde. Die Idee war so einfach, dass sie die damals gängigen Use Cases als Analysetool sofort überholte. Das Tool ist aber so einfach wie schwierig. Funktionalität aus Anwender-Sicht zu beschreiben, fällt vielen sehr schwer. Noch spannender ist zu beobachten, dass es tausende User Stories gibt, die im folgenden Format formuliert werden:
Als User möchte ich XX
Also wird zum einen einfach aus User-Rolle = User und die Frage nach dem “Wozu” wird oft weggelassen.

Echte Menschen für echte Rollen – die Persona

Heute möchte ich kurz über den User reden. Es ist wichtig zu sehen, dass User-Rolle gemeint war, nicht User. Es geht darum, dass sich der Product Owner und das Team eine echte Anwenderrolle überlegen und mit dieser arbeiten. Das Konzept der User-Rolle ist hier aber offenbar nicht griffig genug. Daher schlage ich vor, das Konzept der User-Rolle aus den User Stories zu streichen und durch das Konzept der Persona zu ersetzen. Personas sind am lebenden Menschen orientierte, imaginierte Personen, die unsere Applikationen, unsere Anwendungen, unsere Produkte benutzen.
Eine noch schönere und ausführlichere Beschreibung einer Persona findet ihr auf dieser Website, zusammen mit der folgenden Beschreibung, was eine Persona ist:
“Personas are archetypal users of an intranet or website that represent the needs of larger groups of users, in terms of their goals and personal characteristics. They act as ‘stand-ins’ for real users and help guide decisions about functionality and design. Personas identify the user motivations, expectations and goals responsible for driving online behaviour, and bring users to life by giving them names, personalities and often a photo.
Although personas are fictitious, they are based on knowledge of real users. Some form of user research is conducted before they are written to ensure they represent end users rather than the opinion of the person writing the personas.“
Wir machen also aus der Rolle Administrator zum Beispiel: Hans Müller, 35 Jahre, IT-Fachmann, lebt in München, fährt morgens mit der U-Bahn zur Arbeit. Er hat zwei Kinder, ist Studienabbrecher und faszinierter Science Fiction Fan. Er liebt es, mit seinen Kinder Lego zu spielen.
Diese Person ist aber erforscht. Das heißt, wir reden mit einigen Admins, finden heraus, wie die wirklich leben, wie sie unsere Applikation tatsächlich nutzen werden. Hat man mit seinem Team diese Personas identifiziert – und davon gibt es natürlich einige, ihr könnt auch mehr als eine Persona pro User-Rolle definieren -, dann kann man anschließend die User-Rolle durch die Persona ersetzen. Auf diese Weise entsteht eine wesentlich lebendigere Vorstellung davon, für wen man die Applikation erzeugt, als durch die User-Rolle. Zumal dann per se klar wird, dass es nicht nur einen User gibt.
Viel Spaß beim Erstellen von Personas!
[1] Boris Gloger: Scrum – Produkte zuverlässig und schnell entwickeln, Hanser, 3. Auflage, 2010

Die Bücher für den Rest des Jahres

Heute fasse ich mich mal kurz. Denn in den folgenden Büchern steht ohnehin genug Spannendes zu lesen. Hier meine Empfehlungen für eure Leselisten. Alle diese Bücher und natürlich noch einige mehr findet ihr direkt im bor!sgloger Buchempfehlungsstore auf Amazon.

Ich verspreche, dass es sich auf alle Fälle lohnt, diese Bücher zu lesen!
 

Wenn Scrum draufsteht, ist auch Scrum drin. Oder?

Also steht auf einem Projekt oder auf einer Projektmanagementmethode “Scrum”. Dann heißt der Projektmanager ganz schnell Product Owner und der Teamleader wird zum ScrumMaster. Schließlich machen wir doch Scrum, oder?

Agilität ist ein Mindset

Wenn es bloß so einfach wäre. Die größte Hürde im Verständnis von Scrum ist noch immer, dass ein Name allein noch keine Agilität bewirkt. Tatsächliche Agilität ist eng mit einem Paradigmenwechsel im Denken verknüpft. Agile Methoden wollen die motivativen Elemente befreien, die in jedem Menschen verborgen liegen und wirken daher disruptiv auf viele traditionelle Strukturen und Organisationen. Dass Agilität so tief in die Denkweise eingreift, können oder wollen viele Manager nicht erkennen, sogar wenn von ihnen selbst die Initiative ausgeht. Agiles Denken greift an, ist provokativ, sehr oft erzeugt es Chaos und Verunsicherung.  Es bedeutet, dass alte und oftmals überkommene Ideen durch wissenschaftlich fundierte Vorgehensweisen falsifiziert werden. Daran zerbricht auch der Vorwurf, Agilität sei ein Glaubensbekenntnis: Der Gott der Agilität existiert nicht. Agiles Denken ist tief verwurzelt in der empirischen Methode. Ursprünglich hatten Ken und Jeff sogar darauf bestanden, dass sich Scrum aus der Empirical Process Control heraus entwickelt hatte. Scrum ist eine wissenschaftliche Methode, wenn man wissenschaftlich als „durch das Experiment betätigt oder falsifiziert“ definiert. Aus genau diesem Grund vergleiche ich Scrum auch gerne mit dem Zeitalter der Renaissance.

Wiederentdeckung

In der Renaissance wurden die Natur, ihre Gesetze und letztendlich die Beobachtung als der Schlüssel zur Erkenntnis wiederentdeckt. Wiederentdeckt deshalb, weil das Mittelalter ignoriert hatte, was die antiken Denker bereits wussten.
Mercury-Kapsel, copyright NASAScrum knüpft mit den agilen Denkweisen an die Ursprünge der Softwareentwicklung an. Zu Beginn der Softwareentwicklung waren es einige wenige – so wie es in der Antike nur einige wenige waren, die wissenschaftlich gedacht haben. Dann beherrschte die Kirche das Territorium der Wissenschaft. Rund 1200 Jahre spielte das augustinische Denken die Hauptrolle, erst im 13. Jahrhundert begann man sich wieder auf die Ideen von Aristoteles zu besinnen. Nichts anderes passiert heute in der Produktentwicklung. Vor 50 Jahren wurden Produkte von exzellent ausgebildeten Wissenschaftern entwickelt, teilweise saßen Nobelpreisträger darunter wie zum Beispiel in den Bell Labs. Allerdings waren die auch schwer zu kontrollieren. Dann kam das Management mit seinen Ideen und versuchte mit seinem hohen Sicherheitsdenken, Stabilität zu schaffen. Und heute sind es wieder die wissenschaftlich ausgebildeten und kreativen Menschen, die das Design Thinking nutzen, um aufzuzeigen, dass die alten Ideen aus den 1960er-Jahren doch korrekt waren. Sie wissen wieder, wie man Produkte entwickelt, die auch richtig gut funktionieren.

Erfolg mit agilem Denken

Agiles Denken beginnt mit der klaren Erkenntnis, dass man immer die Ergebnisse erzielen wird, für die eine Organisation aufgestellt ist. Erzeugt man keine guten Produkte, dann liegt es nicht am bösen Markt, dem bösen Kunden, an der Situation oder an wem auch immer. Es liegt ganz einfach daran, dass die eigene Organisation in ihrer aktuellen Gestaltung nicht zu den Anforderungen ihres Umfeldes passt.
Nicht die Realität ist falsch, nicht das Universum, nicht die Gesellschaft oder der Markt laufen in die falsche Richtung, wenn ich keinen Erfolg mit einem Produkt habe. Nein, es ist ganz einfach die simple Tatsache, dass mir der Erfolg nicht gegeben ist, weil der Kontext nicht zu meinem Produkt passt. Weil die  Entwicklungsmethoden ungeeignet sind, weil ich nicht die für diese Aufgabe geeigneten Menschen eingedstellt habe, weil die Prozesse zu langsam sind uvm.

Der Designer Tom Ford hat das wunderbar ausgedrückt: Er hatte das große Glück, ein wenig früher zu erahnen, was der Markt bald haben will. So hatte er, was der Markt wollte, als der Markt bereit war zu erkennen, dass er es will. Er hatte sich mit seinen Produkten so in Position gebracht, dass er rechtzeitig zur Stelle war. Er hat sich aber offenbar nicht nur mit seinem Produkt richtig positioniert, er hat auch die gesamte Infrastruktur geschaffen, damit sein Geschäftsmodell funktioniert.

Erfolg mit Menschen

Agiles Denken sieht klar, dass wir es in unseren Arbeitsprozessen mit Menschen zu tun haben. Es nimmt die Menschen mit ihren Emotionen, mit ihren Wünschen, mit ihren Bedürfnissen wahr, es arbeitet mit und nicht gegen sie. Agiles Denken stellt die Interaktion zwischen Menschen über die Abläufe von Prozessen her, lässt Raum für Intuition, Inspiration und Improvisation.
Agiles Denken setzt auf die Zusammenarbeit, auf den Dialog, auf den Kontext und auf das Vertrauen, dass Menschen etwas miteinander schaffen wollen. Mitch Lacey erzählte vor ein paar Monaten bei einem Vortrag in Wien, dass er zu einem Kunden sagte: „Wenn ich ihnen jetzt am Anfang ein Proposal mache, ohne sehr gründlich zu analysieren, was sie wirklich brauchen, dann ist das doch im Grunde sehr unprofessionell. Lassen sie es uns doch gemeinsam erarbeiten, indem ich Ihnen immer etwas liefere.“ [1] In dieser Geschichte steckt der Geist der Agilität in jedem Wort. Dinge nehmen wie sie sind, ohne sie zu beschönigen. Sich darüber im Klaren sein, was realistisch ist und die eigenen Grenzen kennen. Das sind die Grundelemente, die sich auch in den Werten von Scrum wiederfinden.
Agiles Denken ist sich der Rahmenbedingungen und der geschäftlichen Implikationen bewusst. Agile Manager (Manager, weil es im agilen Denken den Projektmanager nicht geben kann) wissen natürlich, dass es Zwänge gibt, dass diese Zwänge aber nicht einschnüren sollten. Und wenn sie es tun, dass diese Fesseln gesprengt werden müssen. Immer eingedenk der Tatsache, dass viel mehr Dinge möglich sind, als viele Menschen glauben.
All das habe ich früher und all das bezeichne ich immer noch als einen Paradigmenwechsel für die meisten Denkprozesse in Unternehmen.

Auf der Reise nach und durch Scrumland

Wer sich auf die Reise ins Scurmland macht, der muss mit vielen vielen Hindernissen, Gefahren und Untiefen rechnen. Es gibt keine asphaltierten Wege, keine Umgehungsstraßen, keine fertigen Lösungen aus dem Lieferkarton. Aber wir sind auch nicht mehr im Scrum-Urwald. Es gibt schon die ersten Trampelpfade und Lehmwege. An manchen Stellen gibt es sogar schon Gasthäuser und die ersten Siedlungen, in denen man erfahren kann, wie es weitergeht. Die ersten Wegweiser stehen und die Pioniere haben die ersten Seilbrücken gebaut. Mittlerweile wurden schon einige Reiseführer geschrieben und die ersten Do-It-Yourself Bücher stehen bereits im Regal. Gehen muss man aber immer noch selbst. Die Ärmel hochkrempeln, neue Wege ebnen, eigene Best-Practices entwickeln, selbst kreative Lösungen entwickeln und sich das Scrumland Stück für Stück aneignen. Wer den Weg gehen will, der darf sein Vorhaben auch  Scrum nennen und wird sicher viele Erfolge für sich und seine Organisation verbuchen können.
Wir stehen noch immer am Anfang – Aber… Nur das Label drauf zu kleben, also sich die Federn zu holen, ohne den Vogel zu erlegen … das geht nach hinten los. Garantiert.
[1] Mitch Lacey bei seinem Vortrag bei der Agile Tour 2011 in Wien. Nicht wörtlich wiedergegeben.

Grundwerte und Teamentwicklung in Scrum Teams

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

Das Modell der drei Grundwerte

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.

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

Shu-Ha-Ri oder Scrum by the book ☺

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.
Copyright: Gerhard PeyrerPositive 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:

(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.”

 

Kreativität schafft Raum, wo kein Platz ist

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.

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 :-).

Kreativität und Intuition

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.

Das letzte Wort hat unser Hirn

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

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

Spiel und Spaß – Produktivitätsfaktoren für Teams

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.”
Foto: ProduktivitätsplüschEigentlich 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:
[quote author=”Steve Jobs”]“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.”[/quote]
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!

Starte nur dann ein IT-Projekt, wenn du dir den Verlust auch leisten kannst

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,

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.

Dan Pink über Business

Ich bin gerade wieder über dieses Video gestoplert und denke, ihr solltet es unbedingt ansehen: