- Engineering-Teams stehen oft unter dem Druck, „mehr Funktionen schneller zu veröffentlichen“
- Doch wenn zu viele Aufgaben gleichzeitig laufen, sinkt die Produktivität sogar
- „Das Geheimnis, um mehr auszuliefern, ist paradoxerweise, weniger zu tun“ –
Less is More
Kernprinzipien
- Alle Arbeit sichtbar machen
- Arbeit in kleine Einheiten definieren
- Laufende Arbeit begrenzen
- Ressourcen entsprechend der Kapazität zuweisen
- Bonus: Puffer schaffen für Unvorhergesehenes
# Alle Arbeit sichtbar machen
- Wenn Arbeit sichtbar wird, stellt man sich der Realität
- Wenn alle Arbeit auf einen Blick sichtbar ist, hat das folgende Vorteile
- Prioritäten lassen sich klar festlegen
- Unnötige Arbeit kann gestoppt oder pausiert werden
- Das Team kann sich darauf konzentrieren, begonnene Arbeit abzuschließen
- Das Ziel ist nicht, jede Arbeit für immer nachzuverfolgen → sondern die Realität klar zu erkennen und bessere Entscheidungen zu treffen
# Arbeit in kleine Einheiten definieren
- Wenn Arbeit zu groß ist, erschöpft sie die Energie des Teams und der Fortschritt bleibt unklar
- Die Größe von Arbeitseinheiten auf etwa 1–2 Wochen begrenzen
- Entwickler bleiben durch kurzfristige Erfolge motiviert
- Feedback kann schnell eingeholt und Anpassungen können rasch vorgenommen werden
- Vorteile kleiner Arbeitseinheiten
- Code Reviews werden einfacher
- Wissensaustausch entsteht auf natürliche Weise
- Die Zusammenarbeit im Team wird gestärkt
- Das Risiko bei Deployments sinkt
- Wenn Arbeitseinheiten kleiner werden, steigt das Tempo → Man wird nicht von komplexen Funktionen überwältigt und kann den Schwung beibehalten
# Laufende Arbeit begrenzen
- Wenn mehrere Funktionen gleichzeitig bearbeitet werden, sinkt die Produktivität eher
- Es entstehen Kosten durch Kontextwechsel → Die Anpassung an eine neue Aufgabe kann bis zu 23 Minuten dauern
- Je mehr laufende Arbeit sich ansammelt, desto eher treten folgende Probleme auf
- Qualitätsverlust
- Mehr Bugs
- Sinkende Team-Moral
- Signale für Überlastung auf Teamebene
- Mehr als 4 Aufgaben pro Entwickler
- Der Abschluss dauert länger als erwartet
- Es gibt mehr laufende als abgeschlossene Funktionen
- Signale für Überlastung auf individueller Ebene
- Nachlassende Konzentration
- Längere Reaktionszeiten bei Code Reviews
- Schwierigkeiten, in Status-Meetings Prioritäten zu erklären
# Ressourcen entsprechend der Kapazität zuweisen
- Der Ansatz „Ein Entwickler übernimmt eine Funktion“ ist ineffizient
- Die Ressourcen des Teams auf die wichtigste Arbeit konzentrieren
- Mehr Zusammenarbeit → Probleme werden schneller gelöst
- Bessere Code-Qualität → Peer Reviews in Echtzeit werden gefördert
- Arbeit wird schneller abgeschlossen
- Durch Zusammenarbeit können Entwickler ein tieferes Verständnis aufbauen
- Leistungen auf Teamebene sollten gefördert werden → Fokus auf Teamleistung statt auf individueller Leistung
# Puffer schaffen
- Der Betrieb mit 100 % Auslastung verschlechtert die Ergebnisse eher
- Unerwartete Arbeit ist unvermeidlich → nur der Zeitpunkt ist ungewiss
- Probleme, die ohne Puffer entstehen
- Das Team arbeitet reaktiv
- Die Qualität sinkt
- Innovation nimmt ab
- Technische Schulden wachsen
- Mit Puffer ergeben sich folgende Vorteile
- Flexibler Umgang auch mit unerwarteten Problemen
- Kreative Problemlösung wird möglich
- Hohe Qualität bleibt erhalten
- Ein nachhaltiges Arbeitstempo lässt sich aufrechterhalten
- Ein angemessener Puffer liegt bei etwa 20 % → kann je nach Team angepasst werden
Zusammenfassung der Kernstrategie
- Arbeit sichtbar machen → um der Realität ins Auge zu sehen
- Arbeit in kleine Einheiten definieren → um den Schwung zu halten
- Laufende Arbeit begrenzen → um die Konzentration zu steigern
- Ressourcen entsprechend der Kapazität zuweisen → um sich entlang der Prioritäten zu fokussieren
- Puffer schaffen → um flexibel zu bleiben
Fazit
- Um mehr zu schaffen, braucht es eine Strategie des Weniger-Tuns
- Die Leistung eines Teams wird nicht daran gemessen, wie viele Funktionen gleichzeitig bearbeitet wurden, sondern daran, wie effektiv es Kundennutzen liefert
- Die Aufgabe von Führungskräften ist nicht, dem Team mehr Arbeit aufzubürden, sondern unnötige Arbeit zu entfernen
12 Kommentare
Auch in dem Buch <Phoenix Project>, das auf GeekNews mehrfach erwähnt wurde, taucht eine ähnliche Aussage auf: Je näher man an 100 % Auslastung kommt, desto länger werden die Reaktionszeiten exponentiell.
Oh. Das kommt auch in dem Buch Goal vor!
<The Phoenix Project>ist schließlich selbst als die IT-Version von<The Goal>geschrieben worden.Wow … vielen Dank!!
Wir bemühen uns zwar, 80 % der Arbeit und 20 % Puffer einzuplanen, aber ich frage mich jedes Mal, nach welchem Maßstab man das festlegen soll … Manchmal denke ich auch, dass man es vielleicht einfach nach Zeit bemessen sollte.
Deshalb halte ich mir den Freitagnachmittag komplett als Zeit für eigene Entwicklungsprojekte frei!
Wenn man Aufgaben in so kleine Tasks aufteilt, bekommt die Führungskraft mit dem Gesamtbild sehr viel Macht. Die mitarbeitenden Engineers werden dadurch eher demotiviert und fragen sich: „Worauf arbeiten wir hier eigentlich hin?“ Ein typischer Nachteil von sprintbasiertem Agile.
Es wirkt, als wäre der Text zu sehr nur aus der Perspektive der Führungskraft geschrieben – genau wie der Titel sagt.
Das Momentum von Engineers wird auch stark davon beeinflusst, in welche Richtung die Führungskraft die Flagge hält. Es scheint mir, dass man auch etwas mehr darüber nachdenken sollte, wie man vermitteln kann, welchen Wert man den Kunden geben will und was der Output und das Delivery-Outcome jedes Sprints sein sollen. Natürlich sind das schwierige Soft Skills, daher sieht man nur selten Führungskräfte, die das wirklich gut können, und es gibt auch nicht viele gute Texte darüber.
Diesem Kommentar stimme ich sehr stark zu. Es bestand die Gefahr, dass Micromanagement bei technischen Aspekten aufkommt. Das ist wirklich nicht einfach.
Sollte es nicht darum gehen, das große Ganze zu teilen und die Arbeit in kleine Tasks aufzuteilen, nachdem sichergestellt ist, dass alle es verstanden haben??
Wenn man in Zeiträume von 1–2 Wochen aufteilt, scheint es ganz natürlich, dass nur ein begrenzter Kreis von Personen das Gesamtbild einer einzelnen Funktion kennt. So wie beim Unterschied zwischen Prozess und Thread. Man begrenzt den Fokus und steigert dadurch die Produktivität.
Selbst wenn man dieses Bild teilt, setzt das voraus, dass Fragen dazu aufkommen würden; zugleich habe ich offenbar auch ganz selbstverständlich vorausgesetzt, dass man das große Ganze nicht im Blick behalten kann, wenn sich die Richtung bei jedem Sprint Planning Stück für Stück verändert.
Ich stimme dem, was in diesem Artikel vorgeschlagen wird, voll und ganz zu, und gleichzeitig stimme ich auch dem von Ihnen angesprochenen Problem zu.
Tatsächlich ist das auch ein Punkt, über den ich selbst nachdenke.
Es war zwar je nach Squad unterschiedlich, aber wenn man die Teammitglieder aktiv in die Sprint-Planung einbezogen hat, trat das von Ihnen erwähnte Problem nicht auf. Während wir den Kontext des Projekts geteilt und die sich in jedem Sprint verändernde Situation gemeinsam transparent gemacht haben, damit alle die sich ändernden Aufgaben ausreichend verstehen konnten, habe ich zugleich gefordert, die Arbeit sehr fein zu unterteilen.
Wie Sie gesagt haben: Betrachtet man aus Managementsicht den Fortschritt, die Messung der Arbeitsgeschwindigkeit, den Umgang mit unerwarteten Situationen und die Opportunitätskosten, wenn Arbeitsergebnisse nicht wie beabsichtigt ausfallen, dann zeigt sich am Ende doch, dass es besser vorangeht, wenn man die Arbeit in kleine Teile aufteilt.
Ähnliche Beiträge tauchen immer wieder auf, aber die menschliche Gier kennt kein Ende, und dieselben Fehler werden wiederholt.
Eine CPU-Auslastung von 100 % ist bei Computern nicht normal,
aber bei Menschen führt eine Arbeitsauslastung von 100 % zu dem Schluss, dass man sich noch mehr anstrengen müsse ...