bor!sgloger » Gilda Feller

Der ScrumMaster als Dienstleister

Gilda Feller — Wed, 26 Sep 2012 07:37:58 +0000

Als Consultant lernt man in vielen Projekten viele Menschen kennen. Von dem einen weiß man nicht mehr den Namen, wenn man das Haus verlassen hat und der andere sorgt dafür, dass man wieder etwas dazulernt auf dem Weg des Lebens. Von einer solchen Begegnung möchte ich euch erzählen. Aus Gründen der Privatsphäre nennen wir sie einfach “Hilde”. Als ich Hilde kennengelernt habe, hat sie in einem Großprojekt 15 ScrumMaster, 20 Product Owner und 18 Teams (insgesamt 180 Menschen) organisatorisch begleitet. Jeder, der ein Anliegen hatte, konnte sich an Hilde wenden. Was mich so beindruckt hat: Hilde hat Kundenorientierung mehr als groß geschrieben. Sie hat alles getan, was in ihrer Macht stand, um Probleme aus dem Weg zu räumen, die Kommunikation zu nutzen und nebenher noch die “Mutter des guten Rates” zu sein. Eine Kollegin, die jeder gerne im Unternehmen hätte. Und sie hat mir Dinge beigebracht, die ich mit euch teilen möchte:

Nutze deine Kontakte und stelle sie allen zur Verfügung. Das eigene Netzwerk wird sich so verbreiten. Und Impediments aus dem Weg räumen macht einfach nur Spaß, wenn man die richtigen Leute kennt.
Schaffe eine WohlfühlAtmosphäre. Eine Umgebung, in der man gerne arbeitet. Der erste Schritt ist schon mal, die ungenutzten Möbel und Gegenstände zu entfernen, tote Blumen zu entsorgen und ggf. Bilder des Teams aufzuhängen.
Sei ansprechbar. Je mehr Bereitschaft ihr für Gespräche zeigt, umso eher werden euch die wichtigen Dinge angetragen.
Übernehmt ihr Aufgaben, dann informiert euren “Auftraggeber” (also Management, Teammitglieder, andere SM) über den Stand der Dinge. Auch wenn es ein “Ich bin noch nicht weitergekommen” ist, wird das Gegenüber euch dankbar sein. Der Auftraggeber weiß, dass sein Anliegen in guten Händen ist und auch so behandelt wird
Übrigens: Jedes Anliegen ist wichtig. Natürlich müsst ihr eine Prio einhalten, aber behandelt auch die Anliegen mit niedriger Prio als etwas Wichtiges. Denn was für euch eine “30″ ist, könnte für jemanden anderen eine “1″ sein…
Nehmt euch Zeit für euren Gesprächspartner. Wenn ihr keine Zeit habt, dann gebt einen Termin an, zu dem ihr Zeit habt.

Liebe ScrumMaster, ist da was dabei, das ihr für eure tägliche Arbeit nutzen könnt?

Kreativitätstechniken

Gilda Feller — Tue, 11 Sep 2012 06:01:16 +0000

Ich sitze an meinem Schreibtisch und möchte für mein Scrum-Team eine neue Retromethode entwerfen. Die Zeit vergeht und vor mir nur das leere Blatt. Schon drei Mal habe ich angefangen etwas aufzuschreiben. Drei Mal wieder gelöscht. Was soll ich mit ihnen machen? Was interessiert mein Team, die Leute sind doch alle so unterschiedlich? Womit begeistere ich sie?

Na, kommt euch die Situation bekannt vor?

Ich möchte was Cooles machen, um mein Team aus seinem Alltag herauszuholen und den Leuten eine frische Retro anbieten. Weg von 08/15 … Natürlich kann ich googeln. Mit Retrospektiven haben sich schon viele auseinandergesetzt. Aber ich möchte etwas Individuelles anbieten. Etwas, das die Persönlichkeit meines Teams herausstellt …

Was hindert uns daran, auch mal unsere Ideen zu sammeln. Und das ist gar nicht so schwer. Hier einige Möglichkeiten, um der eigenen Kreativität auf die Sprünge zu helfen:

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

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

ScrumMaster Checkliste

Gilda Feller — Wed, 29 Aug 2012 04:59:52 +0000

Gerade wenn wir als ScrumMaster lange im Einsatz sind, werden wir betriebslind. Der gute ScrumMaster hat natürlich schon die Initiative ergriffen und sich jemanden gesucht, der ihm Feedback geben kann. Aber immer geht das nicht. Darum möchten wir euch heute eine Checkliste zur Verfügung stellen, mit der ihr eure Arbeit selbstständig bewerten und an verbesserungswürdigen Stellen arbeiten könnt. Ihr könnt diese Checkliste natürlich auch als Grundlage für ein Coaching nutzen.

Hier geht es zur Checklist_ScrumMaster_2012

Schreibt doch mal: Hat sie geholfen? Habt ihr noch etwas für euch ergänzt?

Vom Los- und in die Freiheit lassen

Gilda Feller — Fri, 17 Aug 2012 05:48:49 +0000

Ich hatte vor Kurzem ein gutes Gespräch mit dem Standortleiter in einem meiner Projekte. Es ging um das „Loslassen“ von Teams. Wir haben festgestellt, dass das Management es oft eine sehr gute Idee findet, Scrum zu machen. Höhere Produktivität, bei weniger Ressourcen, bei weniger Kontrolle. Hört sich nicht schlecht an. Wenn es aber dann so weit ist, fällt es dem Management oft schwer, die Teams selbst schalten und walten zu lassen, wie es für eine Selbstorganisation notwendig ist. Im schlimmsten Fall werden die Teams “laufen gelassen”, aber dann schleudert das Management doch wieder zeusgleich einen Blitz hinein. Hie und da wird etwas Freiheit gelassen, aber wenn es um Selbstorganisation geht, hält das Management dann doch noch mal die Hand drauf: „Wir müssen ja auch unsere Köpfe hinhalten.“ Ein gutes Argument, das ich aus einer anderen Richtung gehört habe. Aber ist es nicht genau das, was Management ausmacht? Nämlich Verantwortung tragen? Verantwortung für Menschen, die nicht kontrollierbar sind? Denn sind wir mal ehrlich: Ab einer Menschenmenge von, ich sage mal, fünf (eine willkürliche Zahl), kann ein Manager doch gar nicht mehr steuern, was Angestellte, oder in unserem Fall das Team, tun. Und seit Jahren wissen wir, dass Kontrolle keine Führungsmethode für die Zukunft sein kann.Das bedeutet für Management in Scrum: Teams loslassen. Und das ist schwer!

Von der Bestimmer-Position in die Berater-Rolle

Ich vergleiche das gerne mit der Situation zwischen Eltern und ihren Kindern. Habt ihr Kinder? Als sie noch klein waren (oder noch gar nicht auf der Welt) habt ihr gesagt: „Mein Kind hat all die Freiheiten, die es braucht, um selbstständig zu werden. Es soll sich entwickeln und ganz nach seinen Fähigkeiten agieren. Ich werde nur beschützen und vor allem da sein, wenn es meine Hilfe braucht.“ So. Und dann kommt euer Kind in die Pubertät. Und dann fängt es an, tatsächlich eigene Interessen zu entwickeln und selbstständig zu agieren. Und trotz festgeschriebener Regeln (zum Beispiel: „Erst die Schule, dann das Vergnügen!“) wird das Vergnügen anders ausgelebt, als ihr es euch gedacht habt. Ihr habt es ja „damals“ nicht so bunt getrieben (mehr Respekt, mehr Regeln, weniger Freiheiten,…). Aber genau das ist der Punkt. Eltern, die ihre Kinder ziehen lassen, werden erstaunt sein, wie schnell Kinder zurückkommen und um Hilfe und Unterstützung bitten. Und die Elternrolle verwandelt sich von der (so nenne ich sie gerne) „Bestimmer-“ Position in die Berater-Rolle.

Und so ist es auch mit dem Management: Lasst eure Teams los. Gebt ihnen nicht nur das Gefühl, selbstbestimmt handeln und entscheiden zu können, sondern gebt ihnen wirklich die Chance. Und sie werden es gut machen. Nicht unbedingt so, wie das Management will, aber es wird gut, weil das Team selbst entscheiden konnte und die Konsequenzen selbst trägt. Wie auch Kinder, wenn sie älter werden. Wie sagt man so schön: Lass deine Kinder gehen, wenn du sie nicht verlieren wills.t“ Management will ja auch Freiheit, oder?

Und noch etwas: Nein, es ist nicht leicht. Aber es lohnt sich!

Der Product Designer als rechte Hand des Product Owner?

Gilda Feller — Mon, 09 Jul 2012 06:47:26 +0000

Die Anforderungen an den Product Owner sind immens hoch. Je nach Produkt und Zuständigkeit übernimmt er eine große Verantwortung: Einerseits aus der Sicht des Business Value und der Steigerung der Produktattraktivität für den Kunden, anderseits aus der organisatorischen Sicht. Er muss den Überblick über die Termine mit Kunden halten, Kundenkontakt halten, um Anforderungen entgegenzunehmen und entsprechend im Backlog zu verorten. Schon allein die Pflege des Backlogs und der dazugehörigen Formierung der Anforderungen an das Team ist eine hohe Belastung. So fangen immer mehr Unternehmen damit an, ihre „ehemaligen“ Product Designer (PD) als „rechte Hand“ des PO einzusetzen. Die PDs schreiben Feinkonzepte, halten den Kontakt zum Kunden und arbeiten dem PO zu.

Vom Gedankengang her gar nicht so falsch. Der PD als Sparring Partner – als jemand, der mitdenkt, überprüft und gestaltet. Gleichzusetzen mit der Zusammenarbeit, die wir ja auch in den ScrumTeams finden. Aber kritisch zu sehen: Durch das Zuarbeiten des PD führen wir eine unnötige Hierarchieebene ein.

Die Verantwortlichkeit des PO verändert sich: Er ist „nur noch“ derjenige, der auf dem Backlog sitzt und die Zuarbeiten kontrolliert. Wie könnte eine Lösung aussehen? Beispielsweise kann man darüber nachdenken, wie man das Produkt in einzelne Komponenten oder Projekte aufteilt, um die Arbeit für einen PO „mundgerecht“ zu machen. Dabei bleibt unbestritten, dass die Verantwortlichkeit des PO hoch ist und er auch mit dem Abspecken seiner Rolle ein Workaholic ist und bleibt.

Wir reden von Selbstorganisation und Emanzipation der Teams: Also auch Teammitglieder können Storys schreiben. Eine große Entlastung für den PO.

Management – ein Reminder

Gilda Feller — Tue, 19 Jun 2012 03:11:56 +0000

In dem wirklich spannenden Kommentar „Manager müssen eine neue Offenheit lernen“ von Karl-Heinz Büschemann in der Süddeutschen Zeitung plädiert der Autor anhand des Abschieds von Infineon-Chef Peter Bauer für mehr Ehrlichkeit in den Chefetagen. Bauer räumte in seiner Abschiedsrede Schwächen ein. Etwas, das man nicht oft in einer Abschiedsrede hört und überhaupt “untypisch” für einen Chef.

Das Bild des unfehlbaren und allwissenden Managers hat sich im Laufe der letzten Jahre selbst überholt. Komplexe Systeme wie Unternehmen können nicht von einer Person allein geführt, gesteuert und in die Zukunft getragen werden. Ohne kontinuierlichen Austausch (zwischen ALLEN Hierarchien) werden Entscheidungen auf Grundlage wackeliger Informationen getroffen. Dass auf dieser Grundlage vom Management auch Fehlentscheidungen getroffen werden, ist unvermeidbar. Denn wie auch Büschemann schreibt: „Niemand ist unfehlbar.” Aber genau das ist es, was das Management heute lernen muss (und man sollte hier nicht einmal so weit gehen, von einem Management 3.0 zu sprechen). Manager von heute sollte sich im Klaren sein, dass auch sie Fehler machen können (und auch müssen?!). Büschemann schreibt gegen Ende seines Kommentars: „Nur wer in der Führungsetage zeigt, dass er keineswegs alles selbst und besser weiß, kann seinen Mitarbeitern ein Vorbild sein.“

Ein Vorbild zu sein, bedeutet zu seine Fehlern zu stehen und diese ggf. auch zu revidieren. Unter Umständen auch den Dialog mit den Mitarbeitern zu führen, Transparenz in den Entscheidungen zu erzeugen. Die Angst des Managements ist es oft, dass Gesicht zu verlieren und in den Augen der Mitarbeiter weniger “Bedeutung” zu haben. Ein Manager, der Fehler zugibt, erweist sich als fehlbar und somit als menschlich. Fehler eingestehen zu können, bedeutet auch eine entsprechende Unternehmenskultur zu führen. Nur in einer Kultur, in der Fehler gemacht werden dürfen, werden auch welche zugegeben. Und gehen wir vom humanistischen Menschenbild aus, können wir sagen, dass jeder Mitarbeiter sein Bestes in der bestehenden Situation gibt und somit keine Fehler bewusst erzeugt werden.

Um sich die Bedeutung noch einmal zu verdeutlichen: Mitarbeiter sehen krasse, mit tiefschürfenden Konsequenzen verbundene Entscheidungen oft als eine Fehlentscheidung des Managements an. Das hat oft die Konsequenz, dass darauffolgende Entscheidungen mit viel Widerstand “durchgeboxt” werden und von den Angestellten nicht getragen werden.

Und an dieser Stelle zur Erinnerung: Scrum gibt dem Team die Macht der Selbstorganisation. Je organisierter das Team ist, desto weniger unsichere Entscheidungen muss das Management tragen. Je mehr Beteiligung der Mitarbeiter, desto verstärkter werden Entscheidungen auch von den Mitarbeitern getragen. Und noch mal zu Erinnerung: Ein Management kann nur ein Management sein, wenn es Mitarbeiter hat, die produzieren. Management ist KEIN Selbstzweck, sondern Management bietet Ressourcen, damit das Team produzieren kann.

Was der Berliner Flughafen mit agilen Werten zu tun hat

Gilda Feller — Wed, 09 May 2012 11:46:12 +0000

Die Schlagzeile des heutigen Tages, die Deutschland, Airlines und Passagiere weltweit nervös macht: Die Eröffnung des neuen Berliner Flughafens wird auf unbestimmte Zeit verschoben. Der 3. Juni als Eröffnungstermin ist Geschichte. Niemand kann sagen, wann der Willy Brandt-Flughafen bereit sein wird, sich den Reisenden zu stellen. Man hört von sechs Wochen Verschiebung. Der Prestige- und Vorzeigebau wird nicht fertig. Deutschland ist (mehr oder weniger) schockiert. Und eine der Fragen, die sich die Medien stellen, lautet: „Warum hat niemand früher gesagt, dass es länger dauert?“ Denn drei Wochen vor Start wird doch schon abzusehen gewesen sein, dass dieses nicht kleine Bauvorhaben nicht fertig wird …
So die momentane Situation – zumindest soweit sie aus der Informationsflut, die uns zu diesem Thema derzeit umspült, nachvollziehbar ist. Aber mal ehrlich: Kennen wir das aus unserem Berufsalltag nicht auch? Projekte die nicht fertig werden? Ampeln, die den aktuellen Projektstand darstellen sollen und die dann doch ausgehebelt werden, wenn das Ende näher rückt?

In vielen Unternehmen reißen Projekt-Deadlines und es muss nachgearbeitet werden. Eigentlich ist es eher die Regel, dass die geplanten Zeiten nicht eingehalten werden. So weit nicht schlimm. Denn wir sind Menschen und können nicht in die Zukunft gucken. Das gilt auch für den Bau des Willy Brandt-Flughafens. Ein Projekt in dieser Größenordnung ist nur schwer zu greifen – irgendwas vergisst man immer … Um auf Veränderungen schnell reagieren zu können und Gefahren wie eine Nicht-Fertigstellung möglichst früh erkennen zu können, machen wir Scrum. Iterative und überschaubare Zeiten, in denen man genauer planen kann. Ich möchte mich nicht zu weit aus dem Fenster hängen und sagen: Berlin hätte sein Bauvorhaben mit Scrum machen sollen. Aber ist doch eine spannende Fantasie … erste Ansätze waren mit dem Passagier-Testbetrieb auch schon da.

Offen kommunizieren!

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

Es muss schnell gehen, heute machen wir kein Scrum

Gilda Feller — Mon, 26 Mar 2012 20:00:10 +0000

Zu meiner großen Freude führen immer mehr Unternehmen Scrum ein und beginnen diesen Produktentwicklungszyklus auch wirklich zu leben. Besonders gelobt werden die Planbarkeit und der Umgang mit dem Commitment. Und dennoch: Immer wieder schleicht sich ein altbekanntes Phänomen ein, das absolut im Widerspruch zu Scrum steht und auch konträr zu den eben erwähnten positiven Aussagen ist.

Folgende Situation: Eine vergessene Ausschreibung trudelt auf dem Tisch eines Mitarbeiters ein. Plötzlich müssen Kundenwünsche „schnell“ oder „mal kurz“ vom Entwicklungsteam umgesetzt werden. Untermalt von der Aussage:

"Leute, es muss schnell gehen, heute machen wir kein Scrum!" Ein Gehetzter

Und dann setzt man sich (im besten Fall) noch einmal zusammen und bespricht im Schnellverfahren, was zu tun ist. Dann hauen alle in die Tasten und die Abstimmung, die in Scrum eigentlich mehr Raum hat und sonst so gelobt wird und zum gewünschten Erfolg führt, wird ausgesetzt, weil sie angeblich zu lange dauert. Was bedeutet das? Dass Scrum nur toll ist, wenn man lange Planungsphasen hat? Wenn es aber schnell gehen muss, gibt es keine Zeit für eine richtige Abstimmung?

Was will Scrum?

Scrum möchte weg vom schnellen Dazwischenschieben von Aufgaben, hin zu einem strategischen Agieren und Planen. Dazu ist ein Product Owner nötig, der alle Termine im Blick hat und auch einmal Nein zu unerwarteten Kundenanforderungen sagen kann. Und hier spreche ich nicht vom Stillstand beim Kunden – dass es hier eine Ausnahmesituation braucht, ist selbstredend. Hier sind wir schnell bei den Verantwortlichkeiten und Aufgaben des PO: Er oder sie muss die Kundentermine im Blick behalten, sie priorisiert in das Backlog bringen und die Kundenanforderungen dann von den Entwicklern abarbeiten lassen. Keine leichte Aufgabe, denn meist ist es ja nicht nur ein Kunde, dessen Wünsche und Bedürfnisse gestillt werden müssen. Einen guten Product Owner zeichnet ein gutes Organisationstalent aus. Und nicht nur das: Er hält den Kontakt zum Kunden, um rechtzeitig Anforderungen einzusammeln und den Entwicklern periodisiert zur Verfügung zu stellen.
Gelingt das dem Product Owner gut, dann ist es eine Arbeitserleichterung für die Entwickler. Sie müssen dann nicht mehr im letzten Moment auf den Plan gerufen werden, um das Feuer am Dach zu löschen.

Gilda Feller, Scrum Consultant bei bor!sgloger