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.

Related posts:

1. Der klassische Projektmanager in Scrum
2. Scrum – Erfolgsfaktor Personalmanagement
3. Die drei weiteren Rollen in Scrum

Auch in der Produktentwicklung werden gerne Ziele gesetzt. Bis Ende des Jahres soll der Gewinn um dreißig Prozent steigen, der Wartungsaufwand halbiert werden und die Anzahl zufriedener Kunden signifikant wachsen. Alles schön und gut.

Aber: Was passiert mit uns, wenn wir uns solche Ziele setzen? Wir bauen Brücken, um sie zu erreichen. Mary und Tom Poppendieck zählen drei Möglichkeiten auf, ein Ziel zu erreichen:

• Die Arbeit umgestalten
• Das System verzerren
• Tricksen

Gibt es eine Abkürzung zur Veränderung?

Ziele können also auch über Abkürzungen erreicht werden. Wir biegen dann die Verhältnisse so lange zurecht, bis sie auf das Ziel passen. Eine wirkliche Veränderung erreichen wir damit nicht – sondern bewirken mitunter etwas ganz anderes. Deshalb dürfen wir Ziele nicht mit Zwecken verwechseln: Mein Ziel ist, 100 Meter in 11 Sekunden zu laufen. Dabei verfolge ich den Zweck, etwas für meine Gesundheit und mein Selbstbewusstsein zu tun. Wenn ich dazu eine Abkürzung nehme und zu leistungssteigernde Drogen greife, mag ich mein Ziel zwar erreichen – den Zweck verfehle ich aber oder handle sogar konträr dazu.

Mary und Tom Poppendieck raten aus solchen Gründen davon ab, Ziele zu setzen. Und sie liefern ein weiteres Argument: Wer anderen Ziele setzt, bringt ein Defizit zum Ausdruck. Du bist noch nicht schnell genug. Das Unternehmen generiert noch zu wenig Gewinn. Das kann zu einer negativen Stimmung führen.

Sollen wir also besser gar keine Ziele setzen? Ich sehe das anders. Ziele haben einen großen Vorteil: Sie sind prinzipiell erreichbar. Das macht uns stark. Denn wir können auf sie hinarbeiten, uns ihnen Schritt für Schritt nähern. Und am Ende stolz sagen: Ich habs geschafft.

Sie zeigen, wo man gerade steht und was noch zu erreichen ist. Sie dürfen nicht utopisch sein, sondern müssen den Möglichkeiten des Systems entsprechen. Ich kann 100 Meter in 11 Sekunden laufen – 10 Sekunden sind für mich außer Reichweite. Unter dem Stichwort SMART verbergen sich fünf Eigenschaften guter Ziele: Spezifisch, messbar, erreichbar, relevant, zeitlich terminiert.

Und: Ziele dürfen nie isoliert formuliert werden. Sie ergeben nur dann Sinn, wenn sie mit einem Wozu, mit dem Zweck verbunden sind. Wer seinen Gewinn steigern möchte, um seine Quartalsziele nicht zu verfehlen, der mag mit Bilanzkosmetik genau das Richtige tun. Wer es aber tut, um die Produktivität zu erhöhen, der wird um Veränderungen in der Organisation nicht umhinkommen. Dabei sind Ziele nur Wegmarken, wie die Leuchtfeuer am Boden vor der Landepiste. Umso wichtiger ist es, ein scharfes Bild vom dem zu haben, was man erreichen möchte. Wir nennen das Vision. Erst eine gute Vision macht Ziele attraktiv, gibt ihnen Anziehungskraft. So kann aus dem mühsamen Abrackern eine spannende Herausforderung werden. John F. Kennedy hat es mit seiner Vision zur Mondlandung geschafft, die ganze Welt bei der Zielerreichung mitfiebern zu lassen.

Wie sieht es in deiner Organisation, in deinem Leben aus? Hast du Ziele, für deren Erreichung du arbeitest? Machen sie Sinn, steckt dahinter ein Zweck? Und welches Bild, welche Vision verbindest du damit?

Mary und Tom Poppendieck: Leading Lean Software Development: Results Are Not the Point. Addison-Wesley.

Related posts:

1. Was hat Fußball mit Zielen zu tun – und das alles mit Scrum?
2. Utopie – Quo Vadis?
3. Eine Erleuchtung: Scrum als Coaching-Tool!

Die Folge dieser Unvorhersehbarkeit des Unbekannten ist, dass wir in eine Position der Ablehnung gehen und jeden Sinn für Neutralität und Offenheit verlieren. Alles, was darauf hindeutet, dass etwas anders werden wird, wird nicht nur einfach in Frage gestellt, sondern zumeist wie eine Bedrohung erlebt. Und damit nicht genug. Wir finden in anderen Menschen oftmals Gleichgesinnte und ziehen uns gegenseitig runter, weil wir im Pessimismus eine Gemeinsamkeit gefunden haben: „Das kann nicht funktionieren!“ Die Argumente, die für eine Veränderung sprechen, reichen einfach nicht aus. Sie sind immer zu schwach, weil wir gemeinsam (relatedness) an dem festhalten, was uns in dieser Unsicherheit gewiss (certainty) zu sein scheint: eine Veränderung kann nur schief gehen und bringt nichts Gutes. Der Fokus geht ausschließlich in Richtung des Problems: Was wird alles nicht funktionieren? Was könnte alles schief laufen? Was würden wir verlieren, wenn wir uns für die Veränderung entscheiden?

In meinen Trainings erlebe ich bei einer simplen Übung eine ähnliche Denkart. Ich schreibe vier einfache Rechenaufgaben auf:

18 + 4 = 22     //     23 – 8 = 15     //     6 x 4 = 20     //     25 : 5 = 5

Was fällt euch auf? Stimmt. Eine (die dritte) Rechnung ist falsch (6 x 4 = 24). Das Gleiche stellen die Trainingsteilnehmer auch fest. Immer. Es war noch nie anders. Kein einziges Mal habe ich erlebt, dass die erste Reaktion lautete: Drei Rechnungen sind richtig, nur eine ist falsch. Stattdessen wird das Haar in der Suppe gesucht und gefunden. Das Schlechte oder in diesem Fall Falsche fällt uns schneller ins Auge, nicht zuletzt, weil ein Misserfolg immer emotional stärker erlebt wird, als ein Erfolg. Daraus entsteht eine Art Schutzhaltung, die ihre Kraft darauf ausrichtet, sich durch eine pessimistische Grundhaltung gegen ein Negativerlebnis zu wappnen: klappt etwas gut, dann bin ich überrascht und erleichtert, klappt etwas nicht, dann fühle ich mich bestätigt, weil ich es ja schon vorher gesagt hatte. Die Folge sind negative Denkmuster, die unsere Denkkanäle einseitig prägen und wie eine Abwärtsspirale wirken. Sogenannte negative Denkmuster gehen von einer Unveränderbarkeit der aktuellen (Problem-)Situation aus und versperren damit jeden Weg auf eine andere, neue, optimistische, lösungsorientierte Perspektive. Die Dominanz von Verallgemeinerungen (z.B. Scrum passt nicht zur Branche X), blockierenden Annahmen (z.B. So kann das doch nichts werden) oder selbsterfüllenden Prophezeihungen (z.B. Ich konnte noch nie gut mit anderen kommunizieren) überdecken auf diese Weise jede Möglichkeit des anders Denken.

Eine der drei integralen Verantwortungen des ScrumMasters ist, dass dieser sein Team schützen soll. Natürlich ist hiermit in erster Linie gemeint, dass keine Anforderungen außerhalb eines Commitments zur Verpflichtung werden, damit das Team störungsfrei arbeiten kann. Ein ScrumMaster schützt aber ebenso gegen die Verbreitung negativer Denkmuster. Als Change Agent gehört es zu seiner Aufgabe, das agile Mindset zu schärfen, indem der Fokus auf die Lösung (weg vom Problem) gerichtet wird. Steve de Shazer, Begründer der lösungsfokussierten Kurzzeittherapie, wirbt für eine solche Form der  Umdeutung (Reframing), indem er sagt: Wenn etwas nicht funktioniert, dann probier etwas anderes.

Worte, die unser Denken verändern können

Ihr fragt euch nun sicher, was ihr jetzt tun könnt? Natürlich ist das Ablegen von Handlungsroutinen nichts, was per Knopfdruck geschieht. Es ist aber möglich. Wenn mir Menschen von Problemsituationen erzählen, dann konzentrieren sich die Schilderungen auf zwei Aspekte: Wie schlimm und aussichtslos die Situation ist und was alles nicht funktioniert bzw. was derjenige alles nicht tut. Würdigt und lobt, was ihr bereits unternommen habt, sorgt ab diesem Moment für einen Kurswechsel und fragt:

Was machst du stattdessen?

Es ist nur ein Wort. Ich kann euch aber empfehlen, euer Gegenüber zu beobachten, wenn ihr eure Frage mit der Lösungsformel „stattdessen“ stellt. Es passiert nichts. Stimmt. Euer Gegenüber schweigt. Und er oder sie schweigt, weil er oder sie nachdenkt. Und das ist ein gutes Zeichen. Ihr habt ins Schwarze getroffen. Ich empfehle euch, nicht locker zu lassen. Immer wieder wird euer Gegenüber versuchen, gedanklich und mit seinen Argumenten dorthin zu „flüchten“, wo er oder sie sich auskennt – ins Problem. Das ist leicht zu erkennen an einem Aber, Negationen oder dem Konjunktiv. Bleibt am Ball und lasst den Problemwälzer auf die Suche nach positiven Ausnahmen (= ein klitzekleines Anzeichen, wann/wo das Problem weniger war) gehen oder konfrontiert ihn mit Fragen, mit denen er nicht rechnet:

• Was an dem Problem möchtest du unbedingt behalten?
• Was war das Beste an deinem Problem?
• Woran merkst du, dass das Problem nicht mehr da ist und was ist dann anders?

Übrigens: Solltet ihr feststellen, dass euer Gegenüber plötzlich mitmacht und Gefallen daran findet, an seinem Lösungsbild zu arbeiten, dann verweise ich gern ein zweites Mal auf de Shazer: „Wenn etwas gut funktioniert, dann mach mehr davon!“

Related posts:

1. Scrum – eine Revolution (4)
2. Definition of Done: Die harte Schule
3. Value Based | Nutzen Schaffen (3)

Wer nur an der lokalen Optimierungen arbeitet und versucht, Scrum-Teams zu hochmotorisierten Produktionsstätten zu machen, wird eines Tages frustriert das Handtuch werfen. Denn ein Team kann nur so gut sein wie die Organisation, in der es funktioniert.

Deshalb setzen wir mittlerweile in jedem Scrum-Implementierungsprojekt ein Transition Team auf. Es besteht meist neben Product Ownern und ScrumMastern aus dem mittleren und höheren Management. Es soll eine Koalition darstellen, die Veränderungen in der Organisation anstoßen und durchsetzen kann. Wir nennen es Transition, um zu zeigen, dass wir noch nicht dort sind, wo wir sein möchten, uns aber auf dem Weg dorthin befinden.

Transition Teams können aus vielen Gründen scheitern. John P. Kotter benennt in seinem Buch Leading Change einige Ursachen, die sich auch mit unserer Erfahrung decken.

Schwaches Problembewusstsein

Ein Transition Team ist immer eine Zumutung, denn es erfordert von seinen Mitgliedern eine Menge Zeit. In meinem Transition Team gehen pro Person mindestens sieben Stunde pro Woche drauf – häufig deutlich mehr. Der Terminkalender meiner Teammitglieder ist natürlich immer überfüllt. Zusammenarbeit wäre nicht möglich, wenn nicht allen klar wäre, dass die Arbeit im Transition Team Priorität über andere Termine hat. Dazu muss allen Teammitgliedern klar sein, dass Veränderungen dringend und wichtig sind, und dass das Transition Team das Mittel der Wahl zum Erreichen dieser Veränderungen ist.

Tipp: Stellt Eurem Transition Team folgende Frage: Woran werden wir scheitern? Wer in den Abgrund blicken kann, der entwickelt ungeheure Energien.

Falsche Besetzung

Ein Transition Team muss Mitglieder mit genügend Entscheidungskompetenzen haben, um die Veränderungen auch durchsetzen zu können. Es gibt nichts Frustrierenderes als ein hoch engagiertes Transition Team, das stundenlang die schönsten Konzepte und Szenarien ausarbeitet, um dann an irgendeinem Entscheidungsgremium zu scheitern. Manche Transition Teams sind so groß, dass keine gute Diskussion mehr möglich ist. Anderen fehlt es schlichtweg an einem ScrumMaster, der sich um ihre Produktivität kümmert.

Tipp: Orientiert Euch bei der Größe an Scrum-Teams! Diese sollten nicht mehr als neun Mitglieder haben, darunter ein Product Owner und ein ScrumMaster als dedizierte Rollen.

Unangemessene Zielvorstellung

Was wollen wir mit dem Transition Team eigentlich erreichen? Ich erlebe häufig zwei Extreme. Das eine Extrem besteht aus Transition Teams, die hauptsächlich an Verwaltungsaufgaben arbeiten. Ein Beispiel hierfür ist der Einsatz neuer Tools oder die Beschreibung bzw. Ausgestaltung von Abläufen. Das sind Aufgaben, die keiner großen Veränderung bedürfen und entsprechend bescheidene Ziele nach sich ziehen. Das andere Extrem besteht aus Transition Teams, die an Zielen arbeiten, die so monumental sind, dass sie sie aus eigener Kraft gar nicht erreichen können. In meinem derzeitigen Transition Team wollten wir ganz zu Beginn die agile Organisation konzipieren – bis wir dann merkten, dass das Aufsetzen von Scrum-Teams zu jenem Zeitpunkt unsere eigentliche Aufgabe war.

Tipp: Gebt Euch zuerst eine Vision, die das Zielbild darstellt. Gebt Euch dann eine Mission, die den Weg dorthin beschreibt.

Keine Führung

Welche Menschen sitzen in deinem Transition Team? Sind es Verwalter und Optimierer? Oder gibt es auch Menschen, die den Status Quo in Frage und die Organisation vor echte Herausforderungen stellen können? Manchmal reicht auch schon eine Person mit Führungsanspruch in einem Transition Team – solange sie als Visionär alle anderen Mitglieder für den Change begeistern kann.

Tipp: Prüft bei jeder Story, inwiefern sie dem Geiste der Vision entspricht. Vieles wird sich dann als nebensächlich entpuppen.

Wenn man so viel falsch machen kann, warum machen wir uns dann überhaupt die Mühe, Transition Teams aufzusetzen? Weil wir Scrum als Vehikel zu einer Veränderung nutzen möchten, die zwar in den Scrum-Teams ihren Dreh- und Angelpunkt hat (wir machen Produkt-, nicht Organisationsentwicklung), aber ohne gescheite Rahmenbedingungen früher oder später verkümmert.

Woran merken wir, ob ein Transition Team seine Arbeit gut verrichtet? Indem es sich nach und nach überflüssig macht. Denn eine Organisation mit hinreichend starken ScrumMaster- und Product Owner-Teams kann mehr und mehr Veränderungen von selbst anstoßen und durchsetzen. Aber dahin zu kommen, das ist der eigentliche Weg einer jeden Transition. Es lohnt sich.

John P. Kotter (1996): Leading Change. Harvard Business Review Press. (http://astore.amazon.de/borisgloger-21/detail/0875847471)

Siehe auch: Bitte geben Sie Ihr Ziel ein! Tipps für das Transition Team

Related posts:

1. Bitte geben Sie Ihr Ziel ein! Tipps für das Transition Team
2. Warum keine Tasks im Backlog?
3. Scaling Scrum is simple but very hard | 10 Tipps

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!

Related posts:

1. 3 + 3 Rollen in Scrum Oder doch nur 3 +1?
2. Die drei weiteren Rollen in Scrum
3. ScrumMaster can not be the Product Owner | 10 reasons

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

Related posts:

1. Coaching Ausbildung – Contrain – Mantz/Rösner
2. Über das Schreiben | Leidenschaft
3. Bin ich am Arbeitsplatz zufrieden?

Doch hier die Geschichte.

Ein Strom floss von seinem Ursprung in fernen Gebirgen durch sehr verschiedene Landschaften und erreichte schließlich die Sandwüste. Genauso wie er alle anderen Hindernisse überwunden hatte, versuchte der Strom nun auch, die Wüste zu durchqueren. Aber er merkte, dass – so schnell er auch in den Sand fließen mochte – seine Wasser verschwanden. Er war jedoch überzeugt davon, dass es seine Bestimmung sei, die Wüste zu durchqueren, auch wenn es keinen Weg gab. Da hörte er, wie eine verborgene Stimme, die aus der Wüste kam, ihm zuflüsterte: “Der Wind durchquert die Wüste, und der Strom kann es auch.”

Der Strom wandte ein, dass er sich doch gegen den Sand werfe, aber dabei nur aufgesogen würde; der Wind aber kann fliegen, und deshalb vermag er die Wüste zu überqueren.
“Wenn du dich auf die gewohnte Weise vorantreibst, wird es dir unmöglich sein, sie zu überqueren. Du wirst entweder verschwinden, oder du wirst ein Sumpf. Du musst dem Wind erlauben, dich zu deinem Bestimmungsort hinüberzutragen.”

Aber wie sollte das zugehen?

“Indem du dich von ihm aufnehmen lässt.”

Diese Vorstellung war für den Fluss unannehmbar. Schließlich war er noch nie zuvor aufgesogen worden. Er wollte keinesfalls seine Eigenart verlieren. Denn wenn man sich einmal verliert, wie kann man da wissen, ob man sich je wiedergewinnt?

“Der Wind erfüllt seine Aufgabe”, sagte der Sand. “Er nimmt das Wasser auf, trägt es über die Wüste und lässt es dann wieder fallen. Als Regen fällt es hernieder, und das Wasser wird wieder ein Fluss.”

“Woher kann ich wissen, ob das wirklich wahr ist?”

“Es ist so, und wenn du es nicht glaubst, kannst du eben nur ein Sumpf werden. Und auch das würde viele, viele Jahre dauern; und es ist bestimmt nicht dasselbe wie ein Fluss.”

“Aber kann ich nicht derselbe Fluss bleiben, der ich jetzt bin?”

“In keinem Fall kannst du bleiben, was du bist”, flüsterte die geheimnisvolle Stimme. “Was wahrhaft wesentlich an dir ist, wird fortgetragen und bildet wieder einen Strom.”

Und der Strom ließ seinen Dunst aufsteigen in die Arme des Windes, der ihn willkommen hieß, sachte und leicht aufwärts trug und ihn, sobald sie nach vielen, vielen Meilen den Gipfel des Gebirges erreicht hatten, wieder sanft herabfallen ließ.

Der Strom lernte. Und wurde mit jedem Tag besser.

Wer werde ich danach sein?

Schöne Geschichte, oder? Aber was hat das mit Scrum zu tun? Ich finde, diese Geschichte stellt wunderbar bildhaft dar, was bei einer Scrum-Einführung mit den beteiligten Menschen passiert. Zuerst ist man mit den alten Methoden erfolgreich. Man passiert so manche Engstelle und überwindet  so manche Stromschnelle. Alles funktioniert gut und man kommt weiter, wie der Fluss in seinem gewohnten Flussbett. Man hat seinen Status und hat sich einen Namen gemacht.

Doch dann tritt eines Tages ein Problem auf, das mit den üblichen Bewältigunsstrategien nicht mehr zu lösen ist. Wie der Fluss auf die Sandwüste trifft und all sein Wasser versickert, so sehr er es auch versucht, sind die alten Lösungsstrategien nicht mehr erfolgreich. Von außen erhält man einen Ratschlag, wie  z. B. die Einführung von Scrum. Aber zugleich wird auch klar, dass man bei der Einführung von Scrum viele alte Gedankenmuster loslassen muss und dadurch entsteht natürlicherweise Verunsicherung und auch Angst bei allen Beteiligten.

“Wer werde ich danach sein?”, fragt der Fluss. Mich hat ein Seniorarchitekt genau das bei der Scrumeinführung gefragt. Wer werde ich sein, wenn ich nicht mehr Seniorarchitekt bin? Wenn das nicht mehr auf meiner Visitenkarte steht. Und ich habe ihm das gesagt, was die Stimme dem Fluss sagt: “Das Wesentliche von dir wird bleiben – du mit deinen Fähigkeiten und deiner Persönlichkeit.” Nur der alte Status bleibt zurück, nichts als eine Bezeichnung. Bring dich mit all deinen Fähigkeiten ein, und du wirst automatisch eine wichtige Rolle spielen. Unnötig zu sagen, dass er glücklich und zufrieden mit Scrum wurde.

Denn genau darum geht es bei der Scrum-Einführung: Alte Gedankenmuster zurücklassen, seine eigentliche Potentiale zu entdecken und entwickeln, den Menschen wieder in den Mittelpunkt zu stellen. Und eine ganz neue Art der eigenen Arbeit und der Zusammenarbeit mit den Kollegen zu entdecken.

Scrum ist also mehr als ein Change, es es ist mehr eine Transformation, in der alles Alte hinterfragt wird und nur das, was wirklich gut ist, bleibt.

Und jetzt lest doch einfach die Geschichte nochmal und überlegt, wo die Parallelen zu Scrum sind. Vielleicht findet ihr noch viel mehr als ich.

Related posts:

1. Kreativitäts-Fitnessplan
2. Über das Schreiben: Leidenschaft | Passion | Freewriting
3. Scrum und Kanban in der Realität – Kurt Nielsen

Wenn wir zu unseren Kunden gehen, dann immer mit der Absicht, etwas zu verändern. Wir implementieren Scrum, was einhergeht mit einer Veränderung der Rollen, Prozesse und Werte der Zusammenarbeit. Und wir möchten am liebsten, dass alle Mitarbeiter freudig aufspringen und rufen: „JA! Wir wollen uns verändern!“ Stattdessen jedoch sind viele Mitarbeiter erst einmal verhalten: „Ja, die agile Idee ist klasse und wir haben schon viel von Scrum gehört und gelesen, aber ich bin mal gespannt, wie ihr das hier machen wollt.“

Und dann starten wir mit ersten Trainings und damit, die ersten Teams auf Scrum umzustellen. Das bedeutet für die Mitarbeiter viel Veränderung: Die Teams werden neu gemischt, Mitarbeiter bekommen andere Rollen, wir implementieren Regelmeetings, alles wird transparent gemacht und wir sprechen plötzlich offen mit allen über Hindernisse in der Organisation. Uffz! So anstrengend haben sich die Mitarbeiter die Umstellung gar nicht vorgestellt. Plötzlich spürt man in den Teams den Gedanken: „Och, eigentlich war es doch immer ganz gemütlich hier. Können wir nicht wieder zurück?“ Dann bekommen die Consultants eine anstrengende Aufgabe, nämlich die angestoßene Veränderung konsequent weiter aufrecht zu erhalten. Die Veränderungen müssen im Verhalten der Mitarbeiter und den Prozessen im Unternehmen verankert werden.

Nicht zu früh abweichen!

Aber das Zurückrudern meinen die Mitarbeiter nicht böse – für diese Reaktion gibt es eine rein biologische Erklärung. Professor Gerhard Roth, Neurobiologe an der Universität Bremen sagt: „Für unser Gehirn gibt es kaum etwas schwierigeres, als Gewohnheiten abzulegen.“ Wir haben uns bereits an Verhaltensweisen gewöhnt und können sie automatisch anwenden. Das ist gut so, denn wir müssen selektieren, worüber wir uns Gedanken machen, sonst läuft unser Arbeitsspeicher im Gehirn voll.

Barack Obama trägt nur blaue und graue Anzüge. Warum? Er sagt: „Ich will mich nicht entscheiden, was ich anziehe oder esse, weil ich zu viele andere Entscheidungen treffen muss.“ Gewohnheiten und Routinen sind wichtig, um uns Luft zu verschaffen und sie geben uns Sicherheit. „Das Gehirn versucht unentwegt, so viele Handlungen wie möglich in Routinen zu verwandeln,“ sagt Professor Roth. Und daran arbeiten wir mit der Einführung unseres Scrum-Flows: eine neue Sicherheit und Routine herzustellen. Ja, ich weiß, das dauert ein paar Sprints, aber es funktioniert! Dazu müssen Mitarbeiter und Consultants großes Durchhaltevermögen beweisen und konsequent zusammenarbeiten.

Viele Teilnehmer in Trainings fragen mich: „Was ist der größte Fehler, den man bei der Einführung von Scrum machen kann?“ Und meine Antwort darauf ist: „Das zu frühe Abweichen vom Scrum-Flow und den Scrum-Grundlagen. Oder den vermeintlich nervenden Consultant zu früh nach Hause zu schicken.“ Mindestens die ersten drei Sprints sollten wirklich nach Lehrbuch umgesetzt werden. Da muss man sich durchbeißen, und konsequent sein. Das ist hart, aber danach wird der Scrum-Flow zur Routine und wir können uns stärker auf andere Dinge konzentrieren, wie z.B. Teamentwicklung oder Steigerung des Levels of Done. Jetzt beginnt also die Kür der Veränderung und damit der eigentlich spannende Teil. Daher lautet mein Rat zu Anfang: „Haltet durch! Land ist in Sicht“

Angelehnt an den Artikel “So besiegen Sie schlechte Gewohnheiten!” (Elke Hartmann-Wolff) im  Focus 02/13 vom 07.01.2013

Related posts:

1. Education Paradigms & Softskills
2. Scrum – Eine Revolution (3)
3. Das letzte Wort hat unser Hirn

Geht es bei Scrum wirklich um Software-Entwicklung? Kann es das richtige Ziel sein, ein einzelnes Entwicklungs-Team produktiv zu machen? Dreht sich die Einführung eines agilen Mindsets in einem Unternehmen tatsächlich um technische Praktiken und Management-Frameworks?

Nein! Das alles greift viel zu kurz.

Immer wieder höre ich von Managern den Wunsch: „Wir müssen effizienter werden.“ Dahinter steckt oft der klassische Ansatz der lokalen Optimierung. Wenn nur jeder Bereich, jede Abteilung, jedes Team und jeder Mitarbeiter maximal ausgelastet sei, dann würden unsere Projekte auch schneller fertig.

Immer wieder höre ich von Managern die Aussage: „Die Entwicklung muss eine bessere Qualität liefern. Das Anforderungsmanagement muss bei uns vorgelagert sein. Der Betrieb ist sowieso voll ausgelastet, da die Software nie richtig funktioniert.“ Auch hier wird die Software-Entwicklung als zentraler Schuldiger gesehen, durch den die Probleme in der restlichen Organisation verursacht würden.

Was geschieht nun im Regelfall nach einer erfolgreichen Einführung von Scrum und agilen Entwicklungsmethoden? Die beteiligten Manager erkennen nach kürzester Zeit, dass die Probleme in der restlichen Organisation nicht verschwinden, obwohl die Entwicklung funktionierende Software schneller und in besserer Qualität liefert.

Scrum hat die Macht, die wahren Probleme einer Organisation sehr schnell offenzulegen! Und diese Offenlegung geschieht eben auch an den Schnittstellen der Entwicklungsteams in andere Bereiche. Damit erkennen wir die Kommunikationsschwierigkeiten zwischen allen Beteiligten am Produktentstehungsprozess. Produktmanager haben vielleicht noch nie mit Administratoren gesprochen, Verkäufer noch nie mit Testern, Entwickler noch nie wirklich mit dem Support. Aber all diese Mitarbeiter mit ihren unterschiedlichen Verantwortungen müssen gemeinsam daran arbeiten, den „Wow!“-Effekt für Kunden und Anwender zu erzeugen!

Durch die reine Optimierung unserer Entwicklungsmannschaft werden wir es nicht schaffen, den Anwender signifikant zu begeistern. Nur durch das Zusammenspiel aller Beteiligten können wir ein Produkt, eine Dienstleistung erzeugen, die der Anwender wirklich haben möchte.

Was müssen wir also tun, um ein erfolgreiches Scrum-Unternehmen zu transformieren?

Eigentlich ganz einfach: die Scrum-Teams müssen cross-funktional mit Beteiligten aus allen Unternehmensbereichen besetzt werden, die zur Erschaffung des Produktes benötigt werden!

So einfach dies klingt, so schwierig ist die Umsetzung der dafür notwendigen Grundlage: Veränderung der Unternehmensstruktur und vor allem der Unternehmenskultur. Das bedeutet, das agile Mindset, also die agilen Werte und Prinzipien, im Unternehmen auf allen Ebenen zu etablieren. Dies ist die eigentliche Herausforderung, mit der wir es zu tun haben. Und ich freue mich jeden Tag darüber, wenn ich sehe, wie Mitarbeiter und Manager sich von ihren traditionellen Vorstellungen Stück für Stück trennen, weil sie erkannt und erfahren haben, dass es andere, vielleicht erfolgreichere Wege gibt, mit Menschen gemeinsam ein funktionierendes Produkt zu bauen.

Wenn ich meinen alten Kollegen das nächste Mal treffe, werde ich ihm also antworten: „I have fun changing product development organizations. And sometimes that even may have something to do with making software teams productive.“

Related posts:

1. Scrum History | Ken´s Talk über Qualität
2. Scrum mit verteilten Teams | Jeff Sutherlands Paper and Talk
3. Effektiver mit Scrum | Hamburg |18.06. 20:00 | Lehmanns Fachbuchhandlung |

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)

Related posts:

1. Scrum – Eine Revolution (3)
2. Scrum – Produkte zuverlässig und schnell entwickeln
3. Management in Scrum Organisationen