Agile Produktentwicklung
Agile Produktentwicklung beschreibt den Einsatz von agilen Methoden, häufig Scrum, in der Hardwareentwicklung.
Steigende Komplexität, geprägt durch immer kürzere Zyklen oder weltweit verteilte Teams, bestimmt den Arbeitsalltag und erfordert innovativere Entwicklungsprozesse. Der Einsatz von agilen Methoden hilft hier, mit weniger starren Regeln und bürokratischem Aufwand, dafür mit interaktivem Vorgehen eine neue Überlebensstrategie für Unternehmen zu schaffen.
Agile Teams weisen eine stetige Verbesserung in kurzen Sprintzyklen vor, der Arbeitsfortschritt ist spürbar. Gegenseitige Anerkennung führt zudem zu einer positiveren Arbeitsatmosphäre und somit zu einer sich selbst beflügelnden Erfolgsspirale.[1]
Geschichte[Bearbeiten]
Die Anfänge von Scrum lassen sich auf Ikujirō Nonaka und Hirotaka Takeuchi[2][3][4] zurückverfolgen. Damals schuf Jeff Sutherland[5] in einem Projekt für die Guinness Peat Aviation eine neue Rolle für die Projektleiter. Diese wurden zu Teammitgliedern, und ihre Rolle war eher die eines Moderators als die eines Managers. Ken Schwaber veröffentlichte auf der OOPSLA 1995 den ersten Konferenzbeitrag über Scrum. Darin schrieb Schwaber: „Scrum akzeptiert, dass der Entwicklungsprozess nicht vorherzusehen ist. Das Produkt ist die bestmögliche Software unter Berücksichtigung der Kosten, der Funktionalität, der Zeit und der Qualität.“[6] Der Begriff Scrum stammt aber von Ikujirō Nonaka und H. Takeuchi, die damit das Gedränge (englisch scrum) im Rugby als Analogie für außergewöhnlich erfolgreiche Produktentwicklungsteams beschrieben. Diese Teams arbeiten als kleine, selbst-organisierte Einheiten und bekommen von außen nur eine Richtung vorgegeben, bestimmen aber selbst die Taktik, wie sie ihr gemeinsames Ziel erreichen.[7]
2001 veröffentlichten Ken Schwaber und Mike Beedle mit Agile Software Development with Scrum das erste Buch über Scrum. 2003 folgte Schwabers Agile Project Management with Scrum.[8] 2003 war auch das Jahr, in dem die ersten zertifizierten Scrum Master von Schwaber ausgebildet wurden. 2007 erschien schließlich Ken Schwabers drittes Buch, „The Enterprise and Scrum“. Darin geht es nicht mehr bloß um die Einführung von Scrum in Software-Entwicklungsteams, sondern um die Ausweitung auf das gesamte Unternehmen.[9]
Parallelen zu Scrum finden sich in der schlanken Produktion (englisch lean production), die ihren Ursprung in japanischen Unternehmen hat. Sie strebt eine bessere Wertschöpfung durch verstärkte Zusammenarbeit an. Nonaka und Takeuchi führen den Erfolg solcher Unternehmen auf ein gelungenes Wissensmanagement zurück. Im westlichen Verständnis sei die Ressource Wissen auf Worte und Zahlen begrenzt. Wissen kann nach diesem Verständnis erworben oder antrainiert werden. Japanische Firmen hingegen sehen in dieser Art von Wissen nur die Spitze eines Eisbergs. Für sie ist Wissen in erster Linie implizit („tacit“). Dieses implizite Wissen ist subjektiv und intuitiv, es enthält unser Bild der Realität und unsere Vision für die Zukunft. Während explizites Wissen sich leicht darstellen und verarbeiten lässt, ist dies bei implizitem Wissen deutlich schwerer. Unternehmen wie Toyota oder Canon profitieren vom impliziten Wissen ihrer Mitarbeiter, indem sie hohen Wert auf die Interaktion zwischen ihren Mitarbeitern legen.[10]
Scrum lässt sich in diesem Zusammenhang als Gegenentwurf zur Befehls-und-Kontroll-Organisation verstehen, in der Mitarbeiter möglichst genaue Arbeitsanweisungen erhalten. Stattdessen baut Scrum auf hochqualifizierte, interdisziplinär besetzte Entwicklungsteams, die zwar eine klare Zielvorgabe bekommen, für die Umsetzung jedoch allein zuständig sind. Dadurch bekommen die Entwicklungsteams den nötigen Freiraum, um ihr Wissens- und Kreativitätspotenzial in Eigenregie zur Entfaltung zu bringen.[11]
Scrum verkörpert die Werte der agilen Software-Entwicklung, die 2001 im agilen Manifest von Ken Schwaber, Jeff Sutherland und anderen formuliert wurden:[12]
- Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge.
- Funktionierende Software ist wichtiger als umfassende Dokumentation.
- Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlungen.
- Reagieren auf Veränderung ist wichtiger als das Befolgen eines Plans.
Obwohl die von Nonaka und Takuchi beschriebenen Unternehmen, wie Fuji Xerox, Honda oder Canon, Hardware-Produkte entwickelt haben, setzten sich agile Methoden zuerst in der von steigender Komplexität gebeutelten Softwareentwicklung durch. Immer mehr Unternehmen finden jedoch zu den Ursprüngen zurück und nutzen agile Methoden, wie Scrum, wieder vermehrt in der Hardware-Entwicklung.
Agile Produktentwicklung[Bearbeiten]
Die Agile Produktentwicklung ermöglicht jedoch das Überwinden von Gegenargumenten, die die Umsetzbarkeit der Agilen Methode bezüglich der Hardware anzweifeln.
Im Fokus der Agilen Methode steht der agile Rhythmus - alle zwei Wochen wird die Planung aktualisiert und umgesetzt, das Team bekommt regelmäßiges Feedback, was wiederum zu schnelleren Erfolgen, Spaß und Selbstbewusstsein führt. Dieser Erfolgsrhythmus schweißt das Team zusammen, die Teammitglieder werden in mehr Eigenverantwortung gebracht: Menschen werden größer gemacht![1]
Um dies zu erreichen müssen zwei Aspekte fokussiert werden: Die Teams müssen sich konzentrieren können und in den Flow kommen, das Management soll in die Führung kommen. Agile Führung lässt sich wiederum anhand von drei Elementen beschreiben:
- Klare Ziele setzen
- Freiraum lassen
- Feedback geben
Der agile Handlungsrahmen[Bearbeiten]
Psychologische Grundlagen[Bearbeiten]
Parkinson's Law[Bearbeiten]
Die 1955 vom britischen Soziologen C. Northcote Parkinson im "The Economist" veröffentlichte Gesetzmäßigkeit "Work expands so as to fill the time available for its completion", impliziert, dass jeder so lange braucht, wie er Zeit zur Verfügung hat.[13]
Dementsprechend ergibt sich eine extrem hohe Relevanz der Ermittlung von Terminen, um die Produktivität der Entwicklung gewährleisten zu können. Denn grundsätzlich gilt abreißendes Engagement bei zu kurz bemessenen Terminen, sowie die Expansion der Arbeit bei zu lang bemessenen Terminen.
Students Law of Tension[Bearbeiten]
Das sogenannte Students Law of Tension beschreibt ein Phänomen, das in der Praxis hauptsächlich bei Schülern und Studenten vorzufinden ist: die Erfüllung einer Aufgabe wird bis kurz vor deren Abgabetermin geschoben. Meist führt dieses Vorgehen zu Angst, welche Konzentration und Energie entgegenwirkt. Wem es hingegen möglich ist, die Aufgabe zu portionieren und in einen realistischen zeitlichen Rahmen zu bringen, vermeidet den Anstieg von Adrenalin zum Ende eines Projektes, beziehungsweise einer Aufgabe hin, welcher zu negativer Anspannung führt.[14]
Agile Methoden ermöglichen eine Verstetigung der Antriebskraft durch Herunterbrechung der motivierenden Ausstrahlung des Endtermins auf mehrere Teiltermine und somit das Finden eines Rhythmus.
Rollen in Scrum[Bearbeiten]
Product Owner[Bearbeiten]
Der Scrum#Product_Owner stellt eine gänzlich neue Rolle in Scrum dar. Er ist verantwortlich für die Bereiche Marktanforderungen, Produktarchitektur und Projektmanagement. Da in der Praxis meist nicht eine Person alle drei Bereiche abdecken kann, ist es wichtig, dass der Product Owner hinreichend geschult wird und zusätzlich die notwendigen Menschen im Entwicklungsteam sind, um das gewünschte Produkt zu liefern.
Entwicklungsteam[Bearbeiten]
Die optimale Größe für ein agiles Team wird durch mindestens fünf, maximal acht Personen beschrieben. Diese Größendefinition beruht auf gruppendynamischen Zusammenhängen - zu große Teams weisen Schwierigkeiten in der Teamkoordination auf und sind schwer zu organisieren. Zudem neigen sie zu einer Unterordnung in Subteams mit informellen Teilprojektleitern. Zu kleinen Teams fehlt hingegen die Meinungsvielfalt und die Kapazität. Kreative Lösungen sind schwierig zu generieren.[15]
Ein weiterer fundamentaler Grundsatz ist die Befreiung der Teams von jeglicher Art der Leitung. Die Abwesenheit des Chefs hebt so die Einzelverantwortung jedes Teammitglieds auf ein höheres Niveau. Diese Verantwortungsübernahme liefert die Grundlage für konzentrierte, engagierte Lösungsfindungen im Team. Die Mitglieder kommen in einen hochdynamischen Arbeitsfluss und können ungestört kreative Lösungswege erarbeiten.
Scrum Master[Bearbeiten]
Der Scrum#Scrum_Master beschreibt eine neutrale Rolle, er hat fundiertes Wissen in den Themen Agilität (Management), Change Management und Coaching.
Grundsätzlich lassen sich drei Grundsätze festhalten, die beim Einsatz eines Scrum Masters eine zentrale Rolle spielen:
- Der Scrum Master übernimmt weder die Rolle des Product Owners noch ist er im Entwicklerteam.
- Er ist immer zu gleichen Teilen auf das Coaching des Entwicklerteam und des Product Owners ausgerichtet.
- Der Scrum Master besitzt keinerlei Weisungsbefugnis und übernimmt weder fachliche noch inhaltliche Projektverantwortung.[1]
Aktivitäten[Bearbeiten]
Alle Aktivitäten haben einen festen Zeitrahmen, die nicht überschritten werden sollen. Die empfohlene Sprintdauer beträgt zwischen 7 und 30 Tagen, häufig werden 14 Tage als Ausgangspunkt gewählt. Anstatt der im konventionellen Projektmanagement behafteten Anpassung des Zeithorizont auf die Komplexität der Aufgaben, wird bei agilen Methode ein fester Rhythmus installiert und der Grad der Fertigstellung der gewählten Time-Box angepasst. Es stellt sich folglich nicht mehr die Frage, wie viel Zeit benötigt wird, sondern was man in der festgelegten Zeit fertigstellen kann.[16]
Etappenplanung[Bearbeiten]
Um im Sprint die Inhalte des Backlogs ableiten zu können, braucht der Product Owner einen Überblick der gesamten Terminplanung des Projektes. Außerdem soll Klarheit über die konkreten Ziele des Projektes geschaffen werden. Als optimale Sichtlänge hat sich ein Zeitintervall von drei Monaten herausgestellt. Nach dem Ende dieser sogenannten Etappe, ist keine weitere Planung vorhanden, allerdings kann hier der PEP als Orientierung dienen.[1]
Die Etappenplanung erfolgt als erster operativer Planungsworkshop am Agilen Board des POT. Die Fokussierung auf drei Monate, sowie die Visualisierung am Board erhöhen die Präsenz des Planes und schafft so eine konstante Sichtlänge.
Konklave (Sprint-Backlog)[Bearbeiten]
Das Konklave findet im POT statt und dient zur Vorbereitung vor der Diskussion mit dem Team. Hierbei geht es vor allem um die Einigkeit zwischen den Verantwortlichen für Markt, Technik und Projekt.
Alle zwei Wochen zum Sprintbeginn findet das Konklave am gleichen Tag, zur gleichen Uhrzeit statt. Als Instrument dient das POT-Agile-Board, welches aus vier Spalten besteht: die erste umfasst das Backlog, die zweite ist mit "Work in Progress" betitelt, die dritte mit "Done" und die vierte mit "Definition of Done".
Das POT hält seine Ergebniswünsche schriftlich fest, indem es diese auf Post-ist schreibt und in die Backlog-Spalte klebt. Hierbei sind vier Regeln zu beachten, die bei der Erstellung des Backlogs helfen:
- Ergebnis Wünsche des POT sollten in konkreten, messbaren Ergebnissen formuliert werden - ideal sind drei Worte.
- Größe Die Wünsche sollten eine ähnliche Größe aufweisen. Zu kleine Arbeitspakete werden zusammengefasst, zu große in mehrere kleine unterteilt.
- 15 Backlog-Items Um eine übersichtliche, leicht verständliche Backlog-Liste zu garantieren, limitiert man den Umfang der Items auf 15. So kann eine gute Balance zwischen Übersichtlichkeit und der Konzentration auf die Inhalte, die das WAS beschreiben erreicht werden.
- Priorisierung Abschließend wird die Liste in Reihenfolge der Bedeutung der einzelnen Items gebracht. Das Team muss sich also auf eine Priorisierung einigen.[1]
Sprintplanung[Bearbeiten]
Nach dem Konklave kommen Entwicklungsteam und Product Owner zusammen, um die Sprintplanung vorzunehmen. Diese erfolgt in fünf Phasen und wird vom Scrum Master begleitet.
Phase 1: Diskussion der vorbereiteten Backlog-Liste[Bearbeiten]
Der Product Owner stellt dem Team den Product Backlog vor. Dieser kann nun hinterfragt werden, einzelne Items werden bewertet oder hinzugefügt. Im Vordergrund steht hier der Anspruch durch klare Zielsetzung gute Führung zu erlangen.[17]
Phase 2: Die Team-Kapazitätsplanung[Bearbeiten]
Der Backlog ist durch den Input des Teams verändert, es folgt die Abfrage nach der Bewältigungsmöglichkeit. Da es in der Praxis kaum die Idealvoraussetzung der hundertprozentigen Zuordnung der Mitarbeiter zum betrachteten Projekt gibt, muss jedes Teammitglied dahingehend seine Kapazitäten prüfen. Aus den Angaben wird eine Gruppenkapazität ermittelt, die einen visuellen Überblick bietet.[15]
Phase 3: Die gelbe Linie[Bearbeiten]
Der Höhepunkt des Sprintzyklus ist die Item-Bewältigungs-Bewertung des Teams vor dem Hintergrund der Gruppenkapazität und der neuen Backlog-Liste. Hierzu tritt ein Teammitglied an das Agile-Board und setzt eine Linie, die symbolisiert, wie viel das Team im folgenden Sprint schafft. Die Items unterhalb der Linie werden nach dem Prinzip "Wenn's gut läuft, schaffen wir diese drei Backlog-Items auch noch!"
Die Vorteile oder auch "good news" dieser gelben Linie sind:
- Die Möglichkeiten des Teams werden ins Bewusstsein gerückt. Dies erhöht die Wahrscheinlichkeit Enttäuschungen zu vermeiden!
- Die Konzentration auf möglichen Umfang befreit von lähmender Überlast!
- Das sichtbare, physische Ziehen der Linie symbolisiert das Ziel von Agile: die Selbstbestimmung im Team!
- Die Backlog-Items oberhalb der Linie wurden zugesagt!
- Eine Overperformance hinsichtlich der Erfüllung der Aufgaben unterhalb der Linie ist immer noch möglich!
- Das POT kann sich auf die Aufgaben unterhalb der Linie konzentrieren und sich über optionale Wege, wie die Erhöhung von Kapazitäten, das Tauschen von Items oberhalb mit Items unterhalb der Linie oder die Entscheidung zum gänzlichen Weglassen.[1]
Phase 4: Das Thumbs-Up-Ritual[Bearbeiten]
Die gemeinsame Sprintplanung wird mit einem symbolischen Ritual abgeschlossen: Alle Team- und POT-Mitglieder besiegeln ihre Einigkeit über die Arbeitsinhalte des folgenden Zwei-Wochen-Sprints, indem sie ihre Daumen nach oben ausgestreckt halten. Gegenseitiges in die Augen schauen fragt zusätzlich nonverbal ab, ob ein volles Commitment erreicht ist.[1]
Nach diesem sogenannten "Thumbs-up-Ritual" zieht sich das POT-Team zurück, der zweite essentielle Aspekt guter Führung wird somit eingeleitet: Freiheit lassen!
Phase 5: Das Team-Agile-Board[Bearbeiten]
Nachdem das POT-Team sich zurückgezogen hat, beginnt für das Team der Prozess der Selbstorganisation. Hierzu wird ein Agiles Board verwendet.
Die Backlog-Items mit den Ergebniswünschen des POT werden in einzelne Aktivitäten heruntergebrochen, die notwendig sind, um das Ziel am Sprintende zu erreichen. Erst diese Form der Selbstorganisation führt zur vollen Übernahme der Verantwortung des Vorgenommenen!
Daily Stand-Up[Bearbeiten]
Das Daily-Stand-up-Meeting bietet für den Agile Coach die Möglichkeit den eigentlichen Erfolg von Agile zu messen.
Um während des Meetings Konsequenz und Effizienz zu verstärken und die Gefahr einzudämmen, dass nicht alle Beteiligte Nutzen von der Diskussion haben und sich zurückziehen, ist eine gewisse Disziplin zu schaffen. Daher ist für die Dauer des Daily-Stand-up-Meetings ein Zeitraum von 15 Minuten festgelegt. Dieser Zeitkorridor reicht zum Informationsaustausch zwischen den Beteiligten aus, Angaben über Vorgenommenes, sowie was geschafft oder nicht geschafft wurde sind möglich.[18]
Im Daily sind lediglich Team und Agile Coach anwesend, das POT ist grundsätzlich nicht dabei. Eine Ausnahme würde die explizite Einladung durch das Team darstellen, um erfragte Hilfestellung zu leisten.
Sprint Review[Bearbeiten]
Das Sprint Review erfolgt nach Ablauf des Sprints.
Im Review präsentiert das Team dem POT zum ersten Mal die erarbeiteten Ergebnisse. Die sich daraus ergebende Sensibilität muss vom Agile Coach bei der Moderation berücksichtigt werden. Besonders das POT wird hinsichtlich der Führungsfähigkeit auf die Probe gestellt: Die Konzentration sollte auf dem Ergebnis, nicht auf einer Wegvorgabe liegen.[1]
Für die Präsentation der Sprintergebnisse gilt auch bei der Demo ein haptischer Ansatz: Die Ergebnisse sollten zu sehen, bestenfalls sogar anzufassen sein. Das Prinzip "go to Gemba", was soviel heißt wie an den eigentlichen, realen Ort des Geschehens gehen, kann helfen Klarheit zu erhöhen und Missverständnisse zu vermeiden.
Ein weiterer wichtiger Aspekt der Demo liegt auf der authentischen Wertschätzung, welche einen großen Motivator für die Team-Mitglieder darstellt.
Retrospektive[Bearbeiten]
Der Tenor des Teams auf die Frage, was das Entscheidendste für den Projekterfolg sei, ist das Vertrauen im Team. Eine Gelegenheit dieses Vertrauen zu schaffen, ist die Retrospektive (RETRO) - diese erfolgt alle zwei Wochen am Ende eines Sprints. Moderiert wird die einstündige Retro durch den Agile Coach.[19]
Die Retrospektive bietet die Möglichkeit, Spannungen, die sich im Rahmen des Sprints aufbauen zu erkennen und anzusprechen. Missverständnisse, die früher zu einem Eigenleben geführt hätten, können im besten Fall aufgedeckt und schnell und leicht ausgeräumt werden. Um die angestrebten Team- und Prozess-Verbesserungen zu erreichen, wird in der Retrospektive das Instrument der Feedbackvergabe genutzt. Feedback umfasst die Äußerung positiver, sowie negativer Aspekte einer zu betrachtenden Situation. Dabei ist zu beachten, dass die Aufmerksamkeit auf einen konstruktiven Lösungsansatz zu lenken ist, um sich nicht in Negativschleifen zu verfangen.[15]
Die Retrospektive ist nach der Demo angesetzt und umfasst zwei Teile: das Team-Feedback und die Prozess-Review.
Team Feedback[Bearbeiten]
Das Team-Feedback hat das Ziel, dass Team zusammenzuschweißen, die Menschen aufmerksamer und füreinander achtsam zu machen. Die regelmäßige Durchführung führt zu einem Trainingseffekt bei den Mitarbeitern:
- Die Retro befähigt die Teammitglieder dazu, die anderen intensiver zu betrachten und achtsamer wahrzunehmen.
- Positive Erinnerungen oder Erlebnisse an eine Situation festigen die Beziehungen im Team. Dementsprechend konzentriert man sich bei der Betrachtung des Sprints auch immer positive Erinnerungen an Handlungen der Teammitglieder vor Augen zu halten.
- Die Fähigkeit, positive Aspekte regelmäßig zu formulieren und Dritten mitzuteilen führt bei stetiger Wiederholung dazu, dass die Teammitglieder dies nicht bloß alle zwei Wochen in der Retro vornehmen. Die beschriebene Regelmäßigkeit erleichtert den Ausdruck von Anerkennung. Es entwickelt sich eine Positivspirale, die die Basis für verbesserte Achtsamkeit und Energie im Team bildet.[1]
Prozess-Review[Bearbeiten]
Das Prozess-Review soll das Team zur Vergegenwärtigung der Arbeit der letzten 14 Tage führen. Welche Abläufe haben beispielsweise den Entwicklungsfortschritt beschleunigt oder die Qualität der Produkte verbessert?
Teams, die sich außerhalb der Trampelpfade befinden, das heißt außerhalb der vordefinierten Prozesse arbeiten, arbeiten konzentrierter und übernehmen ein Höchstmaß an Verantwortung. Das mögliche Risiko wird durch die Retro begrenzt: Sie wirkt als Lessons-learned-Workshop, der die Korrektur von Fehlern während des Prozesses ermöglicht.
Wenn Teams sich stetig optimieren und eigenverantwortlich handeln, werden sie nach und nach zu Hochleistungsteams.[15]
Einzelnachweise[Bearbeiten]
- ↑ 1,0 1,1 1,2 1,3 1,4 1,5 1,6 1,7 1,8 Axel Schröder: Agile Produktentwicklung: schneller zur Innovation - erfolgreicher am Markt. Carl Hanser Verlag GmbH & Co. KG, München 2017, ISBN 978-3-446-45015-8.
- ↑ The New New Product Development Game. Cb.hbsp.harvard.edu, 1. Januar 1986.
- ↑ I. Nonaka, H. Takeuchi: The Knowledge-Creating Company. Oxford University Press, 1995.
- ↑ Peter DeGrace, Leslie Hulet Stahl: Wicked Problems, Righteous Solutions: A Catolog of Modern Engineering Paradigms. 1998.
- ↑ Jeff Sutherland. Abgerufen am 21. Oktober 2011.
- ↑ Boris Gloger: Scrum. Produkte zuverlässig und schnell entwickeln. 3. Auflage. Hanser Verlag, München 2011, S. 19.
- ↑ The History of Scrum (englisch) – abgerufen am 25. Dezember 2016.
- ↑ Mike Beedle. Abgerufen am 21. Oktober 2011.
- ↑ Ken Schwaber: Scrum im Unternehmen. Microsoft Press Deutschland, 2008, S. XI–XII.
- ↑ Ikujiro Nonaka, Hirotaka Takeuchi: A Theory of the Firm’s Knowledge-Creation Dynamics. In: Alfred Chandler u. a. (Hrsg.): The Dynamic Firm. The Role of Technology, Strategy, Organization, and Regions. Oxford University Press, 2008, S. 215–216.
- ↑ Boris Gloger: Scrum. Produkte zuverlässig und schnell entwickeln. 3. Auflage. Hanser Verlag, München 2011, S. 27–30.
- ↑ Scrum Code of Ethics
- ↑ Parkinson's Law. In: The Economist. 19. November 1955, ISSN 0013-0613 (economist.com [abgerufen am 25. Oktober 2017]).
- ↑ H.-C. Kossak: Lernen leicht gemacht - Gut vorbereitet und ohne Prüfungsangst zum Erfolg. Carl-Auer-Systeme Verlag und Verlagsbuchhandlung GmbH, Heidelberg 2016.
- ↑ 15,0 15,1 15,2 15,3 Agile Hochleistungsteams. In: Der F&E-Manager. Band 04/2015, ISSN 2196-9248, S. 16–21.
- ↑ Agil. In: Der F&E Manager. Band 01/2014, ISSN 2196-9248, S. 14–19.
- ↑ Roman Pichler: Agile Produktmanagement mit Scrum: Erfolgreich als Product Owner arbeiten. dpunkt.verlag, 2014, ISBN 978-3-86491-437-9 (google.de [abgerufen am 30. Oktober 2017]).
- ↑ Jason Yip: It's Not Just Standing Up: Patterns of Daily Stand-up Meetings. (psu.edu [abgerufen am 30. Oktober 2017]).
- ↑ Judith Andresen: Retrospektiven in agilen Projekten: Ablauf, Regeln und Methodenbausteine. Carl Hanser Verlag GmbH & Company KG, 2017, ISBN 978-3-446-45302-9 (google.de [abgerufen am 30. Oktober 2017]).
Diese artikel "Agile Produktentwicklung" ist von Wikipedia The list of its authors can be seen in its historical and/or the page Edithistory:Agile Produktentwicklung.
