Samstag, 9. April 2016

Einführung von Scrum im Unternehmen, Teil 2

Da mein Post Einführung von Scrum im Unternehmen einige Fragen aufgeworfen hat, möchte ich gerne Hilfestellung bei der Beantwortung der von mir in den Raum geworfenen Fragestellungen leisten. Zur Erinnerung: Ich habe folgende Fragen gestellt, die vor der Einführung von Scrum oder spätestens während des ersten Sprints beantwortet werden sollten:

  • Was verspricht sich das Unternehmen von Scrum?
  • Soll Scrum nur 'ausprobiert' werden?
  • Ist die Produktvision vom Product Owner erreichbar und transparent?
  • Besitzen die User Stories einen Kunden- und einen Unternehmenswert?
  • Sind die Definitionen von 'selbst verwaltend' und 'selbst organisierend' bekannt?
  • Worin besteht der Unterschied zwischen 'Scrum anwenden' und 'Scrum verstehen'?
  • Ist der Unterschied zwischen einer einzelnen Person und einem Team bekannt?
  • Dürfen Fehler gemacht werden?
  • Wann und wo darf der Scrum Master in die Prozesse eingreifen?
  • Was ist das Ziel des Scrum Masters?
  • Was ist das Ziel des Product Owners?
  • Was ist das Ziel des Entwicklungsteams?
  • Sind Forschungsarbeiten im Scrum-Prozess vorgesehen?
  • Was bedeutet Agilität in Scrum?



Weiterhin bleibe ich dabei, keine allumfassenden Antworten zu liefern, da ein Auseinandersetzen mit den Fragen wichtig für das Verständnis von Scrum ist. Gerne gebe ich aber eine Richtung vor, die eingeschlagen werden sollte. Einzelnen Themen werde ich zu einem späteren Zeitpunkt eigene Artikel widmen.

Was verspricht sich das Unternehmen von Scrum?


Vor allem in großen Unternehmen wird die Entscheidung für den Einsatz von Scrum im oberen Management getroffen. Oft wird Scrum als 'Allheilmittel' angesehen, das jegliche Probleme in Abläufen und Prozessen lösen soll.
Ja es stimmt, dass Scrum Probleme in einigen Vorgehensweisen identifiziert und offen legt. Jedoch ist nicht jede Unternehmensstruktur und nicht jedes Projekt für Scrum geeignet. Es gibt noch eine Vielzahl anderer agiler Werkzeuge, die vielleicht sogar geeigneter wären, als Scrum.
Auch ist es nicht möglich, ein bereits sinkendes Schiff mit Scrum zu retten. Der Einsatz und die Einführungen müssen wohl überlegt und bedacht angegangen werden. Nur dann ist damit zu rechnen, dass der Einsatz erfolgreich sein kann.

Soll Scrum nur 'ausprobiert' werden?


Wenn die Entscheidung getroffen wurde, Scrum einzusetzen, dann sollte es nicht nur ausprobiert, sondern mit vollem Einsatz praktiziert werden. Es darf nicht der Gedanke herrschen "wenn es nicht klappt, machen wir halt einfach so weiter wie vorher".
Der Gedanke, mit 'vollem Körpereinsatz Scrum zu leben', sollte aber nicht nur von denjenigen vorgelebt werden, die Scrum eingeführt haben, sondern von allen, die damit zu tun haben, allen voran das Team. Kein anderer als die Mitglieder des Teams kommen dem Framework so nahe.
Natürlich gehören auch die 'indirekten Teilhaber' mit dazu, die über die neuen Prozesse in Kenntnis gesetzt werden sollten. Dazu gehören andere Abteilungen, die noch nicht umgestellt wurden (oder vielleicht auch nicht sollen), und die Kunden, die das Endprodukt einsetzen wollen.

Ist die Produktvision vom Product Owner erreichbar und transparent?


Um dem Entwicklungsteam einen roten Faden zu präsentieren und ein Ziel, das angegangen werden soll, muss vor dem Start mit Scrum und mehrfach während des Entwicklungsprozesses vom Product Owner dem Team seine Vision vom fertigen Produkt präsentiert werden.
Das Entwicklungsteam muss wissen, wofür es arbeitet und was das allumfassende Ziel der schweißtreibenden Arbeit ist. Dabei ist es wichtig, dass dieses Ziel bzw. diese Ziele in einem abschätzbaren Zeitraum zu erreichen sind. Theoretische Ziele, die zwar schön wären, aber eher unrealistisch sind, sind überflüssig und helfen dem Team nicht, die Aufgaben 'ernst' zu sehen und das große Ganze zu erkennen.

Besitzen die User Stories einen Kunden- und einen Unternehmenswert?


Das ist ein wichtiger Punkt, bei dem nicht nur die Kunden den Wert der Aufgaben erkennen sollen, sondern auch die Personen, die das umsetzen. Das Team muss für die eigenen Aufgaben einen Wert erkennen können, damit die eigentliche Arbeit ebenfalls an Wert und an Sinn gewinnt.
Dieser Punkt würde sich zudem auch auf das Sprint Review auswirken, das mit gehaltvolleren Aufgaben zu einer wichtigen Veranstaltung im Terminkalender der Stakeholder wird. Die Arbeit wird dadurch mehr wertgeschätzt.
Alle Aufgaben, die dem Kunden keinen Mehrwert bieten oder dem Unternehmen keinen direkten Wert darstellen, sind sekundär zu handhaben und entsprechend zu priorisieren.

Sind die Definitionen von 'selbst verwaltend' und 'selbst organisierend' bekannt?


In Scrum heißt es immer so schön, "Das Team organisiert sich selbst.". Doch was ist damit gemeint? Welche Tätigkeiten genau werden vom Team selbst verwaltet? Bei welchen Aufgaben benötigt das Team vor allem am Anfang noch Unterstützung, um es zur Selbstorganisation zu bewegen?
Dieser Punkt ist sehr individuell und unterscheidet sich nicht nur von Unternehmen zu Unternehmen, sondern auch von Person zu Person. Nicht jede einzelne Person kann eine Selbstorganisation durchführen, das Team als Ganzes jedoch schon. Wenn das Team als eine Einheit fungiert werden Absprachen, Planungen und Vorgehensweisen intuitiv und zeitnah getroffen.
In einigen Fällen klappt das bei neuen Scrum-Teams, ohne dass viel Energie in die Formierung der Teamstruktur gesteckt werden muss. Oft muss das Team aber bis zu diesem Punkt begleitet werden, was eine Vorbereitung und Durchführung eines erfahrenen Scrum Masters erfordert.

Worin besteht der Unterschied zwischen 'Scrum anwenden' und 'Scrum verstehen'?


Was ähnlich klingt und beim ersten Gedanken auch ähnlich sein kann, ist deutlich unterschiedlich. 'Scrum anwenden' ist dabei der einfache Part und beschreibt das Befolgen der Regeln von Scrum. Da nur wenige Regeln durch das Framework vorgeschrieben sind, ist es in den meisten Fällen von Teams kein Problem, diese auch zu befolgen.
Schwieriger wird es, wenn es um das eigentliche Verständnis von Scrum und die Idee dahinter geht. Die Regeln beschreiben nur die Vorgehensweise, Scrum selbst muss aber in Fleisch und Blut übergehen. Erfolgreiche Scrum Master reden nicht ohne Grund oft davon, 'Scrum zu leben' und damit ist sicher nicht gemeint, immer pünktlich zu seinen Terminen zu erscheinen.
Es geht um den Grundgedanken, die ständige Verbesserung, die optimistische Darstellung der Dinge, den Zusammenhalt im Team und der Umgang mit anderen Menschen. Es geht um Kommunikation und gegenseitigem Helfen. Es geht um das Hineinversetzen in andere Personen und die Dinge aus einer anderen Sicht zu sehen.
Dieses erweiterte Weltverständnis kann in keiner Schulung gelehrt oder erlernt werden. Scrum muss akzeptiert und praktiziert werden. Sicherlich ist nicht jede Person dazu in der Lage, alles derart positiv zu sehen wie beschrieben, oft ist es sogar realitätsfern und schadet mehr als es nützt. Doch muss das Team und jede einzelne Person bereit sein, es zu probieren. Das Team als eine Einheit kann einzelne "negative" Komponente kompensieren und funktioniert weiterhin gut und ist erfolgreich.
Die größte Unterstützung auf diesem Weg, um Scrum zu verstehen und nicht nur anzuwenden, bietet der Scrum Master, weswegen die Auswahl der geeigneten Person für diese Rolle mit Bedacht getroffen werden sollte.

Ist der Unterschied zwischen einer einzelnen Person und einem Team bekannt?


Klingt nach einer einfachen Frage, auf die man eine einfache Antwort hat. Fakt ist, ein Team besteht aus mehreren einzelnen Personen. Doch was macht ein Team aus?
Die Theorie klingt einleuchtend und logisch: Nur durch Zusammenarbeit kann ein gutes und durchdachtes Produkt an den Kunden geliefert werden. Eine Hand greift in die andere, keiner backt nur seine eigenen Brötchen. Insellösungen führen nur selten zum Ziel, Einzelkämpfer bleiben oft auf der Strecke.
In der Praxis ist es aber oft viel schwieriger. Es existiert umfangreiches Spezialwissen bei einzelnen Personen, was dazu verleitet, Aufgaben alleine zu erledigen. Das Team wird erst bei der Präsentation des Ergebnisses mit einbezogen.
Klar wird es in jedem Fall so bleiben, dass jemand auf einem Gebiet besser ist als jemand anderes, doch die eindeutigen Grenzen müssen verschwimmen. Es muss nicht jeder im Team die Aufgabe können, aber das Team als eine Einheit muss in der Lage sein, eine Lösung zu finden.
Zudem muss das Verständnis aufgebaut werden, dass das Team für die erledigten Aufgaben die Verantwortung übernimmt und nicht auf einzelne Personen gezeigt wird. Das Übernehmen von gemeinsamer Verantwortung ist der erste große Schritt hin zu einem erfolgreichen Team.

Dürfen Fehler gemacht werden?


Die Produktion von Fehlern gehört (meiner Meinung nach) zu einem Lernprozess dazu. Es kann sogar der wichtigste Bestandteil beim Erlernen neuer Dinge sein. Nur durch große oder kleine Fehlschläge wird die Mechanik durchschaut und es wird versucht, diesen Fehler zu beheben und in Zukunft zu vermeiden.
Natürlich muss differenziert werden, welche Art Fehler gemacht werden dürfen. Eine Schaltfläche an der falschen Stelle ist sicher nicht so tragisch wie der Absturz des gesamten Programms. Doch auch da entscheidet immer die Ursache, wie es zu dem Fehler gekommen ist.
Vor allem durch Probleme und Fehler ist es möglich, sich zu verbessern, da so schonungslos Schwachstellen im System hervorgehoben werden. Fehler sind daher ein wichtiger Bestandteil eines sich stetig verbessernden Systems.
Was so einfach und einleuchtend klingt, ist aber nicht allen beteiligten Personen bewusst. Sowohl dem Management des Unternehmens, als auch den ausführenden Arbeitskräften, muss bekannt sein, dass eine gewisse Fehlertoleranz vorhanden ist und bei Fehlschlägen jemanden 'nicht gleich der Kopf abgerissen wird'. Kommunikation und Transparenz sind hier die Schlüsselwörter.

Wann und wo darf der Scrum Master in die Prozesse eingreifen?


Aktives Eingreifen in Abläufe, Prozesse oder sonstige Mechaniken seitens des Scrum Masters sind weder gewünscht, noch erlaubt. Der Scrum Master ist nach den Scrum-Prinzipien nicht dazu berechtigt, eigenmächtig ohne Abstimmung und Zustimmung des Teams Änderungen zu bewirken.
Jeder Schritt und jede Änderung an Abläufen, die das Team oder einzelne Mitglieder betreffen könnten, können nur nach gemeinsamer Abstimmung erfolgen. Der Scrum Master kann und sollte solche Änderungen aber anstoßen und kann auch entsprechend argumentieren, weswegen eine Anpassung sinnvoll wäre.
Jedoch hat sich der Scrum Master stets dem Team zu beugen, da er eine dienende Rolle im Scrum Team eingenommen hat und stets zum Wohle des Teams entscheiden muss.
Selbst wenn Scrum-Prozesse nicht eingehalten werden und das Sprint-Ziel dadurch gefährdet wäre, darf der Scrum Master lediglich Hinweise und Tipps geben, gerne auch eindringlich, aktiv und selbstständig Änderungen herbeiführen darf er aber nur nach gemeinsamer Abstimmung.

Was ist das Ziel des Scrum Masters?


Die Ziele des Scrum Masters können sehr unterschiedlich sein. Diese können von der Erweiterung der persönlichen Kenntnisse bis hin zum Sprungbrett für verantwortungsvollere Positionen im Unternehmen reichen. Das sind jedoch eher persönliche Ziele, die stets untergeordnet gehandhabt werden sollten.
Eines der wichtigsten Ziele sollte die erfolgreiche Entwicklung des Endproduktes sein, der eine interdisziplinäre Führung des Entwicklungsteams vorausgeht. Ohne die Fokussierung auf dieses Ziel ist es nur schwer möglich, ein hochwertiges Produkt zu liefern und das Team glücklich und zufrieden zu stimmen.

Was ist das Ziel des Product Owners?


Für das Entwicklungsteam sind die Ziele des Product Owners sehr wichtig, da der PO für das Team der Auftraggeber ist. Natürlich können die Ziele auch auf persönliche Vorteile zugeschnitten sein, der Mehrwert des Unternehmens sowie für die Kunden müssen aber ebenfalls erkennbar sein.
Die Produktvision (oben beschrieben) stellt dabei nur eines der Ziele dar. Wichtig ist, dass vor allem die Ziele des PO kommuniziert werden, damit das Entwicklungsteam sich danach ausrichten und Prioritäten entsprechend setzen kann.

Was ist das Ziel des Entwicklungsteams?


Auch das Entwicklungsteam sollte Ziele definieren. Diese Ziele können auch in einem gemeinsamen Gesprächen mit dem PO oder übergeordneten Manager erfolgen. Wichtig ist, dass es sich nur um Teamziele handelt, die gemeinsam erreicht werden können. Ziele, die von einzelnen Personen verfolgt werden, können kontraproduktiv sein und sich schädigend auf den Scrum-Prozess auswirken.

Sind Forschungsarbeiten im Scrum-Prozess vorgesehen?


Für eine erfolgreiche Anwendung von Scrum sollten die Scrum-Regeln streng befolgt werden. Doch bleibt hierbei nicht die Agilität auf der Strecke? Nein, denn Scrum bietet auch viel Freiraum für "die tägliche Arbeit", Analysen, Verbesserungen der technischen Basis oder eben Forschungsarbeiten.
Doch an welchen Stellen können solche 'Tätigkeiten außer der Reihe' im Framework platziert werden? Ist sowas überhaupt gewollt? Sicherlich gibt es Teams, die abgeschottet von der Außenwelt ihre Arbeit zuverlässig und schnell verrichten. Ohne Einwirkungen von außen ist konzentriertes und fokussiertes Arbeiten möglich.
Eine solche Abschottung bringt natürlich auch einige Nachteile mit sich. Team-übergreifende Abwechslung oder der Blick über den Tellerrand hat viele Köpfe schon zu kreativen Ideen verleitet, die so manches Unternehmen erst groß gemacht haben.
Soll nur Kundenwünschen gefolgt werden (dessen Lösungen eben die angesprochene Kreativität oft erforderlich machen) oder soll der Kunde auch Produkte erhalten, die er bislang nicht benötigt oder angefragt hat, nach dessen Einführung aber nicht mehr drauf verzichten mag?
Viele Faktoren spielen eine Rolle, wie Scrum angewendet werden soll. Das Unternehmen selbst und die einzelnen Zieldefinitionen sollten zur Entscheidungsfindung mit einbezogen werden.

Was bedeutet Agilität in Scrum?


Agilität wird oft damit gleichgesetzt, dass jeder tun kann was er will und wann es als notwendig erachtet wird. Doch es benötigt Regeln, damit es nicht als heilloses Durcheinander endet.
Die Iterationen in Scrum bewirken, dass in abschätzbaren Zeiträumen und je nach Iterationslänge flexibel auf sich ändernde Anforderungen reagiert werden kann. Zudem unterstützt das Framework aktiv die stetige Verbesserung interner Prozesse, die je nach Aufwand sofort angewandt werden darf.
Zu beachten ist, dass Scrum feste Regeln vorschreibt, in dessen Umfang sich frei bewegt werden darf.
Diese genannten Punkte sollten stets unter Berücksichtigung des agilen Manifestes befolgt werden, dessen Werte in Scrum Anwendung finden.

Schlusswort


Alle genannten Punkte sind lediglich als Hinweis oder Denkanstoß zu sehen und können von Fall zu Fall abweichen. Es sollen viele Anregungen gegeben werden, um Scrum besser zu verstehen und erfolgreich anzuwenden. Jedem der angesprochenen Themen könnte ein eigener Beitrag gewidmet werden, doch hier sollen es nur Anreize sein.
Alle Beteiligten müssen die Offenheit mitbringen, etwas Neues zu lernen und damit auch erfolgreich zu sein. Negative Grundgedanken sollten vermieden werden.
Natürlich gibt es noch weitaus mehr Themen, die sich bei der Einführung von Scrum stellen oder erst nach einiger Zeit aufkommen. Doch viele Probleme können mit der richtigen Einstellung und Ernsthaftigkeit bereits im Vorfeld abgewendet werden.
Viel Spaß und viel Erfolg bei der Einführung von Scrum!


Falls Ihnen der Artikel gefallen hat, würde ich mich um einen geringen Unkostenbeitrag sehr freuen. Vielen Dank.

Keine Kommentare:

Kommentar posten