In einem spannenden Gespräch letzte Woche kam die Frage nach den drei wesentlichen Ziele eines Scrum Masters auf. Hier fiel die Aussage, das wesentliche Ziel eines Scrum Masters sei es, Kundennutzen zu stiften.
Im alten Scrum-Guide von Ken Schwaber und Jeff Sutherland hieß es, dass ein Team sein „Commitment“ zu einem Sprint-Ziel abgibt. Commitment übersetzt heißt so viel wie „Bekenntnis zu“ oder „Festlegung“. In einer Aktualisierung des Scrum-Guides aus dem letzten Jahr sorgte die Streichung des Begriffes „Commitment“ für Diskussionen in der Community.
Wenn man ein Projekt nach Scrum durchführen und damit diese Methode zur Softwareentwicklung im Unternehmen einführen will, dann sind es meist die gefühlt hohe Anzahl an Meetings, die dem Management übel aufstoßen. Auf einige Regeln, die ein Meeting von „Overhead“ (also wertlosem Mehraufwand) zu einem gewinnbringenden Aufwand machen, bin ich bereits eingegangen. Aber hat es vor diesem Hintergrund...
Immer wieder höre ich gerade bei neu aufgesetzten Teams die Frage, wieso man eigentlich zu Beginn eines Projekts oder einer Iteration in Storypoints schätzt und nicht direkt in Stunden. Die Antwort ist einfach – Storypoints sind schlichtweg die bessere Schätzgröße, aber warum?
In den Daily Stand Ups bei Scrum werden üblicherweise von jedem Team-Mitglied die folgenden drei Fragen beantwortet: Was habe ich seit dem letzten Daily Stand Up gemacht? Was werde ich bis zum nächsten Daily Stand Up machen? Gibt es etwas, das mich zur Zeit bei meiner Arbeit behindert? Meiner Erfahrung nach sorgen diese drei Fragen zu unnötigen und zeitraubenden Ausführungen und Diskussionen.
In einem Interview mit David J. Anderson, Begründer der “Kanban-Philosophie in der IT”, äußerte er sich zu der Frage nach den Grundgedanken beziehungsweise Prinzipien von Kanban und benennt drei Grundprinzipien.
Ziel jeder Softwareentwicklung ist das Entstehen eines gewissen Werts. Niemand – vor allem keine Unternehmen – entwickeln Software zum Spaß (es sei denn Spaß an der Entwicklung ist der ausgesprochene Wert). Auch in einem typischen Auftraggeber Dienstleister Verhältnis geht es darum, für beide Seiten Wert zu erzeugen.
