Kommunikation 2.0

Wann hast du zum letzten Mal eine Person gesehen, die in der Öffentlichkeit weinte? Kannst du dich noch daran erinnern? Und, falls ja: Wie hast du dich dabei gefühlt? Hast du überlegt, ob du etwas tun solltest, um der Person zu helfen? Hast du es vielleich sogar getan?
Der Schriftsteller Jonathan Safran Foer fragt sich anlässlich einer solchen Erfahrung, wie die heutigen Kommunikationsformen unser Leben beeinflussen. Seine These: Moderne Kommunikationsmöglichkeiten sind als Ersatz für unmögliche Aktivitäten entstanden. Wenn ich meinen Kollegen nicht sehen konnte, dann rief ich ihn an. Wenn ich nicht anrufen konnte, dann schrieb ich ihm eine E-Mail. Und wenn ich keine E-Mail schreiben konnte, dann schickte ich ihm eine Kurznachricht.
Diese alternativen Kommunikationsmöglichkeiten wurden nicht als Verbesserungen, sondern als abgeschwächter Ersatz eingeführt. Mit der Zeit geschah aber etwas Spannendes: Die Menschen fingen an, die Ersatzkommunikation der unmittelbaren Kommunikation zu bevorzugen. Safran Foer führt das auf den Bequemlichkeitsfaktor zurück: Denn die emotionalen Herausforderungen sinken, wenn unser Gegenüber nicht im gleichen Raum ist. Im Vieraugengespräch sind wir in unserer Ganzheit gefordert: Unsere Stimme, unsere Blicke, unsere Haltung und Körpersprache sind Teil der Botschaft, die wir überbringen.
Hinter einer E-Mail oder einer Textnachricht können wir uns hingegen gut “verstecken”. Und da steht der andere plötzlich vor einem Dreizeiler auf seinem Handy und versucht, die Botschaft hinter der Botschaft zu entschlüsseln. Wir alle wissen: Das kann mächtig schief gehen. Denn Informationen sind selten nur Informationen – dahinter stecken Menschen mit Gefühlen, Motivationen und Absichten. Eine trockene Termineinladung hat mir einmal das komplette Wochenende vermasselt, weil ich nicht einschätzen konnte, was wirklich dahinter steckte. Wäre mir die Botschaft persönlich übertragen worden – ich hätte schon am Gesichtsausdruck und der Stimme meines Gegenübers die Lage einschätzen können.
Wir erleben das gleiche Problem mit geografisch verteilten Teams: Die kommunikative Bandbreite eines Gesprächs von Angesicht zu Angesicht wird durch noch so raffinierte technologische Ersatzlösungen nie erreicht. Allein die physische Nähe –  Raum einnehmen, aufeinander zugehen, den anderen unvermittelt vor Augen zu haben – führt zu einer Präsenz, einer Gravitationskraft (Attraktion), die Menschen in besonderer Weise empfänglich macht. Nicht umsonst blühen unsere stärkste Gefühle – Liebe und Hass – bei der Anwesenheit der geliebten und/oder gehassten Person am stärksten auf.
Ich habe Zugreisen verbracht, in denen mein Ökosystem an Geräten – Telefon, Tablet, PC,Lesegerät – mich dermaßen umnebelt hat, dass ich nicht sagen konnte, wie das Gesicht von meinem Sitznachbarn aussah. Und hätte er geweint – womöglich hätte ich es zum Anlass genommen, mich noch tiefer in meiner Welt zu verbuddeln.
Vermittelte Kommunikationswege sind weder schlecht noch gut. In vielen Situationen brauchen wir sie einfach, und manchmal funktionieren sie wunderbar – eine knappe Mitteilung, das spontane Teilen von Glück oder Trauer, die Erreichbarkeit von Unerreichbaren.
Zugleich haben wir immer die Möglichkeit, unvermittelt, von Angesicht zu Angesicht zu kommunizieren. Immer. Und wenn wir auf das Treffen ein Jahr warten und eine weite Reise dafür in Kauf nehmen müssen: Wir haben die Wahl. Und diese Wahl, sie ist wichtig, denn in der vollen Bandbreite der menschlichen Kommunikation, in der An-Wesenheit des anderen, können wir füreinander da sein:
We live in a world made up more of story than stuff. We are creatures of memory more than reminders, of love more than likes. Being attentive to the needs of others might not be the point of life, but it is the work of life. It can be messy, and painful, and almost impossibly difficult. But it is not something we give. It is what we get in exchange for having to die.

Jonathan Safran Foer: How not to Be Alone. The New York Times Sunday Review, 8. Juni 2013.

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?!

Die (Über-)Lieferung von Vertrauen

Nahezu jedes Unternehmen hat Erfahrungen mit der Beauftragung von Software-Entwicklungsprojekten und das sind zum Teil schlechte Erfahrungen. Durch solche schlechte Erfahrungen haben über die Zeit immer mehr Organisationen das Vertrauen in ihre Software-Entwicklung verloren. Ich möchte nicht behaupten, dass es nur furchtbare Software-Entwicklungsprojekte gibt. Aber ich behaupte, dass wir hier zu großen Teilen in einer Vertrauenskrise leben. Diese Vertrauenskrise hat nicht nur mit enttäuschten Erwartungen zu tun, sondern auch mit einer veränderten Welt, in der Vertrauen nicht mehr über langfristige Bindungen aufgebaut wird (Vertrautheit), sondern in der Schnelllebigkeit entstehen muss. Wir brauchen also einen anderen Weg, um Vertrauen über mangelnde Vertrautheit zu entwickeln. Kommen wir nochmal zurück zu den Software-Entwicklungsprojekten und verallgemeinern kurz: Umso weniger Vertrauen besteht, desto mehr Kontrolle möchte man ausüben. Vertrauen und Kontrolle versteht man weitläufig als entgegengesetzte Pole, die nicht gleichzeitig existieren können.

Wenn wir das Problem kennen, dann kennen wir doch auch die Lösung?

Vertrauen entsteht nicht über Worte, das wissen wir bestimmt, denn das ist neuronal in unserem Gehirn so verankert. Wir benötigen also Taten, die sich einer schnelllebigen Welt anpassen. Taten, die es ermöglichen, die Erwartungen eines Auftraggebers, eines Kunden und jene von Endnutzern mit dem Beauftragten abzugleichen. Wir als Software-Entwickler brauchen Lieferungen qualitativer, anwendbarer Software in kurzen Zyklen. Mit den Lieferungen zeigen wir, dass wir verstanden haben und liefern können was beauftragt wurde. Wir zeigen, dass wir den impliziten Anspruch auf Qualität halten können. Zudem rücken wir Kunden und Nutzer in den Mittelpunkt, beziehen ihn immer wieder in die Entwicklung ein und geben ihnen eine Stimme. Wichtig dabei ist, dass wir diesen Prozess wiederholen, ritualisieren, oft durchführen, damit wir als Software-Entwickler Verlässlichkeit zeigen können. Wir zeigen, dass es kein Glückstreffer war, sondern dass wir wiederholt qualitative Software  liefern können – wir zeigen professionelles Arbeiten. Im Scrum-Prozess stehen die Lieferung und das Präsentieren der fertigen Funktionen am Ende jedes Sprints, üblicherweise nach 14 Tagen. Am Ende jedes Sprints zeigt das Scrum-Team die lauffähigen Funktionen im Review den Kunden und Nutzern.
Da wir gerade beim Kunden sind, bleiben wir kurz bei ihm. Es wäre fahrlässig, würde der Kunde die Kontrolle aufgeben. Die beauftragte Software ist relevant für die Ergebnisse des eigenen Unternehmens und soll dazu beitragen, die Zukunft des Unternehmens zu sichern. Als Kunden brauchen wir also einen Kontrollmechanismus. Diesen Kontrollmechanismus sollte man nicht an Worten, konkret Verträgen, festmachen, sondern man sollte auch hier wieder auf Taten setzen. Ein wichtiges, wenn nicht gar das Kontrollelement des Kunden sind die Reviews, die er einfordern und aktiv daran teilnehmen sollte. Das Review ist die Fortschrittskontrolle und die Kontrolle des inhaltlich Gelieferten. Zudem ist es die Kontrolle über die Schnelllebigkeit der Märkte, denn wenn Sie als Kunde agil entwickeln lassen, bekommen Sie Kontrolle über Time-to-Market und haben Einfluss auf Änderungen – idealerweise sogar “Change for free“, solange sie auch den Umfang Ihres Produkts/Projekts anpassen. Dafür sollten Sie auch einen Vertrag aufsetzen, der das Ganze widerspiegelt. Auch das ist heutzutage möglich und sogar Wunsch bei vielen Software-Entwicklungen.

Fazit

Liefern wir als Software-Entwickler regelmäßig in kleinen Abständen mit hoher Qualität, so haben wir die Chance, zerstörtes Vertrauen aufzubauen oder dem gewährten Vertrauensvorschuss gerecht zu werden. Nutzen wir Rückkopplungspunkte wie Reviews dazu den Kunden einzubinden, lösen wir sogar das Paradoxon von Vertrauen und Kontrolle zu unserem Vorteil auf. Letztlich gewinnen beide, der Kunde und die Software-Entwicklung. Die Software-Entwicklung vielleicht sogar ein wenig mehr, denn sie hat etwas zurückzugewinnen und das gilt für die gesamte Branche.

Die Interpretation eines Commitments

Ein Commitment – was ist das eigentlich? Ist es ein Wort, ist es ein Wert oder ist es etwas ganz anderes? Dieser Frage möchte ich heute auf den Grund gehen.
In Scrum gibt es das Commitment an zwei Stellen: einmal als Wert und einmal als Ritual im Sprint Planning 1. Im aktuellen Scrum-Guide der Scrum Alliance wurde das Commitment durch eine Vorschau/Prognose (Forecast) ersetzt. Ein Forecast wie Wetterbericht nach dem “Yesterday weather principle”, ersetzt das “Ja-Sagen” des Entwicklungsteams im Sprint Planning 1.
Nochmal zurück zur Ausgangssituation: Was ist ein Commitment? Dafür gibt es einige Übersetzungen und noch mehr unterschiedliche Reaktionen von Entwicklungsteams, wenn es um das Commitment geht.
Einige Entwicklungsteams reagieren auf das Commitment im Sprint Planning 1 zurückhaltend und zögerlich – sie probieren es mal. Das passiert bspw. dann, wenn ein Entwicklungsteam nicht einschätzen kann, ob es eine Story schafft. Das hat oft damit zu tun, dass dem Entwicklungsteam nicht klar ist, was gefordert wird, die Story zu groß ist oder schlichtweg dem Entwicklungsteam nicht klar ist, wie es umgesetzt werden kann. Das sind meist aber nur Symptome fern der Ursachen. Hier sollte man genauer hinsehen: Ist die Story nicht klar oder zu groß, so war das Entwicklungsteam im Vorfeld nicht ausreichend einbezogen. Das Team hat entweder zu wenig Eigenverantwortung gezeigt sich zu beteiligen oder es wurde daran gehindert. Zögert das Entwicklungsteam, so steckt meines Erachtens auch immer Angst dahinter. Ein Team traut sich nicht zu liefern, da sich die Erfahrungen beim Scheitern wie Schläge in den Nacken anfühlten und nicht wie Erkenntnisse, die erst nach dem Start auf uns gewartet haben. Erfahrung bleibt in Erinnerung, da helfen keine schönen Worte, dass es anders sein soll – solche Worte verblassen. Neulich hatte ich erst ein Gespräch mit jemandem, der den Kulturwechsel von Angst vor dem Scheitern hin zum Erfolg durch Scheitern hinter sich hat. Er meinte, es dauerte ein 3/4 Jahr, bis jeder die Erfahrung gemacht hatte nicht bestraft zu werden und wieder angstfrei arbeiten konnte. Wenn Angst im Spiel ist, braucht es positive Erfahrungen, damit ein Commitment mehr wird als ein “wir probieren es mal”. Doch auch so ein Commitment muss man respektieren, um eine angstfreie Atmosphäre zu erzeugen.

Das Wesentliche

Was ist ein Commitment noch? Was kann es sein, was ist das Ziel hinter einem Commitment? Ein Commitment ist zum einen ein “Ich gebe mein Wort und mache es fertig”, es ist zum anderen “ein Hebel für das Team, um Überlastung zu vermeiden” und es ist ein “eigenes Ziel, das sich zu verfolgen lohnt”.
“Ich gebe meine Wort und mache es fertig” meint: “I am commited to this.” Beim Pokern würde man sagen ich bin “all in”. Ich denke, dass meine Karten passen, ich setze es und ziehe es durch. Es ist kein Probieren, sondern eine klare Ansage der eigenen Selbstverantwortung. Ich mache das, das ist meine Verantwortung und ich bin dabei. Es ist eine Selbstverpflichtung, die jeder im Team zu leisten hat – deswegen frage ich jeden Einzelnen danach, ob er dabei ist, ob er “all in” geht. Dabei ist es mir egal, ob die Mutlosigkeit Einzelner den Willen und die Disziplin infrage stellt und die Nachfrage als Utopie belächelt wird. Wichtig ist mir, Selbstverantwortung zu erzeugen oder zumindest einen Raum dafür zu geben.
Einen Raum geben heißt auch einen Hebel anbringen, an dem man ziehen kann, um Überlast zischend entweichen zu lassen. Das Commitment ist ein solcher Hebel. Wenn ein Team “Stop” sagt, dann heißt es Stop. So schützt sich ein Team vor Überlast, und nur so kann es auch “all in” gehen, sich committen. Denn nur der, der nicht überlastet ist, kann sagen, ob er etwas schafft und sich auch voll dafür einsetzen. Mit dem Commitment setzen wir das PULL-Prinzip ein. Wir entkoppeln uns vom Druck.
Sind wir einmal entkoppelt vom Druck, können wir uns mit den Zielen befassen, die an uns herangetragen werden und die es umzusetzen gilt. Wir können uns mit ihnen befassen und sie dadurch zu unseren Zielen machen. D. h. wir müssen sie verstehen, sie fassen können, das warum verstehen und deswegen auch verwirklichen wollen – es ist ein Teilhaben und ein Teilnehmen. Gelingt uns das, dann schaffen wir es vielleicht zu der Art von Commitment, die mir am besten gefällt: Die Hingabe eines Teams für sein Produkt und die Lust, daran zu arbeiten. Eben voll drin zu sein und die Konzentration hochfahren und zu fokussieren. Dafür müssen wir oft auch kämpfen, denn das bedeutet Freiheit und Selbstverantwortung – Commitment eben – und zuletzt bedeutet es auch, im Kampf mit sich selbst zu bestehen, sich nicht abzulenken, denn um die eigene Wahl, die eigene Freiheit und Selbstverantwortung dreht es sich immer wieder:
“Nichts garantiert unsere Freiheit. Verneine sie oft genug, und eines Tages gibt es sie nicht mehr. Zu guter Letzt haben wir unsere Füße und Hände gefesselt und rufen triumphierend aus, wie recht wir hatten.” (Allen Wheelis in How People Change)
Ich erlebe mein persönliches Commitment in meiner Freizeit und ich merke dort sehr deutlich, wenn ich committed bin, wenn es wirklich heißt “I am into it”. Ich erlebe es genau dann, wenn ich an meiner Leistungsgrenze klettere. Wenn ich drin bin und mich konzentriere. Wenn ich bewusst wähle, die schwierige Stelle mit vollem Einsatz anzugehen; mich dazu entscheide, den Griff zu halten. Wenn ich mit dieser Einstellung rangehe, dann schaffe ich den Sprung, bin bei der Sache. Wenn du mich fragst, was ein Commitment ist, dann werde ich dir antworten, dass es eine Geisteshaltung ist, die darüber bestimmt, ob du es schaffst, ob du es durchziehst, oder ob du aufgibst, bevor du angefangen hast. Du kannst dich auf den Sturz konzentrieren oder auf den nächsten Griff – du hast die Freiheit zu wählen.

Kopfstandkino Risiko

Agile, Scrum und Risiken. Drei Dinge für mich, die zusammengehören. Hohes Risiko, hoher Gewinn, aber eben auch hohes Risiko. Wir vermeiden gerne Risiken, weil uns der Zugang fehlt. Wir arbeiten lieber darum herum, statt zu scheitern. Wenn ich Risiken angehen möchte, dann brauche ich zumindest einen Zugang, der mir einen kontrollierten Rahmen bietet. Einen Zugang, der mir hilft Entscheidungen zu treffen und mich unterstützt, kleine Fehler zu machen, statt einen großen.
Was macht agil nun anders? Agil stellt Risiken auf den Kopf – im wahrsten Sinne des Wortes. Jedes Risiko lässt sich als Chance formulieren, viele Risiken können als Eintrag im Product Backlog landen. Als Features, deren Nutzen es zu testen gilt, als minimal lieferfähiges Produkt (minimum viable product) über das sich der Mark testen lässt. Statt Risiken zu verwalten, tritt man dem Risiko entgegen, bereitet sich auf eine epische Schlacht mit ihm vor und begrüßt die Erkenntnisse, die auf dem Weg warten. Auf dem Weg heißt: nach dem Start.

Software-Anforderungen erfassen und weitergeben ist ein Kommunikationsproblem

Scrum ist ein Kommunikationsrahmen. Ein Rahmen, in dem mehr und mehr Beteiligte angehalten werden, miteinander zu sprechen und wertschätzend zu kommunizieren. Ein Rahmen, in dem ritualisiert alle relevanten Beteiligten eingebunden werden, damit ein gemeinsames Bild entstehen kann. Wir klären gemeinsam die Anforderungen. Angefangen im Sprint Planning 1: Hier holen wir uns die Personen hinzu, die uns genau sagen können, was gewünscht ist. Im Daily Scrum halten wir Kontakt mit ihnen und optimalerweise nutzen wir die Zeit nach dem Daily Scrum, um Rückfragen zu klären. Spätestens im Review zeigen wir, was umgesetzt wurde. An diesem Punkt kommt die Erkenntnis ins Spiel und wir können den Nutzen validieren. Wichtig ist jedenfalls: “Die Personen, die eine Software wollen, müssen mit den Personen kommunizieren, die die Software bauen.” (Gojko Adzic)
Je weniger Kommunikation stattfindet, desto höher das Risiko, dass wir das Falsche liefern. Dass wir zwar technisch einwandfrei liefern, jedoch nicht das liefern, was der Kunde möchte. Oder in anderen Worten, wie Gojko Adzic es sagt: “I am getting more and more convinced every day that communication is, in fact, what makes or breaks software projects. Programming tools, practices and methods are important, but if the communication fails then the rest ist just painting the corpse.”
Also gehen Sie das größte Risiko “Kommunikation” an und starten Sie mit einem Prozess, der die Kommunikation in den Vordergrund rückt: Scrum!
Wie Scrum im Detail mit Risiken umgeht finden Sie unter anderem in diesem Artikel: Agiles Risikomanagement mit Scrum – empört Euch!

Gute ScrumMaster können bis 10 zählen

1 – ein ScrumMaster, ein Scrum-Team. 

Immer wieder kommt die Frage auf, wie viele Scrum-Teams ein guter ScrumMaster führen kann. Soll er nur ein Team haben? Kann er nicht zwei oder vielleicht sogar drei haben, wenn diese schon erfahren genug sind? Ich bin der Ansicht, dass Menschen, egal wie talentiert oder wie gut sie organisiert sind, immer nur eine Sache machen können, wenn sie diese fokussiert und mit Hingabe erledigen wollen. Ein Scrum-Team zu führen ist komplex und fordert dem jeweiligen ScrumMaster alles ab. Meine Empfehlung lautet daher: ein ScrumMaster, ein Scrum-Team.

2 – zwei Rollen auf einmal können nicht funktionieren.

Was für die Führung eines ScrumTeams zutrifft, das zählt für die Erfüllung der Rolle als ScrumMaster nicht minder. So dogmatisch es für viele immer wieder klingen mag, so sinnvoll und (erfahrungsgemäß) realistisch ist es: Ein ScrumMaster sollte seiner Verantwortung als ScrumMaster nachkommen und nicht mehr! Ein ScrumMaster sollte ebensowenig als Entwickler, wie in Zweitfunktion als Product Owner agieren: Interessenkonflikte und Überforderung sind quasi vorprogrammiert. Meine Empfehlung lautet daher: gute ScrumMaster wissen, dass sie nicht zwei Rollen belegen können.

3 – drei Verantwortungen, drei Hüte.

In einigen Punkten gehen bor!sgloger consulting und die Scrum Alliance nicht immer konform. Aber in der Three-Hats-Challenge des ScrumMasters herrscht Einigkeit: „A good ScrumMaster will be a process facilitator, a servant leader to the team and a change agent within the organization.“ (3) Diese drei Hüte erfordern von einem ScrumMaster, drei Verantwortungen im Fokus zu behalten, um ein Scrum-Team produktiv(er) zu machen:  Scrum (Prozess) einführen, das Scrum-Team schützen (nach innen und außen) und Hindernisse (Impediments) beseitigen. Die Three-Hats-Challenge unterstreicht das, was die Zahlen eins und zwei zum Ausdruck bringen. ScrumMaster sein ist ein Fulltime-Job.

4 – Scrum heißt ganz oder gar nicht – vier Prinzipien als Kompass des Handelns.

Der ScrumMaster will „vier Prinzipien immer und immer wieder zur Anwendung bringen“ (Gloger, 2011, S. 23), weil diese Argumente enthalten, die es braucht, um Scrum mit Erfolg in einer Organisation zum Einsatz zu bringen: Selbstorganisation, das Pull-Prinzip und damit die Kontrolle von Input, Timebox und damit die Vorgaben von Grenzen (Rahmen) sowie Nutzbare Business-Funktionalität als Ergebnis jeder Iteration (Sprint). Boris Gloger (2011, S. 23) vertritt die klare Auffassung: Ist eines der Prinzipien verletzt, dann ist es kein Scrum!

5 – der ScrumMaster und die fünf Werte von Scrum.

Werte sind immer ein Fundament und ihre Intention ist es, nach ihnen zu streben. Es geht weniger darum, sie zu perfektionieren, als vielmehr sie als Fixstern, wie als Lichtstrahl in einem Leuchtturm, also als Orientierung anzuerkennen und „just do them now, as best you can. Good stuff happens immediately regardless of where and when you start.“ (4) Scrum kennt derer fünf Werte, die die Grundlage des Handelns bilden. Sie lauten: Respekt, Offenheit, Fokus, Commitment, Courage.

6 – drei plus drei ist gleich sechs.

Der Erfolg von Scrum, des De-Facto-Standards in der Softwareentwicklung, ergibt sich unter anderem durch seinen Rahmen (Framework). Eine Rahmenbedingung stellen die sechs Rollen, die der Scrum-Prozess vorsieht: drei funktionale Rollen (= das ScrumTeam), nämlich Product Owner, ScrumMaster und Entwicklungsteam, drei organisationale Rollen, nämlich Manager, Customer und Enduser.

7 – Mike Cohns Eigenschaften eines guten ScrumMasters plus eine von mir.

Mike Cohn nennt sechs „Eigenschaften eines guten ScrumMasters“ (1), durch die sich die seines Erachtens „besten ScrumMaster auszeichneten“ (1): Verantwortungsbewusstsein, Bescheidenheit, Förderung der Zusammenarbeit, Engagement, Einfluss und Wissen (vgl. Cohn, 2010, S. 146ff). Es ist eine großartige Zusammenstellung. Mir fehlt noch eine siebte Eigenschaft, eine, die in der heutigen Kommunikation von und mit Menschen oftmals vergessen wird beziehungsweise viel zu kurz kommt – nicht zuletzt, weil wir Menschen verlernt haben, uns diese Eigenschaft zu nutze zu machen: das Schweigen.

8 – bei acht ist Schluss.

Die Zahl 8 steht für mich wie Felsen, wenn ein ScrumMaster ein Estimation Meeting leitet. Wenn die Teammitglieder die vom Product Owner priorisierten Userstories schätzen, dann steht für mich fest, dass ein guter ScrumMaster nur die vom Entwicklungsteam geschätzten Userstories ins Sprint Planning 1 zulässt, die kleiner gleich 8 Storypoints (entsprechend der Cohn`schen Reihe = unreine Fibonacci-Skala) geschätzt wurden (besser wäre natürlich, wenn sie einen noch kleineren Funktionsumfang haben). Sind sie größer und in der Priorität des POs so hoch, dass sie im nächsten Sprint geliefert werden, dann sollte der ScrumMaster darauf achten, dass der PO diese Stories noch mal schneidet oder dass sie zu einem weiteren Anlass für eine Konversation VOR dem SP 1 werden.

9 – mehr als neun bedeutet immer weniger.

Ein Scrum-Team sollte aus nicht mehr als neun Teammitgliedern bestehen. Amazon spricht vom so genannten „Zwei-Pizza-Team“ (Cohn, 2010, S. 208). Das bedeutet, dass ein Team so klein sein sollte, damit eine Bestellung von zwei Pizzas kein Tohuwabohu wird, sondern leicht von der Hand geht. Vorteile kleiner Teams sind u.a. weniger Zeit für Koordination und Kooperation, weniger soziales Faulenzen, weniger Gefahr der Spezialisierung einzelner, höhere Produktivität, etc.

10 – Robin Hood, mein Held als ich zehn war.

Boris Gloger vergleicht die Rolle eines erfolgreichen ScrumMasters mit der Romanfigur Robin Hood (vgl. Gloger, 2011, S. 24ff.). Als ich zehn Jahre alt war, war Robin Hood auch mein Held: Erol Flynn, unerschrockener Widerstandskämpfer gegen den bösen König John und den Sheriff von Nottingham. Der ScrumMaster hat stets die Rolle des Veränderers. Er ist Vorreiter und geht dorthin, wo es weh tun kann oder wo er anderen (z.B. Management) weh tun muss. Er stellt Fragen, die sich sonst keiner zu stellen traut. Er sucht und findet Lösungen, wo andere an Problemen, Stillstand und Routinen gescheitert sind. Er gibt seinem Team Hoffnung, hält ihm den Rücken frei und weitet die Kultur von „Scrum“ auf die Organisation aus. Die besondere Herausforderung hierbei ist, dass der ScrumMaster ohne Autorität führt. Seine Rolle und die damit verbundene Verantwortung ist es, die ihm erlaubt, sein Handeln darauf auszurichten, den bösen Mächten des Stillstands die Stirn zu bieten und dafür zu sorgen, dass der Prozess in den (Scrum-)Flow kommt.
 
Literatur
(1) Cohn, M. (2010). Agile Softwareentwicklung. Mit Scrum zum Erfolg. Addison-Wesley
(2) Gloger, B. (2011). Scrum. Produkte zuverlässig und schnell entwickeln. Hanser

(3) http://www.scrumalliance.org/courses/20093867-certified-scrummaster
(4) http://newtechusa.net/agile/scrum-values/

Entschuldigen Sie bitte, wie lösen Sie Ihre Probleme?

2012 – Das Jahr geht zu Ende und viele Unternehmen stecken mitten in ihren Transitionen hin zur agilen Organisation. Ob strategisch beschlossen oder durch die eigenen Teams in die Unternehmen gebracht: AGILE setzt sich immer mehr durch und stößt auf Herausforderungen. Die größte Herausforderung in den Organisationen ist die eigene Kultur. Denn ohne einen Wechsel in den Köpfen und Herzen der Menschen wird jeder Wandel zum Spießroutenlauf – mit wenig Hoffnung auf Erfolg. Peter Drucker drückt es so aus: “Culture eats strategy for breakfast” und beide sitzen sich in den Unternehmen täglich beim Brunch gegenüber. Um einen Wandel zu vollziehen, der nicht der hungrigen Kultur zum Opfer fällt, benötigen wir also eine Kultur, die gemeinsam mit der Strategie am großen Kuchen Organisation backt. Ein solcher Wandel gelingt meines Erachtens, wenn man sich nach allgemeingültigen Prinzipien ausrichtet. Prinzipien wie beispielsweise Fairness, Offenheit, Respekt & Freude.
2001 – In diesem Jahr wurde der Grundstein für die Agilität gelegt, das Agile Manifesto. Mit dem Agile Manifesto geben wir Unternehmen eine Orientierung nach Prinzipien, die für den Wandel hin zur agilen Organisation wichtig sind. Eine genaue Ausrichtung – ein true north, um sich stetig zu hinterfragen und neu zu orientieren.
2012 – Wie gehen heute die meisten Organisationen ihre Probleme an? Leider zumeist mit der Denkweise, durch die sie entstanden sind. Hilft das bei der Lösung? Laut Albert Einstein NEIN, denn: “Probleme kann man niemals mit derselben Denkweise lösen, durch die sie entstanden sind.” Wie versuchen Organisationen ihren Wandel durchzuführen. Nehmen wir das Beispiel der klassischen Organisation zur agilen Organisation: Es wird geplant, geplant, geplant. Am Start sucht man bereits das Zielfoto und das in einem komplexen, globalisierten System, dass lediglich auf Anreize reagiert und nicht gesteuert werden kann. Grundbedingung ist natürlich, dass wir Organisationen als komplexe Systeme begreifen, die am besten durch empirische Prozesse ausgesteuert werden können. Also einen faktenbasierten Prozess, der auf Messung der Ergebnisse beruht – bspw. ein Prozess wie Scrum, der dazu noch einen Change Agent in jedes Team steckt und das im Auftrag der Kultur. Konkret einen Prozess, der sich auf das Tun versteht, der es ermöglicht anzuschauen, zu inspizieren oder wie Johann Wolfgang von Goethe es sagte: “Denken ist interessanter als Wissen, aber nicht als Anschauen.”

2012/2013 – und wie geht es weiter?

Am besten hinterfragen Sie sich regelmäßig, inwiefern Sie selbst hinter diesen Werten stehen, wie stark Sie sich an diesen Werten ausrichten. Eine stetige Reflektion des eigenen Tuns hilft uns in der Zukunft, uns besser an den eigenen “Wunschwerten” auszurichten. Haben Sie schon Vorsätze für das neue Jahr? Vielleicht finden Sie konkrete Punkte zum Anknüpfen und bringen anstehende Tätigkeiten mit den Werten überein.
Als ScrumMaster führen Sie bspw. in der Retrospektive eine Einpunktabfrage für die Werte und wie sie im Team gelebt werden durch. Dadurch sehen Sie bspw. wo ihr Team gefühlt steht und können konkrete Vorsätze zu den jeweiligen Prinzipien/Werten ableiten.
Versuchen Sie, sich bei alten Denkmustern zu erwischen. Wenn Sie solche Momente finden, dann reflektieren Sie diese: Was hätte ich anders machen können oder was kann ich jetzt genau anders machen, anders in Bezug auf ihr Ziel?
In diesem Sinne: “Denken und Tun, Tun und Denken, das ist die Summe aller Weisheit, von jeher anerkannt, von jeher geübt, nicht eingesehen von einem jeden.” (Johann Wolfgang von Goethe)

Selbstorganisation in Scrum: stets gefordert – selten klar!

Kürzlich bin ich auf eine interessante Unterscheidung zwischen extern gemanagten, self-managing und self-leading Teams gestoßen, und habe sie in der folgenden Tabelle zusammengefasst:

Team hat Einfluss auf das … der Arbeit Team ist abhängig von … Anreizen
was wie warum extrinsischen intrinsischen
externes Management + + + +
Self-Management ✔✔ + + + +
Self-Leadership ✔✔ ✔✔ ✔✔ + + + +

Das theoretische Framework für Self-Leadership findet sich in der Kontroll-Theorie (Carver & Scheier, 1982). Die Erweiterung auf das Team Level steht unter den Grundannahmen der Arbeitsdesign-Theorien, Job-Charakteristika-Theorien (Hackman & Oldham, 1976) und der sozio-technischen Systemtheorie (Cummings, 1978).

Manz (1991) unterscheidet Self-Leadership von Self-Management anhand der zu Grunde liegenden Fragen WAS, WARUM und WIE und somit dem möglichen Einfluss der Teams (die letztere Unterscheidung findet man in ähnlicher Weise auch bei Hackman (1986), Lawler (1986), Walton (1985). Dabei beschreibt er Self-Management als “a self-influence process and set of strategies that primarily address how work is performed to help meet standards and objectives that are typically externally set . . . [it] tends to rely on extrinsic motivation and to focus on behavior.” (p. 17)
 
Self-Leadership definiert er als: “a self-influence process and set of strategies that address what is to be done (e.g., standards and objectives) and why (e.g., strategic analysis) as well as how it is to be done . . . [it] incorporates intrinsic motivation and has an increased focus on cognitive processes.” (p. 17)
 

Mir gefällt an dieser Darstellung von Steward/Courtright/Manz, dass sie auf einfache Art und Weise die wohl wesentlichen Aspekte zusammenfasst und darüber hinaus einfach auf die Scrum-Terminologie übertragbar ist. Interessant finde ich außerdem die Einstufung nach dem möglichen und ausgeübten Einfluss der Teams sowie der Abhängigkeit von Anreizen (die es hier im Sinne von Impulse, Motivation, Stimulus, Anreiz zu verstehen gilt).
Nimmt man das klassische Projektmanagement, wird sowohl das WAS, WIE und WARUM vorgegeben. Der Teamgedanke und Vorteil kann sich somit meiner Meinung nach nur bedingt entfalten. Die ausschließliche Abhängigkeit von extrinischen ,Anreizen‘ zeigt außerdem, dass das Team ohne externes Management wohl kaum handlungsfähig ist.
Betrachtet man dann die Entwicklungsteams (nicht Scrum-Teams) in Scrum, kommt man zum Self-Management. Sie können selbst entscheiden, WIE sie das Geforderte umsetzen. Außerdem sind sie nicht ausschließlich von extrinsischen Anreizen (Vision, priorisiertes Backlog, Constraints) abhängig, sondern können innerhalb dieses Rahmens intrinsische ,Anreize‘ entwickeln und verfolgen.
Self-Leadership trifft meiner Meinung nach auf gut eingespielte Scrum-Teams zu, die gemeinsam mit Product Owner und Scrum Master sowohl auf das WAS, das WIE und das WARUM Einfluss haben. Ganz unabhängig von extrinsischen ,Anreizen‘ sind sie jedoch nicht, da das Unternehmen z.B. mit dem Produktportfolio bestimmte und notwendige Vorgaben macht..
Wie bei allen abstrakten Definitionen und Kategorien, gilt es jedoch auch hier wieder darauf zu achten, in welchem Detailgrad die Entscheidungen getroffen werden können. Dieser sollte zu jedem Zeitpunkt dem Reife- und Kompetenzgrad des Teams angemessen sein und die Abnahme von Verantwortung durch externes Management sollte nicht so weit gehen, dass es zu einer Schonhaltung des Teams führt.
Und genau das ist wohl die Schwierigkeit (die auch durch diese Definition nicht aufgelöst wird).
Neugierig auf Lösungsansätze? Ich auch. Teilt eure und/oder lest weiter unsere Blogs.
 
Quellen:

Carver, C. S., & Scheier, M. F. (1982) Control theory: A useful conceptual framework for personality—Social, clinical, and health psychology. Psychological Bulletin, Vol. 92, S. 111-135.


Cummings, T. G. (1978): Self-regulating work groups: A socio-technical synthesis. Academy of Management Review, Vol. 3, S. 625-634.


Hackman, J. R. (1986): The psychology of self-management in organizations. In M. S. Pollack & R. O. Perloff (Eds.), Psychology and work: Productivity change and employment, S. 85-136. Washington, DC: American Psychological Association. 
Hackman, J. R., & Oldham, G. R. (1976): Motivation through the design of work: Test of a theory. Organizational Behavior and Human Decision Processes, Vol. 16, S.  250-279. 
Lawler, E. E. (1986): High involvement management. San Francisco, CA: Jossey-Bass.
Manz, C. C., & Sims, H. P., Jr. (1991): SuperLeadership: Beyond the myth of heroic leadership. Organizational Dynamics, Vol. 19, S.  17. 
Stewart, G.L., Courtright S.H. &  Manz, C. C. (2011): Self-Leadership: A Multilevel Review, Journal of Management,Vol. 37, S.  185-195.  
Walton, R. E. (1985): From control to commitment in the workplace. Harvard Business Review, Vol. 63, S.  77-84.  

A hole in my sidewalk – ein Muss für jeden ScrumMaster

Die „Autobiographie in fünf Kapiteln“ von Portia Nelson (im Original: There is a hole in my sidewalk) ist ein Muss für jeden, der als Change Agent, Meeting Facilitator und Servant Leader ScrumTeams führt und entwickelt.
Manchmal braucht es keine Erklärungen, keine Interpretationen, keine Sinndeutungen, weil die Worte für sich selbst stehen und eure eigenen Gedanken Antwort genug sein werden.
Lasst euch inspirieren.
 
Kapitel eins
Ich gehe die Straße entlang.
Im Bürgersteig ist ein tiefes Loch.
Ich falle hinein. Ich bin ratlos und hilflos.
Ich fühle mich nicht schuldig. Es dauert
endlos lang, wieder herauszufinden.
 
Kapitel zwei
Ich gehe dieselbe Straße entlang.
Im Bürgersteig ist ein tiefes Loch.
Ich tue so, als ob ich es nicht sähe.
Ich falle wieder hinein. Ich kann nicht
glauben, dass ich mich wieder in dieser
Situation befinde. Aber ich fühle mich
nicht schuldig. Es dauert immer noch
lange, herauszukommen.
 
Kapitel drei
Ich gehe dieselbe Straße entlang.
Im Bürgersteig ist ein tiefes Loch.
Ich sehe, dass es da ist.
Ich falle hinein – es ist schon eine
Gewohnheit – aber ich habe meine
Augen dabei weit geöffnet. Ich weiß, wo
ich mich befinde. Es ist meine Schuld.
Ich klettere sofort heraus.
 
Kapitel vier
Ich gehe dieselbe Straße entlang.
Im Bürgersteig ist ein tiefes Loch.
Ich gehe daran vorbei.
 
Kapitel fünf
Ich gehe eine andere Straße entlang.
 
Aus: Radatz, 2000, S. 29
 
Literatur:
S. Radatz (2000). Beratung ohne Ratschlag. Systemisches Coaching für Führungskräfte und BeraterInnen. Verlag Systemisches Management

Glauben, erklären, überzeugen? Erleben!

Als Agile Coaches und Berater werden wir ab und zu als „Evangelisten“, manchmal sogar als „Taliban“ bezeichnet.
Ja, wir glauben!

In einem früheren Blog hatte ich schon ein paar gute Argumente gelistet (In Scrum we trust!) und es gibt  auch gute Tipps, wie man am besten ein Evangelist wird (How to be a successuflu agile development evangelist).

Nun, andere Leute auf dem Weg zur Veränderung zu begleiten, bleibt weiterhin eine schwere Aufgabe!!

Mike Cohn („Succeeding with agile“) fasst die fünf Schritte zur erfolgreichen Einführung agiler Vorgehensweisen mit dem Akronym ADAPT zusammen:

Awareness – das Bewusstsein, dass der derzeit verwendete Prozess nicht die gewünschten Ergebnisse  bringt
Desire – das Verlangen, die bestehenden Probleme mit Hilfe agiler Methoden zu adressieren
Ability – die Befähigung, eine agile Methode erfolgreich einzusetzen
Promotion – das (interne) Marketing für die agile Vorgehensweise in Form von Erfahrungsberichten
Transfer – die Ausweitung der agilen Methoden auf andere Unternehmensbereiche (aus Sicht einer IT-Projektabteilung)
Eine (positive) Erfahrung zählt mehr als alle schönen Worte. Der Hirnforscher Gerald Hüther erklärt in der österreichischen Tageszeitung “Der Standard”, warum man durch günstigere Erfahrungen seine Haltung verändert.
Der Frontallappen ist der Bereich im Gehirn, in dem unsere sogenannten Metakompetenzen, unsere Überzeugungen, Glaubenssätze, inneren Einstellungen und schlussendlich die daraus hervorgehenden Haltungen verortet sind. Sie bestimmen, was ein Mensch denkt, wie er Dinge bewertet, wie er handelt. Der springende Punkt dabei ist: Wir können die dort entstandenen Haltungen nicht einfach ändern. […] Erfahrungen gehen buchstäblich unter die Haut – mit anderen Worten, der Mensch fühlt. Das emotionale Netzwerk im Hirn verknüpft sich mit dem kognitiven Netzwerk zu einer festen Struktur. Diese lässt sich nicht durch noch so viele Anfeuerungen und Ermunterungen in all den flammenden Ansprachen bei Betriebsfesten oder durch sonstige Belehrungen und Ermahnungen verändern. Das gelingt wie gesagt nur durch neue Erfahrungen, mit denen dann die alten, eingefahrenen Netze im Gehirn überschrieben werden. Mit den besseren können also dann die weniger guten Erfahrungen gelöscht werden. Am besten gelingt das, wenn der Mensch begeisternde Erfahrungen macht. Die reißen ihn dann in des Wortes wahrstem Sinne mit und aus alten Haltungen heraus.