Vor welchen Herausforderungen stehen Softwareteams in den unterschiedlichen Organisationen? Wie sehen diese Herausforderungen aus, die der regelmäßigen Lieferung und hohen Qualitätsstandards der Software im Weg zu stehen scheinen?
Im vorherigen Blogpost meiner dreiteiligen Serie haben wir den zweiten Grund „Das Softwareteam versteht sich nicht gut“ erläutert. In diesem Blogpost werden wir uns mit dem dritten Grund beschäftigen, den wir oft beobachten. Er ist aber ebenso relevant wie die zuvor genannten Gründe!
Vielleicht erkennt der eine oder andere eine ähnliche Herausforderung innerhalb seiner Organisation wieder und bekommt durch die Lösungsansätze neue Impulse für sein Umfeld.
Grund 3: Agile Rollen sind nicht wirksam
Scrum ist ein Discovery-Framework. Designed und konzipiert, um regelmäßig Softwareinkremente an Kunden/User auszuliefern. Anhand des wiederkehrend eingeholten Feedbacks wird die Software kontinuierlich weiterentwickelt; am besten so kundenzentriert wie eben möglich.
Damit mithilfe von Scrum hochqualitative Software entstehen kann, braucht es neben Werten, Prinzipien, Ritualen und Artefakten etwas sehr Entscheidendes: Rollen! Diese müssen besetzt und gut ausgefüllt werden.
Das ist natürlich die allbekannte Theorie von Scrum und im Scrum Guide sehr anschaulich beschrieben.
Was aber passiert, wenn diese Rollen nicht gut, gar nicht, oder gar doppelt belegt werden? Oder auch Fachwissen fehlt, um die Aufgaben eines Product Owners bzw. Scrum Masters ausführen zu können. Darauf gehen wir nun näher ein.
Interne Abhängigkeiten innerhalb des Teams
Zunächst möchte ich auf die internen Abhängigkeiten innerhalb des Teams eingehen. Diese Herausforderungen liegen meist im direkten Einflussbereich des Teams.
Product Owner
Muss die Rolle des Scrum Masters mit übernehmen
Der Scrum Master ist die Rolle in Scrum, die gerne versucht wird, einzusparen. Dann gibt es im Team entweder gar keinen Scrum Master, ein Scrum Master muss mehrere Teams betreuen, oder der Product Owner soll die Aufgaben des Scrum Masters mit übernehmen. So oder so wird sich diese Konstellation negativ auf die Lieferfähigkeit und die Qualität der Software auswirken.
Scrum Master leisten einen entscheidenen Beitrag, indem sie dafür sorgen, dass alle Mitglieder eines Scrum-Teams möglichst reibungsfrei ihre Aufgaben erledigen können. Aus diesem Grund sollte die anspruchsvolle Rolle des Scrum Masters auch nicht vom Product Owner mit übernommen werden.
Neben zeitlichen Engpässen (zwei Vollzeit-Jobs, die von einer Person übernommen werden) sind die Aufgaben von Scrum Master und Product Owner oft widersprüchlicher Natur. Was teilweise gut für die Weiterentwicklung des Produktes ist, ist es nicht für die Weiterentwicklung des Teams. Hier gilt es, Kompromisse zwischen Product Owner und Scrum Master auszuarbeiten. Nicht einfach, wenn das ein und dieselbe Person ist.
Fehlendes Fachwissen: In der Organisation gibt es kein klares Rollenverständnis
Eure Organisation arbeitet seit Jahren agil? Ihr habt, bevor ihr den Job des Product Owners angetreten seid, viele Jahre Berufserfahrung gesammelt und Euer Wissen wurde vor Antritt nochmal aufgefrischt? Zudem ist jedem Stakeholder in Eurem Unternehmen klar, wie der Job des Product Owners aussieht und wie er/sie seinen Betrag dazu leisten kann? Merkt ihr was?
Genau diese Rahmenbedingungen sind oftmals nicht gegeben. Wenn überhaupt, arbeitet die Softwareentwicklung agil. Viele Product Owner waren zuvor Projektleiter bzw. Product Manager und hatten schlicht keine Möglichkeit, Berufserfahrung als Product Owner in einem agilen Umfeld sammeln zu können. Und eine Auffrischung, geschweige denn eine Schulung wie denn der Job des Product Owner innerhalb der Organisation auszufüllen ist, hat nicht stattgefunden. Zudem sind viele Stakeholder noch in ihrer alten Rollen und Pflichten-Sicht verfangen.
Ein Product Owner sollte stets eine Sicht auf die Außenwirkung (z. B. den Kundenwert und die Zufriedenheit) haben. Wohingegen der Projektleiter eine ehr nach innen gerichtete Sicht (was z. B. Budgets, Scope und Timing betrifft) hat.
In so einem Umfeld ist der Job eines Product Owners sicher noch fordernder als ohnehin schon. Insbesondere, wenn es darum geht, die richtigen Entscheidungen zugunsten des Mehrwertes des Produktes zu treffen.
Die Organisation empowered/befähigt den Product Owner nicht ausreichend
Neben den oben genannten Punkten kommt oftmals hinzu, dass der Product Owner nicht ausreichend befähigt ist, Produktentscheidungen zu treffen. Gründe hierfür können mannigfaltig sein. Das reicht von Stakeholdern, die im Hintergrund die Fäden ziehen, über Geschäftsführer, die ihre Verantwortung nicht abgeben können, oder aber schwache Product Owner, die durch andere quasi die Entscheidungshoheit über das Produkt entzogen bekommen.
Egal welche Konstellation auftritt, sie haben doch eine Gemeinsamkeit: Trifft nicht derjenige die Entscheidung, der das Produkt, die Kunden und die Stakeholder am besten kennt, wirkt sich das negativ auf die langfristige Entwicklung und schlussendlich auch negativ auf die Qualität des Produktes aus.
Wer selbst gerne einen Überblick bekommen möchte, wie viel Einfluß sein eigenes Handeln als Product Owner hat, dem lege ich das POEM nahe, dass im folgenden Blogpost sehr gut beschrieben ist.
Lösungsansatz
Organisationen tun gut daran, agile Rollen in Teams nicht doppelt zu besetzen. Ein Product Owner der zusätzlich Scrum Master sein soll, kann beide Jobs nicht zufriedenstellend erledigen. Zudem ist eine Rollenklärung vor Antritt bzw. Übernahme der Stelle unbedingt ratsam. Schließlich können bereits im Vorfeld klar die Erwartungshaltung und die vorherrschenden Rahmenbedingungen erläutert werden. Das spart nicht nur viel Zeit, Ressourcen und Nerven. Sondern der Product Owner kann auch von Beginn an wirksam für das Produkt sein.
Zu guter Letzt sollte sehr kritisch hinterfragt werden, ob die Besetzung der Rolle Product Owner ohne die erforderlichen Befugnisse (Priorisierung, Umsetzung der Backlogitems) sinnvoll ist.
Die Antwort kennt ihr selbst.
Scrum Master
Rolle ist nicht besetzt
Die Rolle des Scrum Masters ist erfahrungsgemäß die Rolle in Organisationen, die am ehesten versucht wird einzusparen. Diese Einsparung sieht dann wie oben beschrieben so aus, dass ein Teammitglied (nicht selten der Product Owner) diese Rolle mit übernimmt. Oder aber ein Scrum Master für n Teams zuständig ist; also ein Vollzeit-Scrum-Master z. B. drei Teams betreut.
Mit etwas Abstand betrachtet und mit wenig Erfahrung im agilen Arbeiten kann das durchaus nachvollzogen werden. Der Scrum Master ist nicht aktiv an der Entwicklung des Produktes beteiligt. Alle Regeltermine und Rituale gibt ja der Scrum Guide vor. Wofür braucht es denn dann bitte noch einen Scrum Master?
Ihm/Ihr fehlt Fachwissen; in der Organsation gibt es kein klares Rollenverständnis
Diese Herausforderung ist vergleichbar mit der oben genannten des Product Owners, mit dem Unterschied, dass der Fokus des Scrum Master nicht primär auf dem Produkt und dessen Mehrwert liegt. Sondern auf dem Team sowie dem Scrum-Framework und dessen Abhängigkeiten innerhalb und außerhalb des Teams. Aber zu guter Letzt sind die spürbaren Auswirkungen beim Produkt ähnlich: Sie betreffen sowohl Qualität wie auch die Lieferfähigkeit des Scrum-Teams.
Lösungsansatz
Auch hier gilt: Organisationen tun gut daran, agile Rollen in Teams nicht doppelt zu besetzen. Ein Scrum Master, der zusätzlich anteilig Product Owner sein soll kann beide Jobs nicht zufriedenstellend erledigen. Zeit und Geld, die ihn die Ausbildung des Scrum Masters fliessen, kommen am Ende dem Produkt und der ganzen Organisation zu Gute.
Es gibt aber auch andere Modelle. So können z. B. Menschen, die bisher noch wenig Erfahrung in der Rolle des Scrum Masters sammeln konnten, durch einen erfahrenen Scrum Master Schritt für Schritt an die Praxis herangeführt werden; quasi Training on the Job. Mayflower bietet solche Modelle sowohl für Scrum Master wie auch Product Owner an.
Externe Abhängigkeiten
Neben den zahlreichen internen Herausforderungen gibt auch einige externe. Diese liegen oft nur bedingt im Einflussbereich der Teams.
Aufbau von Druck durch den Kunden/Stakeholder
Der Einfluss von Stakeholdern kann in einzelnen Fällen bis an die Spitze einer Organisation reichen. Nicht selten ist dann ein Geschäftsführer eben auch einer der wichtigsten Stakeholder eines Produktes. Solange diese Konstellation die Entscheidung des Product Owners nicht negativ beeinflusst, ist das auch vollkommen in Ordnung. Aber was, wenn doch?
Um bei diesem Beispiel zu bleiben: Geschäftsführer erwarten nun mal, dass ihren Wünschen nachgegangen wird. Was aber, wenn der Wunsch eines wichtigen Stakeholders aus guten Gründen (vorerst) nicht erfüllt werden kann und dieser den Druck auf den Produkt Owner erhöht? Dann braucht es an dieser Stelle einen starken Product Owner und Scrum Master an seiner Seite, die auch mit schwierigen Situationen – wie beispielsweise diesen – sicher umzugehen wissen. Mehr davon im Lösungsansatz.
Es werden Aufgaben um den PO herum direkt an das Team adressiert / Deadline Festlegung ohne Abstimmung/Rücksprache mit dem Team
Der nächste Punkt tritt gerne im Doppelpack auf. Richtig fordernd für den Scrum Master wird es dann, wenn Aufgaben direkt an einzelne Teammitglieder adressiert bzw. delegiert werden. Oft sogar von disziplinarischen Vorgesetzten und/oder Abteilungsleitern. Dabei handelt es sich offensichtlich um ein Anti-Pattern, was aber nicht bedeutet, dass dieses Verhalten selten zu beobachten ist.
Dazu gesellt sich nicht selten eine Vorgabe von Deadlines die aber – Vorsicht – ohne Abstimmung oder Rücksprache mit dem Team erfolgt. In der Praxis werden dann gerne Versprechungen mit Fristen genannt, von dem das Softwareteam erst viel später erfährt; oder dann, wenn es schon zu spät ist.
Infrastruktur-Abhängigkeiten: Entwicklungs-Testumgebung funktioniert nicht, ist aber für die Entwicklung notwendig
Die letzte Herausforderung bezieht sich auf Abhängigkeiten, die in Zusammenhang mit der Infrastruktur stehen.
Um ein Inkrement zum Sprintende fertig zu bekommen, ist zum Beispiel eine funktionierende Testumgebung notwendig. Sollte diese nicht Einsatzbereit sein (beispielsweise weil Zertifikate ausgelaufen sind), wird dies die Fertigstellung des Inkrements und somit das Sprintziel gefährden.
Lösungsansatz
Sowohl im Team als in der ganzen Organisation bringt es Vorteile, starke und befähigte Product Owner und Scrum Master zu beschäftigen. Die persönliche Stärke können Product Owner z. B. zusammen mit Scrum Mastern oder Agile Coaches trainieren.
Ein sicheres Umfeld bietet z. B. das Agile Spiel „Facilitation Dojo“ von Udo Wiegärtner. Des Weiteren gibt es z. B. durch Trainings und Fortbildungen die Möglichkeit, sein eigenes Wissen rund um Product Ownership zu erweitern. Werft dazu doch gerne mal einen Blick auf unser Training Become a Product Leader.
Schwieriger wird es dagegen, die Entscheidungsstärke von Product Ownern innerhalb der Organisation zu stärken. Das können gute Scrum Master und Agile Coaches aber ebenfalls durch gezielte 1-on-1-Gespräche mit den Beteiligten erreichen. Denn in den meisten Fällen ist die Auswirkung von solchen Entscheidungen gar nicht beabsichtigt, es fehlt aber an Transparenz um es selbst erkennen zu können.
Der Kreis schließt sich ein Stück, denn auch bei den Herausforderungen „es werden Aufgaben um den PO herum direkt an das Team adressiert/Deadline Festlegung ohne Abstimmung/Rücksprache mit dem Team“ weiß ein starker, befähigter Product Owner einen Weg, dieses unerwünschte Verhalten zu unterbinden.
Ein Lösungsansatz könnte dabei sein, mit den Stakeholdern in engem und regelmässigen Kontakt zu stehen. Und ihnen klar zu machen, dass Anpassungswünsche zwar vom Product Owner entgegengenommen werden, es aber grundsätzlich keine verlässliche Zusagen geben kann. Diese entstehen durch Inspect & Adapt, die Roadmap sowie Priorisierung. Anders lautende Ansagen laufen dann eben einfach mal gegen die Wand. Sicher nicht schön, der Lerneffekt ist dabei aber um so größer und dauerhaft.
Infrastruktur-Abhängigkeiten kann man langfristig begegnen, indem alle notwendigen Abhängigkeiten die die Infrastruktur betreffen innerhalb des Teams adressier- und lösbar sind. Es muss also dafür Sorge getragen werden, dass das Team selbst dazu in der Lage ist, die eigene Infrastruktur zu monitoren, zu warten und weiterzuentwickeln.
Drei Gründe, warum Softwareteams es nicht schaffen, regelmäßige Lieferung und hohe Qualität einzuhalten
Summary
Oft liegt eine Mischung der oben genannten Punkte vor – in ganz unterschiedlichen Ausprägungen. Doch führen sie in Summe immer zum gleichen Ergebnis: Sie sorgen für ungenaues Schätzen der Entwickler. Was sich wiederum negativ auf die Fertigstellung des Inkrements und dessen Qualität auswirkt. Und hier schließt sich der Kreis zur oben genannten Manifestierung im Ergebnis. Ein Defizit von fehlendem (Fach)Wissen im Team wird oft erst ganz am Ende bemerkt, nämlich dann, wenn das Produkt mit den echten Kunden bzw. Stakeholdern in Kontakt kommt.
Natürlich kann die Qualität des Produktes im nächsten Sprint verbessert werden, es ist nur schlicht teurer und wirft die Sprintplanung gehörig durcheinander. Ohne Eingriff entsteht eine Abwärtsspirale.
Ich hoffe, dass ich Euch in meiner dreiteiligen Serie einen kleinen Einblick darüber geben konnte, welche Umstände dazu führen können, dass Softwareteams es nicht schaffen, regelmäßige Lieferung und hohe Qualität einzuhalten – und was man tun kann, damit es in richtige Bahnen gelenkt wird. Es ging um Fehlendes Fachwissen, um Unstimmigkeiten im Team und jetzt eben um unwirksame agile Rollen.
Schreibe einen Kommentar