NBA16: Kleine Stories machen Sinn

Hallo und herzlich willkommen bei NoBullshit Agile. Mein Name ist Thomas. Ich bin Teil eines agilen Teams und bespreche hier jede Woche Themen aus der agilen Projektwelt. Dabei orientiere ich mich an den großen Kategorien Menschen, Teams, Kunden, Projekte und Agilität. Mein Fokus liegt dabei auf der Praxis, daher auch der Name NoBullshit Agile. In der letzten Folge habe ich darüber gesprochen, dass Agilität vor allem ein Mindset ist und wie wichtig ich es finde, das zu verstehen und zu verinheitlichen. Das hier ist die Folge 16 und heute geht es darum, das kleine Story zu Teil Sinn machen. Bevor wir mit dem Thema anfangen, wie immer ein bisschen Housekeeping, ich hatte zur letzten Folge der Folge 15 auf Mastodon eine Umfrage gestartet und zwar lautete die Frage, wie zufrieden seid ihr mit der Agilität bei euch im Unternehmen? Und dabei ist folgendes herausgekommen. Es gab drei Antwortmöglichkeiten. Antwortmöglichkeit 1. Ich bin total zufrieden, haben 8% angeklickt. Zweite Antwortmöglichkeit, da ist noch Luft nach oben, das haben 50% angeklickt. Und die dritte Antwortmöglichkeit war, obwohl wir es sagen, sind wir gar nicht agil. Und das haben 42% angeklickt. 24 Leute haben an der Umfrage teilgenommen. Viele haben sie auch geteilt, vielen Dank da nochmal. Und es gab auch einen ganz interessanten Austausch in dem Thread zu der Umfrage. Da nochmal ganz direkt vielen Dank an Rosanna, Floatchain Senzai, Leonid, Bruno, Eva und Thorsten. Vielen Dank, so was macht mir total Spaß. Und dann merke ich auch, dass ich den Podcast so nicht ins Luftlehre mache, sondern es wirklich Leute gibt, die zuhören und die gerne auch so eine Interaktion suchen. Das freut mich total, das ist der Hauptgrund, warum ich den Podcast gemacht habe oder warum ich den mache, warum ich ihn gestartet habe, weil ich ganz gerne so eure Meinung mal zu den Themen hören möchte, die ich hier so einmal die Woche bespreche. Ja, die Ergebnisse finde ich halt spannend. Es ist ein bisschen auch mein Bauchgefühl und meine Erfahrung, dass die meisten und das muss man halt so sagen, tatsächlich nicht vollkommen zufrieden sind mit der Agilität des Unternehmens. Ich vermute mal, dass es jetzt natürlich Interpretation, Agilität an sich ist schon eine coole Sache, aber die Umsetzung des Ganzen und die Umsetzung ist eben tatsächlich nicht trivial. Wenn ihr Lust habt, ich verlinkt denen die Umfrage und damit dann natürlich auch den Thread hier in den Shownutz. Schaut ja gerne mal rein, was die Leute so zu dem Thema geschrieben haben. Wie gesagt, ich finde super spannend und nochmal vielen Dank an alle für den Austausch. Dann steigen wir mal in das Thema ein, wie gesagt, die Überschrift lautet, kleine Stories machen Sinn. Ich habe halt immer wieder Diskussionen erlebt und erlebe sie zum Teil auch noch, wo Leute sagen, eine große Story ist gut. Also klar, da werden wir uns auch gleich gewohnt erhalten. Was heißt denn überhaupt klein? Ja, aber oft genug sagen Leute, also größere Stories werden halt bevorzugt. Die Argumente sind dann so was wie, ja, die sind einfach zu Hand haben. Die machen das Backlog oder das To-Do nicht so voll. Wenn ich halt eine große Story habe, habe ich halt auch nur eine Story im Backlog dazu und auch nur eine Story im To-Do. Das wirkt natürlich erstmal im Handling für gewisse Leute einfacher. Manchmal ist das Argument auch ja, wenn man eine große Story hat, dann bleibt der Kontext erhalten. Also dann habe ich ja alle Informationen zu dem, was ich liefern soll in einer Story. Und manchmal ist dann das nächste Argument ja, aber die Zerteilung, die kann man ja auch in Subtas machen. Ich muss ja jetzt eine Zerteilung nicht auf Storyebene machen, sondern das kann ich ja da drunter tun. Und manchmal ist auch wirklich das Argument so, ja, das ist dann auch weniger Tipparbeit. Und von diesen Argumenten gibt es halt echt total viele. Das ist keine vollständige Aufzählung, aber ihr seht schon, was so die Argumente pro große Story sind, wo die wohl ungefähr hinzielen. Was ich auch schon gesehen habe, ist, dass tatsächlich ganze Projekte wirklich irgendwie 20 Tage oder noch mehr in einer Story sind. Ja, also ehrlich gesagt, ich habe da überhaupt kein Verständnis für. Das ist wirklich nicht das, was eine Story ist. Dass die Idee einer Story ist da überhaupt nicht mehr drin. Deswegen vielleicht mal so ein bisschen der Blickwinkel darauf. Was ist denn eigentlich ganz fundamental eine Story? Und ganz grundsätzlich geht es darum, wir wollen in einer Story eine Geschichte erzählen. Und wir wollen eben beschreiben, was der Benutzer des Systems mit dem System macht oder vielleicht sogar da erlebt. Und eine Story an sich soll halt einen Wert schaffen. Es ist immer wieder dieses Thema, was tun wir und schlussendlich wollen wir einen Wert liefern. Für uns selber, wenn wir denn für uns selber entwickeln oder eben auch für einen Kunden. Und eine Story hat halt überhaupt nichts mit der Verwaltung von einem Projekt oder mit Projektmanagement zu tun. Und dann sind wir wieder genau an dieser Stelle, wo wir vorhin bei den Pro Argumenten für große Stories waren. Wenn dann so kommt, kleine Stories machen, mein Backlog, schwieriger im Handling oder wenn ich eine große Story habe, dann bleibt der Kontext erhalten. Dann ist das immer der Blick von einem Projektmanagement. Und ich höre halt immer wieder, dass Methodiken, Projektmanagement Methodiken wären. Also sei es Scrum oder sei es kann man, aber das sind sie einfach nicht. Diese Methodiken sollen schlussendlich bei der Agilität unterstützen. Und ich bin ja wirklich, das habt ihr wahrscheinlich auch gemerkt bei ein paar anderen Folgen, wenn ihr bei ein paar anderen Folgen mal reingehört habt, gar nicht so auf der Seite, wie funktioniert Scrum oder wie funktioniert kann man, sondern ich bin ja eher an dem Fundament, an der praxisnahen Ecke der Agilität und kommen deswegen halt immer auf das Agile Manifest und die 12 Agile im Prinzipien. Und ich finde es einfach richtig und wichtig, das aus der Agilität heraus grundsätzlich anzugucken. Und deswegen komme ich auch immer wieder in den Diskussionen an die Stelle, wo ich sage, ja jetzt in diesem Fall Stories und kleine Stories, was ist eine Story, diese fundamentale Frage? Und eine Story ist wie gesagt, hat nichts mit Projektmanagement zu tun. Und wenn wir uns mal so ranrobben an was ist eine Story und welche Kriterien soll eine Story erfüllen, dann finde ich eine Story soll so klein wie irgendwie möglich sein und sie soll in sich geschlossen sein. Das ist jetzt die erste Aussage zu klein und groß und in sich geschlossen. Und ich weiß, ich sage nachher auch noch was dazu, dass es keine absoluten Größen für Stories gibt. Und das würde ich auch nie einführen. Ich würde nie sagen, okay, das hier ist die maximale Größe einer Story, weil das einfach sehr stark auch an dem dran hängt, was ihr tut und in welchem Umfeld ihr arbeitet. Aber die relative Aussage so klein wie möglich, so klein wie irgendwie möglich, die kann man treffen, die kann ich treffen. Und ich finde, da gehört die Diskussion und die Beobachtung einfach permanent auch dazu. Diese Story, die wir hier haben, ist die wirklich so klein wie möglich oder gibt es organisatorische oder technische Gründe, warum wir sagen, die muss so groß und ich mache gerade Gänsefüßen in der Luft, die muss so groß sein. Weil dann kann man nämlich gucken, okay, was kann ich denn technisch tun, jetzt vielleicht nicht sofort, aber worauf kann ich hinarbeiten, dass der technische Grund für große Stories Schritt für Schritt beseitigt wird oder eben auch der organisatorische Grund für große Stories. Schlussendlich möchte ich in der agilen Welt, dass Stories so schnell wie möglich released werden können, damit sie eben diesen Wert schaffen. Und Wert schaffen kann etwas nur, wenn es am Markt ist. Also dann spielt es vielleicht einfach echte Euro ein, aber Wert schaffen bedeutet eben auch, ich kann meinen Feedback-Zyklus starten, ich kann das Feedback zu dieser Story bekommen, um zu gucken, ob sie zum Beispiel am Markt funktioniert. Und wie gesagt, natürlich geht es auch um das, was der Kunde da zum Beispiel bezahlt hat, das soll halt natürlich Geld wieder verdienen. Und die kleinen Stories werden uns auch bei der Vertragsgestaltung mit dem Kunden helfen. Ich werde eine Folge machen über ja, agilen Festpreis, no estimates, wie kann man denn agile Vertragsgestaltung mit Kunden machen, wie kann ich den Kunden überzeugen, dass das Schluss endlich auch, ich sag mal, wirtschaftlich der bessere Weg ist. Und da werden kleine Stories einfach eine große Rolle spielen. Ha ha, kleine Stories große Rolle. Als nächstes zu diesem Punkt, was ist denn klein? Und ich hätte ja schon gesagt, ja, das ist natürlich relativ, aber meine Einschätzung, meine Erfahrung nach, wenn es irgendwie zwei Wochen bis zu einem Release dieser Story dauert, dann ist die Story zu groß. Dann ist einfach der Abstand dieser Feedback-Zyklen zu groß. Und ich finde alles, was über zwei Wochen ist, ist ja, na ja, untragbar ist so ein hartes Wort, aber also ich würde wirklich harte überlegen, was ihr euch da auch wegnehmt, wenn ihr solche Zyklen haben. Jetzt weiß ich natürlich wieder, viele von euch machen Scrum und ihr habt Sprints und ihr liefert höchstwahrscheinlich das Inkrement am Ende des Sprints und zwei Wochen Sprint ist, glaube ich, so eine relativ typische Sprintgröße. Ich weiß, manche Leute gehen auf eine Woche, finde ich auch deutlich besser, aber es gibt natürlich auch Sprints, die mehr als zwei Wochen dauern. Und das ist für mich wieder ein Rund, wo ich denke, ja, in bestimmten Situationen, umfelden geht es gar nicht anders, aber vielleicht könnt ihr darüber nachdenken, dass sie auch während eines Sprints schon was liefert, um diesen Feedback-Zyklus zu bekommen und um wirklich echte Werte dazu schaffen. Es gibt wirklich richtig, richtig gute und richtig praxisrelevante Methoden, um Stories, die man hat, zu beobachten und sie auch kleiner zu kriegen. Ich habe einfach jetzt einen Artikel in den Schonwurz verlinkt. Es gibt viele Methoden, zum Beispiel die Invest-Methode, alles Leitlinien, die sehr praxisnah helfen zu prüfen. Kriege ich die Story noch kleiner und die auch sehr praxisnah eben einem was an die Hand geben, um zu sagen und so kriegen wir diese Story kleiner. Deswegen, wenn ihr euch damit noch nicht beschäftigt habt, schaut einfach mal rein, wie gesagt, dieser eine Artikel, den ich verlinkt habe, das ist vielleicht so ein Startpunkt, irgendwo muss man ja anfangen. Ich möchte ganz gerne nochmal insgesamt im Zusammenhang Argumente für kleine Stories bringen. Das erste und vielleicht auch das wichtigste Argument, ich finde kleine Stories sind einfach deutlich einfacher im Handling. Also das kann ich im Planen sehr einfach benutzen, das kann ich im Sortieren einfach benutzen. Ich finde, sie sind viel einfacher zu diesem ganzen Thema agiles planen. Da findest du in der Folge 13 agile Projektplanung auch nochmal viel und da greif ich das Thema kleine Stories tatsächlich auch nochmal auf. Den Link zu dieser Folge findest du wie alle Links in den Schonwurz. Das nächste Argument für kleine Stories ist, ich finde die schaffen Fokus. Es ist viel einfacher, den Fokus zu halten und Kontextwechsel zu vermeiden, wenn man denn mit kleinen Stories arbeitet, weil ich eben dann beschränkt bin auf das, was in dieser Story zu erledigen ist. Vorhin das Beispiel, was ich hatte, ganze Projekte sind eine Story. Das ist super, super schwer wirklich zu gucken, wo ist da jetzt gerade mein Teil an was arbeite ich und was ist mein Fokus. Das nächste kleine Stories helfen einfach bei der Transparenz und Transparenz ist ja auch wieder so ein ganz fundamentales Ding aus dem agile Manifest. Es ist viel besser erkennbar, wie der Fortschritt ist. Für dich als Teammitglied, für das Team, für alle weiteren Stakeholder, für die Kunden, wenn ihr euer Board teilt mit dem Kunden, man sieht viel besser, ah, gucke mal, diese Story ist in diesem Stadium. Das hilft übrigens auch natürlich beim Daily. Es gibt deswegen mehr Transparenz. Ich kann daran dann erkennen, wir kommen voran oder man erkennt eben auch, diese Story ist schon lange in diesem Status. Die ist eigentlich gar nicht so groß. Da scheint ja wohl ein Blocker zu sein. Das kann man dann auch aktiv zum Beispiel im Daily ansprechen und sagen, hier was ist denn mit dieser Story, die geht einfach nicht weiter, was ist denn da los, um so ins Gespräch auch im Team zu kommen, dass jemand dann sagen kann, ja, also gut, dass du es ansprichst, ich kann da Hilfe gebrauchen. Mit kleinen Stories habt ihr eine viel größere Flexibilität, denn ihr könnt die Reihenfolge der einzelnen Stories natürlich viel besser steuern. Ihr könnt seit viel Flexibler die Reihenfolge auch zu verändern, wenn ihr auf das Umfeld reagieren wollt oder misst. Kleine Stories erhöhen den Durchsatz. Also das betrifft natürlich, dass eine kleine Story schneller fertig ist, aber das betrifft auch alle möglichen Prozessschritte, die überhaupt definieren, dass eine Story dann fertig ist. Also vielleicht habt ihr einen QA-Prozess, vielleicht habt ihr im Prozess gemeinsam mit dem Kunden eine Feedback-Runde, bevor es in Produktionen gibt. Das geht mit kleinen Stories natürlich alles viel, viel schneller. Ein weiteres Argument ist das Thema Risikomanagement. Manchmal wird das vergessen, habe ich so das Gefühl. Kleine Stories bergen viel weniger Risiko als große Stories. Ich kann nach einem Release viel schneller auch auf Situationen reagieren. Das habe ich bei großen Stories nicht. Und kleine Stories helfen ganz einfach bei Releases. Ich bin hier viel schneller. Das Stichwort wäre hier die Bewegung hin zu Continuous Delivery. Wenn ich auf diesem Weg bin und dahin möchte, sind kleine Stories unabdingbar. Denn sonst kann ich überhaupt nicht in diesen Modus von Continuous Delivery kommen. Mein Tipp wäre, probiert das mal aus, wenn ihr es gefilbt. Ihr habt zu große Stories, kontrolliert wirklich mal, wie lange bau ich so eine Story, braucht bis bis ihr wirklich Geld verdient oder ein Wertschafft auf eine andere Art und Weise, bis der Feedback-Zyklus wirklich starten kann. Beobachtet das mal scharf und versucht mal wirklich rauszufinden, ob die Story so klein, wie es für euch möglich ist, wirklich wahr. Hätet ihr diese Story kleiner bekommen und versucht es zu berücksichtigen, wenn ihr neue Stories anfängt. Lasst euch nicht von einem Tool wie zum Beispiel Giradan hindern, kleine Stories zu machen. Also versucht wirklich einfache Lösung zu finden. Ich sehe das viel zu oft, dass Leute sich von Tools leiten lassen, dass sie sagen, ja, das Tool kann das aber nicht. Versucht wirklich solche Dinge zu eliminieren. Wir wollen Agil sein. Wir sind uns sicher, dass das der richtige Weg ist. Und ja, da wollen wir uns von solchen Dingen nicht behindern lassen. Was mich wirklich interessieren würde, ist, was ist für euch eine kleine oder eine große Story? Wie lange braucht ihr für eine Story bis sie fertig ist? Auch dafür starte ich parallel zu dieser Folge eine Umfrage auf Mastodon. Und auch da würde ich mich einfach wieder riesig freuen, wenn ihr mitmacht, wenn ihr die teilt, wenn ihr mit mir zusammen und mit anderen auf Mastodon das diskutiert. Ja, und das soll es eigentlich schon gewesen sein für heute. Wie gesagt, vor allem soll das eine Inspiration sein, nochmal über Stories nachzudenken. Und wie immer, ich freue mich einfach auf euer Feedback. Ich freue mich auf eure Meinung. Ich freue mich auch wirklich über kritische Meinungen. Ich habe die Weisheit hier auch nicht mit Löffeln gefressen. Und wie ich vorhin schon gesagt habe, das Ganze ist für mich einfach so ein Diskussionsstarter. Deswegen auch wenn ihr etwas nicht gefällt, schreibt mir das gerne. Wenn du Feedback hast, jeglicher Art, gibt mir die Möglichkeit, mich zu erreichen. Du kannst mich per Mail erreichen unter nobshile@gmail.com. Du findest mich auf Mastodon. Es gibt einen Forum, wo wir uns austauschen können. Gib mir wie gesagt super, super gerne Feedback. Dann wünsche ich dir noch eine ganz tolle Woche und wir hören uns beim nächsten Mal. Ciao, ciao. [Musik] [Musik] [Aufregende Musik]