NBA04: Scrum: Warum es Zeit ist, ein anderes agiles Vorgehen zu erwägen

Hallo und herzlich willkommen bei No Bullshit 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 immer auf der Praxis, daher auch eben der Name No Bullshit Agile. In der letzten Folge habe ich über das Thema Open Space, also so eine Art Barcamp gesprochen. Da geht es vor allen Dingen um den Wissensaustausch in der Firma und das hier ist die Folge Nummer 4 und heute soll es um Scrum gehen. Scrum ist sicherlich das große Thema. Ich glaube uns allen fällt Scrum als erstes ein, wenn man über Agilität spricht und ich will heute mal ein bisschen meinen Blick darauf erläutern. Ich sehe das mittlerweile muss ich dazu sagen alles ein bisschen kritischer. Ich bin mittlerweile nicht mehr sicher, dass Scrum das beste agile Framework ist. Ein Hauptgrund für mich ist tatsächlich entspricht Scrum wirklich den fundamentalen agilen Prinzipien. Zu dem Prinzipien mache ich sicherlich auch nochmal eine Folge, aber es gibt so ein paar Punkte wo ich denke, nach ist Scrum um das gleich mal sozusagen nicht doch eher einen Management Framework. Scrum neigt dazu meiner Meinung nach, dass ein Management eine gute Möglichkeit hat, zum Beispiel einen Reporting zu bekommen. Vielleicht nochmal kurz zu mir. Ich hätte das ganze am Anfang in der ersten Folge ja schon mal erzählt. Ich habe mit einem Team knappe fünf Jahre, ich überliege gerade, aber ich glaube knappe fünf Jahre wirklich hardcore Scrum gemacht und wirklich nach Scrum Guide, also so wie sich das gehört, bin also der Meinung, ich kenne mich eigentlich mit Scrum einigermaßen aus. Wir haben alle Prozesse, alle Rituale gut durchlebt, haben das für uns angepasst und getuned und würde deswegen sagen, dass ich schon Erfahrung mit Scrum habe. Scrum im Gegensatz zum Beispiel kann man orientiert sich halt stark an Planung und Ausführung von Projekten. Der Fokus liegt tatsächlich auf Projekten und eben nicht auf Software. Der große Unterschied gedanklich ist halt für mich an der Stelle, der Blick auf Entwicklung von Software, die gut funktioniert, ist halt viel viel wichtiger als der Blick auf Projekte. Projekte beziehen sich immer auf sowas wie Timings, wie viel ist wandschaftbar, was kostet das, das sind alles wichtige Informationen, die braucht man als Projektmanager auch. Und der Kunde braucht sie auch, aber schlussendlich geht es ja nun mal wirklich darum, funktionierende gute Software zu liefern, egal auf welcher Art. Und Scrum hat eben diesen fundamentalen Ansatz darauf abzuzielen, wie man Projekte durchführt. Deswegen auch meine These da und ich bin damit auch nicht alleine, dass Scrum eher ein Management-Tool ist. Es geht eher darum eben zu gucken, wer ist wann, wofür verantwortlich. Es gibt eben in Scrum die ganz klaren Rollen, den PO, der die Produktvision hat. Es gibt das Team, das sich kummittet dazu, in einem Sprint eine Leistung zu erbringen. Und es gibt den Scrum-Master, der vor allen Dingen eine organisatorische Rolle auch hat. Und der im Zweifelsfall auch derjenige ist, der dem Team, ich formuliere es mal positiv, helfen soll, seinen Commitment des Sprints auch einzuhalten und zu erreichen. Der Scrum-Master an sich hat natürlich auch viele positive Eigenschaften in seiner Rolle. Er schützt das Team eben für einen Außeneinfluss. Es gibt ja diese lustigen Witze zu jemanden, kommt mit dem Donut an und sagt, kannst du das für mich nicht schnell machen? Und dann stellt sich das Scrum-Master eben davor und sagt, nee, für einen Donut wird das nichts. Das müssen schon zwei sein. Nee, Spaß beiseite. Aber ihr wisst, was ich meine. Wenn wir mal zur Projektplanung kommen, dann kann ich aus meiner Erfahrung sagen, dass man natürlich durch zum Beispiel Velocity irgendwann mal ein Gefühl dafür entwickelt, was denn wohl die Velocity des Teams ist und die wird im Laufe von Projekten je öfter man das macht, auch zuverlässiger. Es sei denn, es ändern sich Parameter, es sei denn zum Beispiel, dass was das Team entwickeln soll, ist komplettes Neuland, dann ist nämlich die alte Velocity ehrlich gesagt gar nicht mehr belastbar. Und in dem Moment ist man wieder bei der Situation, dass man eine gewisse Prognose treffen muss. Und natürlich ist ein probates Mittel, die Stories in kleine Teile zu zerteilen und im Task-Splitting halt zu gucken, wie komplex ist die Aufgabe und die Velocity im Zweifelsfall auch anzupassen. Aber schlussendlich ist es eben ja ein Fundament von Scrum, die Iteration. Und in der Iteration kummittet sich das Team dazu, eben die entsprechenden Elemente der Iteration auch umzusetzen. Doch die Praxis zeigt eben, dass das immer und immer schwierig ist. Wenn man repetitive Tätigkeiten hat, ist eine Velocity sicherlich sehr verlässlich und ist auch ein gutes Mittel für eine Prognose. Ich bin nicht grundsätzlich dagegen. Aber in dem Moment, wo ich etwas tue, was nicht bekannt ist, wo die das Team zwar eine Velocity durch Storypoint-Schätzung ermitteln kann, aber sobald das nicht mehr auf festen Beinen steht, ist es eben sehr, sehr schwierig, das Commitment auch einzuhalten. Und natürlich und deswegen dieses Thema Management-Tool ist es von außen gesehen für andere total angenehm zu sagen, ja, das Team hat sich darauf kummittet und zum Beispiel auch zu sagen, okay, das Team hat ja eine Velocity von 100 oder so und es ist ja auch nicht mehr in dieser Iteration als 100. Und deswegen ist dieser Ansatz des Management-Tools bei Scrum halt so stark da. Andere Methoden, wie zum Beispiel Kannmann, aber auch Extreme Programming, sind halt viel dichter an der Softwareentwicklung und damit auch an der Realität. Solche Systeme erkennen eben an, dass wir unbekanntes Terrain da bestreiten, wenn wir Software entwickeln, weil in der Regel eine Softwareentwicklung immer eine Individuallösung ist. Das ist halt nicht wie bei VW, wo einmal definiert es wie ein Golf aussieht und dann kann man den reproduzieren, sondern in Zweifel machen wir komplex oder nicht komplex permanent neue Dinge. Und das erkennen XP oder Scrum oder Kanban eben an und bei Scrum gibt es so eine trügerische Sicherheit der Planbarkeit, nämlich die Iteration oder den Sprint. Und Kanmann und Extreme Programming erkennen das eben an, was ich vorhin schon meinte. Scrum ist nur Projektmanagementmethodik, Kanmann nennt sich Change Management Methodik und Extreme Programming ist halt vor allen Dingen der Methodik, wie man Software entwickelt. Es ist dichter an der Software als an dem Projekt. Was ich positiv über Scrum sagen kann, um das auch noch zu erwähnen, es ist eigentlich ganz schön den Guide Line an sich zu haben, weil eigentlich von Tag 1 an klar ist, welche Rollen es gibt, welche Rituale es geben soll, wie lang die Zeiträume jeweils sind für ein Daily, für ein Refinement, für ein Sprint Planning. Das ist ja alles definiert im Scrum Guide. Sprich, man hat eigentlich ein relativ verlässliches System. Wenn ich da Kanmann als das Gegenbeispiel mir angucke, der Kanmann Guide ist auch gewachsen überall die Jahre, er ist auch recht ausführlich, aber er beschreibt eben einfach nur das Meinzitten, das grundsätzliche Vorgehen. Und ein fundamentales Prinzip von Kanmann ist ja eben Start da, wo du bist. Also schau dir deine heutigen Prozesse an und dann kommt bei Kanmann die zweite Komponente dazu, Evolutionäres Change Management. Nutze alle Erfahrungen, um dann eben das Kanmann System, das System, wie du Software schreibst, wachsen zu lassen. Es gibt noch ein ganz schönes Zitat, was ich gefunden habe oder so ein Gedankenspiel, nämlich Scrum kann ja so eine Art Gateway Droge zur Agilität sein. Und das finde ich gar nicht so schlecht. Was ich eben gerade schon sagte, Scrum hat deutlich klare Regeln, ist deswegen wahrscheinlich erstmal einfacher zum Starten und dann kann man irgendwann auch Scrum verlassen. Wir hatten zum Beispiel das Problem, dass wir eben nicht nur neue Software entwickelt haben, sondern auch ältere Software supporten mussten. Und auch da kann man sich was überlegen, dass man sich x% oder y-Velocity Punkte eben für unbekannte Dinge reserviert. Das heißt, es lässt sich schon auf irgendeine Art und Weise einbauen. Aber in dem Moment verlässt man dann eigentlich auch schon wieder Scrum. Ich weiß, es gibt theoretische Ansätze oder es gibt Agenturen und Firmen, die solche Ansätze auch nutzen. Das ist nicht nur eine Theorie, um diese unbekannten Dicke einzubauen. Aber das ist eben etwas, was Scrum so nicht vorsieht, aufgrund der einzelnen Sprints. Und kann man, managed halt nur den Flow, sprich, da geht es vor allen Dingen da drum, wie kann ich den Flow optimieren von "Advice is ready for development" bis "Release". Und da sind keine Zyklen und keine Iterationen drin. Und damit kann ich diesen Flow auch anpassen. Ich kann ja definieren, was als nächstes ins System kommt, durch Optionen. Also das, was die nächsten Dinge für das Team sind, was das Team sich als nächstes nehmen kann. Und da ist es einfach so auch solche Dinge wie Expedite oder eben Support-Tätigkeiten lassen sich mittels kann man deutlich transparenter und auch einfacher steuern. Es ist auch in meinen Augen eben deutlich ehrlicher zu sagen, das ist jetzt etwas, was einfach die höchste Priorität hat, weil es zum Beispiel den größten Wertschaf, als wir haben uns vor anderthalb Wochen dazu committed, dass das und das und das gemacht wird und wir mogeln, ich mache gerade so Gänsefüßchen in die Luft, wir mogeln jetzt mit einer Ausnahmeregel noch Dinge mit rein. Und ich habe mich selber erlebt in Scrum, dass ich gesagt habe, ja das ist jetzt eigentlich nicht ganz die Regel, aber das müssen wir jetzt machen, wo wir immer und immer wieder das System zumindest stark geborgen haben, damit das funktioniert. Und wenn man sich mal in Foren umguckt, die sich mit Agilität beschäftigen oder Artikel dazu diest, das Thema taucht auch immer und immer wieder auf. Also ich bin ziemlich sicher, dass es nicht nur uns so gegangen ist, sondern halt vielen weiteren. Was ich jetzt gar nicht groß gesagt habe, da kann ich nur ein, zwei Sätze zu sagen. Scrum hat natürlich auch so eine Kraftvolle, wenn man es jetzt sehr picky sehen will, auch so gewaltvolle Wörter, Vokabular, also Scrum aus dem Rugby, Scrum Master, das ist alles, es ist alles eher verfestigt, sage ich mal. Ich kann halt nur sagen, mir gefallen Ansätze, wie kann man viel besser. Ich finde es besser, dass das Thema, wir wollen funktionierende Software liefern im Mittelpunkt steht und nicht das Projektmanagement für eine Entwicklung. Und das ist sicherlich etwas, was man meiner Meinung nach Scrum einfach auch angreiden kann. Ja, über das Thema könnte man sicherlich noch deutlich länger reden. Ich werde mal gucken, das würde ich dann in den Show Notes mit aufnehmen, dass ich vielleicht ein, zwei Artikel noch dazu erwähne, aber ansonsten denke ich, wir sind soweit durch für heute. Und wie ich immer sage, ich freue mich über Feedback. Vielleicht gibt es zu diesem Thema ja ein bisschen mehr Feedback, weil ihr einfach eine ganz andere Meinung habt, weil ihr ganz andere Erfahrungen gemacht habt. Vielleicht nutzt ihr Scrum auch anders als wir. Vielleicht seid ihr irgendwie unternehmensintern eine Software Entwicklungsabteilung. Da kann ich mir Scrum nämlich zum Beispiel viel besser vorstellen als für eine Agentur, die für mehrere Kunden was entwickelt. Da würde ich ganz gerne in Austausch gehen. Deswegen, wenn du Feedback hast, dann gerne als Mail zum Beispiel an nobsagile@gmail.com. Alternativ findest du mich auch auf Mast oder unter nobullshit@gile@podcast.com. Habt eine ganz tolle Woche und bis zum nächsten Mal. Bye. [Musik] heures.