Prolog: Wenn ich den Begriff “Ressourcen” in Zusammenhang mit Mitarbeitern höre, rollen sich mir die Fußnägel hoch und das sieht nicht nur komisch aus, das riecht auch seltsam. Übersetzt bedeutet das Wort Ressource schlicht “Mittel” und unter “Mittel” versteht man Methoden, Werkzeuge oder Geld. Worte machen Leute und – auch wenn sie oft unüberlegt verwendet werden – sind die häufig Ausdruck für Haltungen. Menschen sind grundsätzlich keine Maschinen, keine replizierbaren Werkzeuge, sondern komplexe Individuen. Es ist mir wichtig, das einleitend als Grundhaltung zu beschreiben.
Continue ReadingWäre es nicht schön, wenn man in die Zukunft blicken könnte? Man wüsste beispielsweise die Lottozahlen oder könnte möglichen Rahmenbedingungen in der Zukunft bereits in der Gegenwart begegnen. Auch in der Softwareentwicklung wollen wir gerne die Zukunft vorhersagen. Wir nennen das dann Aufwandsschätzung und glauben oder hoffen, dass wir durch besonders ausgefeilte Techniken in die Zukunft blicken können. Wenn wir das nur könnten, dann würden Projekte – klein wie groß –rechtzeitig und innerhalb des Budgets fertig. Wir hätten keine Sorgen mehr.
Continue ReadingWenn 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.
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?
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 Sinn, neben den täglichen Abstimmungen, den Plannings und Retrospektiven auch noch einen „Backlog Grooming“ Termin einzuführen?