Führung als Team: Frommer Wunsch oder realistische Perspektive?

Viele Unternehmen, gerade auch High Performance Unternehmen, sind heute vernetzt strukturiert. Sie  haben schlankere Hierarchien und arbeiten verstärkt mit unterschiedlichen Formen der Projekt- und Teamarbeit. Die Hierarchien gewinnen eine neue und andersartige, oft geringere Bedeutung. Die klassische Führung mit ihrer starken Betonung des heldenhaften Einzelkämpfers an der Spitze mit seiner  “Alle mir nach”-Attitüde hat sich abgenutzt und ist auch als Modell wenig sinnvoll für selbstorganisierte Teams. Oft wird dieser Widerspruch thematisiert im Sinne von “Wir da unten sollen als Team zusammenarbeiten, aber die da oben sind lauter Einzelkämpfer” (und oft in deutlich wahrnehmbarer Konkurrenz zu einander). Gerade für die Führung agiler Unternehmen (aber nicht nur für diese) ist die Installation von Führungsteams eine effektive Alternative. Führungsteams sind kollektive Steuerungs- und Entscheidungsfunktionen in Unternehmen. Sie verteilen Macht, Kompetenz und Verantwortung auf mehrere Schultern. Trotzdem wird dem Führungsteam im Management aus einer tradierten Vorstellung von Führung heraus immer noch mit einer gewissen Skepsis begegnet und/oder man belässt es bei schnell durchschaubaren Lippenbekenntnissen. Dabei bietet diese Führungskonstellation durchaus höchst überlegenswerte Möglichkeiten.
Führungsteams können

Führungsteams bewegen sich in der Regel weit mehr als Mitarbeiterteams in einem Spannungsfeld zwischen Individualität und Kooperation, zwischen persönlicher und geteilter Verantwortung. Daraus ergeben sich Problemfelder, die es zu beachten gilt:

Grundsätzlich gilt, dass Teams, welcher Art auch immer, nicht per se bessere Leistungen bringen als einzelne Spezialisten. Vielmehr braucht Teamarbeit spezifische Bedingungen, um den allseits gewünschten Synergieeffekt im Sinne von Effektivität und Effizienz leisten zu können:

Führungsteams sind zweifellos  eine wirkungsvolle, aktuelle Alternative zu klassischen Formen der Führung für Unternehmen. Aus meiner Erfahrung als Moderator und Entwickler diverser Führungsteams konnte ich erkennen, dass dort, wo Führungsteams optimal kooperieren und ihre Führungsaufgabe gemeinsam bewältigen, auch die gemeinsame Erfolgswahrnehmung hoch ist. Vor allem aber ist persönliche Zufriedenheit, Gelassenheit und Motivation bei den Führungskräften in der Regel ausgeprägter vorhanden und wahrnehmbar. Auch die Rückmeldungen von kollektiv geführten Mitarbeitern deuten auf eine verbesserte sachliche Arbeitssituation und ein angenehmeres Miteinander hin, diese positive Wirkung nach unten ist sehr hoch einzuschätzen.
In der Regel geht die Initiative zukünftig als Führungsteam zu agieren von der ranghöchsten Position im System aus. Hier kann man CEO, CTO, Bereichs- und Abteilungsleitern nur genug Mut wünschen, sich darauf einzulassen, ein Führungsteam zu kreieren. In einem gut gestalteten Teamentwicklungsprozess kann in den meisten Fällen dann auch die evtl. noch vorhandene Skepsis des einen oder anderen Führungsteammitgliedes gezielt bearbeitet und abgebaut werden.

Agile Take-off

Sehr geehrte Damen und Herren! Wir begrüßen Sie auf dem Flug von Graz nach Düsseldorf. Bitte schnallen Sie sich an, stellen Sie Ihre Sitzlehne aufrecht und klappen Sie Ihre…
Da saß ich nun im Flugzeug und hörte mit einem Ohr die Durchsage der Flugbeleiterin. Neben mir ein Herr, Mitte 60, graumelierte Haare, perfekt sitzender Anzug. Seine Augen auf mein Buch gerichtet. Auf das kleine Agile-Buch von Sander Hoogendoorn. Da wurde es mir ein wenig bunt und ich erwiderte seinen Blick. Plötzlich sagte mein Sitznachbar zu mir: „Entschuldigen Sie, aber ich „missbrauche“ Sie, um in Ihrem interessanten Buch zu lesen. Was bedeutet agile oder besser gesagt, wie können Projekte agil werden?“
So starteten wir agil in Richtung Düsseldorf … und in ein Gespräch über Scrum und Wasserfall, über Iterationen und Releases, über Change Management und Komfortzonen. „Alles schön und gut in der Theorie“, meinte er. „Wären da nicht die Menschen mit all ihren Befindlichkeiten.“ Da horchte ich plötzlich auf und es machte „klick“ in meinem Kopf. Natürlich! Recht hat er! So recht!
Denn: was ist Scrum? Ein Steuerungsinstrument? Ein Change-Management-Ansatz? Eine Einstellung? Die innere Haltung? Agil?
Ja, alles.
Wenn das alles auf Scrum zutrifft, was tut diese geballte Ladung an Veränderung dann mit uns?
Können wir davon ausgehen, dass unsere Teams, ScrumMaster, Product Owner, Manager oder sonstige Stakeholder einfach schwupsdiwups anfangen agil zu denken, Veränderungen ohne Hindernisse  akzeptieren und zur agilen Tagesordnung übergehen?
Nein! Meine ich.
Seit geraumer Zeit wird zu Projektbeginn das bestmögliche Team von Entwicklern, Fachexperten und Testern zusammengestellt. Nach Abschluss des Projektes werden die Teammitglieder wieder getrennt und in neuen Projekten (oft mit neuen Teammitgliedern) eingesetzt. Das Prinzip geht von den besten verfügbaren Einzelpersonen aus, aber nicht von den besten verfügbaren Teams. In vielen Projekten dauert es leider sehr lange, bis diese Einzelpersonen zu einem effizienten und produktiven Team werden. Da muss ich Sander Hoogendoorn Recht geben. Aber warum ist das so?
Weil es in Projekten eben menschelt. Erst recht, wenn wir von Wasserfall auf agil wechseln. Weil Veränderungsprozesse Menschen in Ausnahmezustand versetzen. Weil die Veränderung einer Einstellung oder die Weiterentwicklung der inneren Haltung Zeit brauchen. Zeit, um Ängste zu überwinden und Zeit, um den Nutzen zu erkennen. Vor allem den Nutzen für sich selbst.
Sozialpsychologisch betrachtet sind Menschen „bilanzierende Wesen, die Veränderung als kognitive und emotionale Unsicherheiten erleben. Emotionen wirken dabei wie Vergrößerungsgläser. Change Prozesse sind hochemotional und verursachen somit emotionale Spannungszustände. Und was machen die emotionalen Spannungszustände mit uns? Sie hindern uns daran, den gesunden Menschenverstand einzuschalten, effizient zu arbeiten, gewaltfrei und lösungsorientiert zu kommunizieren, Konflikte zu vermeiden oder schicke Codes zu schreiben.
Wenn wir also davon ausgehen, dass Change Prozesse emotionale Spannungszustände in uns verursachen, können wir dann gleich zu Beginn des Projektes von erfolgreichen Sprints ausgehen bzw. dürfen wir uns dann wundern, wenn diese eben nicht erfolgreich werden? Was wäre dann die logische Konsequenz daraus? Denken wir mal bewusst darüber nach…
So diskutierte ich mit meinem interessanten Sitznachbarn, als wir die Durchsage unserer Flugbegleiterin mit einem Ohr wahrnahmen: “Wir befinden uns im Landeanflug auf Düsseldorf. Legen Sie bitte Ihre Sicherheitsgurte an, stellen Sie Ihre Sitzlehnen aufrecht und schalten Sie Ihre elektronischen Geräte aus.”
Und mein agiles Landing war perfekt!

Unsere Ängste, unsere Kräfte

Jeder von uns kennt die lähmende Kraft von Angstgefühlen. Angst zu haben bedeutet, der Situation nicht gewachsen zu sein. Unser aufrechter Gang, unser Stolz, unsere ganze persönliche Souveränität verblassen im Angesicht der Angst. Und trotzdem – oder gerade deshalb – ist Angst eine unserer wichtigsten Antriebskräfte. Ängste fordern uns dazu auf, sie zu überwinden. Und manchmal werden wir uns der Angst erst bewusst, nachdem wir sie eigentlich schon überwunden hatten: Das Kind, das die Hand seiner Eltern beim Laufen festhält, steht plötzlich selbständig im Raum. Erst wenn es merkt, dass keine erwachsenen Hände es mehr halten, taumelt es und fordert die stützende Hand zurück. Der Passagier mit Höhenangst lässt den Blick nichtsahnend aus dem Fenster schweifen – und merkt dann zu seinem Entsetzen, dass die Häuser 10 Kilometer unter seinen Füßen vorbeirauschen.
In seinem mittlerweile fünfzig Jahre alten Buch postuliert Fritz Riemann vier so genannte Grundformen der Angst:

  1. Die Angst vor der Hingabe
  2. Die Angst vor der Selbstwerdung
  3. Die Angst vor der Veränderung
  4. Die Angst vor der Notwendigkeit

Mit einer Fülle an Beispielen aus seiner therapeutischen Erfahrung beschreibt Riemann Verhaltensmuster, die er jeweils mit diesen vier Ängsten in Verbindung bringt. Als Leser ist man schnell versucht, die eigene Persönlichkeit und die der Mitmenschen auf zutreffende Verhaltensmuster zu prüfen.
Spannende Erkenntnis: In ihrer Extremform verkrüppeln uns die Grundformen der Angst und machen uns zu Menschen, die keine Beziehung zu ihrer Umwelt aufbauen können. Zugleich aber liegen jeder dieser Ängste Sehnsüchte zu Grunde (Riemann nennt sie nüchtern “Forderungen”), die unser Menschsein ausmachen. Diese Sehnsüchte korrespondieren also mit den Ängsten, stehen zum Teil in Spannung zueinander, und sind bei jedem Menschen unterschiedlich stark ausgesprägt:

  1. Dass wir ein einmaliges Individuum werden sollen.
  2. Dass wir uns der Welt, dem Leben und den Mitmenschen vertrauend öffnen.
  3. Dass wir die Dauer anstreben sollen.
  4. Dass wir immer bereit sein sollen, uns zu wandeln.

Wer also Angst vor (4) dem ewig Gleichen, vor Routine, vor Sesshaftigkeit und Wiederholung hat, der hat zugleich auch die Kraft, neue Dinge anzupacken und Altes komplett über den Haufen zu werfen. Jemand, bei dem die Angst vor (3) der Veränderung heraussticht, kann nicht nur ein tiefes und gründliches Verständnis von Sachverhalten entwickeln, sondern bringt auch hohe Zuverlässigkeit und Ausdauer mit sich. Der Mensch, der (1) Hingabe fürchtet, kann souverän und unabhängig auftreten, Herausforderungen mutig angehen und Dinge sachlich-kühl betrachten. Dagegen ist derjenige, den die Angst vor (2) der Selbstwerdung umtreibt, in der Lage, sich durch seine Hingabe in andere Menschen hineinzuversetzen und eine empathische Nähe aufzubauen, die ein starkes, inniges Vertrauensverhältnis ermöglicht.
Bei aller Gefahr, Menschen durch solche Kategorien in Schubladen zu stecken, können die Riemannschen Grundängste als Orientierung durchaus hilfreich sein. Helfen sie uns doch, Menschen in ihrer Vielfalt zu begreifen und zu verstehen, dass erst diese Vielfalt unser Miteinander sinnvoll macht. Da wo ich dreimal zögere, kann meine Kollegin einfach entscheiden. Und bevor sie anderen nochmal auf die Füße tritt, kann ich sie zu einem Perspektivenwechsel ermuntern.
Ich denke, dass diese Verhaltensmuster sich – freilich mit Abstrichen – auch auf Unternehmen anwenden lassen. So wird ein Start-Up vermutlich eine andere Einstellung zu Dauer und Veränderung haben als ein Konzern mit einem hohen Grad an formalisierten Normen. Und ein Unternehmen, das jahrzehntelang einsam auf dem Markt herrschen konnte, wird anders mit der Umwelt interagieren als ein solches, das seit eh und je zur Kooperation mit der Konkurrenz gezwungen war.
Eine spannende Übung zum Schluss: Schau dir deinen engeren Kollegenkreis (z.B. dein Scrum-Team) an und finde heraus, wie stark die vier Sehnsüchte darin ausgeprägt sind. Gibt es vielleicht ein übergreifendes Muster, das die ganze Gruppe beherrscht? Das ist in alteingesessenen Teams mit einer starken Führungsperson häufig der Fall. Vielleicht ist deine Gruppe aber auch reich an Vielfalt, spannend und angespannt zugleich?
Überlege dir dann, wann dir deine Gruppe zum letzten Mal Schwierigkeiten bereitet hat. Was ist dort passiert, wer hat wie gehandelt? Beschränke dich auf die beobachtbaren Tatsachen und darauf, wie du dich dabei gefühlt hast. Mache weiter, indem du eine Situation in Erinnerung rufst, in der du deiner Gruppe Schwierigkeiten bereitet hast. Beschränke dich wieder auf die beobachtbaren Tatsachen und darauf, wie du dich dabei gefühlt hast.
Schau dir dann die vier Sehnsüchte nochmal an und versuche, deine Gruppe als empfindliches Gleichgewichtsorgan zu sehen, bei dem jede Veränderung, jeder Anstoß das System ins Wanken bringen kann. Hast du jetzt ein besseres Gefühl dafür, wie deine Gruppe mitsamt ihrer einzelnen Mitglieder tickt – und was sie auszeichnet? Im Anschluss daran kannst du eine nach innen gerichtete Retrospektive mit deiner Gruppe durchführen. Hierzu eignet sich zum Beispiel die Naikan-Übung, von unserem Coach Dieter Rösner hier beschrieben (http://borisgloger.com/2012/09/23/ich-du-wir-von-austausch-feedback-und-weiterentwicklung-in-teams/).
Literatur
Riemann, Fritz (2011): Grundformen der Angst. Ernst Reinhardt Verlag. München und Basel. Vierzigste Auflage.

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

ScrumMaster, Product Owner, Scrum ChangeManager – neue Rollen brauchen Profil und Kompetenz

Eines der faszinierendsten Elemente von Scrum als Modell ist die Tatsache, dass hier neue, innovative Rollen im beruflichen Kontext kreiert werden und klassischen Rollen prägnantere Funktionen (z.B. dem Manager) zugeordnet sind. Die Funktionen von ScrumMaster und Product Owner sind in der Projektwelt ohne Beispiel. Daher ist das  Verständnis über ihre Aufgaben und Instrumente mitunter noch diffus und schwer einzuordnen. Was genau sind ihre Wirkungsfelder, was sind die dazugehörigen Kompetenzen, welche Methoden und Techniken stehen zur Verfügung, was sind die Einflussbereiche, was genau ihre Aufgaben und Funktionen, etc.? Und wie grenzen sie sich zu anderen Rollen wie Team- oder Projektleiter ab?

Rollen müssen sich legitimieren

In sozialen Systemen sind Rollen zentrale Elemente, denen spezifische Aufgaben und Verantwortungsbereiche zugeordnet sind. Mit ihrem Handeln sollen sie zum Erfolg des Systems beitragen, sie haben eine definierte Legitimation, eine von außen vorgegebene Struktur und sind mit spezifischen Erwartungen an den Rollenträger in punkto Verhalten, Einstellungen, Werte, Know-how usw. verbunden. Es gibt aber immer auch einen eigenen Gestaltungsraum, in dem der Rollenträger seine Aufgaben individuell interpretieren und ausüben kann. in der Arbeitswelt gibt es relativ einfache, unkomplizierte Rollen, aber immer mehr solche, die hoch komplex und herausfordernd sind. Zu den letzteren gehören ganz sicher Rollen wie jene des ScrumMasters und des Product Owners. Neue Rollen brauchen in der Regel Zeit, um sich etablieren zu können und akzeptiert zu werden. Ihr Sinn und Nutzen für das System zeigt sich erst im Laufe der Zeit. Der Rollenträger hat darauf großen Einfluss: Schließlich trägt er mit seinem kompetenten Handeln dazu bei, wie seine Rolle im beruflichen Umfeld wahrgenommen und eingeordnet wird. Dafür braucht man bestimmte Fähigkeiten und Fertigkeiten, aber auch ein entsprechendes Handwerkszeug. Genauso muss die neue Rolle in ihrem Umfeld, besonders an den Schnittstellen, auf Offenheit und Verständnis stoßen, damit der Nutzen tatsächlich wahrgenommen werden kann. Was dabei auf jeden Fall notwendig ist, ist die eindeutige Legitimation durch das Management.
In der Scrum Praxis machen viele die Erfahrung, dass eine Grundausbildung zum ScrumMaster oder Product Owner für die ganze Komplexität dieser Aufgaben nicht ausreicht. Im Alltag wird schnell deutlich, wie zentral der sorgsame Umgang mit Menschen ist. Es müssen vielfältige Kommunikationsprozesse gesteuert werden, in der Veränderungsdynamik muss die laterale Führungskraft die Ruhe bewahren, manchmal auf Konfrontationskurs mit dem Management gehen usw. usw. Kurzgesagt lautet das, was diese Rollen so besonders macht: Change, Change und nochmal Change!

Neue Rollen sind Stützen der Veränderung

Wer an Change denkt, denkt meist zuerst an das Neugestalten von Strukturen und Prozessen im Unternehmen. Als prozesshafte Struktur tut das Scrum natürlich. Ein ScrumMaster denkt aber weit darüber hinaus: Er denkt an die betroffenen Menschen und an die tradierte Unternehmenskultur. Ihm ist bewusst, dass er die Menschen einbinden muss, wenn die Kultur des Systems neu gestaltet werden soll, denn die Menschen sind die Kultur. Sowohl ScrumMaster als auch Product Owner (ggf. auch Team- oder Projektleiter) werden zu wertvollen Stützen eines agilen Unternehmens, wenn sie in ihrem Change-Repertoire sattelfest sind und es zum richtigen Zeitpunkt einsetzen. Damit helfen sie auch dem Management, Veränderungsprozesse über Scrum hinaus anzustoßen. Natürlich gibt es Schattenseiten, wenn diese Rollen schlecht ausgefüllt werden: Frustration, Demotivation, Resignation bei den betroffenen Mitarbeitern. So werden nicht selten die wertvollsten Mitarbeiter „verbrannt“.

Der Scrum ChangeManager als multifunktionale Rolle


 

Was sind die Lernfelder für diese multifunktionalen Rollen? Laterales Führungswissen, die Kompetenz der professionellen Kommunikation, Umgang mit Konflikten, Moderation und Workshopgestaltung, die Kunst des Coachings, systemisches Know-how zum Change Management und zur Teamentwicklung haben zentrale Bedeutung. Ebenso muss die eigene Persönlichkeit durch gezieltes Selbstmanagement weiterentwickelt werden. Für einen solchen „Knochenjob“, bei dem manchmal der Widerstand um die Ohren pfeift,  braucht man Selbstsicherheit und Standing, Klarheit über die eigenen Ziele und Ressourcen, Mut zu Innovation und Kreativität und den bewussten Umgang mit Herausforderungen und Stress. Gerade neue, noch nicht umfassend etablierte Rollen brauchen Zeit um zu lernen, Erfahrungen zu sammeln und Feedback zu bekommen, um sich ihren Status zu erarbeiten.

Zukünftige Rollenträger, Management und Personalentwicklung tun also gut daran, sich schon zu Beginn einer Scrum-Implementierung um die Ausstattung mit den nötigen Fertigkeiten zu kümmern. Der zertifizierte Scrum ChangeManger als Vertiefungs- und Erweiterungskonzept ist ein sinnvoller Weg dazu. Er bleibt nicht beim Verändern vom Vorgehensweisen stehen, sondern sieht das Ganze, die Menschen in einer neuen Situation. Und daher verändert und entwickelt er zu allererst: sich selbst.


Tipp

Wie fülle ich meine Rolle erfolgreich aus? Mit unseren Scrum Supplements stärken Sie Ihr souveränes Auftreten als Change Agent: Konflikte regeln, Impediments lösen, Teams entwickeln, Workshops gestalten, Gespräche zielorientiert führen – all das mit der richtigen Dosis Selbstbewusstsein.

Wenn ich einmal groß bin …

Was macht ein Teamleiter in Scrum? Was wird aus einem Projektleiter? Wie verhalten sich diese Rollen zu den Rollen in Scrum? Früher oder später tauchen in jeder größer angelegten Scrum-Implementierung diese Fragen auf. In den meisten Fällen wird die Rollenduplizität eine ganze Weile erhalten: Der Teamleiter ist dann beispielsweise Product Owner. Und der Projektleiter macht (mehr oder weniger nebenbei) den ScrumMaster. Und umgekehrt. Oder es gibt eine Rollenparallelität: ScrumMaster und Product Owner führen und entwickeln nach Scrum, während Projektleiter und Teamleiter klassisches Projektmanagement machen (oftmals sogar für das gleiche Projekt). Dass das auf Dauer nicht optimal ist, sollte keine Überraschung sein. Umso dringender stellt sich die Frage nach einer besseren Rollenverteilung.

Scrum ist keine Rollenevolution

Die Antwort dazu muss zwangsläufig ernüchternd ausfallen. Scrum wurde nicht erfunden, um das klassischen Projektmanagement weiter zu entwickeln. Scrum versucht daher erst gar nicht, eine Kontinuität oder eine Evolution herzustellen. Von Anfang an ist Scrum als Alternative angetreten, die nicht ein UND oder ein ZUDEM, sondern ein ODER im Angebot hat. Folglich gibt es in Scrum keine natürlichen Zuordnungsmöglichkeiten: Wer behauptet, dass ein Projektleiter “am ehesten” Product Owner wird, der unterschätzt die Radikalität der Scrum-Rollen.
Manche pendeln dann direkt ins andere Extrem und behaupten, für die klassischen Rollen gäbe es in Scrum gar keine Verwendung mehr. Wer so denkt, der ist noch nicht in der Wirklichkeit angekommen: In jedem Projekt geht es doch darum, Scrum unter den jeweils aktuellen Bedingungen zu implementieren. Und diese Bedingungen sind nur im Lehrbuch die einer grünen Wiese.

EIn Beispiel

Ich habe vor kurzem mit einem Projektleiter zusammengearbeitet, der Scrum für sein Projekt einführte. Nach einigen Sprints übernahm er die Rolle des ScrumMasters. Der Product Owner kam wiederum aus dem Fachbereich. Beide Scrum-Rollen haben nie ganz richtig gesessen: Der Product Owner hatte zu wenig Produktkenntnis und konnte daher mit dem Team nicht auf der Ebene eines zweiwöchigen Sprints planen. Er hat sich mit der Zeit in die Rolle des Kunden zurückgezogen – und fühlt sich nun dort besser aufgehoben. Der ScrumMaster war anfangs sehr ungeduldig und versuchte in seiner Projektleiterrolle zunächst, das Team mit Vorschriften und Arbeitszuweisungen zu führen.
Wir haben solche Momente kritisch reflektiert. Über die Sprints gelang es dem ScrumMaster, in die Rolle des Teamsponsors zu wechseln, der nicht nur das Team beschützt (das tat er schon immer), sondern auch Freiräume ermöglicht und Entscheidungen respektiert. Als klar wurde, dass der Product Owner seine Rolle nicht ausüben konnte, spielte der ScrumMaster mit dem Gedanken, dorthin zu wechseln. Wir empfahlen ihm, ScrumMaster zu bleiben. Er hatte genügend Produktkenntnisse und wäre vermutlich ein guter Product Owner geworden. Aber sein Interesse um das Wohl und Gedeihen des Teams war bei ihm so stark ausgeprägt, dass er letztendlich selber entschied, ScrumMaster zu bleiben.

Wichtig: Perspektiven

Das oben genannte Fallbeispiel soll eines zeigen: Ob jemand für eine Scrum-Rolle geeignet ist, hängt einerseits davon ab, wie klassische Rollen gelebt werden. Ein Fachbereich mit wenig Produktkenntnis wird es schwer haben, in die Rolle des Product Owners zu kommen (was nicht heißen muss, dass man ihn nicht dorthin entwickeln kann). Und ein Projektleiter mit viel besserer Produktkenntnis ist nicht unbedingt der bessere Product Owner – entscheidend sind dann nämlich auch die Persönlichkeit und die sonstigen Fähigkeiten der einzelnen Person.
Zu Beginn spricht auch in der Tat nichts dagegen, Rollenfragen – wie hier beschrieben – pragmatisch zu lösen.  Entscheidet sich das Unternehmen jedoch, Scrum auszurollen, dann brauchen wir bessere Antworten auf die Rollenfrage. Denn die Mitarbeiter werden sich in jedem Fall die Frage stellen, wie es mit ihnen weitergeht und manche werden sich in Scrum nicht wiederfinden. Aber auch ein ScrumMaster braucht eine Perspektive: Was bedeutet meine Rolle im Unternehmen, welche Entwicklungs- und Aufstiegsmöglichkeiten habe ich? Auch formelle Strukturen wie Rollenbeschreibungen, Einstufungen und Karrierepfade sind wichtig für die Mitarbeiter, bevor sie sich langfristig für eine solche Rolle entscheiden.
Sind die Perspektiven erstmal da, kann man mit den Mitarbeitern gemeinsam herausfinden, wo sie sich am ehesten sehen und ihnen auch klar machen, wo die Organisation sie am ehesten sieht. Scrum hat enormes Begeisterungspotenzial, weil es für viele Unternehmen einen frischen, unverkrampften und oftmals subversiven Neuanfang bedeutet. Gerade in größeren Unternehmen kann Karriere jedoch nur über formale Pfade gemacht werden. Damit die Begeisterung für Scrum anhält und auch über die Pioniere hinaus wirken kann, braucht es die Anerkennung und Ausgestaltung der Scrum-Rollen im Unternehmen.
Danke an Kristina Klessmann, die mich beim Verfassen dieses Artikels unterstützt hat!

Quadratisch. Praktisch. Gut. Über den Schnitt eines Scrum-Teams

Bei der Gründung neuer Scrum-Teams stellt sich (neben der Frage nach der Zusammensetzung) die Frage nach dem besten Schnitt. Vergleichbar ist das mit einer Maus in der Küche: Soll sie erst den Käse gründlich durchlöchern oder von Anfang an Brot, Marmelade und alles weitere verkosten?
 
Bei kleinen, überschaubaren Produkten fällt die Antwort leicht: Das Team ist dann meist für die gesamte Applikation verantwortlich und kann, zusammen mit wenigen weiteren Teams, das gesamte Funktionsspektrum von der Pike auf entwickeln und modifizieren.
Bei komplexeren Produktlandschaften mit großen, über die Jahre gewachsenen Systemen, einer Pluralität an Technologien und einer Vielzahl daran arbeitender Entwickler, gibt es vor allem zwei Möglichkeiten:
 

  1. Entweder arbeiten die Teams an Komponenten oder
  2. sie arbeiten an Features.

 
Die Aufteilung nach Komponenten bietet klare Vorteile: Die Teams können mit den jeweiligen Spezialisten für diese Komponenten bestückt werden. Und die Abhängigkeiten sind im täglichen Geschäft geringer, zumal jedes Team ungestört an „seiner“ Komponente werkeln kann. Beides – die Spezialisierung und die Isolierung – sind zugleich aber auch die Nachteile von Komponententeams. Denn wenn jedes Team nur noch für seine Komponente zuständig ist, fällt der Blick über den Tellerrand ungleich schwerer.
Und der Koordinationsaufwand wird dadurch nicht geringer, sondern letzlich größer. Keines der Teams liefert nutzbare Produkt-Inkremente. Erst das Zusammenspiel bringt den Nutzen. Spätestens dann, wenn getestet wird, ob alle Komponenten so miteinander funktionieren, wie sie aus Sicht des Systems funktionieren sollten, wird der übergreifende Blick für das Ganze nötig. Das ist dann oftmals zu spät, um Fehlentwicklungen zu korrigieren.
 
Feature-Teams sind dagegen gezwungen, von Anfang an das große Ganze zu denken. Sie begleiten die Abläufe von Anfang bis Ende (end to end) und erzeugen damit in jedem Sprint den „Durchstich“, der das Gesamtverhalten des Produktes erkennen lässt – und somit auch frühzeitiges Feedback ermöglicht.
Feature-Teams können als Zumutung empfunden werden: Entwickler, die sich jahrelang auf die technischen und fachlichen Raffinessen eine Komponente spezialisiert haben, müssen plötzlich ganz von vorne anfangen. Und wenn zwei oder mehr Feature-Teams an den gleichen Komponenten arbeiten, kann leicht etwas kaputt gehen – ohne dass sofort klar ist, wer es gewesen ist.
Diese Hürden lassen sich nur mit „interdiszplinären“ Teams überwinden, in denen das Wissen für den gesamten Prozess vorhanden ist und jeder bereit ist, Neues zu erlernen und Altes abzugeben. Ebenso wichtig ist ein hoher Qualitätsanspruch – also eine ehrgeizige Definition of Done. Feature Teams werden auf Dauer nicht mit modularen Tests auskommen. Automatisierte Integrationstests, End-to-End-Tests und teamübergreifender Austausch (Stichwort: Scrum of Scrums) sind unerlässlich, um möglichst noch im laufenden Sprint Feedback bei Unstimmigkeiten zu erhalten und zum Ende des Sprints einen grünen Build hinzubekommen.
 
Das alles kann, je nach Komplexität und Alter des Produktes, einen großen Aufwand bedeuten. Wer aber agil entwickeln möchte, um am Ende eines jeden Sprints das Produkt (und nicht Teile davon!) inkrementell weiter zu entwicklen, der wird nicht umhin kommen, Feature-Teams zu gründen.
Falls bereits Teams am Laufen sind, lohnt es sich, deren Kommunikationsverhalten zu beobachten. Fragt das eine Team im SoS ständig nach den Experten aus dem Print-Service, weil der Benutzer sich am Ende jedes Sprints freut, wenn die Rechnung nicht nur abrufbar, sondern auch ausdruckbar ist? Dann lohnt es sich vielleicht, das Team um jenen Experten zu ergänzen, und so den funktionalen Scope des Teams evolutionär zu erweitern. Auch hier gilt die alte Devise: Ask the team! Was am Reißbrett  Sinn macht, muss noch lange nicht in der Praxis funktionieren.
 
Literatur
Mike Cohn: Suceeding with Agile. Addison-Wesley 2009.
Dean Leffingwell: Agile Sofware Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley 2010.

Does distance cancel out the efficiency of internationally distributed Teams?

Interview with the bor!sgloger expert panel on the subject of internationally distributed Teams (Part 1)

Over the years, the consultants at bor!sgloger have acquired much expertise on the topic of internationally distributed and dispersed Teams. As it is very difficult to find practical literature on this subject, I have chosen a group of consultants who have each gained first-hand experiences at their clients. The expertise of the panel covers a range of countries all the way from Europe to Far-East Asia, a.o. Rumania, India and Vietnam.
I am proud to present an extensive interview with Deborah Weber, Hélène Valadon, Ina Kurrek*, Kristina Klessmann, Christof Braun* and Dr. Bernd Krehoff – all of whom have worked as either ScrumMaster or Scrum consultant on various cross-cultural projects.
Stephanie G.: I am very happy to have you all gathered here, as it is not very easy to bring together such a large amount of people who have experience in using Scrum with internationally distributed Teams. Without further notice, I would like to get started with the first question. In your opinion, how far do you think Teams can be separated from each other before the distance cancels out efficiency?!
Christof B.: May I start? Thanks. I would like to clarify one thing in advance: it is not exactly about the distance. After all, some theories state that once Team members prefer picking up the telephone to talk to each other rather than get up and walk the distance, it can already be considered a distributed Team. Hence, “distributed” can even be applied to a Team covering two floors in one building – one might sit together for the regular meetings, but one does not really work together anymore. Yet, the Team can still be efficient. Where I do see distance making a difference is when it comes to travelling, as it is much easier to regularly bring together Team members that sit in Germany and Poland than Australia and France.
Deborah W.: Yes, that‘s exactly it – in the second case, the distance is so large, that it becomes troublesome to simply fly over for a sprint change.
Bernd K.: I agree that Team members should see each other at least once a month, which in most cases would be every second sprint change. But this kind of distance actually goes hand in hand with the even bigger issue of the time difference – it simply seems silly when Teams have less than five hours of working time together per day.
Helene V.: You’re right, Bernd. Any kind of time difference increases the complexity of collaborating as a Team. After all, if one location sleeps while the other is at work, it resembles a division of work more than actual collaboration. The larger the time difference, the more difficult it is for Team members to work together for know-how transfer or a simple exchange of information.
Stephanie G.: What you say is very interesting,  as that was exactly my issue. My Team covered five time zones, with the daylight saving time during the German winter not helping either. My Team had to work around the time difference by splitting up the sprint change across three days – Review & Retro, next day Sprint Planning 1, and finally Sprint Planning 2. And the time slots were everything but agile: while the one location had its lunch time cut short (due to strict cafeteria opening hours), the other location had to stay past its usual working hours, and the third location was already starving for lunch by the time the meeting was over. Ina, did you encounter something similar?
Ina K.: Although my Team covered fewer time zones than yours, the time difference truly is an issue. After all, as Héléne has already mentioned – instead of clarifying something right away, asking for help or fixing bugs immediately – the time difference influences Teams in the way that Team members have to either wait for later or the next morning when wishing to speak to the whole Team. This pushes them towards choosing the simpler option of only talking issues through with the local part of the Team. In order to avoid this from happening, I would say that no more than one to three hours of time difference are acceptable. It really stops Teams from being agile.
Christof B.: When working across time zones, Teams have to find dedicated “Team working“ time slots. How can this be helpful in creating a Team spirit? Like in your case, Stephanie, Team members might have to start working strange hours in order to find some kind of overlap. Communication is key and within a Team, I must be able to communicate with my Team members whenever I want to … not whenever I can. Otherwise, it leads to the wrong communication at the wrong time. After all – what is a Team? A Team has a shared goal and works together in order to reach that goal. That said – how can a Team, which is unable to work together, even be called that?! (nodding all around)
Kristina K.: I agree. But let’s not forget that it is not always just the geographical distance, but even more so the mindset of certain Team members that often stops Teams from being efficient.
Helene V.: Yes, I’ve also experienced Teams that sit together in one room, but don’t collaborate.
Kristina K.: Exactly. This is why I truly believe that if you want to make it work (even across a large distance), it will work. However, not all persons are ready to play a part in international Teams. It is necessary to  show even more respect towards each other and accept that you can still learn from your co-workers (even if you have 30 years of product experience). In my opinion, this kind of psychological distance could provide an even higher risk than a geographical distance. Of course, such Team members can be found in any Team – no matter whether dispersed or co-located. Yet, it‘s much easier to develop a psychological distance towards people that you don‘t share an office with five days a week.
Stephanie G.: Thank you very much for your valuable input. I believe I can summarize the answer to my question of how far Teams can be separated from each other before distance cancels out efficiency as

Coming up:
Part 2 – Should internationally distributed Teams be avoided?
 
* former management consultants of bor!sgloger consulting

Brief an einen jungen Projektmanager

Lieber Achim,
 
bevor du mit Scrum anfängst, möchtest Du von mir wissen, was Scrum denn eigentlich ist. Ich könnte jetzt einfach loslegen und schulbuchmäßig von den Rollen, den Meetings und den Artefakten erzählen.
 
Viel lieber möchte ich dir sagen, was Scrum nicht ist: Es ist keine paragraphenlastige Methode für das Management von Projekten. Dazu ist Scrum nämlich viel zu leichtfüßig. Du kannst jederzeit und mit wenig Aufwand ein laufendes Projekt auf Scrum umstellen. Alles, was du dazu brauchst, ist:

  1. Ein fünf- bis neunköpfiges Team, das irgendein Produkt (weiter-)entwickelt.
  2. Jemand, der Verantwortung für die Gestaltung des Produktes übernimmt (das ist der Product Owner).
  3. Eine Person, die sich darum kümmert, dass Scrum gemacht wird (das ist der ScrumMaster).

Außerdem brauchst Du einen Team-Raum, Flipcharts, eine Moderationswand und viele Moderationsmarker (die trocknen nämlich schnell aus). Schon kannst Du loslegen.
 
Du hast immer noch keinen Plan? Das ist normal. Ich stand neulich kurz vor dem ersten Sprint mit einem neu geformten Team, das Hardware und Software für ein neues Produkt im Automobilbereich entwickelt. Alle fragten sich, was das Team denn im ersten, zweiwöchigen Sprint machen sollte.
Der Product Owner hatte die gewünschten Produkteigenschaften aufgeschrieben. Aber diese waren noch viel zu grob, um die Arbeitsgrundlage für zwei Wochen zu stellen. Also fragten wir das Team, was es für die nächsten zwei Wochen vorhabe – und was davon es nach diesen zwei Wochen fertig vorstellen könne.
Im Gespräch zwischen Team und Product Owner wurde schnell deutlich, worauf es ankam: Priorisieren und definieren. Zwei Entwickler arbeiteten an einem Produktfeature, das aus Sicht des Product Owners weniger wichtig war. Also wurde es zurückgestellt. Der Rest des Teams arbeitete gut und zuverlässig vor sich hin, aber eben nur vor sich hin. Die Frage, was denn in zwei Wochen tatsächlich fertig vorstellbar sein könnte, führte zu einer Zielklärung. Vierzehn Tage später hatten wir ein wunderbares allererstes Review, in dem das Team ein Handshake zwischen zwei Geräten sowie ein fertiges Schaltbild für das neue Produkt vorstellte.
 
Scrum ist kein Wunderland. Ja, die ersten Erfolge zeigen sich sehr schnell. Ja, die Arbeitweise ist komplett verschieden und viel, viel besser – weg von Dokumentenstapeln, Abteilungen und Sitzungen, hin zu Kommunikation, Kommunikation und Kommunikation. Gerade das macht die Umstellung im großen Stil dann auch so schwierig. Ein einzelnes Team fällt wenig auf. Es kann noch mehr oder weniger unbefangen vor sich hin scrummen.
 
Spätestens dann, wenn die gesamte Entwicklung auf Scrum umgestellt wird, stellen sich die Fragen nach alter und neuer Welt. Was macht ein Projektleiter, was macht ein Produktmanager in Scrum? Wie sehen Zielvereinbarungen für Team-Mitglieder aus? Und wie schaffen wir es, Teams tatsächlich den Rücken freizuhalten, so dass sie ihre Zeit und Konzentration einem Produkt widmen können? Hier ist das Management in der Verantwortung, die Arbeitswelt neu zu denken (siehe Helenes Blog zum Transition Team).
 
Lieber Achim, ich möchte diesen Brief gerne mit einer Metapher beenden. Spielst du Schach? Dann weißt Du, wie leicht das Spiel zu lernen ist. Selbst ein Kind kann die Regeln schnell verinnerlichen und zuverlässig anwenden. Du hast auch sehr schnell Spaß bei der Sache – der Gegner darf nur nicht allzu gut sein. Mit der Zeit merkst du, dass viel Raum nach oben ist. Dass du mit bestimmten Kombinationen sehr schnell sehr viel besser werden kannst. Hier helfen die Ratschläge, Tipps und Tricks von erfahrenen Freunden, die schon etwas länger im Geschäft sind.
 
Und wenn du dann erstmal soweit bist, dass keiner Dich mehr so leicht schlägt – dann fängt der lange Weg zum Gipfel erst an. Und ja, auch das sollte Spaß machen, weil es um die Kunst der kontinuierlichen Verbesserung geht. Was im Schach der Sieg gegen einen Meister ist – das ist in Scrum ein stolzes Team, das ein richtig geiles Produkt aus der Hand gibt.

Was stört, ist der Kunde

Viele Produkte, für die man sich einen Vorteil durch die Einführung von Scrum erhofft, sind keine Neuentwicklungen, sondern bereits langjährig bestehende Produkte. Mit hohem Wartungsaufwand, langen Releasezyklen und drängelnden Kunden. Und genau diese drängelnden Kunden machen den Product Ownern, Produktmanagern oder Projektleitern zu schaffen. Die Liste der Kundenwünsche ist so lang und individuell, dass ein Abarbeiten, geschweige denn Zufriedenstellen der Kunden im nächsten Jahrzent unmöglich scheint. Außerdem gehen die Wünsche der Kunden oft derart auseinander, dass es sich kaum unter einer konsistenten Vision oder gar Technologie vereinen lässt.
 
Die Auswirkungen sind bekannt. Der Kunde, der am lautesten mit dem Wechsel zur Konkurrenz droht, kommt mit seinen Feature-Wünschen durch. Wenn nicht beim Product Owner selbst, dann über die Eskalation über das Management. Product Owner und Team werden völlig entmachtet. Der Product Owner wird zum Glaskugelleser, in Bezug auf das, was der Kunde mit seinem vage formulierten Wunsch meinen könnte. Das Team muss ein Feature umsetzen oder gar eine Technologie anwenden, die nicht zum Produkt oder der zugehörigen Strategie passt. Verwirrung, Unverständnis und Demotivation sind die Folge. Team und Product Owner arbeiten gegeneinander.
 

Steht der Kunde Scrum im Weg? 

Das oben beschriebene Problem scheint paradox, denn Scrum plädiert doch immer dafür, den Kunden und End User einzubeziehen. Doch Scrum meint nicht in Form von Product Owner oder gar Team-Verantwortlichkeiten (der Kunde gibt vor, was gemacht wird und wie es implementiert sein muss), sondern als Feedback-Geber (wie viel ist man bereit, für ein vom PO vorgeschlagenes Feature zu zahlen und wie gut funktioniert das Implementierte). Um diese Rolle des Kunden und End Users ausüben zu können, müssen sie jedoch erstmal in die Lage versetzt werden, Feedback geben zu können.
 

Aktion statt Reaktion

Product Owner – legt dem Kunden etwas vor, anstatt ihn zu fragen, was er haben möchte. Fangt im nächsten Release mit ein paar Features an. (Keiner spricht davon, den Kunden komplett zu ignorieren!!!) Stellt euch die Frage: Was braucht das Produkt, damit die Kunden der Konkurrenz zu uns wechseln. Nicht: Was müssen wir tun, damit die Bestandskunden bei uns bleiben? Übernehmt so Stück für Stück Ownerschaft für das Produkt. Motiviert das Team dazu, zuerst im nächsten Release on top ein paar coole Features mit einzubauen – Features, von denen ihr und das Team überzeugt seid, dass sie beim End User ankommen. Überzeugt mit Erfolgen, nicht mit Argumenten! Diese Masche zieht sowohl beim Kunden als auch beim Management!
 

Die Kunst, NEIN zu sagen

Ich bin davon überzeugt, dass man NEIN sagen kann, ohne Kunden direkt zu verärgern oder gar zu verlieren. Allerdings nur unter einer Bedingung: Ich muss etwas Besseres im Angebot haben.
Hat man jahrelang nur auf den Kunden gehört und sich nicht zugetraut, etwas Besseres im Angebot zu haben, wird das wohl kaum über Nacht funktionieren. Denn schließlich ist auch der Kunde an das Vorgehen gewöhnt. Jedoch kann man die Zeit, die man dafür aufwendet zu argumentieren, warum Scrum nicht funktionieren wird, dafür aufwenden sich zu überlegen, wie man es zum Funktionieren bringt!