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