• Entwicklung/Architektur
  • Methoden
  • Programmiersprachen
• Betrieb
  • Datenbanken
  • Server
  • IT-Security
  • Speicher
  • Netzwerke
  • Virtualisierung
  • Verfügbarkeit
  • Künstliche Intelligenz
• Management und Recht
  • Projektmanagement
  • Digitalisierung
  • IT-Recht
  • IT-Selbständige
• Aktuelles
• Termine
• IT-Jobs

☰

• Entwicklung
• Betrieb
• Management und Recht
• News
• IT-Jobs
• Newsletter

Sven Röpstorff & Robert Wiechmann 22. Januar 2019

Die 5 Scrum-Werte in der Praxis – Im Prinzip ganz einfach

Selbstverpflichtung (Commitment)

"Realize that the hardest step in achieving anything is making a true commitment."
(Tony Robbins)

Beispiel 1:

Kurz nach der Veröffentlichung eines neuen Produkts gibt es ein massives Problem am Wochenende. Ein Team-Mitglied, das als erstes auf das Problem aufmerksam geworden ist, informiert die anderen Team-Mitglieder darüber. Dieses Team-Mitglied saß schon seit einiger Zeit am Arbeitsplatz und versuchte sich an unterschiedlichen Lösungen. Aufgrund der Dringlichkeit beschloss ich als Scrum Master, auch in die Firma zu fahren und Hilfe anzubieten.

Als ich ankam, stellte ich zu meiner Verwunderung und Freude fest, dass noch weitere Team-Mitglieder eingetroffen waren. Einige unterhielten sich angeregt und versuchten die Ursache zu ermitteln, andere kümmerten sich um etwas zu Essen und in der Küche fand ich jemanden vor, der gerade dabei war, alle mit Getränken zu versorgen. Das Aufspüren des Fehlers und die Behebung zog sich über mehrere Stunden hin. Auch wenn einige der Team-Mitglieder nicht unmittelbar helfen konnten, blieben sie vor Ort und unterstützen dort, wo es eben ging. Für alle überraschend kam auch der Abteilungsleiter im Laufe des Geschehens dazu. Auch wenn das schon bemerkenswert war, setzte er das Team nicht unter Druck, sondern bot seine Hilfe an. Er übernahm dann mit mir die Kommunikation an wesentliche Stakeholder und stärkte den Rücken des Teams durch seine Anwesenheit. Über diesen Schulterschluss mit dem Team wurde noch lange nach dem Vorfall anerkennend vom Scrum-Team gesprochen.

Beispiel 2:

Kürzlich hatte sich die Aufgabenstellung meines Scrum-Teams etwas verändert. Bisher gehörte die Beratung anderer Teams bezüglich der Architektur und der Nutzung des Frameworks mit dazu. Die Abteilung hatte sich jedoch neu aufgestellt und es waren Framework-Experten in die jeweiligen anderen Teams integriert worden, die die Unterstützung durch mein Team obsolet machten. Mein Team sollte sich zukünftig verstärkt um die Weiterentwicklung des Frameworks kümmern. Die veränderte Aufgabenstellung war mit dem Team abgesprochen worden und alle Team-Mitglieder freuten sich sehr darauf. Auch die Product Ownerin war zufrieden, konnte sie doch endlich mit realistischen Sprint-Zielen arbeiten, nachdem die unkalkulierbare Beratung weggefallen war.

In den Daily Scrums stellte sich mit der Zeit jedoch heraus, dass es zwei Team-Mitglieder gab, die nichts zum Sprint-Ziel beitrugen. Anfangs fiel es nicht auf, weil sie sich hinter "Restarbeiten durch die Aufgabenumstellung" versteckten, aber dann wurde klar, dass sie nach wie vor die Beratungstätigkeit für andere Teams wahrnahmen. Sie sahen die anderen Teams nicht in der Lage, "ihr" Framework richtig zu nutzen und waren mehr damit beschäftigt, andere Teams zu kontrollieren, als ihr eigenes Team bei der Erreichung des Sprint-Ziels zu unterstützen. Dieses fehlende Commitment zum Team und auch zum Sprint-Ziel führte natürlich zu massiver Unzufriedenheit innerhalb des Teams aber auch von Außenstehenden mit dem Team.

Fazit

Am ersten Beispiel wird sehr schön klar, wie sehr Einigkeit und Geschlossenheit eines Teams sowohl nach innen aber auch mit Führungskräften positive Kräfte freisetzen können. Diesen Effekt erzielt man aber nur, wenn jeder Einzelne seinen Teil dazu beiträgt. Ist dies nicht der Fall, sind wir schnell in der Situation, die im zweiten Beispiel beschrieben wurde. Unter Selbstverpflichtung verstehen wir die persönliche Verantwortungsübernahme der Team-Mitglieder eines Scrum-Teams. Wir erwarten von unseren Teams ein echtes Bekenntnis zum entwickelten Produkt, den beteiligten Personen und dem übergeordneten Projektrahmen.

Commitment erzielt man nicht einfach durch Verordnung. Wichtig ist, geeignete Rahmenbedingungen zu schaffen, Gespräche zu führen und dafür zu sorgen, dass die Team-Mitglieder sich wohlfühlen und sich in die Lage versetzt fühlen, selbst gerichtet zu agieren. Dann kann Selbstverpflichtung von innen heraus entstehen.

Mut

"Was wäre das Leben, hätten wir nicht den Mut, etwas zu riskieren?"
(Vincent van Gogh)

Beispiel 1

In einem Linienteam konnte ich einmal folgende Situation beobachten: Das Team hatte zwei Räume zur Verfügung, es gab keine festen Plätze, sondern jeder arbeitete dort, wo gerade Platz war. Mir fiel auf, dass fast alle Team-Mitglieder meistens gemeinsam in einem der beiden Räume arbeiteten und ich führte es zunächst auf eine gute und intensive Zusammenarbeit zurück. Dann bemerkte ich jedoch, dass immer das gleiche Team-Mitglied allein im anderen Raum saß. Ich hatte in diesem Team keine Rolle z. B. als Scrum Master, also fragte ich bei Gelegenheit ein Team-Mitglied nach dem Grund. Die Antwort fiel kurz und knapp aus: "Der stinkt! Wir haben ihm ein Duschgel hingestellt, aber er hat die Botschaft nicht verstanden." Ich war überrascht und fragte nach: "Habt ihr denn mal mit ihm darüber gesprochen? So etwas kann man ja aus der Welt räumen, vielleicht ist es ihm gar nicht bewusst." Das Team-Mitglied blickte zu Boden: "Weißt du, bei solchen Themen tue ich mich immer schwer. Wie kann ich so etwas sagen, ohne den anderen zu verletzen? Ich bin meistens sehr direkt." "Das verstehe ich," entgegnete ich, "aber versetz dich doch mal in seine Lage. Er merkt doch sicher, dass ihr euch zurückzieht. Wenn du in seiner Lage wärst, wie würdest du gern auf die Situation aufmerksam gemacht werden? Nimm doch mal deinen Mut zusammen und sprich ihn genau so darauf an, wie du es dir an seiner Stelle wünschen würdest." Ich war gespannt, was passieren würde und beobachtete die Situation aus der Distanz weiter. Tatsächlich bemerkte ich bereits nach kurzer Zeit, dass das Team jetzt beide Räume gleichermaßen nutzte und sich die Stimmung deutlich verbessert hatte.

Beispiel 2

Bei einem Auftrag stand ich von Beginn an in engem Austausch mit dem Geschäftsführer. Schon in den ersten Gesprächen fiel mir auf, dass er über wenige seiner Mitarbeiter Gutes, aber über eine Person überhaupt nichts Positives zu sagen hatte. Während unserer Unterhaltungen über die Scrum-Teams schweifte er bei diesem Team-Mitglied laufend ab. Wenn es etwas gab, was es von seiner Seite aus zu kritisieren gab, stand dieser Mitarbeiter stark in seinem Fokus. Nachdem ich mir die Geschichten ein paar mal angehört hatte, konfrontierte ich ihn mit der Frage, warum er nicht direkt mit diesem Mitarbeiter spreche? Im Grunde war mir klar, warum er es nicht tat und er hatte auch Antworten auf die Frage parat. Ich spiegelte ihm im Anschluss meine Wahrnehmung der Situation und machte ihm deutlich, dass es eine selbst erfüllende Prophezeiung sei: So wie er den Mitarbeiter sehe, könne dieser nichts richtig machen und die Ergebnisse und das Engagement seien, egal was diese Person täte, unzureichend. Der Mitarbeiter dagegen spüre genau das und bestätige durch seine zunehmende Demotivation und Unsicherheit die Perspektive des Geschäftsführers laufend. Diese Beziehung hatte einen direkten Effekt auf das Scrum-Team, da die Stimmung und Leistung des Mitarbeiters darunter litt.

Fazit

Unserer Meinung nach gedeiht Mut, wo die Arbeit im Team von Offenheit und Respekt geprägt ist. Es geht um den Mut, die Wahrheit zu sagen, Fehler zu riskieren und auch unbequeme Wege zu gehen. Unangenehme Gespräche zu führen und konstruktive Kritik an Kollegen oder der Organisation zu üben gehören ebenso dazu. Offenheit und Feedback als weitere agile Werte sorgen dafür, dass der Mut nicht in seine negative Seite ausschlägt und in Übermut und Selbstüberschätzung ausartet. Der Scrum Master kümmert sich dabei um die nötige Balance. Auch der Mut, in entsprechenden Situationen "Nein" zu sagen, muss aktiv gefordert und gefördert werden. "Ich muss dich mal kurz sprechen" könnte eine Aufforderung eines Vorgesetzten sein, die aber eventuell den Arbeitsfluss eines Team-Mitglieds stört. Derjenige sollte dann den Mut haben, offen zu sagen, dass es aktuell unpassend ist und er diese Arbeit beenden wird, statt sie zu unterbrechen und später neu damit zu beginnen (vgl. Fokussierung). Mit einer Antwort wie zum Beispiel: "Ich benötige noch 20 Minuten, die Sache hier fertigzustellen, ich bin dann gleich bei dir", ist dann häufig beiden geholfen. Dies passt auch wunderbar zu unserem nächsten Wert.

Offenheit

"What the world needs most is openness: Open hearts, open doors, open eyes, open minds, open ears, open souls."
(Robert Muller)

Beispiel 1

Ein wichtiges regulatorisches Projekt mit einem sehr straffen Zeitplan, auf das der Vorstand ein besonderes Auge hatte: Bis kurz vor dem Review hatte mein Team versucht, das Sprint-Ziel noch zu erfüllen, aber letztendlich wurde klar, dass es nichts zu zeigen gab. Es war zu spät, das Review noch abzusagen, also musste das Team sich den anwesenden Stakeholdern stellen. Als die Information "Wir können in diesem Sprint nichts Fertiges liefern" auf dem Tisch war, zeichnete sich Entsetzen auf den Gesichtern der Review-Teilnehmer ab. Noch bevor das Team irgendetwas erklären und nächste Schritte aufzeigen konnte, begann operative Hektik auf Seiten der Stakeholder. Der Vorstand müsse umgehend über den Verzug informiert, Schuldige müssten identifiziert werden, usw. Als Scrum Master lag es an mir, hier einzugreifen und das Review wieder auf die sachliche Ebene zurückzuführen. Im ersten Schritt habe ich darum gebeten, dass das Team ausreden darf, um die Situation zu erklären und nächste Schritte aufzuzeigen. Es war nämlich keineswegs so, dass zwei Wochen Arbeit verloren waren und dadurch Verzug eintrat, sondern die zwei Wochen waren sehr effizient genutzt worden, es lag lediglich nichts wirklich abgeschlossen Fertiges vor. Das Team schätzte den verbleibenden Restaufwand auf weniger als einen halben Tag für zwei Personen. Es war letztendlich also kein nennenswerter Verzug eingetreten, sondern die Arbeit würde gleich am ersten Tag des nächsten Sprints erledigt werden.

Abschließend habe ich die Teilnehmer noch auf die Großartigkeit der aktuellen Situation hingewiesen: Nach nur zwei Wochen wurde erkannt, dass es eine Situation gab, auf die sofort reagiert werden konnte. Es wurde also ein sehr kurzer Feedback-Zyklus etabliert. Außerdem waren durch die Offenheit des Teams alle auf dem gleichen Stand, niemand wiegte sich in falscher Sicherheit. Das Team hätte genauso gut behaupten können, dass alles fertig sei, und die Restarbeiten heimlich erledigen können. So aber hat das Team die Weichen zu einer offenen, vertrauensvollen Zusammenarbeit mit den Stakeholdern gestellt.

Beispiel 2

Nachdem ich kurze Zeit in einer neuen Firma als Scrum Master arbeitete, fand ich in einem Gespräch mit einem der Teamleads eine heikle Begebenheit heraus. Die Person war für einen Teil des Scrum-Teams organisatorisch verantwortlich. Ganz beiläufig erzählte er mir, dass er sich schon wieder geärgert habe. Der CEO der Firma hatte nämlich die Angewohnheit, die Arbeitsergebnisse des Scrum-Teams nach Feierabend und bis in die späten Abendstunden zu überprüfen, um dann in einer entrüsteten Zusammenfassung per E-Mail die Führungskräfte darauf hinzuweisen, welche unzureichende Qualität die Arbeit aus seiner Sicht hätte. Im gleichen Zuge bat er doch den entsprechenden Mitarbeiter damit zu konfrontieren und um professionelleres Arbeiten zu bitten. Ich konnte es nicht fassen, da ich diese Firma aufgrund ihres unbedingten Willens, Scrum einzusetzen und dem Wunsch, Agilität weiter auszubauen, ausgewählt hatte. Nachdem mir dieser Gedanke während des Gesprächs durch den Kopf schoss, folgte das I-Tüpfelchen. Der CEO nahm selber Veränderungen am Produkt vor und passte Arbeitsergebnisse an bzw. fügte mal welche hinzu oder entschied, dass andere nicht relevant waren. Dies alles unter dem Radar der Nacht und der stillen Post über die Teamleads.

Fazit

Das Ausmaß an Schädigung in diesem Beispiel ist natürlich in Gänze viel größer, als nur Mut zur Offenheit zu fordern. Unter solchen Umständen kann keiner der Scrum-Werte gedeihen. In dem Beispiel akzeptieren alle die Eingriffe durch den CEO und auch die Teamleads hatten nicht den Mut, das Thema offen anzusprechen. Die Situation führte dazu, dass das Vertrauen der Mitarbeiter immer weiter schrumpfte und alle im Status quo verharrten.
Unter Offenheit verstehen wir ein Klima des offenen Austausches untereinander, in dem nichts versteckt und verheimlicht wird. Für viele klingt das wie ein Idealbild, das nicht erreichbar ist. Aber warum sollte es unerreichbar sein? Zu seinen Fehlern stehen, offen und transparent kommunizieren und dann auch noch erfolgreich und mit Spaß bei der Sache zu sein, gibt es nicht? Teams in einem von agilen Werten geprägten Umfeld, zu dem eine fehlertolerante Kultur zählt, erleben genau das. Wenn es keine Angstkultur gibt, dann geht jeder Mensch viel offener an Themen heran und steht auch zu seinen Fehlern. Fehler sind menschlich und ein offen kommunizierter Fehler tritt wahrscheinlich nicht wieder auf. Auch Kritik ist eng mit dem Begriff Offenheit verbunden. Konstruktive Kritik zu etablieren hilft, sich weiterzuentwickeln. Und je offener jeder mit Kritik an sich selbst umgehen kann, desto einfacher fällt es auch, konstruktive Kritik an anderen zu üben.

Fokus

"If you focus on results, you will never change. If you focus on change, you will get results."
(Jack Dixon)

Beispiel 1

In meiner Rolle als Scrum Master wurde ich eines Tages von einem Team-Mitglied angesprochen. Der Grund war ein vorangegangenes Gespräch zwischen ihm und seinem Vorgesetzten, in dem dieser vom Mitarbeiter die Erledigung von Aufgaben verlangte, die indirekt mit vereinbarten Entwicklungszielen des Mitarbeiters zusammenhingen. Das Team-Mitglied versuchte der Führungskraft zu verstehen zu geben, warum er diese Aufgaben nicht übernehmen könne und verwies im Verlauf des Gesprächs mehrmals auf das aktuelle Sprint-Ziel und das dahinterstehende, größere Ziel. Das "Nein" wollte die Führungskraft nicht akzeptieren und ging verärgert aus dem Gespräch. Das Team-Mitglied bat mich im Anschluss um Rat und Hilfe und um ein klärendes Gespräch mit dem Vorgesetzten.

Beispiel 2

Bei der Begleitung eines Teams ergab sich folgendes Szenario: Das Team arbeitete über mehrere Monate auf eine nächste Veröffentlichung von wichtigen Funktionalitäten hin. Scrum Master und Product Owner arbeiteten eng zusammen, um den bestmöglichen Erfolg zu sichern und damit auch die erfolgreiche Lieferung zum Zieltermin. Mit diesem standen flankierende Maßnahmen im Marketing an, der Verkauf hielt Kunden und potentielle Interessenten schon einige Zeit hin. Auch vertraglich hatte das Release eine gewisse Brisanz. Dem Team wurde durch den Product Owner immer wieder die Wichtigkeit verdeutlicht, die durch die Dynamik im Team spürbar wurde, je näher der Termin rückte. Die Stimmung war energetisch, auch obwohl jeder wusste, dass es ein ambitioniertes Ziel war. Anderthalb Wochen vor dem Termin begab es sich, dass zu einem monatlichen Info-Termin mit allen aus der Abteilung geladen wurde. Bei diesem Termin werden quartalsweise die aktuellen Zahlen, die letzten Erfolge und die nächsten Ziele besprochen. In diesem Termin wurde demnach auch vorgestellt, was im Anschluss an das Ziel des Teams geplant war. Zur Überraschung aller Anwesenden wurde verkündet, dass es sich inhaltlich um ganz andere Themen drehen werde. Was beim Team ankam, war die Botschaft: "Gut, dass wir jetzt die neuen Funktionalitäten bereitstellen, in naher Zukunft werden sie jedoch keine Relevanz mehr haben." Man kann sich vorstellen, was dies mit jedem Einzelnen machte. Alle im Team – einschließlich Scrum Master und Product Owner – wurden überfahren. Es brauchte viel Anstrengung und Überzeugungskraft von Scrum Master und Product Owner, aber auch den Überbringern der Botschaft, dass ganze einigermaßen wieder einzufangen und in Bahnen zu lenken. Der Fokus des Teams litt sehr darunter. Der Termin wurde nicht eingehalten.

Fazit

Der Mut des Mitarbeiters im ersten Beispiel, "Nein" zu weiteren Aufgaben zu sagen, die nichts mit der Zielerreichung zu tun haben, macht die Anstrengung deutlich, die es oftmals braucht, um den Fokus beizubehalten. In einem cross-funktionalen Team gibt es nur das Ziel des Sprints, dem sich alles unterzuordnen hat. Durch das Beharren des Mitarbeiters auf der Zielerreichung konnte dieser selber fokussiert weiterarbeiten, garantierte aber auch den Fokus für das Team. Wir haben schon oft erlebt, dass Führungskräfte sehr viel Wert auf Voraussagbarkeit und Planbarkeit legen und gleichzeitig der Zielerreichung stark im Weg stehen.

Dies wird auch im zweiten Beispiel deutlich. Es ist nichts wichtiger, als die Erreichung des Ziels, bis zur Verkündung des neuen Ziels. Nicht nur, dass die Glaubwürdigkeit und das Vertrauen einen starken Kratzer erlitten, vielmehr wurde die Motivation der Beteiligten gedämpft und darüber hinaus das Ziel nicht erreicht. In diesem Beispiel kommen Aspekte zum Vorschein, die in der Verwendung von Scrum in (Matrix-)Organisationen Probleme aufwerfen. Das Scrum-Team wird von außen mit neuen Zielvorgaben überrascht. Demnach ist das Team inklusive Product Owner auch nicht befähigt, den eigenen Weg zu beschreiten. Das Beispiel zeigt auf, dass es zudem an Offenheit und Transparenz innerhalb der Organisation mangelt.

Für uns kann Fokus nur werthaltig sein, wenn ein Team in seiner Arbeit so wenig wie möglich gestört wird und sich voll und ganz auf das Erreichen des Sprint-Ziels konzentrieren kann. Häufig genug schon gibt es Störungen aus der Organisation, sei es durch Teammeetings, Arbeitsgruppen, Nachfragen, Einstellungsgespräche oder Termine außerhalb des Projekts verursacht. In Scrum ist es die Aufgabe des Scrum Masters, alle störenden Außeneinflüsse vom Team fernzuhalten. Bei jedem Team-Mitglied gehört aber auch eine gehörige Portion Selbstdisziplin dazu, sich nicht durch Andere oder andere Aufgaben von der eigentlichen gemeinsamen Arbeit ablenken zu lassen.

Alle bisher genannten Werte werden durch einen Wert besonders beeinflusst – Respekt. Respektvoll miteinander umzugehen bedeutet die uneingeschränkte Anerkennung des Wertes jeder beteiligten Person und ihrer Arbeit, selbst wenn menschliche Schwächen sichtbar werden oder Fehler entstehen.

Respekt

"Above all things, respect yourself."
(Pythagoras)

Beispiel 1

"Respekt muss man sich verdienen" lautet ein bekannter Ausspruch. Ein Team, dass noch nicht lange zusammenarbeitete und von mir als Scrum Master betreut wurde, vergeigte einen Sprint nach dem anderen. Woche für Woche, Sprint für Sprint zogen ins Land, ohne nennenswerte erfreuliche Nachrichten für außen stehende Stakeholder. Das Team, der Product Owner und ich als Scrum Master sahen kleine Veränderungen und hoben gemeinsam den einen oder anderen großen Stein aus dem Weg. Die Stimmung im Team war gut und trotzdem war jeder aufgrund der fortlaufenden Niederschläge angespannt und enttäuscht. Der Product Owner und ich standen mit den Stakeholdern in engem Kontakt und berichteten über die Herausforderungen, aber vor allem auch über die kleinen Fortschritte. Bei einem dieser Gespräch gab es so einen mächtigen Gegenwind, dass es leider bis zum Team durchdrang. Ich weihte den CTO der Firma über diesen Vorfall in einem klärenden Gespräch ein. Zu meiner Überraschung teilte er nach Prüfung der Faktenlage meine Einschätzung zum Voranschreiten des Projekts und ging noch einen Schritt weiter. Zuerst half er die Sachlage in der Abteilung zu klären, die diesen Eklat heraufbeschworen hatte. Danach stellte er sich am nächsten Daily Scrum ins Team und kommunizierte seine Zuversicht, dass sich die Durststrecke bald in Luft auflösen würde und ermunterte alle, sich nicht von der aktuellen Situation unterkriegen zu lassen. Darüber hinaus bot er seine Unterstützung an, falls seine Hilfe benötigt wurde.

Beispiel 2

Ich habe einige Zeit als Projektportfolio-Manager gearbeitet und in dieser Rolle alle paar Wochen einen Termin mit dem Vorstand und den Hauptabteilungsleitern des Unternehmens organisiert, in dem es um den Stand de Portfolios und nächste Projekte ging. Ich war dazu meistens einige Zeit vor dem Termin vor Ort, um alles vorzubereiten. Nach und nach trudelten die Teilnehmer ein und unterhielten sich noch miteinander. Dabei habe ich das eine oder andere Gespräch mitbekommen und mir klingelten die Ohren. Es war unglaublich, wie abschätzig sich diese hochrangigen Führungskräfte teilweise über ihre Mitarbeiter unterhielten. Es wurden Äußerlichkeiten und Befindlichkeiten lächerlich gemacht, die Intelligenz einzelner Personen in Frage gestellt und ganze Teams als inkompetent dargestellt. Respekt sieht anders aus und mein Respekt für diese Führungskräfte war im Keller.  

Fazit

Die Erwartung des Teams im ersten Beispiel war natürlich eine vollkommen andere. "Ich dachte, wir bekommen jetzt einen auf den Deckel!" war einer der Aussprüche, die ich nach der Ansprache des CTO zu hören bekam. Was hatte er dadurch gezeigt und geschafft? Durch seine ruhige und souveräne Art wirkte er professionell und menschlich. Dadurch, dass er sich vor das Team stellte und allen Mut machte, verdiente er sich umgehend Respekt bei allen Beteiligten. Die Sicherheit, die er versprühte, schaffte ein tiefer gehendes Vertrauen in die Zusammenarbeit und stärkte das angeknackste Selbstvertrauen des Teams umgehend.

Für uns ist der Wert Respekt die Klammer aller Scrum-Werte.

Im zweiten Beispiel hingegen ist davon auszugehen, dass die von der Geringschätzung betroffenen Mitarbeiter dies durchaus bemerken, auch wenn es ihnen gegenüber nicht ausgesprochen wird. Fehlende Anerkennung wird sich auf die Arbeit auswirken und die mangelnde Wertschätzung dadurch sogar noch verstärken. Ganz zu schweigen davon, was die beschriebene Situation über die Führungskräfte aussagt.

Für uns ist der Wert Respekt die Klammer aller Scrum-Werte. Menschen streben in der Regel nach Erfolg und Anerkennung, niemand wird absichtlich irgendetwas falsch machen. Die Anerkennung dessen, was ein Mensch zu leisten imstande ist, und die Unterstützung des Umfelds im Bestreben, immer besser zu werden, sollte heutzutage für jeden, unabhängig von seiner Hierarchiestufe oder Rolle, selbstverständlich sein.

Das Scrum-Wertesystem

Anhand der Beispiele wird deutlich, wie eng verzahnt die Scrum-Werte miteinander sind. Oftmals ist keine klare Trennschärfe zu benennen, da sie sich untereinander bedingen. Wir wissen aus Erfahrung, dass ein wesentlicher Grund für das Funktionieren von Scrum das gelebte Wertesystem ist. Im Prinzip ist es gar nicht so schwer, diesen Werten Aufmerksamkeit zukommen zu lassen. Gerade am Anfang eines Team-Prozesses kann hier der Grundstein gelegt werden.

Insbesondere ist es wichtig zu verstehen, dass diese Werte nicht verordnet werden können. Jedes Team sollte die Werte intern diskutieren und seine eigene Interpretation daraus ableiten. Jeder einzelne Mitarbeiter – egal in welcher Rolle oder auf welcher Hierarchiestufe – darf in einer werteorientierten Unternehmenskultur Werte mitgestalten und auch die Einhaltung von Werten einfordern. Um dies von einer Führungskraft zu fordern, bedarf es jede Menge Mut.

Als Scrum Master

• Erarbeiten Sie die Scrum-Werte und ggf. weitere Werte gemeinsam mit dem Team und machen diese explizit.
• Nutzen Sie in Retrospektiven die Gelegenheit, die Entwicklung der Werte anhand eines Team-Radars nach zuhalten oder führen Werte-Retrospektiven durch [3].
• Weisen Sie lobend darauf hin, wenn jemand einem Wert entsprechend handelt und auch, wenn jemand es nicht tut.
• Sprechen Sie die Werte regelmäßig an und machen diese transparent, bspw. gut sichtbar am Scrum-Board.
• Tauschen Sie sich laufend mit den Führungskräften und anderen Scrum Mastern aus allen Bereichen der Firma aus und arbeiten gemeinsam an einer werteorientierten Kultur.

Als Führungskraft

• Informieren Sie sich darüber, welches Verständnis und welche Erwartungen die Teams sich bezüglich der Werte erarbeitet haben.
• Zeigen Sie, dass auch Sie die Werte respektieren, indem sie sie aktiv vorleben.
• Lassen Sie die Werte nicht aus dem Blick und nutzen diese als Leitplanken für die Mitarbeiterentwicklung.
• Tauschen Sie sich laufend mit Ihren Mitarbeitern aus, um ihre Bedürfnisse besser zu verstehen.

Als Team-Mitglied bzw. Mitarbeiter

• Bringen Sie sich ein, wenn es um das Verständnis und die Ausarbeitung der Werte geht.
• Achten Sie darauf, dass Sie selbst die Werte leben und wertschätzen Sie es, wenn jemand anders auch den Werten entsprechend handelt.
• Hinterfragen Sie das Verhalten von anderen, wenn diese Ihrer Meinung nach nicht den Werten entsprechend gehandelt haben.

In unseren Scrum-Trainings planen wir zu Beginn einen großen Block ein, um über die zugrundeliegenden Werte zu sprechen, bevor wir mit dem operativen Teil von Scrum anfangen. Das Feedback der Teilnehmer zeigt uns, was für einen wunden Punkt wir meist damit treffen. Aussagen wie: "Bei uns in der Firma wird es schwer werden, den doch relativ einfachen prozessualen Teil von Scrum umzusetzen, weil unsere bestehende Kultur das nicht ermöglicht..." hören wir häufig. Deshalb ist es wichtig, dass alle Personen, die bisher direkten oder indirekten Einfluss auf ein Scrum-Team genommen haben, das Wertesystem verstehen und erkennen, wie sehr die Beachtung der Werte nicht nur dem Team hilft, sondern auch den eigenen Zielen.

Autoren

Das könnte Sie auch interessieren