11.12.2020 -
In einem Artikel mit dem Titel „Agile Missverständnisse: Das Ende der Velocity?“ schreibt Björn Schotte über agiles Arbeiten und das hohe Gut der Schnelligkeit. Der Artikel wurde auf blog.mayflower.de im Blog veröffentlicht. Björn Schotte betont, dass agile Transformation und Velocity in Deutschland einen besonders hohen Stellenwert haben, schließlich sind schnelles Arbeiten und Effizienz in Deutschland besonders wichtig. Velocity, also Geschwindigkeit, geht einher mit Vorhersagbarkeit.
Weiterlesen »
11.12.2020 -
In einem Artikel mit dem Titel
„Agile Missverständnisse: Das Ende der Velocity?“ schreibt Björn Schotte über agiles Arbeiten und das hohe Gut der Schnelligkeit. Der Artikel wurde auf blog.mayflower.de im Blog veröffentlicht. Björn Schotte betont, dass agile Transformation und Velocity in Deutschland einen besonders hohen Stellenwert haben, schließlich sind schnelles Arbeiten und Effizienz in Deutschland besonders wichtig. Velocity, also Geschwindigkeit, geht einher mit Vorhersagbarkeit. Alle wollen alles in Prognosen fassen und planen. Schon allein der Begriff Velocity scheint in deutschen Unternehmen besonders gut anzukommen. Ein größeres Arbeitspensum in kürzerer Zeit zu erledigen: Das ist nach Björn Schotte das deutsche Ideal. Leider gibt es aber, wenn es um Agilität und Velocity geht, unheimlich viele Missverständnisse und genau mit diesen will sich Björn Schotte hier befassen.
Der Mythos Velocity
Velocity ist in aller Munde. Der Begriff wird für viele verschiedene Dinge verwendet. Velocity ist streng genommen die Summe der Story Points, die in einer Iteration aus den Sprint Backlog Items erreicht wurden. Velocity ist aber immer ein sehr dehnbarer und flexibler Begriff. Ständig ist sie unter Druck, die Velocity. Teams sollen noch schneller arbeiten, noch flexibler, agiler und effizienter in noch kürzeren Sprints erfolgreich sein. Jeder betont, dass sich eine Velocity irgendwann einpendeln wird, aber nicht jetzt. Es gibt immer noch Luft für Steigerungen. Björn Schotte erwähnt das Gesetz der großen Zahlen und die Monte Carlo Simulation. Er erwähnt Kanban und andere Konzepte. Aber im Grunde geht es überall nur darum, schneller und mehr zu arbeiten.
Ist es so einfach?
Natürlich ist es nicht so einfach. Das Konzept der Agilität ist alles andere als einfach. Es ist komplex, kompliziert und hat tausende von Ausformungen. Kein Sprint ähnelt dem anderen, kein Projekt ist mit einem anderen vergleichbar. Niemand ist in der Lage, eine allgemeingültige Strategie zu entwickeln. Agil bedeutet auch einzigartig, anpassbar an alle Umstände und stets flexibel. Egal wie gut das letzte Projekt gelaufen ist, niemand kann diese Erfahrungen einfach so auf das nächste Projekt stülpen und sich auf ein Erfolgsrezept stützen. Von einfachen Lösungen kann also nicht die Rede sein. In der Softwareentwicklung hat man es mit Unknown Unknowns und mit Known Unknowns zu tun. Viele Unternehmen arbeiten mit Spikes und Timeboxen statt mit Story Points, um auf diese Weise kommende Backlog-Items besser voraussagen zu können. Aber nicht alle sind so diszipliniert. Im Eifer des Gefechts, wo doch ständig Ergebnisse hervorgebracht werden müssen, bestimmt der Markt die Taktung. Alles was zählt ist die Time-to-Market, da müssen andere Dinge oft nachstehen. Nicht selten kommt es vor, dass eine User Story in der Nachbetrachtung anders bewertet wird, weil neue Informationen vorliegen.
Agile Überraschungen
Auch wenn die Teams sich Mühe geben, alles möglichst genau vorauszusagen, so kommt es doch immer wieder zu Überraschungen. Idealerweise kann alles mit Präzision vorhergesehen werden. Aber wann läuft ein Projekt schon ideal? Genau wegen der Überraschungen und Unvorhersehbarkeiten ist die Agilität ja so ein guter und wichtiger Ansatz, der es uns ermöglicht, auf Überraschungen so zu reagieren, dass mit minimalen Verlusten schnellstmöglich Anpassungen vorgenommen werden können. Velocity schwankt also. Die Summer der Punkte, die in einer Iteration erreicht werden, ist oft nicht so wie vorgesehen und ist von Iteration zu Iteration verschieden. Mal sind es mehr, mal weniger. Wie es letztendlich gelaufen ist, kann immer nur im Nachhinein gemeinsam erörtert werden. Die Schwankungen werden meist von technischen Problemen verursache, oft aber auch von Aufgaben, die zusätzlich vom Team übernommen werden und damit für eine Verlangsamung der Velocity sorgen. Wenn User Stories nicht gut vorbereitet werden, kann auch dies sich negativ auf die Velocity auswirken. Denkbar sind hier unendlich viele Szenarien. Aber in einem emergenten System ist es nun einmal immer erst nach Abschluss der Iteration möglich, die Velocity zu bestimmen.
Kommunizieren – ein Schlüsselaspekt
Ständig kommt die Nachfrage, ob es nicht möglich ist, noch schneller zu arbeiten. Die Entwickler rollen dann mit den Augen, denn sie können natürlich bestimmte Dinge beschleunigen, aber die verschiedenen Abhängigkeiten erlauben einfach keine Verkürzung des Timings. Bestimmte Dinge können eben erst zu einem bestimmten Zeitpunkt getan werden. Die Entwickler werden ungehalten, denn sie sind der Meinung, dass die ständige Fragerei nach noch schnellerer Arbeit bedeutet, dass der Manager sie nicht versteht. Daher sollte die Frage nach mehr Effizienz anders gestellt werden. Sieht der Manager schwankende Velocity, kann er darauf hinweisen und versuchen, gemeinsam mit dem Team zu erörtern, ob diese Schwankungen bedeuten, dass an der einen oder anderen Stelle etwas verbessert werden kann. Das ist hilfreicher als nur die Peitsche zu schwingen. Es regt zudem einen Dialog an, was immer besser ist als Forderungen oder Schweigen. Der Dialog innerhalb des Unternehmens und innerhalb des Teams ist immer erstrebenswert.
Velocity als Maßstab?
Letztlich betont Björn Schotte, dass es in der Produktentwicklung um Wertschöpfung für den Endnutzer geht. Daher muss für die Messung des Erfolgs ein anderer Maßstab her. Die Velocity ist ein gutes Instrument, um die eigene Arbeit im Team zu betrachten und zu vergleichen, um Selbstkontrolle auszuüben. Aber als Maßstab für Performance kann sie nicht dienen. Schon gar nicht, wenn es darum geht, die Arbeit von zwei verschiedenen Teams zu vergleichen.
« Alle Beiträge