Ich hatte k\u00fcrzlich die Gelegenheit, mich mit einem Kollegen auszutauschen, der neuerdings erstmalig in einem gr\u00f6\u00dferen agilen Projekt arbeitet. Er berichtete mir von einigen Schwierigkeiten im Projekt, ein interessanter „Kristallationspunkt“ dieser Probleme zeigte sich im Thema „Sch\u00e4tzungen“ und wie diese im Team angegangen werden.<\/p>\n
Zun\u00e4chst ein paar Infos zum Hintergrund: Mein Kollege hat viel Erfahrung mit „klassischen“ Projekten, in denen er beteiligt und als (Teil-)Projektleiter eingesetzt war, von den Projekten waren auch viele erfolgreich. Er ist jetzt als technischer Berater in einem gro\u00df skalierten Scrum-Projekt, das f\u00fcr seinen Auftraggeber auch eine der ersten Ber\u00fchrungen mit agilem Vorgehen ist. Dementsprechend gibt es in dem Projekt und im Umfeld des Projektes eine bunte Mischung aus dem Wunsch, alles „richtig“ und „by the book“ zu machen und Erwartungen und Gewohnheiten, die sich noch sehr an dem bisherigen Vorgehen aurichten.<\/p>\n
Eines der Rituale, das dort eingef\u00fchrt wurde, ist auch das Planning Poker, mit dem den Sprint-Aufgaben Story Points gegeben werden. Daran st\u00f6rte sich nun mein Kollege sehr – von der Frage, warum man denn nun auf einmal Komplexit\u00e4t statt Aufwand sch\u00e4tzen sollte bis hin zu dem z\u00e4hen Vorgehen, da man in Unkenntnis des Aufgabeninhaltes Zahlen „raten“ m\u00fcsse.<\/p>\n
Interessant war f\u00fcr uns im Gespr\u00e4ch dar\u00fcber, dass sich einige Dysfunktionalit\u00e4ten des Vorgehens genau an diesem Punkt heraus kristalisierten.<\/p>\n
Der offensichtlichste Punkt ist der, dass es in dem Team aktuell kaum Teamarbeit gibt – im Endeffekt hat jedes Gruppenmitglied seine oder ihre Aufgaben und arbeitet diese innerhalb des Sprints ab, man kann kaum anderen helfen, da jeder ein Spezialgebiet bearbeitet. Das macht die Sch\u00e4tzrunden schwierig, da jeweils immer nur ein Teammitglied eine Aussage zur Komplexit\u00e4t machen kann, w\u00e4hrend die anderen versuchen zu „erraten“, was diese Person wohl sch\u00e4tzen wird.<\/p>\n
Die eigentlichen Probleme im Team zeigen sich aber, wenn man beginnt zu hinterfragen, warum<\/em> \u00fcberhaupt Sch\u00e4tzungen gemacht werden. Wenn ja ohnehin jeder seine Aufgaben hat, wird die Sch\u00e4tzung dann ben\u00f6tigt um zu wissen, ob die Aufgaben in den Sprint passen? Soll mit dem Sch\u00e4tzen sichergestellt werden, dass alle im Team das gleiche Verst\u00e4ndnis der Aufgabe haben?<\/p>\n Leider war die Antwort, dass das Sch\u00e4tzen ben\u00f6tigt werde, da das Projektcontrolling damit die Leistungsf\u00e4higkeit des Teams messen und \u00fcberpr\u00fcfen wolle. Darin sehe ich ein grunds\u00e4tzliches Problem, das ich hier<\/a> schonmal angesprochen habe, n\u00e4mlich, dass ein Indikator zu einem (zumindest indirekten) Ziel erkl\u00e4rt wird. Schlie\u00dflich soll sich – so die Erwartung des Controllings – der Output des Teams ja verbessern. Wenn das erwartet wird, so sorgt dies bestenfalls zu einem Drift der Sch\u00e4tzungen nach oben. Doch selbst, wenn das nicht der Fall w\u00e4re: Die Sch\u00e4tzung der Komplexit\u00e4t (meinetwegen auch des Aufwandes) der Aufgaben ist f\u00fcr diese Fragestellung eine absolut unbrauchbare Sch\u00e4tzgr\u00f6\u00dfe! Damit wird bestenfalls der konstante (oder steigende) Mittelabfluss sichergestellt, das sagt absolut nichts dar\u00fcber aus, wie gut der Output<\/em> des Teams ist! Dann sollte besser der Product Owner den Business Value<\/em> der Features sch\u00e4tzen. (Und ja, auch da w\u00fcrde sich sicherlich die Sch\u00e4tzung ver\u00e4ndern, wenn ich anfange, das zum Ziel zu erkl\u00e4ren.)<\/p>\n Es gibt meiner Meinung nach einige Gr\u00fcnde, warum ein Sch\u00e4tzen durch ein Team sinnvoll sein kann. Beispielsweise, damit das Team wei\u00df, wie viel Komplexit\u00e4t es im Sprint umsetzen kann. Hier kamen wir \u00fcbrigens auf die Diskussion, warum dann nicht gleich Aufwand gesch\u00e4tzt werden sollte. Meiner Meinung nach deswegen, weil die Komplexit\u00e4t eine Einigung erlaubt, auch wenn die Skills im Team unterschiedlich verteilt sind. Es mag sein, dass ich f\u00fcr die Implementierung eines Features 5 Tage brauche, wenn ich mich in der Technologie nicht auskenne, eine erfahrenere Entwicklerin ben\u00f6tigt eventuell nur 2 Tage. So k\u00f6nnten wir uns nie auf einen Aufwand einigen, wohl aber darauf, dass eine CRUD-Applikation nicht allzu komplex w\u00e4re. Zudem kann ich mit der Sch\u00e4tzung von Komplexit\u00e4t auch belegen, dass zumindest ein \u00e4hnliches Verst\u00e4ndnis f\u00fcr das Feature existiert. Nicht zuletzt habe ich damit einen Indikator, dass ein Team eine bestimmte Velocity hat und diese auch besser werden kann.<\/p>\n Das „Standardziel“ ist es, dass der PO mit den Sch\u00e4tzergebnissen eine Vorstellung davon hat, welche Features in einem l\u00e4ngeren Zeitraum schaffen kann, diese Sch\u00e4tzungen helfen bei einer langfristigen Planung. Damit diese Sch\u00e4tzungen allerdings eine Aussagekraft haben, m\u00fcssen eine ganze Reihe von Voraussetzungen erf\u00fcllt sein: Das Team muss relativ stabil sein, um seine Velocity kennen und halten zu k\u00f6nnen; die Sch\u00e4tzgrundlage muss stabil bleiben k\u00f6nnen, es darf also nicht durch falsche Zielvorgaben eine Ver\u00e4nderung der Sch\u00e4tzbasis belohnt werden; das Entwicklungsziel muss bekannt genug sein, um zuk\u00fcnftige Features sinnvoll und stabil beschreiben (und in der Komplexit\u00e4t kennen) zu k\u00f6nnen.<\/p>\n Kurz gesagt, Sch\u00e4tzen ist kein Selbstzweck. Bevor man eine Sch\u00e4tzmethode ausw\u00e4hlt oder anwendet, sollte das Ziel der Sch\u00e4tzung klar sein, was in der Realit\u00e4t leider erstaunlich selten der Fall ist.<\/p>\n\n Ich hatte k\u00fcrzlich die Gelegenheit, mich mit einem Kollegen auszutauschen, der neuerdings erstmalig in einem gr\u00f6\u00dferen agilen Projekt arbeitet. Er berichtete mir von einigen Schwierigkeiten im Projekt, ein interessanter „Kristallationspunkt“ dieser Probleme zeigte sich im Thema „Sch\u00e4tzungen“ und wie diese im Team angegangen werden. Zun\u00e4chst ein paar Infos zum Hintergrund: Mein Kollege hat viel Erfahrung mit „klassischen“ Projekten, in denen er beteiligt und als (Teil-)Projektleiter eingesetzt war, von den Projekten waren auch viele erfolgreich. Er ist jetzt als technischer Berater in einem gro\u00df skalierten Scrum-Projekt, das f\u00fcr seinen Auftraggeber auch eine der ersten Ber\u00fchrungen mit agilem Vorgehen ist. Dementsprechend gibt… Mehr…Warum sch\u00e4tzen wir das Sch\u00e4tzen so?<\/span><\/span><\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3,11],"tags":[],"class_list":["post-253","post","type-post","status-publish","format-standard","hentry","category-agilitaet","category-methodisches","content-layout-full"],"_links":{"self":[{"href":"https:\/\/daemoniccoder.de\/index.php?rest_route=\/wp\/v2\/posts\/253","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/daemoniccoder.de\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/daemoniccoder.de\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/daemoniccoder.de\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/daemoniccoder.de\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=253"}],"version-history":[{"count":8,"href":"https:\/\/daemoniccoder.de\/index.php?rest_route=\/wp\/v2\/posts\/253\/revisions"}],"predecessor-version":[{"id":262,"href":"https:\/\/daemoniccoder.de\/index.php?rest_route=\/wp\/v2\/posts\/253\/revisions\/262"}],"wp:attachment":[{"href":"https:\/\/daemoniccoder.de\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=253"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/daemoniccoder.de\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=253"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/daemoniccoder.de\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=253"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}