TopMenue

13. Permanente Weiterentwicklung von Produkt, Prozess und Team

Dieser Beitrag befindet sich noch in Bearbeitung!

scrum.that.runs

Ein Teil dieser Seiten wurde ursprünglich für doktor-scrum.de geschrieben und ziehen nun hierher nach scrumcess.de um; leider sind sie aber inhaltlich noch nicht vollständig auf scrumcess.de umgearbeitet. Zudem ist es durchaus möglich, dass die enthaltenen Links noch ins Leere zeigen, bzw. noch auf doktor-scrum.de verweisen.
Ich bitte Sie, das zu entschuldigen.


Kontinuierliche Reifung von Effizienz und Qualität durch permanente Weiterentwicklung von Produkt, Prozess und Team führen zu einer permanenten Verbesserung und Optimierung der Abläufe und ermöglicht bestmögliche Ergebnisse für das Erreichen höchstmöglichen Wertschöpfungspotenzials

Kontinuierliche Weiterentwicklung des Produktes  ^

Scrum ist ein iterativer Prozess, in dessen Verlauf in kurzen Zyklen jeweils weiterentwickelte, vollständig lauffähige und im Rahmen der in der Reihenfolge ihrer Priorität vollständig fertig realisierten Anforderungen produktiv einsetzbare Produktinkremente an den Auftraggeber ausgeliefert werden. Ein Produktinkrement ist also eine Weiterentwicklung und Verbesserung der zuvor an den Auftraggeber ausgelieferten Produktinkremente.

Kontinuierliche Weiterentwicklung des Teams und des Prozesses  ^

Nicht nur das Produkt unterliegt einer permanenten Weiterentwicklung, sondern auch das Team entwickelt sich selbst und den vom ihm eingesetzten Prozess stetig weiter. Am deutlichste wird das bei neuen, noch Scrum-unerfahrenen Teams, denn insbesondere sie müssen den Umgang mit Scrum zunächst einmal erlernen. Dafür ist es für sie notwendig, sich mit dem Prozess zu beschäftigen, um seine Rahmenbedingungen, seine Chancen und Stolpersteine auszuloten und zu erfahren. Der Scrum-Master wird ein Auge darauf haben, dass das Team sich an die Rahmenbedingungen von Scrum hält. Im Laufe des Einsatzes von Scrum wird das Team Erfahrungen mit Scrum und — vor allem — mit sich selbst und dem eigenen Verhalten als Einzelne und als Gruppe machen.

Diese Erfahrungen werden permanent in der täglichen Arbeit miteinander gemacht und im Verlauf der permanenten intensiven Kooperation und Kommunikation zwischen den beteiligten Team-Mitgliedern und im Dialog mit dem Scrum-Coach, bzw. Scrum-Master, bzw. in einem extra hierfür definierten Meeting, der Sprint-Retrospektive, thematisiert. In der Sprint-Retrospektive reflektiert das Entwicklungsteam gemeinsam mit dem Scrum-Master über den jeweils vergangenen Zeitabschnitt — also im allgemeinen den abgelaufenen Sprint — und diskutiert darüber, welche Dinge gut gelaufen sind, welche nicht so gut und welche Dinge verändert werden sollten, um einen auf diese Weise so optimal gestalteten Ablauf wie möglich zu erreichen.

Die Diskussion(en) in der Sprint-Retrospektive sollte(n) in jeweils konkrete Beschlüsse münden, die zeitnah, am besten gleich im folgenden Sprint, umgesetzt werden und die zu einer Verbesserung des Ablaufs zwischen den Teammitgliedern, bzw. zu einer Weiterentwicklung und Verbesserung des Scrum-Prozesses im Zusammenhang mit dem konkreten Team führen sollten.

Die Sprint-Retrospektive ist ein rein internes Meeting des Entwicklungsteams, das sie gemeinsam mit dem Scrum-Master durchführen. Um eine offene und konstruktive Atmosphäre zu erreichen, nehmen weder der Product-Owner, noch Gäste an dem Meeting teil. Sollten die Entwickler in der Sprint-Retrospektive allerdings den Product-Owner und/oder die Stakeholder als Ursprung von Problemen identifizieren, sollten sie die Sprint-Retrospektive zunächst zu Ende führen und sich im Anschluss zeitnah um ein Gespräch mit dem Product-Owner bemühen, da er nicht nur für sich selbst, sondern auch für die ggf. betroffen Stakeholder sprechen kann.

Auf diese Weise verbessert sich das Entwicklungsteam permanent in der Handhabung des Scrum-Prozesses, aber auch in ihrer Leistung und in ihrer Geschwindigkeit, weil Hindernisse, deren Ursprung in der Zusammenarbeit der Teammitglieder miteinander und im Zusammenhang mit dem Prozess begründet waren, reflektiert und behoben wurden. Man rechnet, dass ein ganz neues Team mindestens ca. 3 Sprints braucht, um eine halbwegs vorhersagbare Performance zu erreichen, was nicht bedeutet, dass sie nicht schon in diesen 3 Sprints produktiv wären, aber es kann durchaus sein, dass z.B. die Schätzungen des in einem Sprint realisierbaren Umfangs an Anforderungen weit neben der Realität liegen.

Feedback der Stakeholder  ^

Am Ende eines jeden Sprints erhalten die Stakeholder ein Produktinkrement, das die jeweils für sie wichtigsten und damit wertvollsten Anforderungen vollständig implementiert enthält. Es handelt sich damit jeweils um eine Version, die im Rahmen der implementierten Anforderungen produktiv durch die Stakeholder einsetzbar ist. Auf diese Weise erhalten die Stakeholder regelmäßig in kurzen Zeitabständen die Möglichkeit, sich von dem aktuellen Stand der Entwicklung, vom Produkt und seinem „Look & Feel“ und der aktuellen Benutzbar- und Einsetzbarkeit des Produktes ein eigenes Bild zu verschaffen.

Beta-Versionen
Bei den jeweiligen Produktinkrementen handelt es sich daher um sehr frühe Beta-Versionen, die zwar jeweils noch nicht alle geplanten Anforderungen des Endproduktes enthalten, in denen die implementierten Anforderungen — nach Stand der Dinge — jedoch vollständig und abschließend implementiert wurden und sich damit in einem durch die Stakeholder vollständig testbaren und potenziell in Produktion einsetzbaren Zustand befinden.

Fordern und Testen
Die Aufgaben der Stakeholder in einem Scrum-Projekt bestehen nicht nur darin, gemeinsam mit dem Product-Owner die permanent das ganze Projekt über andauernde Anforderungsanalyse durchzuführen, sondern darüber hinaus auch darin, das am Ende eines Sprints an sie übergebene Produktinkrement nicht nur zu anzuschauen, sondern es auch unter Produktionsbedingungen einzusetzen und in allen realisierten Funktionen und Möglichkeiten so ausführlich wie möglich zu testen.

Erfahren und berichten
Die Aufgabe der Stakeholder ist, zu überprüfen, ob die jeweiligen Anforderungen aus ihrer fachlichen Sicht heraus korrekt umgesetzt und durchgeführt wurden. Sie sollen prüfen, ob es nicht nur das ist, was sie wollten, sondern ob es auch das ist, was sie wirklich brauchen und ob es für sie uneingeschränkt einsetz- und benutzbar ist.
Sie sollten Erfahrungen mit dem Produkt sammeln und ein Gefühl dafür bekommen, wie es sich für sie im Betrieb „anfühlt“. Die Ergebnisse ihrer Analyse sollten sie dem Product-Owner im Zuge der permanenten Anforderungsanalyse diskutieren und zur Verfügung stellen, da die Ergebnisse und Erfahrungen dadurch als direktes Feedback in das Projekt zurückfließen, um dort zeitnah in Form weiterer Anforderungen oder als Bestätigungen des Erstellten berücksichtigt werden zu können.

Spürbare Verbesserungen
Dieses wertvolle Feedback der Stakeholder stellt eine für den Fortgang des Projektes essenzielle Informationsquelle für das Scrum-Team dar und führt zu einer spürbaren Verbesserung des Produktes.

Prinzipien und Werte bilden ein System  ^

Jedes Prinzip und jeder Wert ist der Kopf einer eigenen Beeinflussungskaskade anderer Prinzipien und Werte, denn jede Wertänderung wirkt sich auf weitere Prinzipien und Werte, die auf ihnen aufbauen, aus. An vielen Stellen stehen die Prinipien und Werte sogar in direkter Wechselwirkung zueinander.

Aus diesem Grund müsste jede Wertänderung eines beliebigen Prinzips oder Wertes durch die Kaskadierung Wertänderungen aller anderen Prinzipen und Werte nach sich ziehen, so dass dieses System -- einmal angestoßen -- im Grunde nie wieder zur Ruhe kommen dürfte. Das ist in der Praxis jedoch nicht der Fall, da es sich bei den Abhängigkeiten und Wechselwirkungen um ein soziales, gedämpftes System handelt, dessen innere Wirkung sich von Ebene zu Ebene abschwächt.

Aus diesem Grund werden hier als Quellen und Ziele der wertändernden Beeinflussungen nur die jeweils direkten Addressaten angegeben und nicht diejenigen, die in einer tieferen Ebenen der jeweiligen Kaskade betroffen sind.

Sowohl die Definitionen der Prinzipien und der Werte und ihre jeweiligen Zusammenhänge, Beeinflussungen, bzw. Verknüpfungen oder Nicht-Verknüpfungen, können nicht den Anspruch von Vollständigkeit und Korrektheit erheben, da es sich um eine weitestgehend subjektive Sicht handelt. Man kann daher aus diesen oder jenen Gründen durchaus anderer Meinung sein (zumal die Auswahl und die Beziehungen zueinander aktuell auch noch nicht vollständig von mir kommentiert sind). Sollten Sie also anderer Meinung sein als ich, würde ich mich über einen diesbezüglichen Kommentar sehr freuen; recht vielen Dank!

Was aktuell noch vollständig fehlt, sind Darstellung und Beschreibung der Beeinflussung der Werte untereinander; dieser Teil befindet noch in der Analyse.


[zurück zum Seitenanfang]


, , , ,

No comments yet.

Schreibe einen Kommentar

V1503130747DE