eBizTalk - Berichten, Unterhalten, Weiterbilden
Ob Branchendiskurs, Fachartikel oder ein Blick hinter die Unternehmenskulissen: eBizTalk ist die Plattform, die uns auffordert, unsere Leser über Events und Projekte auf dem Laufenden zu halten. Und uns gegenseitig natürlich auch.

SCRUM in der Praxis – Probleme von außen betrachtet Teil 1

Veröffentlicht am 05.01.2016 von Sebastian Schneider , Agile

In der Artikelserie SCRUM in der Praxis gebe ich meine Einblicke, Erkenntnisse und natürlich auch Tipps direkt aus dem Projektalltag weiter. Ich werde keine SCRUM Einführung voranstellen, Grundkenntnisse über das Vorgehensmodel und dessen Bestandteile sind somit notwendig. Die Zielgruppe sind all diejenigen, die SCRUM bereits verwenden – egal, in welcher Rolle – und diejenigen, die SCRUM in ihren Projekten oder Unternehmen einsetzen.

Die ersten Artikel der Reihe nehmen eine Außenperspektive ein. In meiner Beraterlaufbahn habe ich in vielen SCRUM-Projekten mitgewirkt. Dabei habe ich jede Rolle begleitet, vom Entwickler und Architekt über ScrumMaster bis hin zum ProductOwner. Unabhängig davon, in welcher Rolle ich war, sind mir einige Probleme regelmäßig aufgefallen. Um diese Probleme, die man aus einer gewissen Distanz am besten erkennen und bewerten kann, geht es im Folgenden.

Wieso fangen wir direkt mit Problemen an?

Ganz einfach, Probleme hindern uns daran, unser Ziel zu erreichen. Wenn wir unser Ziel nicht erreichen, wird unser Projekt scheitern, und genau das wollen wir verhindern. Am besten können wir das, wenn wir Probleme schnell erkennen. SCRUM arbeitet selbst auch nach dem Prinzip der Reflektion und Aktion. Allgemeine Lösungen zu präsentieren ist zwar nicht immer möglich, da einige Probleme mit der Unternehmensstruktur, Prozessen oder anderen Rahmenbedingungen zusammenhängen, die eine mögliche Lösung beeinflussen können. Dennoch biete ich für den Anfang Hinweise und Tipps zum Lösen von zwei Problemen an, die den gesamten Produktentwicklungszyklus nachhaltig stören

Problem #1 – Agil, auf Teufel komm raus

Als Geschäftsführer oder Projektverantwortlicher steht man bei jedem neuen Projekt oder auch bei laufenden Projekten immer vor der Herausforderung, das optimale Vorgehen für das Projekt zu wählen. Früher hat man das Wasserfallmodell verwendet, heute ist die Entscheidung nicht mehr so einfach. Agil und Scrum ist in aller Munde, und das spricht dafür, dass dieses Vorgehen ja das Richtige sein könnte.

Der agile Trend verleitet viele Verantwortliche zu denken, sie müssen ihre Projekte agil durchführen, alles andere wäre ja nicht zeitgemäß. Das ist noch nicht so schlimm….problematisch wird es durch diesen Punkt:

SCRUM eignet sich nicht für alle Projekte

SCRUM bietet einen Lösungsansatz für komplexe Projekte, in denen viele Punkte von Anfang an nicht klar definiert werden können, seien sie technischer Natur oder die Anforderungen selbst. Das iterative Vorgehen und das offene Feedback helfen hier, den Kurs immer wieder neu anpassen zu können. Einfache Projekte mit klarem Funktionsumfang oder Projekte für den Betrieb und Service bieten keine geeigneten Voraussetzungen, um SCRUM zielorientiert einzusetzen. Für einfache, kurze Projekte mit klarem Ziel ist eher ein klassisches iteratives Vorgehen eine gute Lösung. Projekte für Betrieb und Wartung profitieren z.B. von Kanban.

Dieser Punkt wird leider zu oft übersehen oder ignoriert und führt zu zwanghaftem agilen Arbeiten. Die Folge ist, dass die spontanen Anforderungen, die zeitlich kritisch sind, immer erst durch einen Sprint laufen müssen, obwohl man sie schneller ausrollen könnte. Oder das Team arbeitet ein Pflichtenheft in Sprints ab, auch hier ist der Overhead durch SCRUM nicht gerechtfertigt, und es entstehen unnötige Kosten. Schlussendlich wird das Projekt als negativ betrachtet, und das Versagen SCRUM angelastet. Hätte man hier ein passenderes Model gewählt, wäre man effektiver – und glücklicher.

Mein Rat ist, Jedes Projekt genau zu bewerten und SCRUM vorzugsweise bei Projekten mit folgenden Kriterien verwenden:

  • Erhöhte Komplexität im Projekt
  • Unklarer Planungshorizont
  • Innovationsthemen
  • Technisches Neuland
  • Hohe Wahrscheinlichkeit zu sich ändernden Anforderungen
  • Unklare oder sich ständig ändernde Rahmenbedingungen

Ein klassisches Vorgehensmodell wie Wasserfall bietet sich dagegen bei Projekten an, die die folgenden Kriterien erfüllen:

  • Anforderungen können in der Planungsphase alle sicher bestimmt werden (und damit ist nicht die Hoffnung gemeint, dies tun zu können;-)).
  • Viele gleichartige Projekte wurden mit klassischem Vorgehen erfolgreich vom Projektleiter durchgeführt.
  • Das Projekt ist klein (zeitlich UND im Umfang).

Problem #2 – “Wir arbeiten agil, also zum Teil”

Aus Problem #1 folgt in den meisten Fällen das nächste Problem. Agilität, die nicht
gelebt wird oder werden kann. Erkennen kann man dies sehr gut daran, dass aus SCRUM zwar einige Instrumente verwendet werden (z.B: das DailySCRUM), andere wesentliche Elemente wie z.B. die Retrospektive meist wegfallen oder weggelassen werden. Begründet wird dies häufig mit Zeitmangel oder “dass man es nicht braucht”.

Dies ist eine Gefahr, da man in die Falle läuft, Agilität und Elemente klassischer Vorgehensmodelle (zwangsweise) zu mischen. Es fehlt an Transparenz, es gibt keine klaren Kommunikationsflüsse, und bei Ausnahmesituationen weiß niemand genau, was zu tun ist. Die eigentliche Produktentwicklung geht häufig im Bereinigen von Vorgehensproblemen unter. Die Folge ist meist ein nicht fertiges Produkt, Budgetüberschreitung oder gar der Abbruch des Projektes. SCRUM verliert auch bei diesem negativen Beispiel seinen guten Namen, da das Versagen auf SCRUM zurückgeführt wird, obwohl es nur an der korrekten Umsetzung scheitert.

Wie kann man dies am besten verhindern? Da dieses Problem meist in Verbindung mit der Einführung von SCRUM auftritt, muss man auch genau dort ansetzen. Es gibt zwei Möglichkeiten SCRUM, sauber einzuführen:

1. Ganzheitliches Einführen von SCRUM

Im optimalen Fall steht die Geschäftsführung hinter der Entscheidung, und alle Aktionen die notwendig sind, werden durchgeführt. Mögliche Umstrukturierungen oder Prozessanpassungen werden von allen getragen, da der Nutzen von SCRUM erkannt ist. Die Teams werden so aufgebaut, dass diese selbstorganisiert arbeiten können, und man identifiziert sich mit den agilen Prinzipien. Kosten für ScrumMaster etc. werden aufgewendet, und das Arbeiten mit Mitteln wie StickyNotes, WhiteBoards, Taskboards etc., die die Transparenz ermöglichen, werden gefördert.

2. Sanfte Einführung per Kanban

Da Option 1 in vielen Fällen nicht bzw. schwer möglich ist, da unter anderem die Umstrukturierungen zu große Ausmaße annehmen würden oder das Projekt zu weit fortgeschritten ist, um einen Hardcut zu machen, bietet sich noch die Möglichkeit, SCRUM “sanft” über Kanban einzuführen.

Hier fängt man langsam an, seine Arbeit an einem Kanban-Board zu visualisieren. Man erkennt Bottlenecks und kann mit der Work-In-Progress Limitierung den Arbeitsfluss optimieren. Danach kann man dieses Vorgehen in einer Timebox abbilden und Sprints daraus formen. Am Anfang jeder Timebox kann man planen, was darin abgearbeitet wird, die Tasks und Stories werden dabei auf das Kanban-Board übertragen. Am Ende der Timebox kann man eine Retrospektive durchführen, die dabei hilft, den Prozess gemeinsam mit dem Team zu verbessern. Dailys werden abgehalten, um den aktuellen Stand am Board zu diskutieren und Probleme zu erfassen.

Wie man sieht, sollte man die Entscheidung für oder gegen SCRUM mit vollem Bewusstsein der Konsequenzen treffen. Wenn das Projekt und das Umfeld passen, kann man SCRUM ganzheitlich einführen. Will man die aktuellen Entwicklungen nicht zu sehr ausbremsen, kann man über Kanban sanft in die Agilität wechseln. Wichtig ist aber immer, dass dieser Schritt gewollt, unterstützt, von allen mitgegangen und ständig verbessert wird.

Wie geht es weiter?

Im nächsten Teil der Serie widme ich mich den Problemen, die häufig auftreten, nachdem SCRUM in ein Projekt oder Unternehmen eingeführt wurde. Ich werde die Folgen auf laufende Projekte darstellen und Tipps geben, wie man diese unsicheren Gewässer umschiffen kann.

google_about_ebiz fb_about_ebiztwitter_about_ebizxing_about_ebiz
ebiz_consulting_expertise