Nach wenigen Tagen ergab sich folgende Bild:
Vor dem Projekt wurde ein detaillierte Spezifikation geschrieben, die zum Projektbeginn von einem Entwickler in Arbeitstasks runtergebrochen wurde, ohne Aufwandschätzung. Der Endtermin war fix. Man zerlegte die Realisierungzeit in kleine Teil-Releases und verteilt die Arbeitspakete (gleichverteilt, x Tasks pro Release). Daraus abgeleitet ergab sich eine grobe Releaseplanung bis zum Projektende. Verschiedene Elemente von Continous Integration wurde installiert: Version Control, Build Server, Unit Testing. Rollen, Regel und die Scrum Rituale, Planning & Estimation Meeting, Sprints, Demo, Retrospective und Daily Scrum wurden nicht angewendet. Der Kunde, in seiner Funktion als Product Owners oder im allgemeinen, war im Verlauf der Realisierung nicht involviert. Es gab eine ausführliche Definition von DONE, kaum jemand hielt sich dran. Wöchentlich wurden Status Meetings abgehalten. Als Projektmanagement und Entwicklertool wurde Jira eingesetzt. Wenige Wochen vor dem ersten Release wusste man nicht, ob man fertig würde. Zusammenfassend kann man sagen: kein agil, kein Scrum!
Ok, ich habe mir also eine Strategie zurechtgelegt, wie Scrum vom Team angenommen und vollumfänglich implementiert werden könnte. Grundsätzlich gab es zwei Optionen:
- Sofortige Scrum Einführung mit allen Ritualen, Rollen und Regeln, quasi "von jetzt auf gleich", oder
- Sequentielle Implementierung, nach und nach ein weiteres Element aufnehmen.
Als ich zum ersten Mal mit Scrum in Berührung kam, war ich in einem Projekt als Software Engineer tätig, was mässig erforgreich war. Der Kunde wurde mehrfach hingehalten, die Reaktionszeit war schlecht und die Bug Rate war sehr hoch. Die Projektleitung wurde ausgetauscht und mit der neuen Person kam ein neues Vorgehen - agil nach Scrum! Der ScrumMaster hat zu Beginn nur eine Regel eingeführt - wir wollen fokussierter arbeiten und alle 3 Wochen etwas nützliches produzieren.
Ich legte mir einen Plan zurecht - was daraus geworden ist und welche Erfahrungen ich gemacht habe?
Dranbleiben.
3 Kommentare:
Wenn der Kunde nicht mitspielt, sondern auf ein Pflichtenheft besteht, kann man dann überhaupt agil arbeiten? XP oder Scrum baut doch darauf auf das der Kunde involviert ist.
Gruß Jens
@Jens: Das Pflichtenheft hast du doch als Product Backlog.
Hallo,
als ich in das beschriebene Projekt als agiler Mentor beitrat, sollte es noch ein langer Weg werden, um nach Scrum zu arbeiten. Bis zu dem Zeitpunkt hier im Post war es ein klassisches Projekt.
Aber zu Deiner Frage, @Jens. Du sprichst zwei Themen an:
a) Pflichtenheft
b) Kunden-Involement
Ersteres gibt es bei einem Scrum Projekt in Form eines Produkt, bzw. Sprint Backlog's. Das Product Backlog hat allerdings eher einen visionären Charakter und kann/wird sich während der Realisierung ändern (wachsen, schrumpfen, inhaltlich, Priorisierung, etc). Das Sprint Backlog hat eher den Charakter eines Pflichthefts, wobei ich diese Terminology nicht ratsam finde, denn es ist kein Pflichtenheft im herkömmlichen Sinne. Der Kunde hat einen Satz von User Stories und ein Committment vom Team, mehr nicht! Vertrauen - das ist wichtig, denn eine User Story ist keine Spezfikation.
Kunden-Involvement: Wenn man exakt nach Scrum arbeitet ist der Kunde ein Teil vom Team - er ist der Produkt Owner. Wenn das nicht der Fall ist, ist es streng genommen kein Scrum. Trotzdem spricht nichts dagegen, agil zu arbeiten. Bei XP bespielsweise setzt man dafür einen "Proxy Customer" ein. Diese Rolle kann fix bestetzt oder im Team rumgereicht werden. Ein Teammitglied hat dann immer den Hut des Kunden auf und verhält sich wie dieser. Wie auch immer man den agilen Prozess adaptiert, irgendwann ist der Kunde immer involviert, z.B. bei der Abnahme.
Mein Rag an dieser Stelle ist, den Kunden so früh wie möglich einzubeziehen und die Software zu zeigen. Je später man einen Fehler erkennt, desto kostenintensiver ist er.
Gruss, jp
Kommentar veröffentlichen