Die Situation des Projekts besteht aktuell in einer Zweiteilung der Ressourcen. Einerseits das Tagesgeschäft mit dem „alten“ Code und andererseits die Neuentwicklung und Konsolidierung des Codes.
Nach den ersten Sprints fiel auf, dass teilweise erhebliche Zeit im Tagesgeschäft aufgewendet werden muss.
Dies brachte die Sprint-Planung trotz eingearbeiteter Puffer hierfür in Schieflage.

Als Reaktion auf diesen Umstand werden die Tagesgeschäfts-Punkte nun wie alle anderen in die Sprint-Planung, teils grob geschätzt, mit einbezogen.
Das hat teilweise dazu geführt, dass sichtbar wurde, dass die Neuentwicklung gestoppt werden muss, um Tagesgeschäft und „Liegengebliebenes“ zu bearbeiten.

Ein weiterer wichtiger Punkt sind die Not-Einsätze. Auch diese besitzen zum Teil erheblichen Impakt, da sie sich meist auf den „alten“ Code beziehen.
Da kann schon mal ein Kollege für den halben Sprint verschwinden. Diese Not-Einsätze werden nun mit roten Kärtchen am Scrum-Board gekennzeichnet und machen so Vorhandensein und den Umfang ein Stück weit sichtbar.

Meine Auffassung ist, dass das Scrum-Board die Live-Situation der Projektarbeit visuell schnell erfassbar machen muss.
Sonst kann man darauf verzichten und sich nur mit Ticketsystemen wie z. B. JIRA beschäftigen, um die Arbeit zu organisieren und zu visualisieren.
Wenn man aber nun auch „Randständiges“ (was es nicht wirklich ist) wie Not-Einsätze oder „Mach-doch-mal-schnell“ auf die Tafel bringt, erhält man einen realistischen Überblick über das lebendige Projekt und den aktuellen Stand. Man kommt in den Raum, schaut auf das Board und erhält eine realistische Momentaufnahme. Man muss in erster Instanz nicht jemanden fragen oder im JIRA diverse Diagramme scrollen und Queries absetzen. Das spart Zeit und erhöht die Sicherheit, das Projekt im Griff zu haben. So gesehen ist das Scrum-Board ein sehr gutes Hilfsmittel für Planung und dem Erkennen der Notwendigkeit gegenzusteuern.

Das ist sicherlich nicht Scrum-only zu verstehen und kann nutzbringend auch in anderen Planungsformen angewandt werden. Aber im Zusammenhang des lebendigen Scrum-Boards mit den engen Rückmeldezyklen Daily-Scrum und kurzen Sprints (bei uns 2 Wochen) ist meiner Meinung nach ein sehr gutes Controlling und Steuern von Projekten möglich.

Neues Projekt und viele neue Sachen zum Ausprobieren. Nachdem man z. B. über GPM oder überhaupt im Tagesgeschäft Wasserfall und diverse andere starre PM-Systeme erlebt hat, ist Scrum mit seinem Ansatz eine ziemliche Erfrischung.

Schlank, kaum Hierarchie und kurze Entwicklungs-Zyklen finde ich nach Halbjahres-Releases mal eine ganz gute Sache.

Zumindest, nach einem nicht so erfolgreichen Release mit langer Laufzeit, fällt mir sofort für mich wichtige Vorteile an dieser agilen Methodik auf:

1. Die Entwickler sprechen untereinander und sind durch den Daily-Scrum gehalten, täglich über ihre Arbeit zu reflektieren, um berichten zu können. Das ist ein entscheidendes Moment auch für die Zusammenarbeit. Hilfe kann schneller gegeben werden und besonders Informationen werden schnell weitergegeben.

Man erhält jeden Tag den aktuellen Stand vom Gesamt-Team. Es ist wie eine tägliche teambildende Maßnahme und wird durch die fehlende starre Hierarchie unterstützt. Letztlich gibt es (nach der Lehre) hier erst einmal nur den Scrum-Master und das Team entscheidet, was geht.

2. Man spricht sehr oft mit dem „Owner“, d. h., der Kunde ist sehr eng mit einbezogen und fühlt sich ständig involviert, kann früh abgefragt werden bei Unklarheiten und kann früh reagieren, falls etwas für ihn aus dem Ruder läuft.

Das scheint für mich der Dreh- und Angelpunkt zu sein. Nicht die Entwickler machen hier die größte Umstellung durch gegenüber der gewöhnten Praxis, sondern der Kunde.

Dieser hat den Vorteil, eng an der Entwicklung zu sein und in kleinen überschaubaren Stücken „versorgt“ zu werden. Wenn denn alles so klappt, besitzt er nach jedem Sprint mit Release-Charakter ein funktionierendes Produkt mit dem neuen Feature-Set. Ein riesen Vorteil gegenüber den Langzeit-Releases.

Aber der Kunde muss sich auf diese kurzen Iterationen einlassen und auch Angebots- bzw. Anforderungssituationen entsprechend anpassen. Das sind wohl die größten Hürden, die man in den meist starren Abläufen und Hierarchien zu überwinden hat.

Ich lasse mich vom weiteren Fortschritt überraschen.