Scrum bedeutet das richtige tun, statt die Dinge nur richtig zu tun
Bevor ein Scrum Projekt begonnen werden kann, müssen das Entwicklerteam, der Product Owner und ein Scrum Master bereitstehen. Bevor jedoch das geeignete Team für das Projekt eingesetzt werden kann, muss im Vorfeld auf Technologischer Ebene entschieden werden, wie Architektur, Programmiersprache und eine grobe Meilenstein Planung für die Herausforderung umgesetzt werden soll. Nachdem all diese Aspekte berücksichtigt wurden, können im nächsten Schritt Überlegungen bzgl. des MVP (Minimal Viabel Product) gemacht werden, inwieweit der Product Owner sein Product Backlog priorisiert, um somit die Userstories in den Sprint Backlog zu transferieren, die ein hohen Business Value vorweisen. Insofern bedeutet dies im Umkehrschluss, dass sich über die Produkt-, Infrastruktur- und Meilensteinplanung sich intensivst Gedanken gemacht werden müssen und nicht dem bloßen Zufall überlassen werden darf. An dieser Stelle muss erwähnt werden, dass nicht allein die Aufsetzung einer agilen Vorgehensweise innerhalb eines Projekts von essentieller Bedeutung ist, sondern auch das Verständnis der Agilität innerhalb des Konzerns implementiert wird, damit Agiles Projektmanagement als Firmenkultur verstanden wird und nicht nur als reines Effizienztool.
Was ist eigentlich eine agile Vorgehensweise?
Scrum ist eine agile Arbeitsmethode, die es ermöglicht Produkte effektiver und effizienter zu entwickeln, und Teams besser zu organisieren. Auch das Teams sich neu reorganisieren um Wissen zu skalieren, laufend von Agilen Coaches aufmerksam gemacht werden, Software Qualität möglichst weit oben zu halten, damit hinterher Refactor Tätigkeiten überschaubar gehalten werden. Sofern das Team, der Product Owner und der Scrum Master ihre Rollen und Funktionen einhalten, sowie die Produkt Vision ggf. die Product Roadmap im Auge behalten, steht einem erfolgreichem Projektabschluss nichts mehr im Wege. Natürlich ist an dieser Stelle zu erwähnen, dass Anpassungen sprich Hinzufügungen von weiteren Artefakten hier im agilen Kontext willkommen sind. Scrum ist eine lebendige anpassungsfähige Arbeitsmethode, die in kurzen Zyklen Produktinkremente auf die von unseren getroffenen Annahmen z.B. Nutzen durch Kunden oder auch technische Umsetzbarkeit überprüft werden können. Gleichzeitig bekommen Sie mehr Kontrolle über Ihre Timeline und somit auch Ihr Budget. Scrum macht Implementierungen Transparent, was in klassischen Vorgehensmodellen wie Wasserfall erst sehr spät oder entweder gar nicht erkannt wird. Scrum ist keine allgegenwärtige Lösung Software Projekte erfolgreich zu meistern, jedoch werden Probleme aufgezeigt und können anschließend explizit angegangen werden. Scrum Teams arbeiten effizienter und skalieren in höherer Qualität, aber was noch viel wichtiger ist, sie arbeiten auch effektiver. Das bedeutet, dass sie das richtige tun, statt die Dinge nur richtig zu tun. Nur liegt das größte Problem in den Software Projekten selbst. Nämlich wenn Projekte die Greenfield Phase verlassen und Anbindung von weiteren innerbetrieblichen Systemen stattfinden, geschieht dies meist leider nicht einwandfrei. Denn Anbindungen von Systemen sind immer sehr Besorgnis erregend, weil vielleicht Services oder im schlimmsten Falle Schnittstellen gar nicht existieren um Daten von System A nach System B zu transferieren. Selbst in agilen Projekten waren dies die häufigsten Probleme die in diesem Szenario entstanden sind und wohlgemerkt bei Scrum Projekten durch die Sprint Zyklen noch größere Schwierigkeiten hervorgebracht hat.
Scrum wird häufig mit Chaos in Relation gesetzt, aber warum?
Wie gesagt, es ist kein Versagen des Scrum Frameworks, sondern vielmehr wieder das Menschlichen Versagen. Wenn gewisse Funktionalitäten benötigt werden, müssen diese im Vorfeld mit den Partner Plattformen geklärt werden, damit diese frühzeitig in die Entwicklung eingeplant werden können und das bestehende Scrum Projekt dies bis zum nächsten Sprint gewährleisten kann. Nur hier ist jetzt der Knackpunkt! Scrum Projekte verachten keine Wasserfall Projekte, jedoch sind die Zyklen in denen Produktinkremente getestet, gebaut und deployed werden wesentlich von effizienter und effektiver Natur als wie die von Wasserfall Projekten. Zum einen liegt es in der starren Planung in der sequenziellen Abarbeitung der Phasen, sowie das frühe Festschreiben der Anforderungen das zu Problematiken in Wasserfall Umgebungen sorgt. Erfahrungen zeigen, dass im Zusammenspiel von Scrum und Wasserfall Projekten eine frühzeitige Kommunikation unabdingbar ist, damit Funktionalitäten In Time, In Scope und In Budget Beidseitig abgeliefert werden kann.
Aus dem Grund ist es nicht das agile Vorgehensmodell das Schuld daran ist, dass Scrum Projekte keine Product Roadmap (Meilenstein Planung) besitzt, sondern vielmehr in diesen Projekten Menschen dafür zuständig sind, das Projekt erfolgreich ans Ziel zu führen. Die Erfahrung zeigt, dass Individuen und Interaktion Vorrang vor Prozessen und Werkzeugen haben.
Nachfolgend könnt ihr euch anschauen wie Henrik Knieberg wunderbar „Product Ownership in a Nutshell“ beschreibt.