Scrum – eigentlich so einfach wie kochen

Einzelne Teams, inzwischen aber auch ganze Unternehmen stellen sich die Frage: Wie können wir uns angesichts sich ständig verändernder Marktbedingungen so aufstellen, dass wir unsere Anpassungsfähigkeit erhöhen und gleichzeitig schneller in der Umsetzung werden? Sicher: Auf diese Frage gibt es viele mögliche Antworten und ganz sicher gibt es nicht das eine Rezept. Eine Antwort ist, die Haltung und Methoden von Scrum für sich zu entdecken und anzuwenden.
Oft erleben wir viele Hemmungen, wenn Menschen zum ersten Mal von Scrum hören und es für sich und ihren Kontext anwenden sollen. Deshalb wollen wir das Thema einmal aus einer anderen Perspektive betrachten und es mit dem Kochen vergleichen. Stellt euch vor, ein Familienmitglied hat Geburtstag. Ihr wollt diesen Geburtstag bei euch Zuhause feiern und ein Festmahl zubereiten. So ähnlich ist es, wenn man den Scrum Flow für sich entdeckt und seinen Projekt-/Arbeitsalltag mit Leben füllt.

Mit Offenheit kocht es sich leichter

Eine wichtige Voraussetzung ist aus unserer Sicht die Haltung, beispielsweise die Offenheit für Experimente. Bezogen auf unser Menü bedeutet das, nicht zu lange zu überlegen, sondern bereit zu sein, einfach loszulegen. Sich darauf einzulassen, dass das Menü während des Kochens weiter Form annimmt. Natürlich kann man beliebig viel Zeit investieren, ein besonders kreatives Menü zusammenzustellen, doch lasst uns einfach mal damit beginnen!
Auf den Kontext der Organisation übertragen, bedeutet das eine neue Haltung in der Führung: sich beispielsweise gemeinsam mit den Mitköchen zu überlegen, was traue ich mir und meinen Mitköchen zu, die Aufgaben aufzuteilen und dann loszulassen. Es bedeutet, in die Selbstorganisationsfähigkeit des Teams zu vertrauen, in die Kollaboration über horizontale und vertikale Grenzen hinweg, damit das Essen gemeinsam gelingt. Welche Zutaten tragen wesentlich zum Gelingen bei?

Die Vision: Pasta oder Schweinshaxe?

Um den Geburtstag gebührend zu feiern, wollen wir unsere liebe Familie und die Freunde bekochen. Natürlich soll es etwas Besonderes geben. Wir haben es geradezu vor Augen: Das größte Festmahl aller Zeiten soll es werden! Ein rauschendes Fest, wie es die Welt noch nicht gesehen hat. Mit einem Leuchten in den Augen erzählen wir bei der Einladung von unserem Plan und sehen, wie geradezu der Funke überspringt. Alle freuen sich auf das anstehende Fest und bieten ihre Unterstützung an. Im Scrum-Kontext ist es der Product Owner, der diese Vision in ein Produkt verwandelt und emotional kommuniziert und dadurch das Team motiviert, voller Energie an der Umsetzung mitzuwirken.

Die Constraints: der Blick in den Kühlschrank

Wir stehen also in der Küche und haben die Vision eines opulenten Festmahls vor Augen. Ein Blick in den Kühlschrank holt uns zurück auf den Boden der Tatsachen. Er ist ziemlich leer. Es ist Monatsende und das Konto zeigt überdeutlich, dass ein Großeinkauf heute nicht mehr drin ist. Es gibt aber noch ein paar Dosen geschälte Tomaten und in der Vorratskammer findet sich eine Packung Nudeln. Etwas Knoblauch ist auch noch da, frische Chili-Schoten und Olivenöl. Leider ist der Backofen seit Wochen defekt, aber immerhin funktionieren die Herdplatten, im Schrank finden sich ein Topf und eine Pfanne. Mit diesen Rahmenbedingungen lässt sich zwar kein 10-Gänge-Menü zaubern, für eine große Portion Penne Arrabbiata dürfte es aber reichen. Zusammen mit der letzten Flasche von dem guten Rotwein ergibt es das bestmöglichste Gericht.
So ambitioniert eine Vision auch sein mag, kein Produkt und kein noch so leckeres Gericht ist frei von Einschränkungen und Rahmenbedingungen, eben den sogenannten „Constraints“. Im Kontext einer Produktentwicklung geben diese Rahmenbedingungen vor, wie die Vision umgesetzt werden kann. Wie groß ist das Budget? Wie viele Mitarbeiter können an einem Projekt arbeiten? Welche gesetzlichen Vorschriften müssen eingehalten werden? Was ist technisch überhaupt machbar?

Die Rollen: Verantwortung teilen – kochen im Team

Wie auch im Scrum Flow gibt es beim gemeinsamen Kochen zugewiesene Rollen. Diese Rollen sind klar voneinander abgegrenzt: Jeder der mitkocht, übernimmt eine bestimmte Arbeit. Im Scrum Flow gibt es die drei Kernrollen Scrum Master, Product Owner und Entwicklungsteam. In drei weiteren Rollen kommen noch Kunde, User und Management ins Spiel. Auch hier sind die Rollen klar voneinander abgegrenzt: Der Product Owner weiß genau, was er oder sie am Schluss vor sich stehen haben möchte. Er organisiert das Menü und ist dafür verantwortlich, dass jeder Koch im Team die benötigten Fähigkeiten hat, um das beste Menü auf den Tisch zu zaubern. Seine „Vision“ gibt er an die Mitköche weiter, die das Entwicklungsteam bilden. Sie kochen das Menü „tatsächlich“ und bringen es in eine Form. Ohne sie würde der Product Owner das Gericht nicht rechtzeitig zur Feier fertigbekommen.
Die Rolle des Scrum Masters kann in der Küche mit jemandem verglichen werden, der sich darum kümmert, dass jeder die Zutaten hat, um seine Arbeit schnellstmöglich auszuführen. Der Scrum Master sorgt auch dafür, dass das Team ohne Probleme und Einschränkungen kochen kann, indem zum Beispiel Geschirr abgewaschen oder Abfälle entsorgt werden. Um den Scrum Flow zu vollenden, benötigen wir noch Kunde, User und Management. Im unserem Fall ist das Geburtstagskind Kunde und User. Es gibt im Vorfeld an, welche Wünsche es hat (oder das Kochteam weiß das aus vergangenen Beobachtungen), und genießt das Mahl im Anschluss an die Zubereitung. Der Manager finanziert das Geburtstagsessen, er hat nichts mit der Küche und dem Kochen zu tun. In unserem Fall könnte das der Vater des Geburtstagskindes sein.

Kochen und abschmecken: Selbstreflexion und Feedback-Loops

Lasst uns nun kochen. Um das Rezept bestmöglich umzusetzen, bietet sich ein gewisses Vorgehen an. Die taktische Ebene des Scrum Flow umfasst alle Meetings und ist mit den Anleitungen in einem Rezept vergleichbar. In diesen Anleitungen steht genau beschrieben, welche Schritte und welche Zutaten wann eingesetzt werden.
Starten wir mit dem Sprint Planning 1: In diesem Meeting überlegen wir uns, was das Festmahl beinhalten soll. Eventuell möchten wir mehrere Gänge zubereiten und entscheiden uns dafür, dass Kartoffelsuppe das Beste für den ersten Gang sei. Nachdem alle zugestimmt haben, überlegen wir uns, wie wir unseren ersten Gang umsetzen werden – vergleichbar mit dem Sprint Planning 2. Jeder Koch hat seine Aufgabe zugeteilt bekommen: Der eine wäscht die Kartoffeln, der andere schält die Kartoffeln, der Dritte schneidet sie klein und so weiter.
Nun ist das Vorgehen klar und alle Köche kommen ins Tun. Während der Zubereitung kann es Rücksprachen geben – im Scrum Flow spiegelt sich das in den Dailys wider. In diesem täglichen, rund 15 Minuten dauernden Standup-Meeting halten alle Köche kurze Rücksprachen zu den einzelnen Aufgaben. Ist die Suppe fertig, wird der Product Owner in die Küche gerufen, um zu probieren. Gefällt ihm die Kartoffelsuppe, wird sie an den Tisch gebracht und kann vom Geburtstagskind und den Gästen probiert und bewertet werden. Sind die Gäste und vor allem das Geburtstagskind zufrieden, hat die Kartoffelsuppe bestanden. Sollte es jemandem nicht schmecken, wird zum Beispiel mit weiteren Gewürzen nachgebessert – das geschieht im Rahmen des Scrum Flow mit Produkten nach dem Review. Nachdem die Kartoffelsuppe von den Genießern „abgenommen“ wurde, trifft sich das Team in der Küche und reflektiert die Zusammenarbeit, wie in einer Retrospektive.
Die Prinzipien und Vorgehensweisen von Scrum sind also eigentlich nichts Neues – sie werden in anderen Kontexten täglich praktiziert. Was vielleicht ungewohnt ist, ist die Anwendung dieser Prinzipien auf die Wissensarbeit. Fangen Sie doch einfach genau so an, wie wir es hier beschrieben haben: Legen Sie einfach los, machen Sie sich den Spaß und bereiten Sie mit Freunden ein Essen nach dem Ablauf des Scrum Flow zu. Guten Appetit!

Diesen Artikel haben Mara Ambs, Michael Gissler und Miruna Sachse im Mob-Writing gemeinsam verfasst.

Agiles Arbeiten: Fokus entsteht durch Vertrauen

Bei einem Product Owner Training haben mich drei Teilnehmer auf das Thema Fokus gebracht. Nicht zuletzt ist “Fokus” einer der fünf Werte von Scrum. Doch wozu brauchen wir ihn, wie wirkt er und überhaupt: Wie entsteht Fokus? In einer angeleiteten Freewriting Session hatte ich dann die Chance, dieses Thema von Grund auf für mich zu beschreiben. Und naja, was soll ich sagen: Dabei fiel mir zunächst einmal Basketball ein. Ich habe selbst früher Basketball gespielt und wirklich geliebt. Man kämpft gemeinsam als Team und spielt alle nötigen Spielzüge aus, um einen Korb gegen seinen Gegner zu werfen.
Der Moment aber, in dem ich absolute Fokussierung wirklich spüren konnte, war während einer Freiwurfsituation. Sie ist hart erkämpft, und sichtlich aus der Puste steht man an der Freiwurflinie und soll zum angezeigten Zeitpunkt den Ball im Korb versenken. Alles andere als eine leichte Übung, wenn man das in einer realen Wettkampfsituation machen muss.
Fürs Gelingen braucht es Fokus und eine einstudierte Routine, durch die man im Moment der höchsten Anspannung die Umwelt vollkommen ausblenden kann. Der Fokus beschränkt sich nur noch auf den Ball, den Korb und den eigenen Herzschlag. Noch einmal tief durchatmen: und Wurf!

Wodurch entsteht Fokus?

Wie kann ich mich dazu bringen, die Umwelt für eine gewisse Zeit auszublenden, um im übergreifenden Sinne auch in der Unternehmenswelt zu „punkten“? Man könnte meinen, Meditation wäre ein möglicher Weg, um in einer Stresssituation cool bleiben zu können. Ja, sicher. Ich denke aber, dass der eigene Fokus nur ein Teil der gesamten Lösung ist. Denn was es in einer Freiwurfsituation braucht, ist nicht nur die eigene Ruhe, sondern die Ruhe des gesamten Teams, in dem man spielt.
Der Kern liegt also im Vertrauen zu seinem Umfeld.
Ich muss mich auf meine Leute verlassen können, egal was passiert. Selbst wenn ich den Ball nicht versenke, braucht es das Team, um den Ball wieder einzufangen, um im Spielverlauf durch weitere Versuche Punkte zu machen. Nur wenn ich es schaffe, dem Team vollkommen zu vertrauen, kann ich mich selbst auf das Wesentliche konzentrieren.

pixabay.com, Skitterphoto, CC0 Creative Commons

Wie funktioniert Fokus in der Unternehmenswelt?

In der freien Marktwirtschaft sind wir einer viel höheren Dynamik und Komplexität ausgesetzt. Wir haben oft mehrere Bälle im Spiel und jonglieren diese viel schneller als wir es eigentlich möchten. Doch der Fokus auf das Wesentliche macht ein Unternehmen wirtschaftlich. Würde ein Unternehmen auf jeden Reiz reagieren, würde es nicht mehr wertschöpfend sein.
Folglich scheint der wertschöpfende Fokus essentiell für den Erfolg in unserer Marktwirtschaft zu sein. Durch Vertrauen sowie eine passende Rollen- und Aufgabenverteilung behält ein Team die umliegenden Geschehnisse im Blick und reagiert nur auf die wichtigen Ereignisse. Denn wer den eigenen Fokus auf die wenigen, wirklich wichtigen Dinge legt, hat eine gute Chance, sein Vorhaben zu meistern. Durch den Fokus kann man sich jede beliebige Situation zu eigen machen, das Beste aus ihr herausholen und sie zu einem guten Abschluss bringen! Wohl wissend, dass das Team hinter mir steht und bei Problemen meinen Rücken stärken wird.

Wider die unsinnige Teamisierung von Leistung

Teamisierung? Gibt es nicht. Ein Kunstbegriff. Für mich beschreibt er ein Phänomen, das seit längerem in Zusammenhang mit der Einführung von agilen Methoden in Unternehmen beobachtbar ist. Ich meine hier nicht die „Sozialisierung“ – darunter versteht man das Vergemeinschaften und Teilen etwa von Belastungen, Gewinnen oder Lernerfahrungen unter den an einer Gesellschaft Beteiligten. Mit „Teamisierung“ meine ich eine leichtfertige Pauschalisierung und Verallgemeinerung von Individuen, die an einem Objekt oder in einer Leistung zusammenwirken. Sie passiert meist unmerklich zunächst auf der sprachlichen Ebene und wirkt sich in weiterer Folge auf die Struktur aus.
Plötzlich gibt es nur noch „das Team“ in seiner äußeren Hülle und Pauschalität – ähnlich indifferent wie „die Gesellschaft“, „die Wirtschaft“ oder „die Wissenschaft“ in politischen oder religiösen Polemiken. Als Hinweis auf eine innere Differenziertheit bleibt maximal das Attribut übrig, dass „das Team“ möglichst „crossfunktional“ besetzt sein soll. Dem Team stehen spezifische Rollen gegenüber: der ScrumMaster, der Product Owner, der Manager, der User, der Kunde. Das Team aber – jedenfalls in der ihm entgegenschlagenden Erwartungshaltung – als amorphe Masse angesprochen und sprachlich behandelt, trägt und erfüllt den hehren Anspruch, im Sinne aller beteiligten Anspruchsgruppen zu handeln, alle Bedürfnisse in sich zu absorbieren und zu verarbeiten. Mit intrinsischer Motivation und methodischer Kompetenz werden alle diese Bedürfnisse in Produktinkrementen iterativ aufgelöst und erfolgreich integriert. „Ask the team“ ist zur Weltformel geworden.
Einst war es eine Aufforderung, die Entscheidungen dorthin zu legen, wo die Information ist. Heute ist es mitunter eine Plattitüde, die einem ungelenken Management in ohnmächtiger Laissez-faire-Manier eine zeitgeistig erscheinende Beschreibung des eigenen – jetzt agilen – Mindsets und Führungsstils ermöglicht. Früher lästerte man vielleicht: „TEAM – toll, ein anderer macht’s.“ Das war wenigstens noch auf die dysfunktionalen internen Teamdynamiken gemünzt und mit einem Augenzwinkern eine freundliche Anmahnung für Zusammenspiel und Teamplay. Ganz nach der Idee des Mannschaftssports.

Leistung ist ein Zusammenspiel von Einzelnen

Aufgaben werden heute teamisiert – in ein Team geworfen – und dort durch das wundersame, unerklärliche Wirken des Teams auf höchstem Niveau bearbeitet und gelöst. Entsprechend wird auch Leistung teamisiert: Also keiner war’s – nicht nur im Negativen (wir erinnern uns an den ahnungslosen Blick kleiner Kinder, die mit dem Fußball eine Scheibe eingeschossen haben. Da war’s auch keiner). Schlimmer noch: Auch im Erfolgsfall war´s keiner. Weil es eben nur das Team gibt. Leistung aber, kommt im Zusammenspiel einzelner Teamplayer zustande. Wir sind kein Schwarm (was für ein grausamer Begriff im Kontext von Agilität), der instinktiv einen Formationsflug oder das Formationsschwimmen meistert. In der Regel sind wir doch höchst spezielle und spezialisierte Wesen mit einem hohen Maße an Differenzierungsmöglichkeiten und Bedürfnissen, die diese Diversität in den Dienst eines gemeinsamen Objekts (vielleicht des Teamworks) stellen. Für den Erfolg ist es noch nicht einmal notwendig, dass wir denselben Benefit aus diesem Zusammenwirken erhalten. Was uns eint, ist der Moment des Erfolgs, in dem wir uns in unseren Anstrengungen, Entbehrungen und Wirken bestätigt sehen.

Agiles Management führt Individuen

Lange Zeit hatte ich nicht verstanden, warum einige (vor allem Software-) Entwicklungsteams sich Namen wie „Defenders“ (entlehnt von Marvel-Figuren) gaben. Heute verstehe ich das als einen Hinweis auf die Unterschiedlichkeit im Team, als Hinweis darauf, die spezifischen Einzelleistungen und -beiträge im Team zu sehen, sichtbar zu machen und anzuerkennen, statt eine amorphe Masse namens „Team“ zu kreieren. Das ist ein wichtiger Schritt agilen Managements und somit einer agilen Führung und Steuerung: Es geht uns im Team um eine handverlesene Truppe von Charakteren und Profilen – ausgerichtet auf eine Sache. Eine Sache, die in ihrer Art und Natur ein komplexes und hochgradig soziales System der Bearbeitung, Beantwortung und Veränderung erfordert. Als agile Manager sind wir dafür verantwortlich, dieses komplexe, hochgradig soziale System zu etablieren und in eine Kultur der Selbsterhaltung und Selbstorganisation zu führen, um eben jener Sache (Aufgabe) gerecht zu werden.

Team ist Beziehung

Allzu schnell lösen wir den Einzelnen wie eine Brausetablette im Teamwasser auf (was nicht anzuraten ist). Jeder im Team bleibt aber wegen seiner menschlichen Natur immer nur er/sie selbst und wird nicht zu Team. Vielmehr vernetzt er sich in wiederholender, erweiternder und laufender Kommunikation mit anderen, die sie selbst bleiben. Erst diese Kommunikation lässt die Idee des Teams entstehen. Und diese Idee nährt sich aus den Beziehungsleistungen einzelner, die sich selbst in Bezug zueinander und zum ko-konstruierten Ganzen – dem Team – setzen. Entweder positiv inspirierend – dann nehmen wir die anderen Teammitglieder und das Teamkonstrukt positiv erweiternd zu unserem individuellen Wirkraum wahr – als Möglichkeit, über uns hinauszuwachsen. Oder wir erleben es eben als Gegenteil: Als Begrenztsein innerhalb der uns ohnehin schon schmerzlich bewussten Limitationen aus unserem Alleinsein. Durch das Teamkonstrukt erlebe ich mich also noch ohnmächtiger, als ich mich durch meine menschlichen Grenzen ohnehin schon erlebe. Sozialisierung der Limitationen statt Erweiterung der Möglichkeitsräume.

Team ist ein Konstruktionsprozess

Das bedeutet: Team ist immer ein Konstruktionsprozess, ein Work in Progress, der sich im Einzelnen positiv oder negativ nährt. Er wirkt selbstverstärkend dort, wo Konsens in der Beurteilung erlebt wird; energetisierend, wenn die Selbsterhöhung durch andere bestätigt wird; zerstörerisch dort, wo diese Konstruktion als behindernd, verhindernd oder gar lebensbedrohlich empfunden wirkt. Team ist also immer auch eine Einzelleistung, so verrückt das klingen mag. Auch wenn diese Einzelleistung zuallererst in der Konstruktionsbereitschaft des Wirklichkeitskonstrukts Team bestehen mag.Das bedeutet aber, sich nach dem Setup auch der Bedeutung der Einzelnen im Gesamtsystem Team bewusst zu bleiben. Damit kann sich die Schlagkraft, Bearbeitungs-, Beantwortungs- und Veränderungskompetenz und -fähigkeit weiterentwickeln und damit das System Team am Leben erhalten werden.
Konkret heißt das: 

Ich wäre nicht Berater, hätte ich nicht einen Begriff, der einem Executive Summary gleichkäme: Coopetition. Die Verbindung aus Cooperation und Competition. Das „sowohl als auch und und“ – auf Unternehmens-, Bereichs- und eben auch Teamebene. Weil wir eben sind, was wir sind: Individuen, die durch Sozialisierung überlebensfähig werden.

Video: Dev Team

Dev-Teams sollen liefern. Sie sollen crossfunktional sein, die Teammitglieder sollen sich gegenseitig unterstützen und sie sollen ständig besser werden. In diesem kurzen Video erkläre ich das Prinzip eines autarken Teams und die zwei wesentlichen Möglichkeiten, um eure Teams zur Zusammenarbeit zu bewegen.
Viel Spaß beim Anschauen — Boris
 

Ein Product Owner für zwei Teams, oder?

Mein Kunde hatte sich innerhalb eines großen Entwicklungsprojekts vorgenommen, nicht nur die verschiedensten Applikationen den neuen Anforderungen des Marktes anzupassen, sondern gleichzeitig die Software-Architektur zu modernisieren, um Continuous Delivery zu ermöglichen. Gestartet wurde mit mehreren parallel laufenden Scrum-Teams an vier verschiedenen Standorten. Wir hatten einen Kollegen aus dem Fachbereich, der neben der Rolle des Kunden auch zwei Scrum-Teams als Product Owner betreuen sollte. Auf welche Herausforderungen stößt dieser nun in der Rolle als Product Owner mit seinen beiden Scrum-Teams?

Was der Product Owner eigentlich tun sollte

Im Allgemeinen ist der Product Owner für das entstehende Produkt und den dazugehörigen Business Value verantwortlich, den das Produkt für das Unternehmen erzeugen soll. Gemeinsam mit dem Team arbeitet er an der Vision, pflegt das Backlog (Schreiben von User Storys und deren Priorisierung im Backlog) und er ist im ständigen Kontakt mit den Stakeholdern.
In meinen Augen ist der Product Owner ein betriebswirtschaftlicher Allrounder mit Liebe zur eingesetzten Technologie, der verschiedene Funktionen in einer Person vereint und dafür sorgt, dass das Richtige entwickelt wird. Zusätzlich bringt er die unterschiedlichen Positionen von Team und Stakeholdern zum größtmöglichen wirtschaftlichen Nutzen für das Unternehmen auf einen Nenner. In diesem Fall sah es aber anders aus.
Bild_ella_1

Der Product Owner hat keine Zeit

Bereits in den ersten Sprints stellten beide Scrum-Teams unabhängig voneinander fest, dass ihr Product Owner für sie kaum zeitlich verfügbar war. Das Backlog war weder vorbereitet noch priorisiert und daher liefen die Meetings sehr unstrukturiert und nicht konstruktiv ab. Nur sehr schwer konnten die Teams in Erfahrung bringen, welche User Storys im kommenden Sprint bearbeitet werden sollten. Für Fragen während des Sprints stand der Product Owner nur sehr eingeschränkt zur Verfügung, da er in seiner Rolle als Hauptansprechpartner im Fachbereich viele Aufgaben wahrnehmen musste und häufig unterwegs war. Letztendlich war auch der Product Owner mit der Situation unzufrieden, weil er den Anforderungen der beiden Teams nicht gerecht wurde und zunehmend überfordert war.

Der dreigeteilte Product Owner

Während einer Coachingsitzung mit diesem Product Owner entstand folgendes Bild:
Bild_ella_2
Es zeigt, dass schlichtweg die Fokussierung fehlte. Der Verantwortliche konnte sich weder seiner bisherigen Tätigkeit als Kunde noch seinen beiden Scrum-Teams widmen.
Mit dem Fokus auf nur ein Team könnte er sich besser in die Rolle des Product Owners einfinden. So sollte ein Product Owner Vertrauen in die Fähigkeiten seines Teams haben und es selbstständig entscheiden lassen, wie es seine Anforderungen umsetzen will. Dieses Vertrauen kann er jedoch nur erlangen, wenn er sich auf eine Sache, hier ein Scrum-Team, konzentrieren und sich mit dem Team und dessen Fähigkeiten auseinandersetzen kann. Zusätzlich ermöglicht die Fokussierung, auch ausreichend Zeit in die eigene Vorbereitung zu investieren. Mit einem vorbereiteten Product Owner laufen die Meetings strukturiert und effizient ab, sodass alle motiviert in den neuen Sprint starten können.
Ein Product Owner ist zudem Teil des Scrum-Teams. Er teilt sich im Idealfall mit dem Dev-Team und dem ScrumMaster einen eigenen Teamraum, verwaltet dort seine Artefakte (Story Map, Product Backlog etc.) und ist als Ansprechpartner verfügbar: für das Team und für die Stakeholder. So kann er sich voll und ganz auf das Team und deren Anfragen konzentrieren und wird nicht ständig unterbrochen. Auf allen Seiten ist dadurch ein Produktivitätsschub zu erwarten.

Ein Product Owner für zwei Teams, oder?

Im Laufe der ersten Sprints erkannten wir, dass die Konstellation nicht zielführend war. Selbst nachdem der Product Owner ein Scrum-Team abgegeben hatte, spürten wir keine wesentliche Verbesserung. Und so wurde schlussendlich entschieden, dass sich der Vertreter des Fachbereichs nun auf diese Rolle konzentrieren sollte – sie beanspruchte seine volle Aufmerksamkeit.
Ich bin der Meinung: Grundsätzlich ist es nicht sinnvoll, einen Product Owner für zwei Scrum-Teams einzusetzen, geschweige denn einen Kollegen, der mit zusätzlichen Aufgaben betraut wird. Die beschriebene Situation zeigt gut, auf welche Schwierigkeiten alle Beteiligten stoßen und dass diese sich nicht immer beseitigen lassen. Die Kunde-Product Owner-Konstellation führte außerdem dazu, dass zwei Teams nicht ausreichend gut und schnell entwickeln konnten und das wiederum verlangsamte das Projekt. Um einer solchen Situation künftig vorzubeugen, sollten alle Projektinvolvierten vor dem Start in den Aufgaben und Rollen innerhalb von Scrum trainiert werden. Zusätzlich sollten die Ausgestaltung der Scrum-Rollen und die Erwartungshaltung innerhalb der Organisation besprochen werden. So können bereits im Vorfeld mögliche Bottlenecks identifiziert und gelöst werden, bevor sie innerhalb des Projekts zu realen Schwierigkeiten führen. Und schließlich bin ich davon überzeugt, dass ein Product Owner seine Rolle nur so effektiv wie möglich ausführen und alles Nötige für sein Team geben kann, wenn er fokussiert arbeitet und sich nicht um mehrere Teams oder Projekte innerhalb der Organisation kümmern muss.
Übrigens ist es durchaus möglich, in Scrum einen Product Owner für zwei Teams einzusetzen. Allerdings setzt das unbedingt voraus, dass die Teams bereits seit mehreren Jahren mit Scrum gearbeitet haben und dass es die Produkt-Business-Beziehung vollständig durchdrungen hat. Der Grad der Selbstorganisation innerhalb der Teams ist dann bereits so hoch, dass es ausreicht, die große Vision des Product Owners zu kennen, um das Richtige zu liefern.
Bild_ella_3
 
Weitere Informationen zu Scrum 3.0 finden Sie hier: “Von Scrum 1.0 zu Scrum 3.0” oder “Boris Gloger and Scrum 3.0: Is the Future of Scrum Really No Backlogs or Standups??”

Warum sitzt David Alaba auf der Bank?

Als Österreicher freue ich mich auf diesen Sommer besonders. Seit Langem hat es unsere Fußball-Nationalmannschaft wieder einmal geschafft, sich für ein Großereignis zu qualifizieren. Wir fahren nach Frankreich und ein ganzes Land ist im Fußballfieber: Fanartikel verkaufen sich wie warme Semmeln, Spiel-Städte wie Bordeaux entdecken den österreichischen Fußballfan als gänzlich neue Touristengruppe und Testspiele gegen Fußballzwerge werden mit Interesse verfolgt. Und so lese ich eines Abends nach dem Testspiel gegen Malta den Spielbericht und wundere mich, dass unser Superstar, David Alaba, bereits zum zweiten Mal das halbe Spiel über auf der Bank sitzt. Müssen wir uns Sorgen machen?
Nein. Ganz im Gegenteil. Teamchef Marcel Koller sieht sich Alternativen an. Richtig gehört. Der Fußball-Zwerg Österreich sucht Alternativen für den besten Linksverteidiger der Welt. Zu Recht. Schließlich kann es sein, dass David Alaba ausfällt, geschont werden muss oder – vielseitig wie er ist – an einer anderen Stelle eingesetzt wird. Um das Team darauf vorzubereiten, lässt er gegen Malta einen anderen Spieler links außen auflaufen. Der Trainer investiert also Testspielzeit.

Fußball ist wie Softwareentwicklung – ein Teamsport

Genauso wie beim Toreschießen (Siehe: Mats Hummels darf keine Tore schießen) zeigt sich in diesem Fall eine Parallele zwischen Fußball und der Softwareentwicklung. Sehen wir uns den Zusammenhang anhand eines – nicht ganz – fiktiven Beispiels an:
Stellen wir uns vor, wir haben einen Spezialisten in unserer Mannschaft, der in seinem Bereich (sei das nun die linke Außenbahn oder die Datenbankverwaltung) eine Koryphäe ist. Aus welchem Grund auch immer ist er zur Zeit jedoch nicht verfügbar. Als Teamsportler wissen wir, dass Ausfälle im Laufe der Saison vorkommen und entsprechende Alternativen aufgebaut werden müssen. Ähnlich sollten auch Entwicklungsteams aufgestellt sein:
Selbstverständlich hat jedes Teammitglied individuelle, unterschiedlich ausgeprägte Stärken. Dennoch müssen wir auf einer Position agieren können, falls es hier zu einem Ausfall kommt. Trainer investieren an dieser Stelle Testspielzeit. Manager können diesem Vorbild folgen und in Wissenstransfer investieren. Dabei verlangt natürlich niemand, dass die Alternative so gut ist wie der Stammspieler, das Team darf nur zu keinem Zeitpunkt auf einer Flanke komplett offen sein.
Im Fußball wie auch in der Softwareentwicklung gibt es die Möglichkeit, Schwächen in der Mannschaft kurzfristig zu kompensieren. Während Fußball-Vereine Spieler ausleihen, können Unternehmen externe Berater oder Entwickler zukaufen. In beiden Fällen gelten dabei zwei Grundsätze:

Doppelspitzen lohnen sich

Im Fußball wie auch in der Softwareentwicklung lohnt es sich, Teams so aufzusetzen, dass jede Position bzw. Funktion mit mehr als einer Person besetzt ist. Während es im Fußball darum geht, gegenüber einem Gegner keine Schwachstelle zu offenbaren, hilft uns die Absicherung innerhalb der Teams dabei, Engpässe in der laufenden Entwicklung zu verhindern. Treten Probleme auf, kann durch die Mehrfachbesetzung außerdem gewährleistet werden, dass jemand da ist, der sich des Problems annehmen kann. Im Sport wie auch in der Softwareentwicklung können Sie sich kurzfristig behelfen, achten Sie dabei allerdings darauf, sich nicht in Abhängigkeiten zu begeben, die Sie nicht steuern können.

Mats Hummels darf keine Tore schießen

Auf dem Fußballplatz hat jeder Spieler eine wesentliche Verantwortung. Die Stürmer sollen Tore schießen, die Mittelfeldspieler die Bälle nach vorne bringen, die Verteidiger sollen verhindern, dass die gegnerische Mannschaft trifft und der Torwart versucht, Schüsse aufs Tor abzuwehren und Elfmeter zu halten. Das bedeutet aber nicht, dass die Spieler nur genau und ausschließlich das machen. Wenn sich die Chance ergibt, darf auch mal ein Abwehrspieler ein Tor schießen oder ein Stürmer in der Abwehr aushelfen. Stellen Sie sich vor, Tore, die nicht von einem Stürmer geschossen werden, zählten nicht. Hummels trifft? Das entspricht nicht seiner Verantwortung als Verteidiger. Marko Arnautovic verhindert auf der Linie ein Tor des Gegners? Die Abwehr des Stürmers gilt nicht, die gegnerische Mannschaft bekommt ein Tor zuerkannt.

Und in der Entwicklung?

Was am Fußballplatz absolut undenkbar ist, scheint in der Entwicklung von neuen Produkten gang und gäbe. Dort gibt es oft einen Hardwareentwickler, der ausschließlich Hardware entwickelt, eine Konstrukteurin, die ausschließlich konstruiert, einen Technischen Zeichner, der ausschließlich Zeichnungen erstellt, eine Einkäuferin, die ausschließlich Teile einkauft, einen Softwareentwickler, der nichts anderes macht, als Software zu schreiben. Jeder hat seinen Bereich, für den er verantwortlich ist. Nur er kann die dort anfallenden Aufgaben übernehmen und nur in seinem Verantwortungsbereich kann er arbeiten.
Wenn wir in Unternehmen neue agile Teams aufsetzen, lautet einer der ersten Einwände, die wir hören oft: „Ich bin Konstrukteur, ich darf nur konstruieren.“ oder „Ich teste nicht, dafür haben wir Versuchsmitarbeiter.“ Die Möglichkeit, außerhalb des eigenen Bereichs zu arbeiten oder zu helfen wird gar nicht in Betracht gezogen. Fehlt es zum Beispiel akut an freien Zeichnern oder ist der Teamkollege überlastet, kommt es selten bis gar nicht vor, dass der andere Kollege, der vielleicht die nötigen Fähigkeiten hätte, dem ersten hilft und somit das Projekt nach vorne bringt.
Was ist der Grund dafür? Hier sind einige Hypothesen:

Würden die Teammitglieder ein bisschen nach links und rechts neben ihrem eigenen Verantwortungsbereich schauen (dürfen), würden sie merken, dass sie sehr wohl helfen können.

T-shaped Professionals in der Produktentwicklung

Auch wenn der Verteidiger seine große Stärke in der Abwehr ausspielen kann, sind seine Fähigkeiten als Stürmer trotzdem gut genug, um auch mal ein Tor zu machen. Der Verteidiger reagiert situativ und flexibel auf die aktuellen Anforderungen, anstatt sich zurückzuziehen und darauf zu warten, dass der Gegner den nächsten Angriff startet. Auch wenn der Stürmer im Mittelfeld aushilft, ist er nach wie vor Experte im Schießen von Toren. Oftmals braucht es nicht DEN Topspieler mit den besten Fähigkeiten, sondern nur jemanden, der zur richtigen Zeit am richtigen Ort das Richtige tut, um den Teamerfolg zu gewährleisten. Genau so verhält es sich auch in der Entwicklung. Der Konstrukteur konstruiert, doch wenn er Zeit hat, darf er ruhig auch mal testen oder in der Fertigungs- oder Prozessplanung unterstützen. Das macht ihn nicht weniger zu einem Experten. In der agilen Community nennt man Mitarbeiter, die fachliche Expertise in ein paar speziellen Bereichen haben und darüber hinaus über Basiswissen in angrenzenden Bereichen verfügen „T-shaped Professionals“. Sie werden erstaunt sein, in wie vielen Bereichen außerhalb der eigenen Verantwortung man durchaus sinnvoll helfen kann.
Ein sehr positives Beispiel für diese Hilfsbereitschaft liefert eine niederländische Firma für Belüftungssysteme, in der ich einige Projekte begleiten durfte. Dort hat in einem Projektteam ein Mitarbeiter aus der Fertigungsprozessplanung in einer Phase, in der er eigentlich noch nicht so viel zu tun hatte, gerne und wie selbstverständlich den restlichen Teammitgliedern seine Hilfe angeboten. Die Designer im Team, die sonst regelmäßig mit neuen Aufgaben zugemüllt wurden, konnte er unterstützen und entlasten, obwohl er nicht in seinem Fachgebiet gearbeitet hat. Das hat dem Projekt und allen Mitgliedern gut getan und Ruhe ins Team gebracht. Das war die Theory of Constraints in Reinkultur: Der größte Engpass wurde aufgelöst, der Durchfluss an der richtigen Stelle erhöht.

Designated Teams fördern nachhaltige Zusammenarbeit

Die Voraussetzung dafür: Offenheit und eine nachhaltige Teamzusammensetzung. Nur wenn die Teammitglieder das Gefühl haben, sagen zu dürfen, dass sie Zeit frei haben, ohne vom eigenen Chef und Abteilungskollegen dafür mit einem Maulkorb bestraft zu werden, werden sie das auch tun. Da Fairness nach dem SCARF-Modell von David Rock ein menschliches Grundbedürfnis ist, muss außerdem absehbar sein, dass der Gefallen, der da geleistet wird, später auch wieder zurückgezahlt werden kann. Werden die Designer später aus dem Team genommen, ohne dass sie sich revanchieren konnten, wird der Prozessplaner einmal und nie wieder geholfen haben. Aus diesem Grund ist die Konsistenz im Team so wichtig. Das Stichwort hier lautet „designated teams“.
Fußball ist eine Teamangelegenheit, genau wie die Entwicklung neuer Systeme oder Software und nur wenn alle zusammenarbeiten, wird man das Spiel am Ende auch gewinnen. Da zählen Tore vom Verteidiger genauso viel, wie Tore der Stürmer. Lassen Sie Ihr Team also auch wirklich als Team arbeiten. Und trauen Sie sich, auch mal über Ihren Schatten zu springen. Sie und Ihr Team werden daran wachsen und davon profitieren.

Product teams for hardware products

Already in 1986 Ikujiro Nonaka und Hirotaka Takeuchi identified cross functional teams as a success factor for the development of new products. In their HBR article „The New New Product Development Game” they described six characteristics of successfully designing products:

  1. Built-in instability
  2. Self-organizing project teams
  3. Overlapping development phases
  4. “Multilearning”
  5. Subtle control
  6. Organizational transfer of learning

Not only simple teams but cross functional ones are a key factor for successful development.

What is a cross functional team exactly?

Cross functional teams are a way of working together more cohesively, across the silos of the organizational chart, reducing hand-overs and achieving a smoother and more efficient workflow. For our clients, we usually build autonomous teams with all or the maximum of competencies needed to develop solutions valuable to the customer. It shows that it is a key success factor. Scrum is a team-based management framework. It fosters interdisciplinary and collaborative work within the organization. It’s no coincidence that the first of the four statements of the agile manifesto says: “Individuals and interactions over processes and tools.“
crossfunctional_teams
Some companies starting with Scrum in hardware development are not willing to build cross-functional teams across organizational silos right from the beginning. Within a short time one can observe the following consequences:

We recommend to be especially careful as far as the team setup is concerned. To be able to deliver value the team’s setup and responsibility should ideally mirror your product architecture based on independent modules. Means each team should be responsible for a functional module. In this case you have one team for each module of your product and you can deliver value on the entire product level at the end of each iteration.

What are the main challenges of interdisciplinary work in a cross functional team?

Responsibility and decision making
Give the team the authority it needs to get things done and move forward. Progress will slow down if the teams have to ask the management for approval at every step. As head of mechanical engineering, system engineering or electrical engineering you have to let down taking single decisions. Instead, support the team in understanding or defining transparent decision criteria. As such a stakeholder you can still challenge the team at least at the end of every sprint! If your project is not doing as well as you desire, try to figure out how you can strengthen the team. Look for solutions within the team before you start looking for solutions outside the team, without the team!
Find a common language
Teamwork is an individual skill, interdisciplinary work is another one. Team members have to learn respecting each single competence and input. As a Product Owner you encourage the team to deliver valuable results and features together. Never define single delivery where only one competence is requested. It will help the team to know each other, understand the single contribution to the whole product development. As a ScrumMaster you can support the team finding a common language by using visualization and encouraging pairing.

Team decision versus level of influence

Depending on the company’s culture or history, different functional silos might have different levels of influence. The ScrumMaster and the manager have to be careful not to transfer these power biases into scrum teams. Be careful that decisions are not a „mechanical decision“ or a „science“ decision but a team decision regarding to the product vision.
Status

Collocation

The best way to lower barriers to team communication is collocation. Without sending the whole team in the desert for the duration of the project like engineering legend Kelly Johnson of Lockheed Martin did in 1943 (see Skunk Works) you should support a maximum of collocated time. It has to be simple for the team members to meet if they want/need it.
Use a War Room or project room (Obeya in lean equivalent) to make the project visible in one place. A place for collecting all the Information and project artifacts will create a magnet for team members as well as for supporting resources and stakeholders. This place can be seen as a working room as well as a show room. Choose a room spacious enough to host your prototype or which is very close to your laboratory or prototyping facilities. In all our projects, we have at least a dedicated team room for scheduled meetings (Planning, Review, Workshops) where we gather all the main Artifacts (Vision, Backlog, Workshop results, etc.). Especially for design, architecture and interface specification invest colocated time instead of other kinds of communication. Like Donald Reinertsen said: „Never place an organization or a geographic boundary on top of a poorly characterized architectural interface.“ (Don Reinertsen: Managing the Design Factory. A Product Developers Tool Kit. Free Press, 1997)

Focus

You wish your team members to be committed, to share a sense of ownership, taking responsibility and making decisions? Strive for dedicated team members! 1 Person= 1 Team = 100%
Even with best intentions, bystanders trying to “help” the team often just create more work for it. Those who are doing the work should be making most of the decisions.  Although you probably cannot afford to have every member assigned to only one team each, the more often you can do this, the better your project is likely to perform. Be sure you have people almost temporarily (some Sprints ) in the team if their field of competence and their decision are strongly needed in this phase. Invite people to join at least the Scrum Meetings, especially the Dailys or Review Meetings. For example when you are in a phase in which you have to negotiate with suppliers and submit orders, ask the colleague of the purchasing department to join the team for a few sprints.
I made the experience how dedicated staffing greatly improved accountability and commitment because:

Although you cannot afford to have every member assigned to only one team, the more you can do this, the better your scrum team is likely to perform.
I am deeply convinced that cross-functional teams are the key to delivering value faster by reducing transaction costs, accelerating decision processes and fostering a real sense of ownership for the entire product: before losing yourself in coordination and integration activities, give it a chance from the beginning!

Scrum Spaces oder Agilität braucht Raum

Ich habe ein neues Team, ein neues Projekt, eine neue Herausforderung. Einige der Tätigkeiten scheinen jedoch auf den ersten Blick nur wenig mit den Aufgaben eines ScrumMasters, wie man ihn aus den Lehrbüchern kennt, zu tun zu haben. Ich möchte, dass mein Team sich wohlfühlt, schließlich wird es hier, im Teamraum, die meiste Arbeitszeit verbringen. Mein Ziel: Ein Raum, in dem alle Lust haben zu arbeiten.
Scrum muss gelebt werden und um etwas zu leben, muss man es spüren – jeden Tag aufs Neue. Es ist ein aufregendes Gefühl, Teil von etwas Neuem zu sein. Scrum heißt, gemeinsam an einem Ziel zu arbeiten. Dieses Wir-Gefühl soll sich auch im Arbeitsraum widerspiegeln. Eine gute Stube. Hier sitzen ALLE Entwickler zusammen. Idealerweise finden auch ScrumMaster und Product Owner in der guten Stube ein Plätzchen zum Arbeiten. An diesem Punkt kommt oftmals die Frage: „Warum denn alle zusammen? Ich habe doch mein Büro …“ Eine einfache Antwort: Face-to-face- Kommunikation. Eine Frage oder ein Problem ist im direkten Gespräch viel schneller geklärt. Ohne Telefon, ohne E-Mail, ohne Chat. Ein Problem? Wir kreieren gemeinsam die Lösung! Tasks können in einem Teamraum einfach leichter und schneller gemeinsam bearbeitet werden. Durch das gemeinsame Arbeiten werden Wissen und Erfahrung direkt ausgetauscht und die Qualität des Arbeitsergebnis steigt dadurch erheblich.
Im Agile Manifesto liest man:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Doch wie schaffe ich es als Scrum Master, diese Prinzipien in das tägliche Arbeitsumfeld meines Teams zu implementieren? Bei der Frage nach dem perfekten Teamraum für agile Teams gibt es kein Schwarz oder Weiß. Alles, was sich gut anfühlt, ist erlaubt. Teams sitzen gerne zusammen, ob in Arbeitsinseln oder in einer U-Form. Fühlt sich das Team wohl, ist es die richtige Form. Und wenn nicht? Dann nutzen wir doch einfach zehn Minuten nach dem Daily, um ein wenig zu experimentieren … agil sein … anpacken und testen.

Wie sieht unser Teamraum nun aus?

Als ich die Teammitglieder gefragt habe, was für sie wichtig ist, stand an erster Stelle das Taskboard. Das Team wünscht sich, immer einen guten Blick auf seine Aufgaben zu haben. Wichtig ist den Teammitgliedern auch, die Sitzplätze je nach Zusammenarbeit wechseln zu können.
Wir wissen, wie wichtig die gemeinsame Arbeit an einer Tätigkeit und der disziplinenübergreifende Austausch sind. Also haben wir die Trennwände zwischen den Arbeitsplätzen abgebaut und Raumteiler entfernt. Nichts, abgesehen von den Bildschirmen, steht nun den Entwicklern und ihrem täglichen Austausch im Weg. Jeder kann so mit jedem kommunizieren und arbeiten, aufstehen, Sitzplatz wechseln, alles ist erlaubt. Feste Sitzplätze schränken das agile Arbeiten für gewöhnlich ein. Daher kann die tägliche Teamaufteilung (Pairs oder MiniMobs) je nach Bedarf wechseln. Das bedeutet auch, dass sich die Sitzordnung mit jeder Anforderung ändert. Platzwechsel als ein kleiner Ausdruck von Agilität – den Blickwinkel auch auf den Teamraum einmal ändern.
Viele Teams zeichnen und teilen gerne ihre Ideen, sie wollen die Strukturen oder Abhängigkeiten ihrer Storys und Tasks sehen. Am besten funktioniert das auf Whiteboards oder Flipcharts. Hier können neue Ideen ergänzt, Optimierungen direkt eingearbeitet und am Ende alles auf einem Foto festgehalten werden. Die zu Beginn noch weißen und leeren Wände füllen sich dann im Laufe der Zeit mit zahlreichen Visualisierungen, Zeichnungen und Artefakten. So bekommt der Raum einen teamindividuellen Ausdruck (oder Anstrich). Wichtig ist dabei, auch darauf zu achten, dass kein Information-Overflow entsteht, sondern dass nur Informationen vorhanden sind, die das Team wirklich braucht.
Wenn der Teamraum groß genug ist, würde ich als ScrumMaster noch eine Time-out-Zone einführen. Bequeme Sessel, ein Sofa – Open Areas. Dieser Bereich ist ideal für ad-hoc-Meetings, so muss nicht extra ein Meetingraum gebucht werden. Auch kann dieser Open-Space-Bereich einfach für 10 Minuten kreative Pause genutzt werden. Diese kurzen Auszeiten können für die Produktivität wahre Wunder wirken.
Agile Räume sind in meinen Augen genauso wie ihre Teams: individuell und anpassungsfähig.

Das andere Ende der Leitung: Scrum in verteilten Teams

Verteilte Teams passieren nicht. Sie entstehen, weil das Management festgestellt hat, dass erforderliches KnowHow nicht an einem Ort versammelt ist oder an einem anderen Standort günstiger zu bekommen ist. Wir müssen unser Team also dezentral organisieren. Nachdem wir uns im ersten Schritt mit der Kommunikation in verteilten Teams befasst haben, können wir uns nun daran machen, das Projektmanagement zu organisieren.

Warum bietet sich Scrum für die Organisation verteilter Teams an?

Am Ende jedes erfolgreichen Teambuilding-Prozesses steht ein gemeinsam geteiltes und verinnerlichtes Ziel. Im Scrum-Umfeld verbinden wir dieses gemeinsame Ziel in erster Linie mit dem Artefakt der Vision und mit dem agilen Wert des Commitments. Die Vision sollte bereits auf strategischer Ebende schnell, klar und deutlich verbreitet und laufend erneuert werden. Auf Sprint-Ebene ist das Commitment zu einem gemeinsamen Ziel das erste integrative Element. Es hilft dem Team, sich auf die Aufgaben des kommenden Sprints zu konzentrieren.
Scrum setzt auch im Verlauf des Sprints auf mehrere integrative Effekte. Wie bereits erwähnt ist das Peer Working ein effektiver Weg der Zusammenarbeit. Hier geht es aber nicht nur um den angesprochenen Vertrauensaustausch. Wenn es den Teamspirit stärkt, Checklisten abzuhaken hilft es uns erst recht, dieses Erfolgserlebnis zu teilen. Apropos: (Miss-)Erfolg ist der abschließende integrative Teil unserer Arbeit. Das Erreichen eines gemeinsamen Ziels kann uns als Team bestärken, Lohn für unsere Mühen sein. Ebenso kann gemeinsamer Leidensdruck Auslöser für Veränderung und Verbesserung sein.

Be part of it!

Spätestens wenn Sie versuchen, Magic Estimation mit einem verteilten Team zu spielen, werden Sie herausfinden, dass die Integration von Menschen, die sich nicht in einem Raum befinden, recht kompliziert sein kann. Hier gibt es verschiedenste Lösungsansätze, die je nach Teamsetting umgesetzt werden können. Zum Beispiel

Spätestens, wenn Sie ein großteils verteiltes Team betreuen, müssen Sie sich als ScrumMaster über eine vollkommen digital spielbare Variante der Magic Estimation Gedanken machen. Egal, um welches Meeting oder welchen Arbeitsschritt es sich handelt, die zwei wichtigsten Anforderungen sind dabei, dass

Remote. Ein Problem, das wir letzten Endes alle kennen.

Ihr Scrum-Team ist an einem Standort zusammengefasst? Herzlichen Glückwunsch! Sie werden sich im Rahmen der Zusammenarbeit gewisse Abstimmungsarbeit sparen. Das bedeutet aber nicht, dass Sie die oben genannten Grundsätze nicht beachten sollten. Irgendwie ist nämlich jedes Team verteilt. Wenn wir von Scrum sprechen, meinen wir die kontrollierte Zusammenarbeit von verschiedenen (Interessen-)Gruppen, den Rollen. Ich habe schon verschiedenste Unternehmen und Teams gesehen: Eine Konstellation, in der der operative Kern, externe Zulieferer, Management, Kunden und User nicht verteilt waren, habe ich dabei noch nie beobachtet. Die zugrundeliegenden Probleme können dabei durchaus die gleichen sein wie bei einem verteilten Scrum-Team. Somit betrifft uns das Problem des verteilten Teams doch irgendwie alle. Machen wir uns das bewusst und agieren wir dementsprechend. So können wir uns wieder ein klein wenig verbessern.