Wenn zwei Entwickler zusammen vor einem Rechner sitzen und gemeinsam programmieren, dann bedeutet das auch die doppelten Aufwände, oder? Diese Frage begegnet mir immer wieder. Den Befürwortern fällt es häufig schwer zu erläutern, warum das so nicht richtig ist. Alistair Cockburn und Laurie Williams haben sich der Frage der Kosten und des Nutzens von Pair Programming gewidmet und kommen nach Interviews und kontrollierten Experimenten zu einem interessanten Ergebnis.
(mehr …)Besser treffen als telefonieren
Die Technik macht es möglich: verteilte Teams sind kein Problem mehr. Skype, E-Mails und andere technische Plattformen helfen, an unterschiedlichen Standorten zu sein und dennoch miteinander zu kommunizieren. Und da wir wissen, dass telefonieren besser ist als E-Mails zu schreiben, greifen wir immer mal zum Telefonhörer. Rückfragen lassen sich so schneller klären und man hat in kürzerer Zeit ein gemeinsames Verständnis. E-Mails sollten dann den Charakter der Dokumentation nach einem Gespräch haben. Und wenn wir schon telefonieren können, wieso ist es da noch besser, sich zu treffen?
(mehr …)Experte oder nicht Experte, das ist hier die Frage
Wenn ich ein Projekt bewältigen muss, dann versuche ich möglichst viele geeignete Experten in ein Team zu bekommen, denn nur eine ausreichende Anzahl von Experten kann ein erfolgreiches Projekt sicherstellen. Lieber arbeite ich mit (noch) mehr Spezialisten, die mir zu 75% oder 50% oder nur 25% ihrer Zeit zur Verfügung stehen, als auf diese Spezialisten zu verzichten oder ich verschiebe das Projekt, bis mir ausreichend Spezialisten wenigstens anteilig zur Verfügung stehen, oder?
(mehr …)Ein Commitment ist keine Garantie
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.
(mehr …)Auch selbstorganisierte Teams brauchen Führung
Immer wieder begegnet mir die Annahme, dass agile(r werdende) Unternehmen auf Manager und Personen mit Führungsverantwortung verzichten können. Ich halte das für einen Irrglauben, der häufig sowohl von einem falschen Verständnis für das Konzept „selbstorganisiertes Team“ als auch von einem zu traditionellen Bild auf das Thema Führung lebt.
(mehr …)Fokussierung im Daily Stand Up
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.
(mehr …)Alternative Schätzverfahren
Ein wichtige Aufgabe zu Beginn eines Projekts, Produkts oder einer Iteration ist die Planung der Aufgaben. In Scrum werden hier üblicherweise Features oder User Stories aufwandsbewertet. Diese Bewertung erfolgt oft durch ein Scrum Poker.
(mehr …)