Szenario: Bei Versuchen mit dem neuen Raketenantrieb stellt die NASA Vibrationen fest, die sich niemand erklären kann. Welche Frage ist sinnvoller: a) Frage an die Astronauten: Ist es für die Astronauten akzeptabel, dass sie bei Ihrem Flug Virbrationen spüren die aber nur geringfügig unangenehm sind? b) Frage an die Ingenieure: Wie hoch ist das Risiko, dass noch ein Problem exisitiert, welches für die Astronauten lebensbedrohlich ist?
Was tun mit Langläufern oder zurückgestellten Aufgaben bei Scrum?
Stories oder Aufgaben, die bekanntermaßen nicht im aktuellen Sprint abgeschlossen werden können, sollten nicht ins Sprint Backlog aufgenommen werden. Das ist oft z.B. bei teamexternen Abhängigkeiten der Fall.
Aber wohin gehören sie denn dann?
Entweder teilt man so ein Issue in kleinere Teile auf, die innerhalb eines Sprint umgesetzt werden können, oder markiert es im Backlog als WARTEND.
Für den zweiten Fall kann man im Backlog eine Trennlinie eingetragen. Z.B. „— WAITING ON SOMETHING above this line —„.
Niedrig priorisierte Bugs oder Aufgaben, die prinzipiell startklar sind, und nur noch auf Zeit bzw. Priorisierung warten, gehören ans untere Ende des Backlogabschnittes, welcher fertig für den Sprint ist. D.h. direkt über eine Trennlinie „— READY FOR SPRINT above this line —„.
Was tun, damit solche Einträge nicht in Vergessenheit geraten?
- Issues die an bestimmte Termine gebunden sind, sollte man in einen elektronischen Kalender eintragen. Dann bekommt man eine aktive Erinnerung.
- Alternativ bzw. zusätzlich kann man ein Board errichten, auf dem solche Langläufer auf Wiedervorlage gelegt werden können. Das Board hat einen Bereich für jeden künftigen Sprint, auf dem diese Aufgaben geheftet werden. Zu Beginn des Sprints wird geprüft, ob die Aufgabe ins Sprintbacklog übertragen werden kann.
- Am Besten gegen das Vergessen ist jedoch eine erste Teilaufgabe zu definieren, die innerhalb eines Sprints abgeschlossen werden kann. Das ist dann die Erinnerung an die Folgeaufgabe.
Verwandte Artikel:
Coaching durch Inception
Wer kennt es nicht – Kollegen, Chef’s oder Kunden die einfach nicht den Ratschlägen folgen wollen? Alle Lösungsvorschläge finden scheinbar kein Gehör. Mit dem Inception Konzept wird es zum leichten Spiel.
Wer den Film Inception gesehen hat, bekommt eine Ahnung wie es funktioniert. Anders als im Film können wir uns jedoch nicht in den Traum unserer Zielperson einhacken. Wir können sie jedoch träumen lassen.
Statt sich auf die Probleme zu konzentrieren geht es darum ein Bild zu erzeugen, wie schön alles sein könnte: Die richtigen Menschen sprechen miteinander … über die richtigen Sachen … zum richtigen Zeitpunkt … Wäre es nicht prima, wenn es zum Releasetag keine Bugs mehr gäbe … Versuchen wir unseren Gegenüber dazu zu ermuntern, zu träumen.
Nun muss dieses Gefühl nur noch sacken. Nach einiger Zeit hat das Unterbewusstsein die damals vorgeschlagenen Lösungen mit der wunderbaren Vision verknüpft oder gar bessere gefunden. An dieser Stelle holen wir unseren Liebling wieder ab und helfen ihm bei der Umsetzung seiner Ideen.
Verwandte Artikel:
Selbstorganisation = Selbstdisziplin?
Funktioniert die in Scrum so groß geschriebene Selbstorganisation nur mit großer (Selbst-)Diszipin oder doch bloß mit intrinsischer Motivation? Oder gar nur mit externer?
Das kennt vielleicht jeder: Selbst gute eigene Vorhaben werden manchmal einfach nicht mehr durchgeführt. Was können wir leicht selbst dafür tun, die Selbstorganisation zu erhalten?
Was tun zur Stärkung der intrinsischen Motivation ohne sich unnötig zu disziplinieren?
- Den Wert des Vorhabens formulieren.
Wenn der Wert nicht hoch genug oder erstrebenswert ist, ist das schon zu Beginn ein Showstopper. - Optionen creiren. Was gibt es überhaupt für Möglichkeiten?
- Ziele konkret vornehmen oder vereinbaren. Wann genau habe ich das Ziel erreicht?
- Den ersten Schritt zum Ziel sofort aufschreiben und vielleicht sogar sofort angehen.
- Abschließend das Ergebnis des Erreichten bewerten. Beibehalten oder ändern?
Verwandte Artikel:
Agiles Projektcontrolling
Agilität bedeutet nicht, dass man orientierungslos vor sich her entwickelt. Durch folgende Praktiken haben die verschiedennen Interessengruppen einen guten Einblick in das Projekt.
- Tägliche Teammeetings
- Burndown (oder -up) Grafiken je Iteration (Sprint) und für das gesamte Release
- Echte Fortschrittsmessung mit der Definition von DONE
- Anzahl der entdeckten Fehler nach DONE Meldung
- Review Meetings am Ende einer Iteration
- Grad der Testabdeckung
Daneben natürlich die üblichen Klassiker:
- Zeit
- Kosten