Mission
Als wir Anfang der 2000er-Jahre agil Software entwickelten, hatten wir den besten Job überhaupt. Wir arbeiteten in motivierten selbstorganisierten Teams, übernahmen Verantwortung, lieferten wertvolle Software für Anwender:innen und bekamen entsprechendes Feedback.
Nicht nur wir empfanden so, viele der Entwickler:innen in den Unternehmen, die wir bei der Einführung von Scrum und XP unterstützten, äußerten sich ähnlich. Und das Management und die Kund:innen dieser Unternehmen hatten das beste Team überhaupt.
Die Stimmungslage hat sich im Laufe der Jahre leider geändert. Heute hören wir häufig: »Mit Scrum ist es immerhin nicht mehr so schlimm wie früher.« Grauenvoll! Das ist uns zu wenig! Wir wissen, dass es besser geht. Wir haben es erlebt.
Scrum ist nicht einfach eine zusätzliche Projektmanagementmethode. Es ist nichts, was angepasst werden muss, damit es in den Konzern passt. Scrum ist eine Geisteshaltung (engl. mindset): Wir sind offen für Neues und Fehlschläge, wir experimentieren, wir verbessern kontinuierlich, wie lernen, wir vertrauen, wir sind mutig, wir finden uns nicht mit dem Status quo ab. An dieser Einstellung gibt es nichts anzupassen. Es ist nur die Frage zu klären, ob man eine solche Geisteshaltung im Unternehmen will oder nicht. Und wenn man sich dafür entscheidet, muss man das Unternehmen an diese Geisteshaltung anpassen. Punkt.
Unsere Vision ist eine Welt, in der Teams und Kund:innen vertrauensvoll und kooperativ zusammenarbeiten, um coole Produkte zu entwickeln, in der Entwickler:innen erfüllt arbeiten können und gleichzeitig ihre Unternehmen erfolgreich sind.
Das wird nur gelingen, wenn wir auf Wirkungen und nicht nur auf Ergebnisse fokussieren. Das entwickelte Produkt ist ein Ergebnis. Und das entwickeln wir natürlich nicht zum Selbstzweck, sondern weil sich dadurch etwas zum Besseren ändern soll. Wir wollen etwas bewirken, normalerweise für die Kund:innen der Produkte und für unser Unternehmen (siehe äußerer Ring in Abb. 1).
Abb. 1Ergebnisse als Mittel zum Zweck, um Wirkungen zu erzielen
Die Kund:innen sollen in die Lage versetzt werden, etwas zu tun, was sie vorher so nicht tun konnten. Und gleichzeitig wollen wir als Unternehmen auch eine positive Wirkung spüren: größere Zufriedenheit und Loyalität der Kund:innen, höhere Umsätze, geringere Kosten etc.
Wie schnell welche Ergebnisse erzielt werden können (die dann hoffentlich zu den Wirkungen führen) hängt maßgeblich von der Leistungsfähigkeit des Teams ab (innerer Kreis in Abb. 1). Die Leistungsfähigkeit des Teams setzt sich zusammen aus der Leistungsfähigkeit der Individuen im Team, der Art ihrer Zusammenarbeit und der Einbettung in den Kontext. Auch hier gilt, dass wir nicht beliebig in die Leistungsfähigkeit des Teams investieren, sondern ausgehend von den gewünschten Wirkungen gezielt die Leistungsfähigkeit verbessern.
Und letztlich muss sich Agilität im Allgemeinen und Scrum im Speziellen daran messen lassen, dass sich diese Wirkungen für Kund:innen und das eigene Unternehmen auch einstellen.
Wir wollen mit diesem Buch einen Beitrag zu dieser Vision leisten. Wir verfolgen die Mission, neben der Scrum-Mechanik auch den dazugehörenden Geist zu vermitteln: das Gefühl, das sich einstellt, wenn man wirklich mit und in Scrum arbeitet. Solange sich dieses »Mensch, ist das cool!«-Gefühl nicht einstellt, ist es noch nicht so, wie es sein soll.
Hinweise zur zweiten Auflage
Das Scrum-Framework hat sich als sehr stabil erwiesen. Was sich weiterentwickelt, ist unser Verständnis davon, welche zusätzlichen Konzepte und Techniken nützlich sind und wie Scrum didaktisch gut aufbereitet werden kann.
Die zweite Auflage dieses Buches ist unserem weiterentwickelten Verständnis geschuldet. Konkret haben wir die folgenden Änderungen und Erweiterungen vorgenommen:
Wir haben das Buch an die neue Fassung des Scrum Guide vom November 2017 angepasst.
Selbstorganisierte Teams, die Probleme von Endkund:innen lösen, haben wir als agilen Kernzyklus integriert und an verschiedenen Stellen zur Veranschaulichung verwendet.
Wir haben das Thema Produktvision in Kapitel 3 stärker ausgearbeitet und insbesondere den Aspekt des Storytelling in diesem Zusammenhang thematisiert.
Story Mapping verbreitet sich als Produktkonzeptionstechnik immer weiter. Wir haben daher eine Kurzeinführung in Story Mapping in Kapitel 3 ergänzt.
Ein häufiges Missverständnis zum Sprint-Review besteht in dem Glauben, dass es sich um ein Abnahmemeeting handelt. Dieses Missverständnis greifen wir jetzt explizit beim Sprint-Review in Kapitel 3 auf.
Die Ansätze zur Aufwandsschätzung haben sich über die letzten Jahre weiterentwickelt. Entsprechend haben wir in Kapitel 6 das Thema Lean Forecasting aufgenommen.
In vielen Unternehmen wird mit Roadmaps gearbeitet. Kapitel 6 beschreibt, wie die agilen Ansätze zur Releaseplanung leichtgewichtig so erweitert werden können, dass zielorientierte Roadmaps entstehen.
Mit der steigenden Verbreitung von Scrum wird auch immer häufiger im Auftraggeber-Dienstleister-Verhältnis agil gearbeitet. Kapitel 7 gibt einen Überblick über mögliche Vertragsgestaltungen.
Hinweise zur dritten Auflage
Die vorliegende dritte Auflage dieses Buches weist die folgenden Änderungen und Erweiterungen auf:
Wir haben das Buch an die neue Fassung des Scrum Guide vom November 2020 angepasst. Die wesentlichen Änderungen bestehen darin,dass nicht mehr von Rollen, sondern Verantwortlichkeiten gesprochen wird (dies macht Scrum als Rahmenwerk für Produktentwicklung noch flexibler, weil die Wahrnehmung der Verantwortlichkeiten eben nicht zwingend exklusiv mit der entsprechenden Rolle einhergehen muss),dass es nur das Scrum-Team und kein Entwicklungsteam mehr gibt (mit der Einführung des Scrum-Teams bereits in früheren Versionen des Scrum Guide sollte die Gemeinsamkeit aller Beteiligten und insbesondere ihre gemeinsame Verantwortung gestärkt werden, gleichzeitig entstand eine begriffliche Verwirrung, weil es plötzlich zwei Teams gab, nämlich das Scrum-Team und das Entwicklungsteam; das ist jetzt klarer) unddass das Produktziel als Teil des Product Backlog aufgenommen wurde (die Einführung des Produktziels ist eine Analogie zum Sprint-Ziel für das Sprint-Backlog und klärt die Verwirrung vieler Scrum-Teams, ob denn eine Produktvision oder Ähnliches für die Produktentwicklung nach Scrum nötig ist).
Wir haben nochmal stärker verdeutlicht, dass es darum geht, Wirkungen zu erzielen, und dass das Produkt (das Ergebnis) nur Mittel zum Zweck ist.
Wir haben das Buch auf eine gendergerechtere Sprache umgestellt – auch wenn uns das sicher nicht an allen Stellen perfekt gelungen ist. Wir haben die englischen Begriffe wie Scrum Master, Product Owner und Stakeholder nicht angepasst, sprechen aber z.B. von Entwickler:innen.
Danksagung
Wir haben sehr viel Glück gehabt, dass wir so vielen verschiedenen Menschen begegnet sind, mit denen wir gemeinsam agile Erfahrungen sammeln durften oder uns über agile