Search
Bildkomposition aus Foto mit der Ziffer zwei für den Blogpost Teil 2 Wertepaare aus dem Manifest für agile Software und eine nachgezeichnete Darstellung von Björn Jensen.

Noch ein bisschen WERTvoller in Richtung Agilität…

Noch ein bisschen WERTvoller in Richtung Agilität…

Update zur Reflexion mittels des Agilen Manifests

Nachdem Du in der letzten Woche einen der vielen Wege kennenlernen konntest, wie man eine Retrospektive (oder einen Workshop) mit Fokus auf die Wertepaare aus dem Manifest für Agile Softwareentwicklung durchführen kann, kommt heute ein kleines Update dazu.

Als Certified Scrum Trainer® (CST®) der Scrum Alliance gebe ich nicht nur Trainings für Scrum Master:innen, Product Owner:innen, Developer:innen oder generell an Scrum und Agile interessierten Personen, sondern helfe auch jenen, die sich auf der Reise zum Certified Scrum Trainer® (CST®) befinden. Das kann durch Co-Trainings geschehen oder mein Mentoring-Programm etc. Wenn das für Dich interessant sein sollte, dann nimm gern Kontakt mit mir auf.

Die Wertepaare als Kontinuum? Eher nicht…

Vor einigen Jahren war ich in diesem Zusammenhang im Co-Training mit Dr. Ralph Miarka von unserem Partner sinnvollFÜHREN aus Wien. In diesem Co-Training haben wir dann mit den angehenden Scrum Master:innen u.a. auch die Übung zu den Agilen Werten gemacht und Ralph hat hier eine wunderbare Ergänzung zum Format von letzter Woche beigetragen.

Generell hat ihm diese Übung sehr gut gefallen, jedoch gab es auch einen Kritikpunkt – zu Recht. In meiner ersten Version liegt unter den Wertepaaren ein Regler:

Erste Darstellungsversion der Wertepaare aus dem Manifest für Agile Softwareentwicklung mit jeweils einem darunterliegenden Regler.


Damit betracht man diese Werte jedoch als Kontinuum, bei der die linke und die rechte Seite sich irgendwann ausschließen. Wobei das ja gar nicht immer der Fall sein muss. Also haben wir die Übung ein wenig modifiziert und statt eines Reglers von links nach rechts pro Seite einen eigenen Regler implementiert mit jeweils einer eigenen Skala (z.B. von 0 – 5).

Obere Darstellung wurde hier modifiziert durch Implementierung eines eigenen Reglers von links nach rechts pro Seite mit jeweils einer eigenen Skala.


So kann man die linke und die rechte Seite eines Wertepaares unabhängig voneinander betrachten und somit ein bisschen tiefer reingehen, um feinere Maßnahmen abzuleiten.

Bspw. könnte ein Team nun für sich erkennen, dass man auf Seiten der “Funktionierenden Software” und der “Individuen & Interaktionen” ein wenig mehr tun sollte, wobei die “Umfassende Dokumentation” und das “Reagieren auf Veränderungen” vielleicht ein wenig reduziert werden sollten.

Und nun? Welche Variante ist denn nun die bessere?

Diese Frage ist sehr einfach zu beantworten, auch wenn die Antwort einem nicht unbedingt gefällt: es kommt nämlich drauf an. Ich habe gute Erfahrungen gemacht, die Variante, die Du letzte Woche kennengelernt hast, mit Personen zu verwenden, für die Agiles Denken noch ungewohnt ist. Sollten die Personen schon mehr Erfahrung haben und weniger Schwierigkeiten mit der Agilen Denkweise haben, dann verwende ich gern die Variante, die durch Ralphs Input entstanden ist. 

Ich hoffe, dass Du damit etwas anfangen kannst und ich würde mich über Deine Erfahrungen (und ggf. Abwandlungen) sehr freuen. Hinterlass’ mir doch einfach einen Kommentar 🙂

Und beim nächsten Mal werfen wir dann wirklich einen Blick auf die Agilen Prinzipien 😉

Oldie but Goldie

Dieser Beitrag wurde ursprünglich 2015 in einem anderen Blog veröffentlicht, der heute gar nicht mehr existiert. Da ich diesen (und auch andere) Artikel nach wie vor für wertvoll halte, werden im Laufe der Zeit immer wieder mal so “alte” Fundstücke unter dem Label “Oldie but Goldie” veröffentlicht.

 

Weitere Artikel zum stöbern

Agile Methoden und insbesondere Scrum haben die Art und Weise, wie Software entwickelt wird, revolutioniert. Sie ermöglichen Teams, schnell auf Veränderungen zu reagieren, den Kunden in den Mittelpunkt zu stellen und die Lieferung von Produkten in kurzen, iterativen Zyklen zu optimieren. Scrum, als eines der beliebtesten agilen Frameworks, strukturiert die Produktentwicklung in Sprints, die typischerweise zwei bis vier Wochen dauern und am Ende jedes Sprints ein potenziell auslieferbares Produktinkrement liefern.
Skip to content