Der überflüssige Scrum Master
Warum ein Invest in Arbeitsmittel wünschenswert für die (agile) Softwareentwicklung ist, aber selbiger in angeworbene Anwender oftmals ignoriert wird, zeigt sich in der umgesetzten Rollenverteilung. Entwickler, Analysten und Product Owner sind tolle Titel – ehh… Rollen; oder beides? Das ist sowieso Schall und Rauch. Schließlich kennen sie alle die Methodik in-und auswendig. Das war zumindest Teil der Stellenausschreibung. Jeder kann alles – irgendwie. Denken zumindest die Unternehmens- und Abteilungsköpfe.
Das Management kratzt methodisch, für gewöhnlich aber leider nur an der Oberfläche. “Kann ja nicht so schwer sein. Wozu braucht man denn einen Scrum Master? Die Meetings kann auch der Product Owner übernehmen.” Und schon hat man eine überladene Methodik revolutioniert, ein Jahresgehalt gespart und einen motivierten Mitarbeiter im Schicksalsberg verglühen lassen. Sauron wäre stolz!
Warum diese Denke, der Alltag in vielen Firmen ist, einen Nährboden für scheiternde methodische Unternehmensaufstellungen, wie auch Kollegen darstellt und warum man Scrum Master für überflüssig halten könnte, soll dieser Beitrag ansatzweise erläutern.
Der Auserwählte
Gerade in der agilen Produktentwicklung setzt man auf überdurchschnittliches Personal. Menschen, die auf ihrem Gebiet einmalig sind. Hochintelligent. Absolut lernwillig. Die „Extra-Meile“ steht ihnen regelrecht auf der Stirn. Erfahren in ihrem Tun. Solche Rennpferde braucht es. Irgendjemand hat das im Unternehmen schließlich entschieden. Und das nur, weil man anstehende Projekte schneller und hochwertiger umsetzen möchte. Der Status Quo soll also schlichtweg verbessert werden. Und die Variable “Personal” soll der Start sein. Man möchte etwas Grundlegendes verbessern. So scheint es.
Um es in einem generalistischen Ton vorweg zu nehmen: Unternehmen ticken dahingehend alle ähnlich. Dieses Denken bzw. dieser Anspruch ist sowohl in Konzernen, als auch in Start-Ups vorhanden. Veränderungen müssen stets beim Menschen vorgenommen werden. Erst dann kann man strukturell anpacken. Irgendwie richtig. Und irgendwie katastrophal.
Letztlich bedeutet es aber auch, dass das Vertrauen in den bereits vorhandenen Fach-Spezialisten nicht für das Kommende gegeben ist. Das kann aus verschiedenen Gründen der Fall sein. Emotionale, wie auch professionelle. Oder man möchte diesen Mitarbeiter schlichtweg in seiner Arbeit (z.B. wegen eines Wachstums der Firma) unterstützen. Einen Kollegen an die Seite stellen, der mindestens dasselbe Know-how mitbringen soll. Vielleicht sogar ein wenig mehr, weil man sich neu aufstellen möchte. Mit neuen Ideen. Aktuelleren Methoden und Tools. Quasi die Chance nutzen. Fair!
Missgedeutete Expertise
Das Problem mit dem “Neu” ist allerdings, dass das Management hierfür auch bereit sein muss. Und auch die Kollegen. Eine eventuell festgezurrte Meinung hintenanstellen. Offen für die Innovation sein, denn: Nur die Einstellung des neuen Kollegen verbessert schließlich noch nicht die Lage; das alleinige Platzieren von Menschen in Abteilungen löst schließlich keine Probleme und auch Veränderungen werden dadurch noch nicht vorangetrieben. Man sollte den Experten auch zuhören. Über “das Neue” nachdenken. Eine Empfehlung ohne
Bauchgefühl überprüfen. Entspricht der neuartige Vorschlag der neuen Personalie, aber nicht der Managementmeinung (oder würde die Umsetzung zu sehr schmerzen), dann kommt das meist nicht gut an. Es wird gar persönlich genommen.
Aber warum? Nun ja, es werden Fehler aufgezeigt. Kollegen und Management liegen also falsch. Oder die aktuelle Vorgehensweise ist zumindest “verbesserungswürdig”. Das weiß die Abteilungs- oder Unternehmensführung aber ja bereits. Daher rührt partiell wahrscheinlich auch die Neueinstellung des Experten. Aber wer wird denn schon gerne von Dritten auf Herausforderungen aufmerksam gemacht? Da muss man sich “vom Neuen” also direkt zu Beginn belehren lassen, statt vielleicht doch in seinem Handeln bestätigt zu werden. So könnte man das deuten. Na prima!
Methodische Experten sind dazu auch noch teuer. So hört man. Zwar bringen sie die Erfahrung (z.B. in Integration, Strategie oder Agilität) mit, die häufig benötigt wird, aber sind diese mit kostspieligen Jahresgehältern verbunden. Kostspielig heißt: Mehr als man eigentlich bezahlen möchte. Geiz ist schließlich immer noch irgendwie geil. Und dazu kommen dann auch noch diese überdurchschnittliche Erwartungshaltung gegenüber des Unternehmens, sowie das bereits angesprochene Belehren. Zwar nach eigener Aufforderung, aber dennoch verletzend. “Und nur weil dies derzeit alle machen, muss das nicht auch von uns integriert werden. Es geht schließlich darum besser zu werden und nicht darum dem Trend zu folgen!” Recht hat das Management. Oder?
Das teure Personal wirkt somit unflexibel und stur. Es will die internen Vorgänge offensichtlich nicht verstehen – oder ihnen schlichtweg nicht folgen. Es fehlt der Wille sich anzupassen. Ständig wird das Implementieren von fehlenden Meetings, die essentiell für die Produktentwicklungsmethodik sein sollen – und somit auch für die Qualität des Produktes – gepredigt. Andauernd wird reflektiert, recherchiert und geschätzt. Früher hat man sich noch hinter die Tastatur begeben und schlichtweg das gecoded was das Management bestellt hat. Ganz ohne Sitzsäcke und Kartenspiele. Das hat ja auch geklappt.
Die These ist also: Experten gelten als anstrengendes Personal mit fixen Ideen, welche ihren Zenit im Overengineering finden. Zumindest aus Sicht des Managements. Beispiel: “Burn-Down Charts braucht man nicht. Die sind sowieso selten korrekt.” wird häufig so von neuen Mitarbeitern empfohlen und ausprobiert. Gefüttert mit ungeprüften bzw. interpretierten Daten des Unternehmens. Klassisch. Hört man immer wieder. Dass das erstmalig eingesetzte Tool nicht für die Unschärfe des Outputs verantwortlich ist, wird aber selten erkannt oder verstanden und der Experte wird rasch vom Management abgestempelt, obwohl die von der Führung gelieferten Daten schlichtweg das Problem waren und nicht das vom Experten implementierte Tool. Schade.
Unternehmensprozesse als Gegner
Hat man erst die Erkenntnis gewonnen, dass ein Experte vielleicht doch nicht die korrekte Personalie für das Unternehmen ist, dann fällt oftmals der Begriff „Talente“. Verstehen Sie mich nicht falsch, oftmals haben Unternehmen auch gar keine andere Chance. Entweder, weil der Markt einem keine andere Wahl lässt oder weil das Geschäftskonto roten Lippenstift aufgetragen hat.
Jung, dynamisch, flexibel und noch hungrig. Hungrig etwas zu bauen. Sofort ein Produkt abzuliefern. Nicht lange schnacken. Da wird noch direkt angepackt und ausprobiert. Da ist der Hunger nach Karriere zu spüren. Da übernimmt dann der talentierte Product Owner auch schon mal selbst CSS Änderungen oder eine Anpassung der Seitenindexierung. Klasse! Frisch von der Uni – mit dem aktuellsten theoretischen Wissen und mit Hands-on-Mentality. Jackpot!
Im Grunde alles Parameter, welche eine “Erfahrung” überstrahlen – laut Management-Definition. So zumindest häufig die Argumentation, um sich die mangelnde Bereitschaft (oder Möglichkeit) der Investition schön zu reden. Investition in Sachen Gehalt, Zeit und Prozesse.
Und dann gibt es noch den Faktor „Formbarkeit“. Eine Art Bonus. Ein Talent kann nun mal sehr einfach auf das jeweilige Unternehmen zugeschnitten werden – ohne Kritik. Schließlich beharrt jeder Konzern oder jedes Start-Up darauf “anders” zu sein. Etwas Besonderes. Der anvisierte Markt tickt gänzlich “abnormal” und sowas lernt man weder auf der Uni, noch in anderen Companys. Man ist unvergleichlich. Da passt eine neumodische Methodik nun mal nicht. Für andere sicherlich, aber doch nicht für unsere spezielle Unternehmenskultur.
Schön also, wenn das angeforderte Personal mit Expertise – ehhh – ich meinte, mit Talent, unmittelbar nach Einstellung gebrandet werden kann. Praktisch. Und belehrt wird das Management auch nicht. Das Talent wird akzeptieren, dass man seine neumodische Idee vielleicht schon mal vor Monaten/Jahren ausprobierte, aber alles irgendwie scheiterte. “Das funktioniert hier nicht.” Wegen Widerstand in der Belegschaft. Zu langer Implementierung von Tools. Zu unflexibler Prozesse. Der Experte würde arrogant entgegnen, dass vielleicht kein erfahrenes Fachpersonal Vorort war, um die Initialisierung zu begleiten und erfolgreich zu machen. Das gegebenenfalls der Rückhalt durch das Management fehlte. Da ist er wieder. Dieser anstrengende Experte, der alle im Unternehmen für dumm hält.
Egal welchen Typ an Personal für das Unternehmen nun ausgewählt wurde, die Arbeit bzw. Vision bleibt die Gleiche. Ab hier gewinnt und verliert man nur noch gemeinsam. Als Unternehmen – Management – Abteilung – Mensch.
Ich bin mein eigener Sparringspartner
Die im Unternehmen platzierte Person wird nun in eine Methodik implementiert. Oder sie führt sie sogar selbst ins Unternehmen ein. Übernimmt die Aufgaben des Product Owners – und die des Scrum Masters. Das muss eben so! Das Unternehmen braucht die Detailtiefe der Methodik schlichtweg nicht. Das Talent wird als Product Owner rocken. Toll, dass man als Neuling direkt so viel Verantwortung vom Management bekommt. Trügerisch.
Tatsache ist, dass man Personal (ich vermeide das Wort Ressource) mit Doppelbelastung demotiviert – kurz- wie auch langfristig. Denn egal für welche Art der Methode sich ein Unternehmen entscheidet: Rollen müssen mit echten Menschen ausgefüllt werden. Und ich schreibe absichtlich im Plural. Wenn man von Rollen spricht, dann sollte man ernsthaft in Erwägung ziehen diese durch je eine Person zu besetzen – insofern die Rollen auch tatsächlich miteinander agieren sollen. Egal ob mit Talenten oder Experten. Und diese werden für sich entscheiden (oder entscheiden lassen), wie man gewünschte Ziele erreicht.
Und dann arrangiert man sich mit Produktentwicklungsmethoden in der außerhalb der Norm liegenden Unternehmenskultur. Sonst funktioniert die Methode ja nicht richtig. Das zumindest glauben Unternehmens- und Abteilungsführungen immer häufiger. Das mag in der Gesamtmethodik sicherlich machbar sein – aber eben nicht mit darin verankerten Rollen und Verantwortlichkeiten.
Als Beispiel, die bereits erwähnten Product Owner und Scrum Master. Die letzten Jahre habe ich vermehrt wahrgenommen, dass diese Rollen zusammengelegt werden. Aus Kostengründen. Missverstandener Methodik. Angepassten Umständen. Dabei sind es genau diese beiden Rollen, welche im definierten Scrum-Methodikrahmen als eine Art “Sparringpartner” zu handhaben sind. Vereinfacht gesagt. Aus Unternehmensführungssicht mag es sehr verlockend sein, wenn ein Product Owner ungebremst in laufende Sprints (also Entwicklungszeiträume) eingreift und mit den Programmierern noch Änderungen von bereits in Bearbeitung befindlichen User Storys (Arbeitsaufträge) bespricht. Aber die Vorteile der agilen Produktentwicklung sind dahin. Die ganze Methodik wird untergraben. Stakeholder, Abteilungsleiter, Entwickler und die Geschäftsführung gieren nach der Rolle. Immer und immer wieder. Tag für Tag. Der Mensch dahinter allerdings wird in einem Mahlwerk zerrieben. – Management – Abteilung – Mensch.
Herr Ober, ich habe ein Haar in meiner Suppe
Um es vereinfacht darzustellen: Der Product Owner sollte sich um seine Stakeholder kümmern. Um seine User Storys. Und die Priorisierungen. Er kippt seine Bestellung und die seiner “Gäste” ein. Übergibt sie sozusagen dem Kellner im Restaurant und wartet auf die Zubereitung. Ganz allgemein gesprochen. In einem klassischen Wasserfallmodell würde man ihm sicherlich den Titel des Produktmanagers anheften.
Der Scrum Master dagegen würde in diesem Vergleich wohl als Projektmanager definiert. Der Kellner. Der Typ, der das Tablett schwingt und mit seinem Gast interagiert. Und der Küche. Er spricht beide Sprachen. Die des Gastes und die der Köche. Dabei macht er dem Gast dann auch schon mal klar, dass man Zwiebelsuppe eben nicht ohne Zwiebeln zubereiten kann und diese (aller Voraussicht nach) nach Zwiebeln schmecken wird. Er wird aber gerne in Erfahrung bringen, ob man den Geschmack nicht etwas verfeinern könnte, um ihn den Bedürfnissen anzupassen. Also für die nächste Bestellung. Vielleicht holt er auch den Koch aus der Küche und stellt ihn persönlich vor. Zudem wird der Kellner die Küche immer wieder daran erinnern, dass im Restaurant der hungrige Gast sitzt, welchen er zu bewirten hat. Doch am Ende des Tages wird er (oder sie) ein offenes Ohr für sein Küchenpersonal (den Entwicklern) haben. Rekapitulieren wie es so gelaufen ist und gemeinsam erarbeiten, wie man noch effizienter werden kann.
Ja, das ist sehr vereinfacht dargestellt. Doch reicht der Vergleich aus, um meinen Punkt klar zu machen: Rennt der hungrige Gast selbst in die Küche, um seine Zwiebelsuppe in Auftrag zu geben, wird es nicht gut enden. Die Gewürzanteile werden verändert, die Menge, der Ton und sicherlich sind die Hygienevorschriften auch nicht mehr so, wie sie sein sollten. Unabhängig davon, dass die Buchung in der Kasse ggf. nun nicht vorhanden ist, weil man die internen Prozesse nicht gut genug kennt. Zwar wird man (im besten Fall) mit einer Suppe die Küche verlassen und seinem mitgebrachten Tischnachbarn überreichen, doch ob sie schmeckt oder so schmeckt wie sie sollte, ist fraglich. Mal ganz abgesehen davon, dass die zeitliche Komponente aus dem Blickfeld gelassen wurde. Gerade hier hört man häufig: Wieso hat es denn jetzt viel länger gedauert als geplant? Ganz einfach: Weil der Plan, wie auch das Produkt, verändert wurde (siehe meinen Beitrag: Warum Scrum in Ihrem Unternehmen scheitert). Schande!
Verantwortung übernehmen
Meiner Erfahrung nach, benötigt es einen sehr erfahrenen Experten, um diesen Tanz ansatzweise über die Bühne zu bekommen. Doch hierzu gehört auch vollstes Vertrauen des Managements, sowie der Entwickler. Und einen abgesteckten Zeitrahmen. Denn dies ist keine Dauerlösung. Sie ist zeitintensiv, sehr belastend und fehleranfällig. Sehr gerne reduziert man die Anzahl der Meetings. Allen voran: Die Retrospektive. Aus Fehlern wird nicht mehr gelernt. Das Gute nicht beibehalten oder hervorgehoben. Die Bedürfnisse des Teams nicht mehr erfasst. Man vergisst das Lernen im agilen Prozess. Kritisch.
Übernehmen alle Beteiligten die Verantwortung für ihren Part, dann sollte schnell klar sein, dass ein Product Owner eben nicht noch ein Scrum Master sein kann. Aber wer ist denn nun verantwortlich für die Misere? Die direkt betroffene Personalie? Die Entwickler? Vielleicht sogar das Management?
Für mich ist klar, dass sich alle Parteien einen Schuh teilen müssen. Die Entwickler können unmöglich zufrieden mit der Situation sein, dass sie unentwegt in ihrer Arbeit unterbrochen und generell nicht mehr gehört werden (denn dies wird auf kurz oder lang geschehen). Die Aufgabe des Problemaufzeigens muss erfolgen. Aber wo platzieren, wenn die Retrospektive ausbleibt und es keine Hierarchien in einer Methodik wie Scrum gibt?
Dann: Der doppelrollenbelastete Mensch. Er ist verpflichtet nach Hilfe zu schreien. Wegen des schmerzenden Zeitmanagements. Bezüglich mangelhafter User Storys. Und den daraus resultierenden Fehlschätzungen des Teams. Den kreischenden Stakeholder nicht zu vergessen. Doch bei wem melden, wenn die Vorgabe durch das Management erfolgte und die Situation genauso gewünscht wurde? Wird man nicht eher als unfähig betitelt? Schließlich spricht die Qualität der Arbeit Bände. Wer möchte sich schon als Schwächling outen? Gerade als Neuling.
Wissen worauf man sich einlässt
Letztlich muss aber auch das Management Verantwortung übernehmen. Es hat die Aufgabe seine Mitarbeiter zu schützen. Das Unternehmen auf Kurs zu halten. Visionen umzusetzen. Das Ohr an der Belegschaft haben. Und daraus resultierend bereits in der strategischen Aufstellung nach Optimierungsmöglichkeiten suchen. Hierbei darf es erkennen, gescheitert zu sein oder auch mal etwas nicht zu wissen. Dafür stellt man ja auch schließlich Experten ein. Oder man schafft es Talente zu fördern, um eine einmalige Expertise im Unternehmen heranwachsen zu lassen. Allerdings muss man dann eventuelle zeitintensive Fehlschläge in Kauf nehmen bzw. die Erwartungen herunterschrauben. Doch diese Perspektive lässt eine fast uneingeschränkte Loyalität der Mitarbeiter gegenüber des Unternehmens erblühen. Das kann sich langfristig gesehen sehr lohnen.
Wenn man es also herunterbricht, dann muss gerade das Management einfach nur lernen loszulassen und Meinungen, die den eigenen entgegnet werden, zulassen. Zumindest für eine objektive Prüfung – vielleicht auch durch einen Dritten. Man darf sich und die eigene Vision hinterfragen, statt nur sein Gegenüber. Und auch, warum man eigentlich gewisse Rollen zulässt und welche nicht.
Es lohnt sich, eine einfache Pro/Contra Liste zu erstellen. Meistens zeigt sich klar, dass man noch mehr Input benötigt, um eine fundierte Antwort zum Thema “Brauche ich einen Scrum Master UND einen Product Owner?” zu erhalten. Hierbei wird sich dann rasch zeigen, dass das Zusammenlegen von zwei Rollen aus einem Bauchgefühl heraus entstanden ist. Aus falschen Gründen. Wie mit den Unschärfen des Burn-Down-Charts stellt man fest, dass die Input-Daten bereinigt werden sollten, bevor man mit einer Entscheidung um die Ecke kommt. Das gilt im Übrigen mit allen Entscheidungen im Leben.
Daran wächst das Team, das Unternehmen und letztlich man selbst.
Hinweise:
Interessieren Sie sich für weitere Tipps aus der Praxis? Testen Sie unseren wöchentlichen Newsletter mit interessanten Beiträgen, Downloads, Empfehlungen und aktuellem Wissen.
Kennen Sie den Begriff Scrumbut?
Martin Peters hat einen weiteren Beitrag im t2informatik Blog veröffentlicht:
Warum Scrum in Ihrem Unternehmen scheitert
Martin Peters
Martin Peters ist seit mehr als 14 Jahren im Großbereich Online Payment und Process & Quality u.a. als Product Owner, Projekt Manager und Produkt Manager tätig. Hierbei verfolgt den Ansatz der Anwendung der korrekten Methodik zur relevanten Zeit. Mit seiner Erfahrung in den Bereichen Digital Commerce, Prozessoptimierung, Service-Implementierung und Coaching wurde er sowohl in Konzernen und Start-Ups für Spezialistentätigkeiten angefordert.