Scrum und Fachbereich?

Wand mit Klebezettel
Von Sebastian Schneider // 30.05.2018 // 0 Kommentare

Scrum und Fachbereich - so ewas begegnet mir in größeren Organisationen häufiger. Wenn ich mit bestehenden Teams arbeiten darf, die Scrum selbst adaptiert haben, dann treffe ich sowohl Scrum und Fachbereich als Kombination an.

Der Fachbereich sieht sich meist als Product Owner und nicht als Entwicklungsteam. Oft teilen sich diese Personen auch auf beide Rollen. Eine Übersicht und Lösungsmöglichkeiten stelle ich Ihnen vor.

Was ist der Fachbereich?

​In größeren Organisationen gibt es den sogenannten Fachbereich. Dieser ist ist häufig mit Personen besetzt, die ​aus bestimmten Bereichen im Unternehmen Anforderungen in ein Team bringen. Diese Personen wissen, wie die Umsetzung vor Kunde auszusehen hat. Sie kennen ​oft den Kunden oder die Kundenanforderungen gut, wissen wo der Schuh drückt und haben häufig ein Wissen, dass tiefer geht, als es ein Product Owner haben kann.

​Je größer das Unternehmen, desto häufiger ist die Chance auf den Fachbereich zu treffen. In kleineren Organisationen ist die Rolle nicht so ausgeprägt vorhanden.

​Aufgaben

​Wenn wir uns typische Aufgaben des Fachbereichs anschauen, dann sind das sehr häufig zwei zentrale, die durch den Fachbereich erledigt werden:

  • ​Der Fachbereich kümmert sich um die Abstimmungen mit Konzenbereichen hinsichtlich Anforderungen und bringt diese zum Team.
  • ​Der Fachberich testet häufig selbst die eingebrachten Anforderungen und hat jemanden der es im eigenen Sinne testen kann.
  • ​Der Fachbereich kennt oder schreibt die Spezifikationen, die mehr oder weniger in richtiger Granularität in das Backlog wandern.
  • ​​Der Fachbereich ist sehr stark in der konkreten Umsetzung eingebunden. Er beschreibt in der Regel nicht das "was" einer Anforderung (vgl. User Story) sondern ist auf einer "wie" Ebene eingebunden.

​Fachbereich und Scrum

​Scrum kennt keine Rolle "Fachbereich", die Aufgaben innerhalb dieser Rolle sind aber durchaus nicht untypisch, auch nicht für Scrum. Aus agiler Sicht ist der Fachbereich wichtig, allerdings nicht richtig im Sinne eines Entwicklungsteam aufgestellt. In den meisten Fällen findet sich diese Rolle irgendwo zwischen Entwicklungsteam und Product Owner.

​Rollenübersicht

Product Owner

Scrum Product Owner

​Der Product Owner ist in Scrum für die Maximierung des Mehrwerts für den Kunden verantwortlich. Er trägt das Risiko für den ROI und bestimmt das grundsätzliche "Was" der Anforderungen

Scrum Master

Scrum Master

​Der Scrum Master ist der Hüter des Prozesses und dafür verantwortlich, dass Scrum richtig ausgeführt wird. Dabei unterstützt er das Team bei der Besietigung von Hindernissen und Entfernen von Verschwendung.

Entw.-Team

Scrum Entwicklungsteam

​Das Entwicklungs.- oder Umsetzungsteam erstellt das eigentliche Produkt. In diesem Team sitzen die Experten, die alle Fähigkeiten besitzen, das Produkt zu entwickeln. Sie bestimmen das grundsätzliche "Wie" der Anforderungen.

​Fachbereich

Scrum und Fachbereich

​Der Fachbereich ist oft eine Mischung aus Product Owner und Entwicklungs- bzw. Umsetzungsteam.

​Er kann sowohl bei der Definition von Anforderung helfen, als auch bei der Umsetzung eine wichtige Rolle spielen.

​Scrum und Fachbereich: ​Herausforderungen

​Herausforderungen zwischen Scrum und Fachbereich, die ich immer wieder in unterschiedlichen Unternehmen machen kann sind unter anderen:

  • ​Durch einen Fachbereich entstehen Product Backlog Items, die nicht optimal für eine Umsetzung sind. Diese sind häufig zu detailliert und nehmen die Lösung vorweg. Es geht mehr um die klassische Spezifikation, als ein typisches Product Backlog Item.
  • ​Der Fachbereich ​sieht sich oft nicht als Teil des Entwicklungsteams, in der er aber sehr wohl gut passen würde.
  • ​Es werden unnötige Verzögerungen und Verschwendung aufgebaut, denn in der Regel sind Übergaben von dem Entwicklungsteam zum Fachbereich mit Wartezeiten verbunden. Dadurch, das der Fachbereich eben nicht Teil des Teams ist.
  • ​Man findet häufig auch zusätzliche Spalten im Sprint Board, die extra für die Übergabe an den Fachbereich dienen. Auch zusätzliche Spalten, können schnell zu Verschwendung führen. Hier werden häufig künstkliche Übergaben und Wartezeiten erzeugt, die absolut nicht notwendig wären.

Lösungsansätze

​Es gibt für alle Probleme eigentlich nur eine Lösung, die wiederum die meisten Probleme erschlägt. Und das ist genau dann, wenn Sie es schaffen, dass der Fachbereich in das Entwicklungsteam wandert. Dann passiert nämlich folgendes:

​Der Fachbereich hat die fachliche Umsetzung im Blick und kann die, die es konkret umsetzen mit Rat und Tat zur Seite stehen. Und das schon während, das Product Backlog Item entwickelt wird.

​Wenn der Fachbereich aktiv im Entwicklungsteam mit arbeitet, ist sichergestellt, dass das Wissen am richtigen Platz ist. Dazu sollte der Fachbereich auch vor Ort sein.

Wenn Sie die Spalte "Abnahme" aus dem Board entfernen, dann haben Sie weniger Übergabekosten. Was passiert?

Das Product Backlog Item ist nicht fertig, wenn keine Abnahme erfolgt ist. Es wird bis zum wirklichen Ende an so einem Eintrag gearbeitet und nicht nur bis eine Entwicklung abgeschlossen ist.

​Sie müssen sicherstellen, dass das inhaltliche Wissen vom Fachbereich optimal genutzt und eingesetzt wird. Fragen Sie sich das retrospektiv oder in der Vorbereitung ​zur Veränderung bitte immer.

Scrum und Fachbereich: ​Empfehlungen bei der Betrachtung und Lösung

​Sie stehen auch vor der Herausforderung die Situation Scrum und Fachbereich in Einklang zu bringen? Schauen Sie sich die folgenden Dinge ​an und nutzen Sie diese als Reflexionsmöglichkeit.

​Transparenz

​Erzeugen Sie Transparenz. Der Sachverhalt muss inhaltlich für alle sichtbar sein. Zeigen Sie den Wertstrom, zeigen Sie aktuelle Wartezeiten und Verschwendung. Machen Sie die aktuelle Situation transparent.

​Inspect & Adapt

​Die Retrospektive ist Ihr Freund, wenn es darum geht, Verbesserungen zu identifizieren und umzusetzen. Sie können auf der Transparenz aufsetzen und nun die "Probleme" ansprechen und aufzeigen und sich überlegen, wie Lösungen aussehen.

​Gemeinsamkeit

​Achten Sie darauf, dass Sie bei solchen Entscheidungen wirklich alle Personen mit einbeziehen.

​Vermeiden Sie es, diese Definition nur mit weniger ​Personen bzw. Stellvertretern zu führen.

​Ausprägungen in der Praxis

​Ich habe mehrere Muster beobachtet und möchte diese Ausprägungen von Scrum und Fachbereich in der Übersicht wiedergeben.

Scrum und Fachbereich

Fachbereich als Product Owner

​Kann funktionieren, wenn das Entwicklungsteam alles Wissen auch ohne den Fachbereich umsetzen kann. Dann schreibt der Fachbereich mit die Anforderungen auf der Was-Ebene und bringt gemeinsam mit dem Product Owner eine eindeutige, relative Priorisierung in das Product Backlog. Solange Sie kein Gremium bilden, kann der Fachbereich als sogenanntes "PO-Team" fungieren.

Fachbereich als Entwicklungsteam

​Kann funktionieren, wenn der Product Owner in der Lage ist die Anforderungen auf der reinen Was-Ebene zu beschreiben (zum Beispiel mit User Stories). Der Fachbereich arbeiten dann im Umsetzungsteam und hilft das Verständnis zur Wie-Ebene zu entwickeln. Dabei kann er auch optimal die "Tester Rolle" spielen, ist aber - im Gegensatz zur Rolle sonst - schon sehr früh mit involviert und kann Verschwendungen reduzieren.

​Product Owner Team und Entwicklungsteam

​Kann funktionieren, wenn der Fachbereich sich klar verpflichtet nur über den Product Owner zu kommunizieren und gerade die Priorisierung und Sortierung des Product Backlogs anzuerkennen. Einige unetrstützen deshalb den Product Owner, andere helfen aktiv im Umsetzungsteam mit.

​Zusammenfassung: Scrum und Fachbereich

​Nicht jede Organisation hat die besten Voraussetzungen für ein Scrum nach Scrum Guide. Aber Sie sollten sich über die Richtung im Klaren sein und die Ziele und Grundlagen von Scrum anstreben. Fragen Sie sich immer was Ihnen die aktuelle Implementierung nützt und wie Sie damit ein Stück näher an die richtige Implementierung kommen.

Sebastian Schneider ist dem Framework Scrum - es war Liebe auf den ersten Sprint - bereits seit 2005 verfallen. Seitdem begleitet er Unternehmen (meist größere) bei der Transition in eine neue Arbeits- und Produktwelt.

Dafür findet er den richtigen Grad zwischen zielgerichteten systemischen Impulsen und dem nachhaltigen Coaching in der Organisation, um diese bei der Entwicklung und Optimierung des eigenen Kundenmehrwerts zu unterstützen und entwickelt mit ihnen Produkte, die ihre Kunden lieben.

Im richtigen Maß gehören dazu die effektive und effiziente Facilitation dazu, sowie agile Spiele und Simulationen, die sein Themenfeld auf einfache Art begreiflichen machen.

Auf Konferenzen, sei es im Fachbeirat oder als Akteur, gibt er gerne Erkenntnisse weiter und freut sich über Kontakte von Angesicht zu Angesicht.

>