{"version":"https:\/\/jsonfeed.org\/version\/1","title":"ralfw-de","description":"","home_page_url":"https:\/\/ralfw.de","feed_url":"https:\/\/ralfw.de\/feed.json","user_comment":"","icon":"https:\/\/ralfw.de\/media\/website\/logo-smaller.png","author":{"name":"Ralf Westphal"},"items":[{"id":"https:\/\/ralfw.de\/fluessiger-bloggen\/","url":"https:\/\/ralfw.de\/fluessiger-bloggen\/","title":"Fl\u00fcssiger bloggen","summary":"Es ist stiller geworden auf meiner Homepage - denn meine Aktivit\u00e4t habe ich auf einen Newsletter verlagert: https:\/\/ralfwestphal.substack.com\/. Wahrscheinlich w\u00e4re eine Abnahme meiner Aktivit\u00e4t sogar eine nat\u00fcrliche Entwicklung \u00fcber all die Jahre. Immerhin schreibe ich seit 2003 Blog-Artikel. Dass ich nach knapp 20 Jahren nicht…","content_html":"

Es ist stiller geworden auf meiner Homepage - denn meine Aktivit\u00e4t habe ich auf einen Newsletter verlagert: https:\/\/ralfwestphal.substack.com\/<\/a>.<\/p>\n

Wahrscheinlich w\u00e4re eine Abnahme meiner Aktivit\u00e4t sogar eine nat\u00fcrliche Entwicklung \u00fcber all die Jahre. Immerhin schreibe ich seit 2003 Blog-Artikel. Dass ich nach knapp 20 Jahren nicht mehr so ideensprudelnd bin, kann ich mir eigentlich nicht verdenken.<\/p>\n

Einerseits. Denn andererseits haben mich gerade die letzten beiden Jahre gedr\u00e4ngt, einiges zu schreiben - nur nicht unbedingt \u00fcber die Softwareentwicklung. Die Corona-Jahre haben mich tief bewegt und ich musste \"da etwas loswerden\". Das passte allerdings nicht zu meiner softwaretechnisch orientierten Homepage. Also habe ich angefangen, auf anderen Plattformen zu bloggen.<\/p>\n

Interessanterweise fiel mir dort der Schreibprozess auch leichter; ich konnte wieder fl\u00fcssiger schreiben. Die Editoren zuerst bei medium und dann bei Substack waren schlicht besser als der f\u00fcr meine Homepage. Und das live Schalten von Beitr\u00e4gen war auch etwas einfacher. (Seit einigen Jahren habe ich mich von Wordpress f\u00fcr meine Homepage verabschiedet und setze auf static HTML; so habe ich keine Last mit irgendwelchen Plug-Ins oder Cookies. Alles so sch\u00f6n schlank mit Publii<\/a> und GitHub Pages.)<\/p>\n

Doch nach l\u00e4ngerer Zeit der Divergenz m\u00f6chte ich jetzt das Dortige zum Hiesigen hinzuf\u00fcgen. Deshalb gibt es im Blog-Men\u00fc einen neuen Eintrag: \"Newsletter\". Der verweist auf mein Substack-Blog<\/a>, das Substack Newsletter<\/em> nennt, weil \u00fcber neue Beitr\u00e4ge immer gleich auch per Email informiert wird, wenn man sich als Abonnent eingetragen hat. Dieses Feature hatte meinem Blog in all den Jahren gefehlt.<\/p>\n

Die Beitr\u00e4ge hier auf meiner Homepage werde ich einstellen. Ich nutze sie nur noch f\u00fcr recht statische Inhalte, z.B. die Beschreibung meiner Trainings. Alles, was dynamisch ist, findet zuk\u00fcnftig bei Substack statt. Ich denke, das ich eine h\u00fcbsche Trennung im Sinne des Separation of Concern<\/em> (SoC<\/em>) Prinzips. (Ob das f\u00fcr SEO der Hit ist, wei\u00df ich nicht. Aber hinter dem besten Google-Ranking renne ich ohnehin nicht hinterher.)<\/p>\n

Mein Substack-Blog kann man per kostenlosem Email-Abo verfolgen oder sich als RSS-Feed in einen RSS-Reader wie Reeder<\/a> ziehen lassen. Ich bin seit einiger Zeit wieder Fan dieser alten Technologie; sie f\u00fchlt sich der Idee des Internet n\u00e4her an als die Social Media Plattformen.<\/p>\n

Bei Substack ist mein Blog in mehrere Kategorien unterteilt. So kann ich sowohl \u00fcber Technisches wie Gesellschaftliches und Politisches berichten, ohne dass es sich zu sehr in die Quere kommt. Auf der Hauptseite kommt zwar alles aus den Kategorien zusammen, doch wer sich nur f\u00fcr Technisches interessiert, kann sich z.B. auf den Newsletter \"Clean Code Development<\/a>\" konzentrieren.<\/p>\n

\"\"<\/figure>\n

Ich wei\u00df, solche \u00c4nderungen bringen Unruhe in meinen Web-Auftritt. Sollte der nicht stabil sein und alles, alles auf der Homepage unter meiner Domain zusammenziehen? Ja, vielleicht. Aber ich m\u00f6chte neue Entwicklungen auch mitnehmen k\u00f6nnen, hier: eine Plattform, die das Bloggen und den Versand von Newslettern noch einfacher macht. Ich vertraue deshalb einfach mal darauf, dass der Effekt nicht zu negativ sein wird.<\/span><\/p>\n

Insofern: Ich w\u00fcrde mich freuen, wenn Sie mir auch zu Substack folgen w\u00fcrden, mit oder ohne Email-Abo.<\/p>","author":{"name":"Ralf Westphal"},"tags":[],"date_published":"2022-06-29T15:32:23+08:00","date_modified":"2022-06-29T15:55:48+08:00"},{"id":"https:\/\/ralfw.de\/wert-mehr-als-komplexitaet\/","url":"https:\/\/ralfw.de\/wert-mehr-als-komplexitaet\/","title":"Wert mehr als Komplexit\u00e4t","summary":"Wie misst ein agiles Softwareteam - gar eines, das Scrum einsetzt - eigentlich seinen Fortschritt? In Erinnerung sind mir da noch burn-down und burn-up Charts, in denen Story Points aufgetragen werden. Ist das aber wirklich hilfreich und zeitgem\u00e4\u00df? Interessanterweise kommen Story Points im Scrum Guide…","content_html":"

Wie misst ein agiles Softwareteam - gar eines, das Scrum einsetzt - eigentlich seinen Fortschritt? In Erinnerung sind mir da noch burn-down und burn-up Charts, in denen Story Points aufgetragen werden. Ist das aber wirklich hilfreich und zeitgem\u00e4\u00df?<\/p>\n

Interessanterweise kommen Story Points im Scrum Guide<\/a> ja nicht mehr vor. Der erw\u00e4hnt zwar noch burn-down Diagramme f\u00fcr den \"forecast\" - auch der Begriff \"estimation\" ist aus dem Guide gestrichen -, doch was da heruntergebrannt wird, ist nicht benannt. Eine \"velocity\" findet ebenfalls keine Erw\u00e4hnung mehr.<\/p>\n

Damit h\u00e4ngen zumindest Scrum-Teams ein bisschen in der Luft, oder? Die Quelle der Wahrheit gibt keine Guidance.<\/p>\n

Nat\u00fcrlich h\u00e4lt sich die Praxis der Story Point Sch\u00e4tzung hartn\u00e4ckig und auch die Velocity steht in den meisten Scrum-Teams, die ich kenne, ganz oben auf der Beobachtungsliste. Konstante Geschwindigkeit ist das Ideal - auch wenn man inzwischen mit wissendem Blick betont, dass Geschwindigkeitsunterschiede normal seien.<\/p>\n

Komplexit\u00e4t kaschiert Aufwand<\/h2>\n

Die Velocity ist die Zahl der Story Points, die pro Sprint umgesetzt wurden. Und Story Points stehen f\u00fcr eine Einsch\u00e4tzung der Komplexit\u00e4t einer umzusetzenden Anforderung, wie sie von den Entwickler eingesch\u00e4tzt wird.<\/p>\n

Eine vom Product Owner pr\u00e4sentierte Anforderungen wird diskutiert und dann wird in einem mehr oder weniger komplizierten Sch\u00e4tzverfahren eine Komplexit\u00e4t daf\u00fcr bestimmt. Die Komplexit\u00e4t ist ganz bewusst keine Sch\u00e4tzung eines Umsetzungsaufwands oder einer Umsetzungsdauer. Agile Entwickler lassen sich zu einer Zeitsch\u00e4tzung nicht mehr herab; dass die daneben liegen muss, wei\u00df doch jeder. Auf solche ein Spiel lassen sie sich nicht mehr ein.\ud83d\ude24<\/p>\n

Sie versprechen nur noch, dass sie eine bestimmte Menge an Anforderungsinkrementen mit einer bestimmten Komplexit\u00e4tssumme in einer festgelegten Zeit umsetzen.\ud83d\ude09<\/p>\n

Auch wenn Story Points keine genaue Dauer f\u00fcr eine Umsetzung angeben, ist allen Beteiligten nat\u00fcrlich klar, dass die mit der Dauer positiv korrelieren. Mehr Story Points f\u00fcr eine Anforderung bedeuten l\u00e4ngere Umsetzungsdauer. Ob 8 Story Points im Vergleich zu 5 Story Points nun genau 60% l\u00e4nger dauern oder nur 30% oder 100% oder mal so und mal so, das w\u00fcrde kein agiler Entwickler definieren wollen. Eine Komplexit\u00e4t von 8 ist eben nur h\u00f6her als eine von 5. Und eine von 13 ist mehr h\u00f6her im Vergleich zu 8 als 8 im Vergleich zu 5. Ich denke, dar\u00fcber gibt es keinen Zweifel.<\/p>\n

Alles andere w\u00fcrde auch keinen Sinn ergeben. Denn der PO will ja eine Idee bekommen, ob die Anforderung A in der Umsetzung wohl l\u00e4nger dauern wird als die Anforderung B. Denn wenn das so ist, k\u00f6nnte das f\u00fcr ihn ein Signal sein, A vorzuziehen - oder A zu verschieben.<\/p>\n

Eine Komplexit\u00e4tssch\u00e4tzung ist also eine verbr\u00e4mte Aufwandssch\u00e4tzung. Und ein Diagramm, das Komplexit\u00e4tswerte darstellt, stellt also Aufw\u00e4nde dar.<\/p>\n

Was sagt dann ein Velocity Chart aus? Dass man in einer Periode eine Komplexit\u00e4t bew\u00e4ltigt, gar \u00fcberw\u00e4ltigt und niedergerungen hat.\ud83d\udcaaEntwickler sind eben Helden! Jeden Tag schauen sie dem Komplexit\u00e4tsmonster unersch\u00fcttert ins Auge!\ud83d\udc79<\/p>\n

Das klingt irgendwie gut - nur was bedeutet das wirklich? Hat das einen Wert? Wenn ja, f\u00fcr wen?<\/p>\n

Wie gesagt: Sich die Komplexit\u00e4tsfrage zu stellen, ist eine gute Sache. Um sie beantworten zu k\u00f6nnen, muss man mit dem Product Owner ins Gespr\u00e4ch kommen. Im Gespr\u00e4ch erkundet man die Anforderungen. Alle werden sich dar\u00fcber klarer. Wo man gro\u00dfe Komplexit\u00e4t erkennt, mit der gro\u00dfe Unklarheit und Unverl\u00e4sslichkeit in der Umsetzung einhergehen, kann man sich um Reduktion schon im Vorfeld bem\u00fchen.<\/p>\n

Das ist alles super! Nur warum diese Werte tracken?<\/p>\n

It's the focus, stupid!<\/h2>\n

F\u00fcr mich ist nur eine Motivation plausibel: Indem man Story Points nicht nur sch\u00e4tzt, sondern auch verspricht, die niederzuringen in einem Zeitraum, setzt man sich ein Ziel. Dieses Ziel soll fokussieren. Dieses Ziel soll einen\u00a0sense of urgency<\/em> induzieren. Wer versucht ist, einer Ablenkung nachzugeben im Verlauf eines Sprints, der wird durch das Commitment auf eine zu erreichende Velocity zur\u00fcck ins Glied geholt. Und je gr\u00f6\u00dfer die zu bew\u00e4ltigenden Story Points, desto dringlicher ist der Fokus! Hohe Komplexit\u00e4t kommt mit gro\u00dfer Unklarheit; da z\u00e4hlt jede Minute im Sprint.<\/p>\n

Am Ende einer Periode kann man dann schauen, inwiefern der Fokus gegl\u00fcckt ist. Wurde die angepeilte Gesamtkomplexit\u00e4t bew\u00e4ltigt? Wenn nein, wo hat es gehakt? Oder war sogar Luft nach oben?<\/p>\n

Auf eine solche Retrospektive finde ich wunderbar. Man nimmt sich etwas vor und schaut am Ende, ob man es geschafft hat. Indem man sich etwas vornimmt, sich ein Ziel setzt, wird die Fokussierung bef\u00f6rdert. Im Zweifelsfall wei\u00df man immer, wo Aufmerksamkeit investiert werden sollte.<\/p>\n

Warum aber die Story Points zur Fokussierung benutzen? Reicht es nicht, die auch aus den Story Points abgeleiteten Anforderungen zu tracken? Am Anfang einer Periode stehen 10 Anforderungen zur Diskussion. Die werden in der Komplexit\u00e4t gesch\u00e4tzt. Dadurch werden daraus 12 Anforderungen. Von diesen 12 Anforderungen nimmt man sich f\u00fcr die Periode 7 vor. Fertig.<\/p>\n

Nachdem man sich f\u00fcr diese 7, das Sprint Backlog, entschieden hat, ist es doch egal, warum man das getan hat. Entweder man schafft alle 7 oder nicht. Am Ende der Periode kann man dann auf sein digitales Team-Kerbholz 7 oder auch nur 5 oder gar 8 Kerben machen und diese Anzahl einer Summe hinzuf\u00fcgen f\u00fcr eine kummulierende Darstellung.<\/p>\n

Wenn man den Plan unter- oder \u00fcbererf\u00fcllt, dann kann man gern dar\u00fcber reflektieren und dabei auch die Komplexit\u00e4tssch\u00e4tzungen heranziehen. \"Bei welcher Anforderung haben wir die Komplexit\u00e4t wieder zu niedrig eingesch\u00e4tzt?\" ist dabei wahrscheinlich die h\u00e4ufigste Frage.<\/p>\n

Ein Tracking der Komplexit\u00e4tssumme jedoch braucht es daf\u00fcr nicht. Das ist nicht nur nicht hilfreich, das ist sogar missweisend.<\/p>\n

Fortschritt nur mit Wert<\/h2>\n

Softwareentwicklung soll kundenorientiert sein. Wert soll f\u00fcr den Kunden geschaffen werden. Wo ist der in einer Komplexit\u00e4tssch\u00e4tzung zu finden? Welche Wertentwicklung hat eine Software, wenn die Velocity stets \u00e4hnlich ist?<\/p>\n

Korreliert Wert mit Komplexit\u00e4t positiv? H\u00f6chstens schwach, w\u00fcrde ich sagen. So schwach, dass ein Diagramm, das die Entwicklung heldenhafter Komplexit\u00e4tsbew\u00e4ltigung zeigt, nicht mit einer kundenorientierten Wertschaffung verwechselt werden darf.<\/p>\n

\n

Wert \u2260 Komplexit\u00e4t<\/p>\n<\/blockquote>\n

Was soll also ein Kunde davon halten, wenn ein Team in dieser Periode mehr und in der n\u00e4chsten weniger und dann wieder etwas mehr Komplexit\u00e4t bew\u00e4ltigt?<\/p>\n

Nichts!<\/p>\n

Komplexit\u00e4t interessiert den Kunden nicht. Oder sie interessiert ihn nur indirekt, wenn er eine Antwort auf die Frage will: \"Wann bekomme ich das Features, das mir sehr wertvoll erscheint?\"<\/p>\n

Entwickler geben darauf mit ihren Komplexit\u00e4tsangaben keine Antwort, selbst wenn die mit Aufwand positiv korrelieren. F\u00fcr eine so konkrete Prognose braucht es andere Mittel. Ich empfehle: Vorhersagen basierend auf historischen Daten.<\/a> Aber das ist ein anderes Thema.<\/p>\n

Jeder Kunde kann unmittelbar den Fortschritt der Zeit sp\u00fcren. Die kostet ihn n\u00e4mlich gew\u00f6hnlich Geld auf die eine oder andere Weise, solange die Software noch zu w\u00fcnschen \u00fcbrig l\u00e4sst:<\/p>\n