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 2

Veröffentlicht am 11.04.2016 von Sebastian Schneider , Agile

Mit der Artikelserie SCRUM in der Praxis gebe ich meine Erkenntnisse und natürlich auch Tipps direkt aus dem Projektalltag weiter. Ich werde keine SCRUM Einführung voranstellen, Grundkenntnisse über das Vorgehensmodell 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.

Der erste Teil der Reihe hat sich mit dem ersten Schwung häufig auftretender Probleme beschäftigt. In diesem zweiten Teil werde ich weitere Hindernisse betrachten, die mir ständig begegnen und Lösungsansätze dafür präsentieren.

Problem #3 – Planungsversessenheit

Was denken die meisten, wenn ein Projekt startet? Was muss getan werden? Was ist das Wichtigste? Aus den alten, klassischen Modellen hat sich die “Unart” eingebürgert, dass die Umsetzung eines Projektes nur mit einem Plan beginnt –ein Plan, der genau beschreibt, welche Schritte wann zu machen sind. Paradox ist dabei, dass jeder weiß, dass eine vollständige und sichere Planung am Anfang unmöglich ist. Wieso ist das aber so? Projekte sind per definitionem Umsetzungen, die neu oder komplex sind und nicht ständig auftreten. Wie können wir also von Anfang an genau wissen, was wann zu tun ist? Gar nicht. Dann gibt es auch noch den Kunden: Er kann durchaus seine Meinung und Anforderungen im Verlauf des Projektes ändern, so dass der ursprüngliche Plan schnell veralten kann. Klassische Modelle wollen das durch teure Change Requests verhindern. Sie besagen, dass der Kunde das bekommt, was er am Anfang dachte zu wollen und zu brauchen. Das muss aber nicht so bleiben, da im Projektvorlauf Aspekte auftauchen oder deutlich werden, die vorab nicht in der gleichen Weise erkenn- und absehbar waren.

Die Konsequenzen können mannigfaltig sein. Am Anfang verbringt man gern viel Zeit mit Präsentationen. Man tingelt von einem Meeting ins nächste und verschwendet so wertvolle Zeit. Im Projektverlauf kommen drastischere Auswirkungen hinzu: Änderungen der Anforderungen des Kunden erfordern die Überarbeitung der Pläne. Es wird neu bewertet, ob man Anforderungen aufnehmen kann. Man fixiert sich auf den ursprünglichen Plan, der Kundenwunsch droht unterzugehen. Die Kundenzufriedenheit sinkt. Kommen jetzt noch ungeplante Umsetzungsschwierigkeiten hinzu (ja, einige Dinge kann man eben nicht planen…), wird es ganz heikel. Diese Schwierigkeiten betreffen nicht den Kunden, somit kann man ihn nicht durch Change Requests abwimmeln. Im starren Plan sind diese auch nicht aufgeführt, und genau jetzt beginnt das Projekt zu schaukeln. Die Umsetzung verlässt den Plan, Kosten und Zeit steigen an, das Management muss reagieren. Am Ende des Projektes kann ein weiterer Faktor hinzukommen: Durch zu geringes Feedback und teure Change Requests bekommt der Kunde im besten Fall das, was er am Anfang in Auftrag gegeben hat. Nicht immer ist es das, was er wirklich möchte. Dies liegt daran, dass der Kunde in der Entwicklung wenig eingebunden war. Änderungen waren nicht erwünscht oder eingeplant, auch wenn diese genau die Kundenerwartungen widergespiegelt hätten. Der erste Plan konnte am Anfang einfach nicht das ausdrücken, was der Kunde am Ende wirklich hätte haben wollen.

Was kann man dagegen tun?

Man sollte sich von Anfang an bewusst sein, dass man nicht alles perfekt planen kann. Weiterhin sollte klar sein, dass auch der Kunde am Anfang nur eine Vorstellung von dem hat, was er braucht und möchte. Im Laufe des Projektes werden diese Vorstellungen immer genauer, daher sollte man Änderungen entsprechend willkommen heißen. Diese stellen die Kundenzufriedenheit sicher. Dafür hilft es, einen gewissen Zeithorizont einzuplanen. Alles, was danach kommt, sollte man immer wieder hinterfragen, am besten gemeinsam mit dem Kunden. Und erst wenn die Informationen komplett vorhanden sind, sollte man sich an die Umsetzung der Features machen. In SCRUM wird dies durch Sprints in Kombination mit den Reviews umgesetzt. Bis zu Beginn eines neuen Sprints können Informationen im Backlog immer weiter verfeinert werden. Nach dem Sprint kann der Kunde immer validieren, ob die Umsetzungen in die richtige Richtung gehen, wenn nicht, kann er den Kurs schnell ändern. Durch die Velocity kann dennoch eine recht genaue Release-Planung umgesetzt werden, wobei auch diese immer den Kundenwünschen angepasst werden sollte. Ein weiterer Vorteil dieses Vorgehens für alle Projektbeteiligten ist, dass der “Plan” (Backlog) nie veraltet ist. Jeder kann jederzeit den aktuellen Stand erkennen und sehen, wo die Reise hingeht. Probleme werden schnell sichtbar und können behoben werden.

Problem #4 – keine Abstimmung zwischen den Beteiligten

Ein letztes Problem, das ich häufig sehe, ist, dass Projektbeteiligte sich zu selten abstimmen und zu wenig miteinander arbeiten.

Ein erfolgreiches Projekt benötigt nicht nur die Fertigstellung eines Produktes, sondern auch einen abgestimmten Vertrieb, ein passendes Marketing etc. Notwendig ist hier natürlich, dass sich diese Abteilungen regelmäßig abstimmen, am besten sitzen die entsprechenden Stakeholder direkt im Review. Wieso ist das so wichtig? Viele Maßnahmen im Vertrieb oder Marketing müssen schon vor Fertigstellung des Produktes angeschoben werden. Alle Maßnahmen beziehen sich jedoch auf das Produkt. Wenn sich das Produkt auf Grund von Marktforschung, Kundenwünschen etc. ändert, muss ggf. auch die Vertriebsstrategie angepasst werden oder anderes Marketingmaterial verwendet werden. Auch für das Umsetzungsteam ist regelmäßiges Feedback wichtig. Der Vertrieb hat oft wichtige Informationen für Features etc. Seine Informationen und Erfahrungen sind für das Projekt Gold wert.

Was ist nun die Folge, wenn keine Abstimmung zustande kommt? Keiner der Beteiligten hat eine gemeinsame Vision des Produktes, zu dem natürlich auch Vertrieb und Marketing gehören

Verhindern kann man das durch gutes Projektmarketing. Der Product Owner sollte regelmäßig Kontakt mit den Beteiligten suchen. Sie sollten zu Reviews eingeladen und nach ihrer Meinung gefragt werden. Auch sollte er Aktionen der anderen Abteilungen zum Projekt im Auge behalten, sich informieren und Input geben. Bei Planänderungen sollte er diese aktiv darüber informieren und ggf. Auswirkungen zeigen – vor allem im persönlichen Gespräch.

Einige der wesentlichen Probleme sind nun bekannt. In den nächsten Beiträgen geht es um alltägliche Dinge rund um SCRUM. Es bleibt spannend.

google_about_ebiz fb_about_ebiztwitter_about_ebizxing_about_ebiz
ebiz_consulting_expertise

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