Manager, entscheidet euch oder entscheidet euch!

Das häufigste Impediment, das uns in Großunternehmen am Weiterkommen hindert, ist die nicht getroffene Entscheidung. Teams stoßen regelmäßig an den Rand ihrer Entscheidungsfähigkeit, da es geschriebene und ungeschriebene Regeln im Unternehmen gibt: Bestimmte Entscheidungen sind vom Vorstand oder zumindest einer bestimmten Hierarchieebene zu treffen.
Eine nicht getroffene Entscheidung hat zwei Effekte:

Nichtentscheiden kostet Geld

Das Arbeiten mit Hypothesen führt zu einem hohen Grad an Unsicherheit und demotiviert die Mitarbeiter: Sie müssen nämlich befürchten, dass ihre Arbeit bei einer gegensätzlichen Entscheidung überflüssig wird. Hierbei ist noch nicht der finanzielle Schaden bedacht, der einem Unternehmen durch verzögerte Entscheidungen und dem daraus resultierenden Hantieren mit Hypothesen entstehen kann.
Ein Beispiel: Ein Team besteht aus neun Mitgliedern, jedes davon verdient im Schnitt 80.000 €/Jahr. Das Team wartet auf eine Entscheidung und beginnt, vorläufig mit einer Hypothese zu arbeiten. Nach sechs Wochen fällt der Vorstand eine gegensätzliche Entscheidung. Durch die verzögerte Entscheidung entstehen also folgende Kosten: 9 Mitarbeiter * 80.000 €/Jahr: 52 Wochen * 6 Wochen = 83.077 €. Innerhalb von sechs Wochen wurde somit das Jahresgehalt eines Mitarbeiters verbrannt und ein motiviertes Team erfolgreich in die Demotivation geführt.
Dieser finanzielle Schaden für das Unternehmen wird in Kauf genommen, weil im Hintergrund das Machtdenken dominiert. Entscheidungsgewalt abzugeben, führt beim Management zunächst zum Gefühl einer gewissen Ohnmacht, da Entscheidungsgewalt doch immer mit Macht gleichgesetzt wird.
Tatsächlich führt das Abgeben von Entscheidungsbefugnissen aber zu motivierten Teams und besseren Performances. Eine Win-Win-Situation: Der Manager darf sich schnellerer und performanterer Teams rühmen, während die Teams die Lust und Motivation am Arbeiten zurückgewinnen. Zudem kann sich der Manager als Führungskraft wieder auf seine eigentliche Aufgabe konzentrieren: auf das Führen!
Möchte man also demotivierte Teams vermeiden, Selbstorganisation fördern und Ressourcen nicht verbrennen, folgen daraus zwei logische Konsequenzen: Entweder trifft der Manager (besser daher der Entscheider) schnelle Entscheidungen, oder er entscheidet sich dazu, Entscheidungsgewalt ab- und dafür in die Teams zu geben. Einfacher lässt sich Motivation nicht erzeugen und Kostenverschwendung vermeiden! Also Manager, entscheidet euch, euch zu entscheiden!

Foto; CC0 Creative Commons – congerdesign, pixabay

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.

Best in Class: Was echte agile Manager und Leader ausmacht

Lunch mit einem langjährigen Freund – seines Zeichens Unternehmer und Business Coach. Nach den üblichen wechselseitigen Updates unvermittelt seine Frage: „Wie ist das jetzt mit den Managern? Die können da mit dem Agilen so einfach mit? Wie geht es den Kollegen dabei?“ Im Kopf gehe ich rasch die Karteikarten meiner Kundinnen und Kunden durch. Beobachtungen der letzten Jahre aus meinem mentalen Datenmeer werden durch meine Big-Data-Algorithmen ausgewertet. Und die Antwort überrascht mich selbst: Best in class sind langjährige Manager gehobener Führungsebenen, die ihr Handwerkszeug beherrschen und auf einer langjährig gepflegten Ethik aufbauen. Leider sind jene aus dieser Liga ohne langjährige Ethik-Vorgeschichte auch das andere Ende meiner Auswertung (Underpeformer, was den Score als Agile Manager & Leader anlangt). Im Gesicht meines Gegenübers Erstaunen. „Wie – nicht die Jungen?“
Nein. Das richtige Mindset ist schon wirklich wichtig. Aber fehlendes Handwerkszeug kann oft alles zunichtemachen. Menschen wollen geführt werden. Das ist ganz viel Haltungs- und Kommunikationsarbeit, Aufmerksamkeit und Disziplin. Und wer da noch mit den handwerklichen Aspekten von Management an der Überforderungsgrenze operiert, kommt ob der durch Agilität gesteigerten Erwartungshaltung gegenüber Führungskräften schnell ins Trudeln oder sogar zu Fall. Andererseits erlebe ich auch eine allzu große Abgeklärtheit als Hemmschuh für agiles Management und Führung. Die Neugier fehlt, das Sich-überraschen-lassen, die Experimentierfreudigkeit und das Zutrauen, dass nicht nur alles schon mal da war, sondern auch Neues entstehen kann. Im Großen und Ganzen kann ich also sagen:

  1. Alte Management-Hasen, die ihr Geschäft verstehen, über Ethik und Neugier verfügen sind eine gute Basis für einen agilen Management Kader und
  2. junge Führungskräfte, die über Managementtalent und eine exzellente Ausbildung verfügen, sind die Stars und überholen das Feld – sind dafür aber selten zu finden. Stars eben.

Jedenfalls lohnt es sich für Mitarbeiter, Vorgesetzte, Personalentwickler, Unternehmer und Peers, genau hinzusehen und die Edelsteine agilen Managements bzw. agiler Führung sorgsam von den begeisterten Strohfeuern oder So-als-ob-Tuern zu unterscheiden. Agilität hat auch was mit Sustainability – mit Nachhaltigkeit – zu tun. Und das ist ein Wesenszug, wenn nicht eine Charaktereigenschaft. So wie Agilität selbst.

Video: Die Rolle des Managers

Wird der Manager noch gebraucht oder nicht – das ist hier die Frage. Naja, eigentlich wurde diese Frage schon längst zugunsten der Manager beantwortet. Wir brauchen die Manager bzw. das Management. Warum? Die Antwort findet ihr hier in diesem Video.
Viel Spaß beim Anschauen — Boris
 

Warum ScrumMaster eskalieren müssen

Worum geht es eigentlich wirklich beim ScrumMaster-Dasein? Dazu gibt es so viele unterschiedliche Ideen wie ScrumMaster. Letztendlich geht es um die Performance des Teams und damit verbunden um die Lösung von Impediments. Wieder so weitläufige Begriffe – was bedeutet das konkret? Vielleicht bin ich einer der Facetten schon mal näher gekommen. Vor kurzem wurde in unserem internen Company Review in der Retrospektive die folgende Frage gestellt: Was hat uns im letzten Sprint produktiv gemacht?
Eine meiner ScrumMaster-Kolleginnen meinte, es seien vor allem die Eskalationen gewesen. Ihr Mentor habe einmal gesagt: “Jede Eskalation bewirkt etwas Gutes.” Sie habe es am Anfang nicht geglaubt, aber in der letzten Zeit habe sie ohne Ende eskalieren müssen und die Aussage habe sich bewahrheitet.
Für mich ein AHA-Moment. Vor allem deshalb, weil es Situationen gab, in denen ich – retrospektiv betrachtet – hätte eskalieren müssen und es nicht gemacht habe. Als ich diese Aussage meiner Kollegin hörte, wurde mir klar, wieso es so wichtig ist zu eskalieren und was passiert, wenn wir es nicht tun.

Es geht um das Team 

Bei der Eskalation geht es in Wirklichkeit darum, für das Team einzustehen (und falls es diesbezüglich Unklarheiten geben sollte: Das Team besteht aus den Entwicklern UND dem PO). Es geht darum, dem Team eine Stimme zu geben und sich vor das Team zu stellen. Damit üben wir nicht nur eine Schutzfunktion aus, wir zeigen dem Team auch, dass es so nicht geht. Wir zeigen den Teams, dass wir sie hören – wir hören die Stimme des Teams und verleihen ihr zusätzliche Kraft. Wir zeigen damit, dass sie nicht allein sind mit den Impediments, die ihre Produktivität behindern. Das wir nicht schon wieder Leute mit irgendwelchen wirren Ideen sind, die nicht hinter diesen Ideen stehen. Wir zeigen, dass wir bereit sind, für das Team und seine Anliegen mit unserer Person einzustehen. Nicht nur das, wir werden damit auch zum Vorbild und geben unseren Teams wieder die Kraft und den Glauben an sich selbst. Simon Sinek würde sagen, wir stellen den Circle of Safety wieder her und erfüllen als wahre Leader unsere ursprünglichste Aufgabe: Wir schützen die Herde.

Keine Angst vor dem Säbelzahntiger

Aber damit die edlen Gefühle nicht die Wahrheit verschleiern: Etwas zu eskalieren braucht eine Menge Courage. Wenn wir Pech haben, berührt der Gang zum Management die Angst, danach keine Stelle mehr zu haben. Und so archaisch und seltsam es in der heutigen Zeit anmutet, können wir uns manchmal noch immer so fühlen, als würden wir vor einem Säbelzahntiger stehen. Sich gegen jemanden zu wenden, der eine höhere hierarchische Position einnimmt oder die Macht hat, unser Projekt zu beenden, kann anscheinend noch immer unseren urzeitlichen Überlebensinstinkt triggern, der sagt: “Raus hier, nur raus!” Das ist insofern seltsam, als dass ich das Management in vielen Fällen aufgeschlossen und unterstützend erlebt habe. Letztendlich geht es darum, gemeinsam etwas zu bewegen und das geht bei größeren Impediments nur als Gesamtorganisation.
Gerade deswegen ist es aber auch die Aufgabe der ScrumMaster, zu eskalieren. Nicht nur weil wir dem Team eine Stimme geben (und gehört zu werden ist eines der Urbedürfnisse jedes Menschen), sondern auch um im Sinne des Scrum-Wertes „Mut” zu handeln. Denn Mut gibt uns die Kraft, die Dinge anzugehen, die uns wirklich im Weg stehen. Genauso wie es den Wert der Offenheit braucht, um  Impediments mit dem Management gemeinsam zu klären und eine bessere Situation zu erschaffen.
In diesem Sinne: Wenn Ihr Bauchgefühl nach einer Eskalation schreit – tun Sie es! Es ist auf jeden Fall mein Anspruch an mich selbst, auf diese Stimme zukünftig stärker zu hören und die Eskalationen durchzuführen, die mein Team braucht, damit es seinen Job noch besser ausführen und mehr für den Gesamterfolg seiner Firma beitragen kann als jemals zuvor.

Der Gewinner: Das mittlere Management

Letzte Woche hatte ich sie wieder: Die Diskussion darüber, dass Scrum und Kanban im Management noch immer als Methode der Softwareentwicklung oder des Projektmanagements angesehen werden. Den einen oder anderen Manager dieser Sorte gibt es sicher noch. Es ist sicher auch richtig, dass es den einen oder anderen Consultant gibt, der das, was in den funktionierenden Frameworks Scrum/Kanban ohnehin drinsteckt, wieder neu verpackt und als die neueste Managementmethode zu verkaufen versucht. All das ist vollkommen okay. Wo es einen Markt gibt, da wird es auch immer einen Anbieter geben.
Aber was können wir tun, damit das Management, oder besser gesagt die heutigen Führungskräfte, Scrum nicht als Bedrohung oder ein neues Übel sehen, das ihnen die Existenz abspricht? Niels Pfläging sagte in einem kürzlich auf InfoQ erschienenen Interview:

“The whole idea of command-and-control is wrong, and it is inseparable from management, the social technology. Management is command-and-control. It is at the heart of what organizations have to overcome to make transformation happen. Let me be clear: Management as invented by Frederick Taylor and his peers, with its explicit division between thinkers and doers, served us well during the industrial age. It was a brilliant idea 100 years ago! But the world has changed, and the Alpha way of organizing became a zombie technology. Management, quite simply, belongs onto the garbage heap of history.”

Das ist nicht hilfreich – es verschreckt. Denn wir brauchen Menschen, die andere führen. Wenn Organisationen größer werden als sieben Personen, dann werden die Dynamiken so komplex, dass Strukturen entstehen. Hier benötigen wir Menschen, die sich darum kümmern, dass die anderen sinnvoll und effizient miteinander arbeiten können. Das können wir Management nennen oder wie immer wir das wollen. Auch Morning Star, das Lieblingskind der Leute, die über selbstorganisierte Firmen schreiben, hat Manager – nämlich jeden einzelnen Mitarbeiter! Jeder ist dort ein Manager und es gibt bei Morning Star auch klare Regeln, die von den Menschen in dieser Organisation aufgestellt wurden. Eines ist jedoch klar: Das gegenwärtige, das so oft anzutreffende Management, das sich vom Geschehen in den Firmen entfernt hat, das Kreativität mit Bürokratie erstickt, das sich trotz Status, Boni und Dienstwagen langweilt und in den Burnout-Sinnkrisen versinkt: Dieses Management ist nicht hilfreich und wir müssen es befreien.

Auch Manager brauchen mal Anleitung

Marx zeigt mir jetzt sicher den Vogel: Die herrschende Klasse “befreien”? Ja! Denn sie sind es, die, ob wir es wollen oder nicht, derzeit die Regeln machen und sich wenig bis gar nicht gegen sinnlose Dinge auflehnen. In “Selbstorganisation braucht Führung” zeigen Dieter Rösner und ich, wie man als Manager wieder Spaß daran haben kann, sein Team zu führen. Doch reicht das aus? Ich glaube, wir brauchen eine ganz neue Diskussion, eine Diskussion, die dem Management zeigt, wie es seine Ziele, die es dank des Topmanagements erreichen muss, erreicht: Wie sie als Manager produktiver werden und dabei dennoch weniger arbeiten. Wie sie mit vielleicht vier Stunden Arbeit am Tag ihre Teams so steuern können, dass diese doppelt so produktiv werden. Wie sie mit dem Umstand des Skalierens von heutigen Projektgrößen so umgehen können, dass sie sich selbst als erfolgreich empfinden. Dann werden sie agil arbeiten und anfangen, daran mitzuarbeiten, die Gräben zwischen den Teams und sich selbst zu überwinden.
Wie man das macht? Indem ScrumMaster aufhören, ihre orginäre Aufgabe darin zu sehen, ein Team aus Softwareentwicklern zu steuern. Nach spätestens sechs Monaten sollte das Team (aus POs und Dev-Team) doch die meisten Aktivitäten selbst übernehmen können. Dann haben sich die ScrumMaster freigeschaufelt und können mit dem Management arbeiten. Behutsam. Wenn Ihr ScrumMaster seid: Zeigt ihnen, wie man mit dem Team arbeitet, wie man die Führung wieder übernimmt, anstatt sie an die ScrumMaster auszulagern. Vielleicht wollen die Führungskräfte dann selbst wieder einmal im Team mitarbeiten.
Wir müssen Managern zeigen, was sie selbst davon haben, agil zu werden. Dann werden sie es werden. Davon bin ich fest überzeugt.

Entscheidungsgremien: Erfolgsfaktor in agilen Projekten?

In einem unserer Projekte ging es darum, einen Systemverbund zu stabilisieren, der bisher durch eine fehlerverursachende Schnittstelle nur eingeschränkt genutzt werden konnte. Im Vorgängerprojekt sollten die beiden Systeme zusammengeschalten werden – es wurde klassisch abgewickelt und musste schließlich wegen Erfolglosigkeit gestoppt werden. Wegen der guten Erfahrungen mit Scrum in anderen Projekten lag es nahe, im zweiten Anlauf den agilen Ansatz zu wählen – hier kam ich ins Spiel. Und bevor ich weitererzähle, hier mein Appell gleich zu Beginn: Seid bereit, das Management aktiv an die Hand zu nehmen. Sie werden es euch danken!

Klassische Wünsche im agilen Rahmen

Schon in der Setup-Phase wurde klar, dass im vorherrschenden Umfeld ein tatsächlich agiles Projektvorgehen eine wahre Herausforderung werden wird. Erstens lastete hoher Druck auf dem Projekt, die Systeme endlich stabil zu bekommen und jede Form von Mehrkosten zu vermeiden. Zweitens wurde das Projekt noch mit einem zusätzlichen Gesamtprojektleiter, der übergeordnet die Verantwortung für das Projekt trug, besetzt. Und drittens hatten die entscheidenden Personen, allen voran das Top Management in Form eines Lenkungskreises, alles andere als agile Ansätze im Sinn. Beginnend mit der Forderung nach einem Reporting mit dem Fokus auf Budget und Zahlen kam auch schnell die Frage nach dem „großen“ Projektplan über die angesetzten 6 Monate auf. Was wird bis Datum XY geliefert und viel wichtiger: Was kostet dieses Unterfangen?

Ein Schritt zurück, um vorwärts zu kommen

Um dem Management einen groben Projektplan zu bieten, erarbeiteten die Product Owner mit Unterstützung der ScrumMaster einen physischen Releaseplan mit Post-Its. Dabei planten sie nach dem Eisberg-Prinzip: die kommenden Sprints detailliert und die zukünftigen Sprints auf höherer Ebene. Mit diesem Instrument konnten sie nun auch auf Gesamtprojektsicht einen Plan vorweisen. Anfangs wurde das noch skeptisch beäugt und als schwammig kritisiert. Das größte Hindernis war dabei wohl, dieses Nichtvorhersagen-Können zu akzeptieren. In traditionellen Projekten gibt man sich von Anfang an der Illusion hin, alles bis zum letzten Tag hin genauestens geplant und damit im Griff zu haben. Den Schritt zurück zu machen und zu akzeptieren, dass der Plan sehr wahrscheinlich so nicht eintreten wird, ist schwierig, aber notwendig. Es gelang in diesem Projekt und im Laufe der Zeit entwickelte sich der Releaseplan zu einem zentralen Planungsinstrument.
IMG_0464 Kopie 3

Sehen, worüber wir reden

Trotz des Releaseplans traf das Management in seinem Lenkungskreis (in dem nur der Gesamtprojektleiter, aber kein Product Owner oder ScrumMaster vertreten war) Entscheidungen, die mehr oder weniger große Auswirkungen auf unser Projekt und unseren Releaseplan hatten. Jedes Mal passten die Product Owner resigniert den kompletten Releaseplan an die neuen Entscheidungen an. Bei der x-ten Diskussion über Inhalt und Budget nahmen wir ScrumMaster schließlich das Zepter in die Hand. Wir forderten das Management auf, seine Diskussionen zu neuen Entscheidungen direkt mit uns – den ScrumMastern und Product Ownern – vor unseren Artefakten zu führen und Befürchtungen mit uns zu besprechen. Um es kurz zu machen: Das war die beste Entscheidung, die wir je treffen konnten. Noch nie zuvor hatte es zwischen dem Management (dem Lenkungskreis) und den Projektverantwortlichen einen so regen Austausch über den Scope und das Budget des Projekts gegeben. Alle Unklarheiten wurden geklärt und wir erzielten ein gemeinsames Commitment. Die Teams hielten dieses Commitment auch ein und lieferten.
Im Nachhinein hat es über den Erfolg des Projekts entschieden, dass das Top Management eingebunden wurde und sich mit den Verantwortlichen direkt und regelmäßig ausgetauscht hat. Wie oft hatten wir in der Vergangenheit das Gefühl gehabt, dass reines „Management by Desk“ praktiziert wurde, ohne zu wissen, wie es um das Projekt wirklich bestellt war. Wie oft hatte das Projektteam Angst vor folgenschweren Entscheidungen im Lenkungskreis. Angst davor, dass das Projekt gestoppt werden könnte, trotz erster nachweisbarer Erfolge. Angst vor Budgetkürzungen, die uns den notwendigen innovativen Freiraum nehmen könnten.
Daher nochmals mein dringender Appell: Nehmt euer Management an die Hand! Führt es zu den Artefakten und trefft dort mit den richtigen Personen die richtigen Entscheidungen — gerade und vor allem in traditionell geprägten Unternehmen.

Generation Y: Wir wollen unser Leben genießen

An vielen Ecken hört man es: die “Generation Y” will anders arbeiten. Die jungen, gut ausgebildeten Menschen zwischen 20 und 30 wollen einfach nicht mehr so hart rackern wie die Generation vor ihnen, heißt es. Und andererseits wissen die Vertreter der “Generation Me” (auch als Baby Boomer bezeichnet) nicht, wie sie im Job mit dieser Generation umgehen sollen. Nähern wir uns dem Thema Work-Life-Balance mit der Brille der “Generation Me”, dann verfällt man schnell der Idee, dass es neben der Arbeit noch etwas anderes geben sollte. Neben der Arbeit. Mich hat diese Trennung von Arbeit und Freitzeit immer gewundert. So als hätte man zwei Leben, als könne man jede Minute zweimal ausgeben: privat und beruflich.

Generation Me: erfolgreich krank

Woher kommt das Bedürfnis bei Menschen der Generation, der auch ich angehöre, nach dieser Work-Life-Balance? Vielleicht weil wir den Wohlstand, das zweite und das dritte Auto, damit erkauft haben. Wir haben sehr viel und sehr hart gearbeitet, denn harte Arbeit ist unser Statussymbol. Gleichzeitig haben wir nicht nur finanzielle Erfolge und Wohlstand erarbeitet: viele von uns haben sich im wahrsten Sinne des Wortes krank gearbeitet. Ich gebe es zu, auch ich bin bei zwei bis vier Flügen pro Woche und durch das ständige Schlafen in Hotels nicht so fit und gesund, wie ich es sein könnte. Auch die Zeitungen und Magazine sind voll von Berichten über unsere schwer erarbeiteten Zivilisationskrankheiten. Wäre ich, so wie viele andere, auch mit 30 Vater geworden, wäre meine Tochter oder mein Sohn jetzt schon 15 und würde sich zu Recht fragen, ob dieses Kaputtarbeiten irgendeinen Sinn hat und ob er oder sie das will. Ihre Antwort wäre natürlich: “Nein!” Und die Vertreter der Generation Y haben natürlich recht, sie müssen es auch gar nicht mehr.

Langweilige Paradiese

Ihre Eltern haben in vielen Unternehmen bereits die vollkommenen Paradiese geschaffen. Dort sind die Arbeitszeiten festgezogen, alles ist geregelt und wer freiwillig mehr leisten will, wird schief angeschaut (natürlich gilt das nicht in jedem Unternehmen). Gleichzeitig wird die Alterspyramide die Gehälter steigen lassen. Bei einer momentanen Geburtenrate von 1,34 in Österreich und der Tatsache, dass die Baby Boomer allmählich in Massen in Rente gehen, wächst der Wert der Arbeitskraft ins Gigantische.
Gleichzeitig sind die großen Betriebe so durchgestylt, dass die Folge nur noch verwöhnte Langeweile sein kann. Wieso ich das sage?
Ein Beispiel: Ich hatte einen Bewerber zum Interviewtermin, der aus der Automobilwirtschaft kommt. Heute 30 Jahre alt, Doktor der Soziologie, entscheidet er sich bewusst gegen die 35-Stunden-Arbeitswoche in einem großen deutschen Automobilkonzern. Die Arbeit dort ist nicht etwa zu anstrengend, sondern zu langweilig. Dort sind die Arbeitsabläufe geklärt, die Projektmanager verbringen ihre Zeit in stundenlangen Meetings, in denen doch nichts Wesentliches passiert, und der Effekt, also ihr Beitrag, ist gleich Null. Die Arbeit wird in Großunternehmen bzw. -konzernen sowieso von Dienstleistern erledigt – wie es Putzerfische bei einem Wal tun. Etwas bewegen, Sinn stiften und sich beweisen, dabei vielleicht auch scheitern und lernen, ist in diesen Unternehmen schwer geworden.
Doch schauen wir mal dorthin, wo die eigentlichen Veränderungen derzeit passieren – nein, nicht bei Goolge und Co. Ganz ehrlich, eine Übermutter als Arbeitgeber, die mit ständig verfügbarem Essen, Massage und 1000 anderen Annehmlichkeiten aufwartet, wo Geld keine Rolle spielt und man machen kann, was man will, erzeugt kein Umfeld, in dem Innovation aufkommen kann. Der Spieltrieb wird angefacht, sicher, und es ist bestimmt ultracool, bei Google zu arbeiten. Aber mal ehrlich, welche Innovationen kamen von Google? Eine einzige! Ihre geniale Suche. Alles andere ist nachgebaut und bestenfalls optimiert. Google geht gerade den Weg der meisten großen Unternehmen: die Kreativität ist dahin, man beginnt, die Konkurrenz und die neuen Ideen zuzukaufen, statt selbst tolle Dinge zu machen.

Neuer Realismus in der Arbeitswelt

Wo ist also das Neue für die Arbeitswelt? Es beginnt immer am Rand. Da ist etwas Neues zu beobachten. Wahrscheinlich werden jetzt viele Trendforscher sagen: “alter Kaffee”, aber ich nehme gerade etwas vollkommen Neues wahr. Kleine Firmen, die weltweit verteilt sind und dank neuer Kommunikations- und Arbeitsinfrastrukturen wie Google Hangout, Skype und GitHub Bedingungen geschaffen haben, mit denen man als kleines Team weltweit miteinander arbeiten kann, beginnen tatsächlich ganz anders zu arbeiten.
Da erzählen dann diese merkwürdigen Menschen aus der Generation Y, dass sie zuhause in ihren Wohnzimmern oder kleinen Arbeitszimmern sitzen, und gleichzeitig bei ihrer Familie sein können (Beispiele für diese Firmen sind: WordPress.com oder Bufferapp). Die Firmenmitglieder treffen sich ab und zu, um sich auch mal zu sehen, aber die Arbeit wird remote, verteilt und dezentralisiert gesteuert. Es entstehen dabei sogar neue Taskmanagement-Systeme, die tatsächlich ein neues Konzept verfolgen: IDoneThis. Sie zeigen, was gelungen ist, und nicht das, was man hätte tun sollen. Das ist eines der ersten Systeme, das mit einer vollkommen anderen Sicht entwickelt wurde. Hier ist es nicht vorgesehen, jemand anderem zu sagen, was er zu tun hat. Jeder sagt – offen – etwas darüber, was er getan hat. Ziemlich verrückt aus der Sicht der Generation ME. Work-Life-Balance spielt für die Generation Y keine Rolle mehr. Sie haben schon lange einen Weg gefunden, freier und viel realistischer mit ihrem Leben umzugehen.

Skalierung aus der falschen Richtung

Wer darüber nachdenkt, wie man Scrum in großen Projekten macht, fängt meistens mit dem klassischen Bild an: Der Product Owner erstellt das Backlog und dann wird es priorisiert … bla, bla, bla – das ist euch allen mittlerweile klar. Wenn ich aber darüber nachdenke, wo die meisten Features herkommen, wer die Fehler findet, wer sich im Review mit dem Kunden auseinandersetzt, dann wird schnell klar, dass die meisten Backlog Items von den Entwicklungsteams geschrieben werden. Sie müssen sowieso von ihnen entwickelt werden. Schaut man in den Design Thinking Prozess von IDEO, dann wird auch dort sehr deutlich, dass das Entwicklungsteam sich selbst überlegt, was der Kunde am Ende benötigt.

Die Entwicklungsteams selbst erstellen die Backlog-Einträge und priorisieren sie auch selbst. Obwohl ich mir das Video über IDEOs Shopping Cart bestimmt 100 Mal angeschaut habe, hat es nicht wirklich Click gemacht. Mir fällt sogar auf, dass ich in jedem Training immer wieder sage, dass das Team die eigentlichen Backlog Items schreibt, aber – wie gesagt – das Klick, das Heureka, fehlte. Dabei lag es schon seit Jahren auf der Hand. Der Product Owner war in den meisten Projekten damit überfordert, wissen zu müssen, was das richtige Feature ist. Er weigerte sich auch oft, das Backlog zu priorisieren und wusste häufig nicht, ob die Kunden das Feature wirklich wollen. Er brauchte immer das Entwicklungsteam, damit er die richtigen Entscheidungen treffen konnte. So weit so schön, wir haben dann immer tolle Erklärungen gefunden, warum der Product Owner, obwohl er keine Ahnung von der Materie hat, dem Entwicklungsteam sagen müsste, was es zu entwickeln hätte.

Dieses Bild hat ausgedient – Skalierung funktioniert so nicht!

Das geht nur so lange gut, wie man nicht skalieren muss. Dann fällt das ganze Kartenhaus zusammen – in einem solchen Fall mit Product Ownern zu arbeiten, die sich inhaltlich nicht auskennen und daher keine Entscheidungen treffen können, führt zu den gleichen Effekten wie im klassischen Projektmanagement: niemand will Entscheidungen treffen. Der Klick kam bei mir, als mich ein Kunde etwas fragte. Dafür bin ich ihm wirklich dankbar.
In diesem Projekt hatten wir es mit 150 Beteiligten – Wissenschaftlern, Entwicklern, Programmierern, Managern – zu tun. Wir rangen mit tausenden kleinerer und größerer Probleme, und wir machten das durch das Aufstellen von Backlogs transparent. Weil das Management die Sicht auf das Ganze haben wollte (was verständlich und nachvollziehbar ist), tauchte die Frage auf, ob man denn so etwas wie ein Master Backlog habe und ob nicht mit entsprechenden Filter-Funktionen in JIRA sichergestellt werden könne, dass alles wirklich abgearbeitet wird? Die gängige Erklärung ist: Sicher, das geht! Das findet sich auch in allen vorhandenen Bildern zur Skalierung von Scrum. „Aber wieso eigentlich?“, fragte ich meinen Kunden. Das Master Backlog sei doch keine Input Queue, sondern bilde nur die Realität ab. Wir müssten unbedingt vermeiden, dass der Product Owner des Master Backlogs dieses priorisiert. Die Verwunderung war groß, denn jedes Bild in Scrum suggeriert, dass die Macht beim Product Owner liegt. Er füllt den Sprint. Der Product Owner kann dieses Backlog aber gar nicht in eine korrekte Reihenfolge bringen. Es sind zu viele Einträge. Der Product Owner müsste bei einem großen Projekt gottgleich alles beantworten können. Solche Typen gibt es, sie sind aber sehr selten und ihr Gewicht wird in Gold aufgewogen.
Gleichzeitig gibt es dennoch – ob der Product Owner es kann oder nicht – zwei Fragen zu lösen:

In großen Projekten ist darüber hinaus drittens auch noch die Frage entscheidend, ob man überhaupt alle Abhängigkeiten zwischen den Teams berücksichtigt hat.
Können die Product Owner diese Fragen nicht selbst lösen, dann müssen sie wohl oder übel die Teams selbst fragen. Doch was, wenn die Product Owner es ihren Teams nicht zutrauen, diese Fragen zu beantworten? Sehr oft haben die Product Owner damit auch recht. Häufig gibt es externe Kollegen in den Teams und die wissen gar nicht all das, was die Product Owner wissen. Sie können es noch gar nicht wissen. Dann bleibt nur, die wenigen Experten in den Teams zu fragen, und schon hat man einen Infinite Loop geschaffen.

Mit Selbstorganisation hat das gar nichts zu tun – nur mit noch mehr Kontrolle

Der Wahn, alles müsste transparent und rückverfolgbar sein, auch nach Monaten oder Jahren müsste noch klar sein, welche Zeile Code von welchem Entwickler geschrieben wurde – dieser Wahn ist heute von vielen Entwicklern umgesetzt worden. Dank JIRA, Bamboo, Team Foundation Server und anderen Tools lässt sich ja alles rückverfolgen. All das hat zu noch mehr Kontrolle und noch weniger Selbstverantwortung der Kollegen geführt. Das Schreiben eines JIRA-Tickets ist einfach – da kann ich als Teammitglied schnell das Denken abschalten, denn es wird ja von einem anderen entschieden, ob ich dann daran arbeiten soll. Wieder wird die Verantwortung nach oben delegiert. Die Entscheidung liegt erneut beim Product Owner, der aber nicht für jede Kleinigkeit geradestehen kann. Wo kommt dieser Anspruch eigentlich her? Denn das sollte er in Scrum gar nie können. Nonaka und Takeuchi hätten nicht beschrieben, wie man einen interdisziplinären, cross-funktionalen Management-Prozess entwickeln kann (den Jeff Sutherland zu Scrum ausgebaut hat), wenn sie dabei gleichzeitig an volle Kontrolle gedacht hätten.
In vielen Scrum-Skalierungsansätzen wird aber genau das Gegenteil propagiert. Was mich dabei erstaunt: In Deutschland sind die Modelle, die das Top-Down-Prinzip in der Skalierung von Scrum erklären (SAF) beliebter als in den USA. Hier werden mehr Bücher dazu gekauft, als in den USA (sagt mein Verlag). Da ist was faul. Übrigens funktioniert es auch nicht. Was gut funktioniert: Skaliert wird durch Abgeben der Verantwortung bei gleichzeitiger Standardisierung, und die Berater verdienen damit viel Geld.
Wenn die Backlogs nicht vom Product Owner und seinen Product-Owner-Kollegen aufgestellt und in die „richtige“ Reihenfolge gebracht werden, wer macht es dann? Genau, die Entwicklungsteams! Skalierung ist dann ganz einfach, denn diese Kollegen wissen sehr gut, was als Nächstes getan werden muss. Sie wissen, ob es heute sinnvoller ist, den Defect zu fixen, oder das nächste Feature anzufangen. Sie haben den Kontakt zu den Usern und können viel besser verstehen, was dort gebraucht wird. Können wir aber den Teams trauen? Wie verhindern wird dann Wildwuchs? Wie verhindern wir, dass Dinge gemacht werden, die niemand braucht? Wie verhindern wir, dass die Entwickler nicht businessgetrieben arbeiten, sich in Lösungen verfangen, einer interessanten Idee nach der anderen nachgehen?
Meine provokante These: Lassen wir doch einfach zu, dass es Schwund und Fehlentwicklungen gibt. Es ist viel billiger, als alles überwachen zu wollen. Die teuren Management-Runden, in denen sich Product Owner erklären lassen, was das Richtige ist, ergeben wenig Sinn. Scrum selbst ist das Korrektiv. Wenn eine Entwicklungsmannschaft nicht liefert, keine Lösungen, keine Ergebnisse, keine neuen Erkenntnisse, wenn sich die Entwicklungsteams ums sich selbst drehen, dann wird das doch im Review sichtbar. Dann kann das Management doch eingreifen. Aber es in die Teams hinein zu kontrollieren, das funktioniert nur bedingt. Dabei wäre das sogar möglich: Wer Qualitätsmanagement als Lernprozess versteht und gefundene Fehler nicht als Versagen von Menschen, sondern als gegebene Realität sieht, wer vergossene Milch als Verlust abschreibt und nach vorne schaut, der kommt auch damit klar, dass Nicht-Liefern eine Information ist. Eine Information ans Management, dass gehandelt werden muss.
Aber das erklärt noch nicht, wie Firmen nun selbstorganisiert skalieren können, oder doch? Ich denke schon! Der Trick besteht darin, sich selbst steuernde, cross-funktionale Teams zu etablieren, die innerhalb eines Kontexts nur auf eine einziges Ziel hinarbeiten können. Dieses Ziel wird durch die Vision geschaffen, doch der Weg dahin bleibt den Teams überlassen. Die Teams müssen sich standardisierte Schnittstellen überlegen. So wie das in der Bauindustrie und in der Elektroindustrie doch auch funktioniert. Diese Übergaben werden trainiert, geschult und zertifiziert. Diese Standards zu verändern ist mühsam, aber so können funktionierende, vielleicht nicht immer perfekte Lösungen gefunden werden. Die Rahmenbedingungen werden von der Organisation gesteckt und die Teams so lange darauf geschult, bis sie die Rahmenbedingungen verstanden haben. Teams, die liefern, werden belohnt und die anderen werden lernen, was erfolgreich ist und werden es kopieren. Gleichzeitig überlässt man mehr und mehr Verantwortung den kleineren Funktionseinheiten, den Teams. Ist das perfekt? Ich weiß es nicht, aber Amazon und Google, Facebook und 3M fahren mit diesem Ansatz ziemlich gut.

Multikulti – vom Umgang mit Internationalität in Projekten

Wir reden immer davon, dass es bei verteilten, global verstreuten Teams um das Verständnis geht, dass Amerikaner eine andere Kultur als die indischen Kollegen haben (Stichwort Skalierung). Es geht also immer darum, die unterschiedlichen Nationalitäten im Blick zu haben und deren Kultur zu verstehen. Bei meiner Arbeit mit internationalen Teams bin ich zu einer anderen Schlussfolgerung gelangt: Internationale Firmen haben selbst eine Kultur. Sicher, es gibt Einflüsse – Lokalkolorit. Aber die Kultur eines Unternehmens ist viel stärker als die des Landes.
Schaut man genau hin, dann sind die auftretenden Probleme oft nicht der unterschiedlichen Landeskultur zuzusprechen, sondern der Tatsache, dass sich zugekaufte Firmen nicht in den internationalen Konzern eingliedern lassen. Klar, Amerikaner ticken ein wenig anders als Deutsche – aber dass die Firma zugekauft wurde, eine andere Firma war, eine andere Art des Umgangs miteinander hatte, ist viel wichtiger und hat größeren Einfluss auf das Selbstverständnis des Einzelnen in einem Unternehmen als seine Nationalität.
Besonders deutlich wird das, wenn man Scrum in Hardware- oder Medizintechnik-Projekten einführt und cross-funktionale, multidisziplinäre Teams aufbauen will: Da bemerkt man plötzlich, dass nicht nur Tester und Entwickler in einer Abteilung unterschiedlich funktionieren, sondern dass es vollkommen andere Weisen gibt, die Welt wahrzunehmen. Wenn Ingenieure auf Biologen oder Chemiker treffen, wenn Metallfacharbeiter sich mit Elektrikern unterhalten sollen, wenn Grafiker sich mit Softwareentwicklern unterhalten, dann treffen die verschiedensten Weltbilder aufeinander.
Das wäre ja nicht weiter tragisch, wenn sich alle darüber im Klaren wären, entsprechend viel Zeit für den gemeinsamen Abgleich einplanen würden und das Management verstehen würde, dass es hier zu Konflikten kommen muss. Doch auch das Management hat natürlich seine blinden Flecken. Einige von ihnen waren vielleicht Ingenieure und sehen die Welt von ihrer Warte, andere sind Soziologen, Biologen oder Chemiker. Da wird oftmals gar nicht verstanden, was der andere meint oder warum er diesen und nicht jenen Zugang wählt.
Das alles sind lösbare Probleme und genau das ist die Aufgabe von ScrumMastern. Doch was passiert jetzt: Diese Teams sollen sich nicht nur aus unterschiedlichen Disziplinen, sondern auch noch aus unterschiedlichen Nationen an unterschiedlichen Standorten zusammensetzen. Vielleicht aus der Not heraus, weil es gar nicht anders geht. Nun wirken oft die Kräfte des Separatismus: Die Vertreter jeder Disziplin verstehen sich untereinander besser als mit den anderen. Sind diese auch noch verteilt, entsteht schnell ein Abwehrhaltung gegen die Kollegen am eigenen Standort, wenn dieser von einer anderen Disziplin ist und in der Minderheit. Oft nimmt man sich nicht die Zeit, sich wirklich kennenzulernen. Die ScrumMaster haben oft gar keine Chance – denn sie sind nicht vor Ort, sie steuern ihre Teams mit Hilfe von Tools und einem Video Conference Call. All das sind wirklich harte Bedingungen. Es wird noch schwerer werden, garantiert. Es wird immer öfter zu Konstellationen dieser Art kommen.
Doch eines wird sich durchsetzen: der Wille zu liefern. Der Druck auf Unternehmen, die so arbeiten (müssen), wird so hoch werden, dass sie sich etwas einfallen lassen werden. Sie werden Teams temporär zusammenziehen, sie werden wieder Menschen nahe zusammenbringen. Wenn Firmen wie Google und Facebook das können, wenn Apple in Cupertino ein Gebäude genau aus diesem Grund heraus baut, damit alle zusammen sind, dann sind diese Firmen schon längst wieder auf dem Weg, die Internationalisierung zugunsten der Produktivität zu reduzieren.
Die Voraussetzung dafür, dass dies gelingen kann: Eine gute Führung. Separatismus, das Auseinanderbrechen von Teams, kann sehr einfach verhindert werden – durch gute Führung. Durch eine Führung, die innerhalb des Teams, innerhalb der Abteilung und innerhalb der Firma die „gleiche“ Kultur schafft. Die gemeinsame Firmenkultur ist in der Lage, die Menschen zum Zusammenarbeiten zu bringen und Ungleichheiten vergessen zu machen. Die Aufgabe von Führungskräften wird schwerer werden. Scrum kann die Themen schneller ans Licht bringen. Lösen müssen es die Beteiligten zusammen.