Eine Time-Box ist ein Zeitabschnitt, der nicht überschritten werden darf und in dessen Grenzen Meetings oder Entwicklungs-Inkremente ablaufen. Die Time-Box ist eines der grundlegenden Konzepte in Scrum und trägt maßgeblich zur Effizienz des Prozesses bei.
Time-Boxing ist auch aus anderen agilen Methoden (z.B. Extreme Programming) bekannt und hat sich in der Praxis bewährt. Ist Ihnen jemals aufgefallen, wie effektiv Sie plötzlich arbeiten, wenn etwas zu einem gegebenen (relativ nahen) Zeitpunkt fertig sein muß? Sie trödeln nicht herum, konzentrieren sich aufs Wesentliche, fokussieren sich auf Ihr Ziel. Mit Time-Boxing kann man diese Fokussierung bewußt herbeiführen.
Das Konzept der Time-Box sollte von allen Beteiligten ernst genommen und nicht aufgeweicht werden. Dafür sorgt der ScrumMaster als Überwacher des Prozesses.
Vorteile des Time-Boxing
- Meetings konzentrieren sich aufs Wesentliche, beginnen und enden pünktlich. Nicht jeder erzählt jedem alles, sondern es werden Informationen ausgetauscht, die für alle Beteiligten von Bedeutung sind. Ein gutes Scrum-Meeting erzeugt zusätzlichen anschließenden Gesprächsbedarf im kleineren Kreis, anstatt alle zu ermüden mit für den Einzelnen uninteressanten Informationen.
- In der Software-Entwicklung erhöhen zeitlich klar definierte und abgegrenzte, nicht zu lange Intervalle (z.B. Sprint-Länge 30 Tage) die Planungssicherheit, weil Voraussagen und Schätzungen für überschaubare Zeitabschnitte mit höherer Genauigkeit möglich sind als für ein komplettes Projekt oder Release. Und wer hat schon etwas von geradezu obszön von der Planung abweichenden Projekten? Was sind solche Planzahlen wert? Erstaunlich, daß viele Projekte trotzdem so gehandhabt werden.
Nachteile des Time-Boxing
Aus Projektsicht hat Time-Boxing keine wesentlichen Nachteile, sonst würde Scrum es nicht propagieren. Time-Boxing stellt aber einige Anforderungen an Gruppen und Individuen, deren Erfüllung sich auszahlt, die aber nicht jeder ohne Training oder Umgewöhnung erfüllen kann:
- Eine gewisse Disziplin in Meetings ist unabdingbar.
- Wer sich selbst gern reden hört - der Autor dieser Zeilen gehört dazu - muß sich manchmal zurücknehmen.
- In der Lernphase kommen, besonders in Daily Scrums, manchmal nicht alle zu Wort, weil das Meeting vom ScrumMaster beendet wird, bevor alle Team Members ihren Bericht abgeliefert haben. Das reguliert sich jedoch sehr schnell selbst, weil das Team merkt, daß es unter dem Informationsdefizit leidet.
- Die bequeme Möglichkeit, eine Iteration in der Entwicklung zu verlängern, weil man nicht fertig wird, steht nicht mehr zur Verfügung, weil die Sprint-Länge von niemandem - auch nicht vom ScrumMaster - während der laufenden Iteration angepaßt werden darf. Der Vertrag zwischen Product Owner und Team ist von beiden Seiten einzuhalten - einziger Ausweg ist die unrühmliche Sprint Cancellation.
Weiter > |
---|