
Scrum spricht bei der Dauer eines Sprints von einer Woche bis zu einem Monat. Die meisten Teams und Unternehmen haben sich bei 14 Tagen eingependelt, weil das der beste Kompromiss zwischen dem Wunsch nach kurzen Entwicklungseinheiten und der Furcht vor überhandnehmenden Planungssitzungen zu sein scheint. Aber sind zwei Wochen immer die ideale Sprintlänge?
Weiterlesen
Wenn Sie ein Buch zum Thema Scrum aufschlagen, finden Sie dort eine Formulierung wie: »Der Product Owner ist für das Projekt verantwortlich. Er trifft alle Entscheidungen.« Er entscheidet in der Theorie sowohl über den Umfang als auch den Auslieferungstermin der Software. Ich habe noch nicht ein einziges Unternehmen erleben dürfen, in dem der PO wirklich so weit reichende Befugnisse gehabt hätte, wenn es sich bei dem Projekt nicht gerade um ein internes Subsystem gehandelt hat. Die Frage lautet also, wie weit sollten die Befugnisse des Product Owners gehen, und wie weit reichen sie in der realen Welt?
Kurze Antwort: Möglicherweise, wenn es nicht an anderer Stelle ein dickes Problem gibt, und wenn man es richtig macht. Eine Vergrößerung des Teams bzw. die Hereinnahme weiterer Teams in das Projekt erfordert zunächst einmal eine tiefgehende Analyse des Ist-Zustands. Bleibt diese aus, und es regiert das Prinzip Hoffnung, dann ist es möglich oder gar wahrscheinlich, dass mehr Mitarbeiter entweder garnichts bringen oder die Sache sogar noch weiter verlangsamen.
Amerikanische Unternehmen haben es vorgemacht, und immer mehr deutsche Teams ziehen nach. An einem Tag in der Woche hat der Entwickler die totale Freiheit, zu tun, wozu auch immer er Lust hat. Wir versprechen uns davon, dass unsere Entwicklerkollegen Spaß an ihrer Aufgabe haben, dass Sie sich an diesen Tagen weiterbilden, und tolle Ideen für neue Produkte, weil das bei Google so gut funktioniert hat. Oft genug bringt die ganze Sache aber viel weniger als wir erwarten. Weil wir es falsch angehen, oder weil wir das Falsche erwarten?




