Im Teil II dieses Artikels habe ich die allgemeinen Randbedingungen beschrieben. Hier in diesem Beitrag möchte ich ein paar Aspekte beleuchten: Wo sind Fehler aufgetreten, was ist gut gelaufen, was müssten wir besser machen, usw.
Fangen wir doch mal mit den Positiven Sachen an
- Kunde war alle zwei Wochen für einen Nachmittag bei uns, um das Projekt anzuschauen und offene Fragen zu besprechen, sowie die Planung der nächsten Aufgaben. Das ganze Team war jeweils während des Eröffnungsteils anwesend. Dadurch hatte auch das ganze Team ein "Gespür" für den Kunden.
- Projektstart war extrem positiv. Das Team war voll drin, wurde nicht durch andere Projekte/Arbeiten abgelenkt. Es herrschte super Stimmung. Jeder fühlte sich als Teil des Teams und Projekts. So macht es auch gleich mehr Spass. Die positive Stimmung ist auch immer gut für die Kommunikation. Dailys Scrums waren in dieser Zeit sehr aufgestellt, unterhaltsam und zugleich informativ.
- Drupal ist hervorragend für Scrum geeignet. Bereits nach einigen Tagen gibt es eine funktionierende Anwendung, die zwar noch Ecken und Kanten hat, aber immerhin läuft.
- Unser Scrumboard war zwar sehr einfach, aber sehr effektiv. Wir konnten uns voll und ganz auf den Scrumprozess konzentrieren, ohne dass wir uns noch mit irgendwelchen Tools hätten plagen müssen. Von daher für den Einstieg ein super gute Lösung: Jeder sieht auf einen Blick, wer gerade woran arbeitet und wer evtl. noch Hilfe braucht.
Es gibt aber auch einige Mängel
- Das Projekte verwässerte gegen Projektabschluss: Mitarbeiter wurden aus dem Team gezogen (Todsünde) und viele Ablenkungen durch andere Projekte/Arbeiten waren hier die Hauptkomponenten. Wenn man den Projektverlauf ein wenig genauer anschaut, dann waren die ersten Sprints sehr effektiv: Es gab viel Arbeit, jeder war beschäftigt. Gegen Ende des Projekts gab es dann keine grossen Baustellen mehr, sondern noch schleifen und feilen an den Ecken. Irgendwie gab es hier noch einen Koordinationsmangel im Kleinen.
- Leider mussten wir feststellen, dass der Kunde seinen Pflichten nicht nachkam und so extrem viel Inhalt fehlte. Das führte dazu, dass: Migrationen nicht gemacht werden konnten, ein Gesamtbild der Seite sehr spät möglich war und eben User Stories als (theoretisch) abgeschlossen waren, aber halt noch nicht getestet werden konnten, weil noch Inhalte/Daten Fehlten. Beispiel: Paymentschnittstelle Postfinance. Eingekauftes Modul, installiert. Task abgeschlossen. Es fehlten Zugangsdaten, um das ganze auch richtig zu testen. 1 Monat später kamen die dann: 1/2 Tag Aufwand, um es einzurichten und daraus resultierende Fehler noch zu beheben.
Was würde/werde ich im nächsten Projekt anders machen
Den Kunden noch besser mit einplanen und einbeziehen. Dazu gehört meiner Meinung:
- Dem Kunden bei Projektbeginn klip und klar machen, dass sein Mitarbeiten unbedingt notwendig ist. Auch der Kunde hat Pflichten! Er muss verstehen, dass wenn er seine Sachen nicht tut, die logische Folge ist, dass sich das Projekt verspätet.
- Bessere Definition von fertig. Solange man Userstories abschliessen kann, welche nur die Aufmerksamkeit des Entwicklers brauchen, ist es wohl relativ klar. Sehr oft ist man jedoch auf irgendwelche Daten angewiesen: Zugangsdaten zu Schnittstellen, Musterdaten usw. Fertig ist ein Task erst, wenn diese Sachen mit drin sind … der Kunde muss das auch verstehen.