Scrum - Zettelwirtschaft im digitalen Zeitalter

Heutzutage ist es wichtig, die Zeitspanne bis zur Markteinführung einer Software so kurz wie möglich zu halten. Gerade SAP-Projekte sind viel zu komplex, um ein vollumfängliches Pflichtenheft zu erstellen.

Bei der Produktentwicklung nach einer klassischen Vorgehensweise vergehen oft Monate oder gar Jahre, bis eine Spezifikation fertiggestellt ist.

Und selbst nach der Fertigstellung kann diese immer noch Lücken und Unklarheiten aufweisen. Doch selbst mit einem lückenlosen Konzept besteht die Gefahr, bis zur Markteinführung mehrere Monate (oder Jahre!) am Markt beziehungsweise an den Anforderungen Ihrer Kunden vorbei zu entwickeln.

Zu den Hauptdefiziten der klassischen Softwareentwicklung zählen daher:

• zu große Entwicklungsschritte - wenn das Projekt scheitert oder in die falsche Richtung läuft, wird dies viel zu spät bemerkt
• Silo-Denken - Fachbereich und Entwicklungsbereich haben kaum direkten Kontakt
• Effizienzverluste - Bürokratie und Verwaltungsaufwand behindern die Produktivität
• Kommunikationsprobleme: Missverständnisse oder unklare Anforderungen werden zu spät bemerkt

Die Ursache für diese Probleme steckt in den Vorgehensmodellen selbst, weil diese zu unflexibel und bürokratisch sind und das gesamte Team unnötigerweise in ein Korsett zwängen. Dadurch wird die Agilität eingeschränkt und Fehler zu spät erkannt.

In Scrum wird neben dem Produkt auch die Planung iterativ und inkrementell entwickelt. Dadurch entstehen lauffähige Zwischenergebnisse (Produkt-Inkremente), die frühzeitig dem Kunden bzw. Fachbereich vorgelegt werden können.

Durch diese Transparenz werden fehlende oder falsch verstandene Anforderungen schnell sichtbar und können in der nächsten Iteration (Sprint genannt) berücksichtigt werden.

Der Entwicklungsprozess in Scrum

Scrum beruht auf einem sehr einfachen Prozess. An einem Scrumprozess sind lediglich drei Rollen beteiligt.

Der Product Owner stellt die fachlichen Anforderungen, der Scrum Master entspricht der Rolle eines Projektleiters, das Scrum Team entwickelt das Produkt.

Product Backlog

Im  Product Backlog werden die Anforderungen gepflegt, erweitert und priorisiert.

Im Gegensatz zum klassischen Vorgehen mit Pflichten- und Lastenheft wird das Product Backlog bei Bedarf verändert. So können neue Erkenntnisse oder Gegebenheiten direkt in die Produktentwicklung einfließen.

Es dient als einzige Anforderungsquelle für alle Änderungen am Produkt. Im Product Backlog werden alle Features, Funktionalitäten, Verbesserungen und Fehlerbehebungen aufgelistet, die die Änderungen an dem Produkt in zukünftigen Releases ausmachen, es entwickelt sich mit dem Produkt und dessen Einsatz weiter und ist kein starres Gebilde wie ein Pflichtenheft.

Sprint Backlog

In fest definierten und regelmäßigen Abständen wird ein Arbeitspaket, das sogenannte Inkrement, aus dem Product Backlogs definiert.

Das Inkrement wird während dem Sprint, das Herzstück der Scrum-Methodik, abgearbeitet. Das Sprint Backlog ist die Menge der für den Sprint ausgewählten Product Backlog-Einträge.

Das Sprint Backlog macht die gesamte Arbeit sichtbar, die das Entwicklungsteam abarbeiten muss, um das Sprint-Ziel zu erreichen.

Der Sprint

Das Herz von Scrum ist der Sprint, eine Zeitspanne von maximal einem Monat, innerhalb dessen ein fertiges, nutzbares und potenziell auslieferbares Produkt-Inkrement hergestellt wird.

Das Inkrement wird während dem Sprint abgearbeitet. Dafür wird das Inkrement in kleinere Arbeitspakete, den sogenannten Tasks, aufgeteilt, einem Bearbeiter zugeordnet und der Aufwand geschätzt.

Eine Aufgabe kann einen vom Team festgelegten Status einnehmen, zum Beispiel „Zu erledigen“, „in Arbeit“ und „Erledigt“.

Während eines Sprints werden alle Aufgaben auf Post-Its notiert und an eine Pinnwand, das sogenannte ScrumBoard, gehängt. Dieses Scrumboard ist zum Beispiel in die drei Spalten „Zu erledigen“, „In Arbeit“ und „Erledigt“ aufgeteilt.

Jedes Team oder Teammitglied kennzeichnet den Arbeitsfortschritt, indem es die jeweiligen Zettel dem richtigen Status auf der Pinnwand zuordnet.

In einem täglichen 15-minütigem Meeting, dem sogenannten Daily Scrum, stimmt das Projektteam seine Aktivitäten für die nächsten 24 Stunden ab.

Dabei beantwortet jedes Teammitglied drei Fragen:

• Was habe ich seit dem letzten Daily Scrum getan?
• Was plane ich bis zum nächsten Daily Scrum zu tun?
• Hat mich bei der Arbeit etwas behindert (Impediments)?

Fortschrittskontrolle in Richtung eines Ziels

Am Ende des Sprints, dem sogenannten Sprint Review Meeting präsentiert das Team das Ergebnis und das Feedback fließt in die Planung der kommenden Sprints ein und der Prozeß beginnt von neuem.

Durch diesen iterativen Ansatz können Sie fehlende Anforderungen schneller identifizieren und Lösungsansätze effizienter definieren.

ScrumBoards hängen in einem Büro an der Wand und sind damit wenig agil und flexibel.

Speziell in SAP- Projekten sind meistens so viele Menschen beteiligt, dass diese nicht in ein Büro passen, bzw. die räumlichen Gegebenheiten keinen Platz für einen dedizierten Teamraum aufweisen.

Dazu kommen zusätzliche logistische Schwierigkeiten durch Nearshoring- oder Offshoring-Komponenten.

Auch im Stakeholder-Meeting erweist sich ein Whiteboard als sperriges und wenig praktikables Instrument, um den aktuellen Stand der Dinge zu präsentieren.

Backlog und Burndown werden oftmals in Excel-Listen verwaltet, und der Projektfortschritt wird ebenfalls manuell in einer Excel-Liste verwaltet, um ein Burndown-Chart erzeugen zu können.

Elektronische Alternative

Elektronische ScrumBoards bieten hier eine sinnvolle Alternative, da sie den gesamten Scrum-Prozess in einer Anwendung vereinen und jedes Teammitglied jederzeit Zugriff darauf hat.

„Virtuelle Post-Its“ verlieren nicht ihre Haftwirkung und die Pinnwand kann endlich wieder als Pinnwand genutzt werden.

Sollten die räumlichen Gegebenheiten einen Teamraum erlauben, können Sie das elektronische ScrumBoard auch auf einem (touchfähigen) TV oder Bildschirm für alle Teammitglieder darstellen.

Scrum in SAP

In einem SAP Projekt haben diese elektronischen Scrumboards allerdings den Nachteil, dass es keine Integration ins SAP System gibt.

Zur optimalen Ausschöpfung der Scrum- Methodik bringt das bsc ScrumBoard für integrierte SAP®-Entwicklungen eine erhebliche Effizienzsteigerung in Ihr Team.

Durch die Nutzung des modernen UI5- Frameworks besticht unser ScrumBoard durch ein modernes und intuitiv bedienbares Oberflächen-Design.

Per Drag & Drop kann es einfach bedient werden und lässt ihre Team-Mitglieder die Aufgaben konzentrierter und schneller erfüllen.

Kontrollinstanzen müssen auf wesentliche und aktuelle Informationen nicht verzichten.

Das digitale ScrumBoard unterstützt Sie und ihr Team bei allen täglichen Aktivitäten und Statusbearbeitungen paralleler Projekte, die Zuweisung und Verwaltung neuer Aufgaben und vielen weiteren Aktionen ohne verwirrende oder ablenkende Zusätze.