Ein gängiger Ansatz bei Timeboxed Iterations besteht darin, jeder Iteration so viele UserStories wie möglich zuzuordnen, um die Auslastung der beteiligten Mitarbeiter zu maximieren. Slack ist die Strategie, bewusst Zeit zu lassen, die nicht für Storys vorgesehen ist, und diese Zeit für ungeplante Arbeit zu nutzen. Obwohl dies ineffizient erscheint, führt es in der Regel zu einer deutlichen Verbesserung der Produktivität eines Teams.
Eine gute Möglichkeit, Spielräume in die Planung einzuführen, besteht darin, sie zu nutzen, um mit der inhärenten Planungsunsicherheit umzugehen. Ein Team, das durchschnittlich 20 Geschichten pro Iteration erstellt, wird nicht bei jeder Iteration genau diese Anzahl abschließen. Stattdessen sehen wir einen Bereich: sagen wir von 15 bis 22. In dieser Situation kann das Team mit der niedrigsten konstanten Zahl (15) planen und die zusätzliche Zeit als Zeitverlust betrachten.
Ein Vorteil dieses Ansatzes besteht darin, dass er die Variabilität beim Abschluss der Geschichte verringert. Anstatt uns zu fragen, ob diese Iteration die letzten fünf von 20 Geschichten vervollständigen wird, können wir mit großer Zuversicht mit 15 rechnen. Für die Planung und Koordination ist eine höhere Sicherheit oft mehr wert als der Versuch, den Durchsatz zu maximieren.
Menschen befürchten oft, dass Faulheit zu Müßiggang führt, aber es gibt viele Möglichkeiten, diese Faulheit produktiv zu nutzen. Am offensichtlichsten ist es, zusätzliche Geschichten als unverbindlichen Bonus in Angriff zu nehmen. Dies hat keinen Einfluss auf die Vorhersehbarkeit der niedrigeren Zusagequote, sorgt aber dafür, dass auf einer möglichst hohen Basis mehr geleistet wird.
Aber mehr Geschichten zu schreiben ist oft nicht die produktivste Sache. Die meisten Teams werden durch Faktoren in ihrem Arbeitsumfeld ausgebremst. Es kann zu Ineffizienzen im Build-Prozess, Unzulänglichkeiten in der Codebasis oder mangelnder Vertrautheit mit Produktivitätstools kommen (die meisten Leute haben alle möglichen unentdeckten Schätze in ihren IDEs). Die Freizeit damit zu verbringen, kann einen großen Unterschied machen, indem es die Produktivität bei zukünftigen Interaktionen steigert. Tatsächlich ist das häufigste Produktivitätsproblem, mit dem Teams konfrontiert sind, auf einen überlasteten Zeitplan zurückzuführen, der dazu führt, dass sich diese Hindernisse festsetzen.
Ein weiterer guter Einsatzbereich von Slack sind Aktivitäten, die die Zusammenarbeit mit Kunden verbessern. Das größte Hindernis für echte Produktivität ist oft ein Entwicklungsteam, das nicht wirklich versteht, wie es die Arbeit seiner Kunden und Benutzer am besten verbessern kann. Mehr über sie zu erfahren, selbst wenn es nur so einfach ist, einen Nachmittag damit zu verbringen, einen Benutzer zu begleiten, kann viel dazu beitragen, den Wert ihrer Funktionen zu steigern.
Slack verbessert die Fähigkeit eines Teams, auf dringende Anfragen zu reagieren. Oft müssen Teams zusammenarbeiten, beispielsweise um eine API für die Funktion eines anderen Teams zu erweitern. Ohne Puffer müssen solche Arbeiten in den Plan eingeplant werden, was die Verzögerung und die Zykluszeit anderer Teams erhöht. Kleinere Aufgaben können in lockerer Atmosphäre erledigt werden, schnell und mit wenig Zeremonien. Denken Sie daran, dass eine hohe Auslastung die Latenz erhöht.
Während ich Slack hier im Hinblick auf Timeboxed-Iterationen beschrieben habe, ist es auch wichtig für Continuous Flow. Wenn ein Continuous-Flow-Team ständig beschäftigt ist, ist das ein Zeichen dafür, dass es nicht genug Spielraum hat, was dazu führt, dass es langsamer auf Anfragen reagiert und sich nicht um sein Arbeitsumfeld kümmern kann.
Während Slack sowohl wichtig als auch oft unterbewertet ist, handelt es sich dabei um ein Gewürz und nicht um das Hauptgericht. Ein Zeitplan, der völlig locker ist, macht Transparenz und längerfristige Planung unmöglich. Aber darauf zu verzichten, ist so, als würde man beim Ölwechsel sparen.
Weiterführende Literatur
Weitere Informationen zu Slack, wie viel und wie man es richtig nutzt, finden Sie unter Die Kunst der agilen Entwicklung. Das Kapitel zu Slack ist im Volltext verfügbar auf seiner Website.
Tom DeMarcos Buch 2002 hatte großen Einfluss darauf, dass mehr Menschen die Bedeutung von Slack verstehen.