Agile Vision

Agiles Teufelsquadrat

Veröffentlicht am 9. November 2022 von Klaus / 0 Kommentare

Kennst Du das Teufelsquadrat?

Erfunden wurde das Werkzeug von Harry Sneed, einem US-amerikanischen Dozenten für Software Engineering. Es wird eingesetzt im Projektmanagement und zeigt, dass die Veränderung eines Projektparameters Auswirkungen auf die anderen Parameter hat.

Das Teufelsquadrat unterscheidet die vier Projektgrößen Qualität, Quantität, Entwicklungsdauer und Kosten.

Verbindest Du nun die Punkte miteinander, so erhältst Du ein Viereck.

Die Fläche des Vierecks ist die nach Sneed benannte nicht veränderbare Projektproduktivität.

Wie wirken sich somit Wünsche des Kunden auf das Projekt aus?

Soll die Qualität eines zu entwickelnden Produkts erhöht und gleichzeitig die Entwicklungsdauer beibehalten werden, so hat das Auswirkungen auf die Quantität und / oder auf die Kosten des Produkts. Durch den Mehraufwand im Qualitätsmanagement können einige Produktfeatures (Quantität) nicht implementiert werden. Alternativ könnte das Produktteam verstärkt werden, hierdurch steigen die Kosten.

Soweit, so gut! Aber taugt das Teufelsquadrat nach Sneed auch für die heutige VUCA-Welt?

Ich meine: Ja. Hierzu habe ich jedoch das Teufelsquadrat nach Sneed ein wenig adaptiert.

Den Projektparameter Komplexität habe ich hinzugefügt.
Um das Koordinatensystem mit fünf Achsen nicht zu kompliziert zu gestalten, wurden zwei Projektgrößen zusammengefügt: Der Aufwand ist das Produkt aus Entwicklungsdauer und Kosten pro Zeiteinheit.
Den Projektparameter Quantität aus dem ursprünglichen Modell habe ich umbenannt zu Features; er könnte auch Stories, Epics oder Product-Backlog lauten.

Stellt sich beispielsweise heraus, dass die Umsetzung des Projekts doch komplexer ist als gedacht, hat das Auswirkungen auf die Anzahl der Features und / oder auf den Aufwand. Die Qualität des Produkts ist für mich nicht verhandelbar. Damit meine ich: Ein gewisser Qualitätsstandard sollte immer eingehalten werden, mehr ist jederzeit möglich.

Weniger Features können implementiert werden. Ist hier wenig Spielraum aufgrund von Must-Haves, so muss über eine Erhöhung des Aufwands nachgedacht werden.

Oder Du beschäftigst Dich mit dem Komplexitätsgrad des Projekts. Wie könnte dieser reduziert werden? Beispielsweise durch Architektur-Pattern, den Schnitt der Services oder auch durch die Organisation der Teams (Reduzierung der Abhängigkeiten zwischen den Teams).

Was hältst Du vom agilen Teufelsquadrat? Ist es hilfreich?

agile Organisation

Was zeichnet ein agiles Unternehmen aus?

Veröffentlicht am 2. Oktober 2019 von Klaus / 0 Kommentare

Viele Unternehmen führen im Schnellverfahren agile Frameworks wie Scrum oder Kanban für Entwicklungsteams ein. Übergreifende Strukturen, Verantwortlichkeiten und insbesondere die Unternehmenskultur bleiben unangetastet. Diese Organisationen behaupten nun von sich, sie seien agil unterwegs.

Aber ist dieser Schritt ausreichend, um am Marktgeschehen weiterhin erfolgreich teilnehmen zu können?

Nein!

Eine Organisation ist nur dann agil aufgestellt, wenn die Kunden und die Mitarbeiter im Fokus ihrer Aktivitäten stehen.

Das heißt: Sie ist nah am Marktgeschehen dran und kennt die Bedürfnisses seiner Kunden, beobachtet das Marktumfeld und ist sensibilisiert für Ereignisse, die Auswirkungen auf das Portfolio haben könnten.

Es werden kurze Durchlaufzeiten von der Anforderungserhebung bis zur Auslieferung des Produkts angestrebt.

Der Kunde wird in den Entwicklungsprozess eingebunden, um sicherzustellen, dass die Anforderungen nach seinen Vorgaben umgesetzt werden. Features, die sich wider Erwartung als nicht hilfreich erweisen oder in einem sich ändernden Kontext ihren Nutzen verlieren, können zeitnah angepasst oder eliminiert werden. Neue Produktinkremente entstehen – gemeinsam mit dem Kunden. Der Kunde erhält ein qualitativ hochwertiges Produkt.

Diese anspruchsvolle Aufgabe können nur intrinsisch hoch motivierte Mitarbeiter bewerkstelligen.

In einem agilen Unternehmen arbeiten die Menschen gern; sie sind wissbegierig, neugierig, schauen über den Tellerrand, probieren etwas aus und kennen den Sinn ihrer Tätigkeit.

Das Unternehmen schafft eine Kultur, einen Rahmen, in dem sich die Mitarbeiter wohlfühlen. Fehler werden offen kommuniziert, um aus ihnen zu lernen. Die Frage lautet nicht „Wer ist hierfür verantwortlich?“ sondern „Wie können wir den Prozess verbessern, damit dieser Fehler zukünftig nicht mehr auftritt?“.

In einem agilen Unternehmen steht der Mensch im Mittelpunkt. Als Kunde und auch als Mitarbeiter.

agiles Projekt/Projektmanagement/Scrum/Story Points

Story Points – Definition und Anwendung

Veröffentlicht am 21. Mai 2019 von Klaus / 0 Kommentare

Die Anwendung von Story Points ist eine gängige Methode, um Aufwände in agilen Projekten abzuschätzen.

Junge agile Teams konfrontieren mich immer wieder mit der Frage nach der Definition von Story Points.

Story Points spiegeln die Komplexität, die Schwierigkeit einer User Story wider. Die Komplexität stellt eine konstante Eigenschaft dar, welche unabhängig vom späteren Bearbeiter der Anforderung ist.

Komplexität einer User-Story ermitteln

Das Entwicklungsteam ermittelt gemeinsam – beispielsweise per Planungspoker – die Komplexität einer User Story. Jeder Teilnehmer erhält ein Satz Poker-Karten, auf denen Story Points nach der Fibonacci-Zahlenfolge aufgedruckt sind. Er ist aufgefordert, die Komplexität gemäß seinem Verständnis von der Anforderung zu schätzen, und legt die gewählte Karte verdeckt hin.

Alle Karten werden gleichzeitig aufgedeckt. Nun haben diejenigen Teammitglieder mit der höchsten und der niedrigsten Schätzung das Wort.

Was war ihre Motivation für diese Schätzung?
Verstehen Sie jeweils etwas anderes unter der Anforderung? Ist sie zu ungenau beschrieben?
Sieht der Teilnehmer mit der höchsten Schätzung Risiken, die den anderen unbekannt sind?
Hat der Teilnehmer mit der niedrigsten Schätzung bereits eine „einfache“ Lösung vor dem geistigen Auge?

Jetzt wird deutlich, dass neben der Aufwandsschätzung Story Points ein weiteres – aus meiner Sicht sehr wichtiges – Ziel verfolgen:

Das Schätzen fördert das gemeinsame Verständnis

Das crossfunktional aufgestellte Team beleuchtet den Schwierigkeitsgrad der Anforderung von vielen Seiten. Es schält sich eine präzise Anforderung heraus, welche die Definition of Ready (DoR) des Teams erfüllt.

Der Vorgang des Planungspokers wird wiederholt, bis ein einstimmiges Verständnis vorliegt. Kann das Team eine Einigung trotz mehrfacher Anläufe nicht erzielen, so ist der Produktverantwortliche gefordert, die User Story nach Rücksprache mit den Stakeholdern zu überarbeiten.

Velocity des Teams

Die Story Points aller abgeschlossenen User Stories in einem Sprint werden aufsummiert und bilden die Velocity des Teams.

Die Velocity unterliegt Schwankungen: Die Teamgröße kann sich im Laufe der Zeit ändern, Teammitglieder gehen in Elternzeit, treten ihren wohlverdienten Urlaub an etc.

Betrachtet ein neu zusammengestelltes Team den Verlauf der Velocity über einen größeren Zeitraum, so nimmt es eine Erhöhung der Velocity wahr. Was ist passiert?

Die Mitarbeiter eines neuen Teams müssen sich zunächst kennenlernen, ihren Platz im Team finden; das Team durchläuft verschiedene Teamphasen (nach Tuckman) und vollbringt Höchstleistungen in der Integrationsphase 🙂 . Die Integrationsphase geht einher mit der Selbstorganisation des Teams.

Aber seien wir ehrlich: Bäume wachsen nicht in den Himmel, die Velocity auch nicht. Ein Team hat immer wieder Phasen, in denen es nicht so produktiv unterwegs ist.

Und wie gehen wir mit Anforderungen um, die nicht komplex sind?

Sie sind einfach in der Umsetzung, jedoch zeitlich sehr aufwändig. Obwohl die Schätzung nach obiger Definition nur wenige Story Points ergibt, da der Komplexitätsgrad gering ausfällt, nimmt die Anforderung das Team zeitlich sehr in Anspruch. Die Velocity sinkt. Ein Alarmsignal für die Führungskraft; das Team ist verunsichert. Sinkt seine Produktivität?

Natürlich nicht. Auch nicht komplexe Anforderungen müssen umgesetzt werden und fordern das ganze Team.

Aus diesem Grunde nehme ich zusätzlich in meine Definition der Story Points den (Funktions-)Umfang der Anforderung auf:

Meine Definition von Story Points

Story Points spiegeln die Komplexität und den (Funktions-)Umfang einer Anforderung wider.