NBA57: Wie sieht das ideale agile Projekt aus?

00:00:00: Hallo und herzlich willkommen bei No Bullshit Agile. Mein Name ist Thomas. Jede Woche spreche

00:00:07: ich hier kurz und knapp über Themen rund um agiles Arbeiten. In der letzten Folge habe

00:00:12: ich mich gefragt, was man tun kann, wenn Kunden oder Stakeholder nicht mitziehen und hab euch

00:00:17: dazu ein paar Tipps gegeben. Wenn dich das interessiert, hör da gerne rein. Den Link

00:00:22: zu der Folge und alle weiteren Links, die ich hier erwähne, findest du in den Show Notes.

00:00:26: Heute in Folge 57 will ich mal darüber sprechen, wie meiner Meinung nach das ideale agile Projekt

00:00:32: aussieht. Ich hab seit ein paar Monaten ein relativ großes Projekt und ja, hab da tatsächlich mal

00:00:38: wieder, sag ich mal, so ein paar Learnings. Und ja, ich will zumindest einmal durchgehen,

00:00:44: was ist wohl ein ideales Projekt und werde sicherlich dann an einigen Stellen auch sagen,

00:00:49: was in meinem aktuellen Projekt gerade nicht so gut funktioniert und was ich denke,

00:00:54: was man denn dagegen tun kann. Ja, ich würde sagen, wir fangen mal an. Ich hab das Ganze in

00:00:59: so Oberkategorien eingeteilt. Das ist bestimmt nicht überschneidungsfrei, aber ich denke,

00:01:04: damit schaffen wir eine ganz gute Rundreise. Ich fange jetzt mal an beim Kunden. Kleine Erinnerung

00:01:11: nochmal. Wir sind ja eine Agentur, die Software für Kunden entwickelt. Es mag sein, dass es bei

00:01:18: euch ein bisschen anders ist. Deswegen benutze ich Kunden und Stakeholder tatsächlich hier

00:01:23: relativ analog. Diese Gruppe ist also relativ groß gefasst bei mir, relativ allgemein gefasst. Ich

00:01:28: meine, wenn ihr intern entwickelt, habt ihr intern auch Kunden. Insofern denke ich jetzt einfach mal,

00:01:33: sollte das passen. Das Erste, wenn ich von Kunden spreche, ist, die müssen auch den Willen dazu

00:01:39: haben, agil zu arbeiten. Die müssen es verstanden haben, warum agiles Arbeiten großer Vorteil ist.

00:01:45: Wenn der Kunde oder die Kundin so eher im Mindset ist von, agil klingt toll. Ich meine,

00:01:52: alle Kunden mittlerweile, habe ich das Gefühl. Jeder sagt, auf jeden Fall will ich agil arbeiten,

00:01:58: aber dann doch eher innerlich so ein Wasserfall sich vorstellt, dann ist es schon schwierig. Ich

00:02:06: wünsche mir, dass Kunden wirklich Zeit für das Projekt haben, dass sie wirklich immer erreichbar

00:02:12: sind, dass man sich darauf verlassen kann, dass man zum Beispiel frühzeitig Feedback vom Kunden

00:02:18: bekommt. Der Kunde sollte halt sehr gut informiert sein über die Ziele des Projekts. Es nützt ja

00:02:24: überhaupt nichts, wenn ich einen Kunden habe, der selber auch nur durchleitet irgendwelche

00:02:30: Informationen, die von irgendwo anders kommen oder der Kunde sich auch nicht besonders intensiv mit

00:02:35: dem Projekt beschäftigt hat. Das ist für mich super wichtig. Diese beiden Punkte sind übrigens

00:02:41: Punkte, die ich im aktuellen Projekt ein bisschen vermisse. Also vor allen Dingen das Thema Zeit. Ich

00:02:47: vermute, das kennt ihr auch. Klar, Leute haben alle immer viel zu tun, aber wenn sie nicht

00:02:52: engagiert sind und wenn sie nicht die Zeit mitbringen, in all den Punkten der Zusammenarbeit,

00:02:58: die agiles Arbeiten so mitbringt, wird es halt unheimlich schwer. Wichtig ist auch, dass dieser

00:03:03: Kunde in der Lage ist, Entscheidungen zu treffen, denn auch das tun wir ja permanent. Wenn wir

00:03:08: umplanen, wenn wir Details definieren, dann müssen halt Entscheidungen getroffen werden und das am

00:03:15: liebsten so schnell wie möglich, damit die Entscheidungen den Laden nicht aufhalten. Ist

00:03:20: es vielleicht nicht der Fall, also ist der Kunde vielleicht nicht direkt oder mein Ansprechpartner

00:03:25: nicht direkt derjenige, der die Entscheidungen trifft oder der die Ziele sehr gut kennt,

00:03:30: ist es zumindest wichtig, dass dieser Mensch einfach gut verdrahtet ist, guten Kontakt hat zu

00:03:37: all denen, die die Entscheidung treffen und dass die dann bereit sind, schnell Entscheidungen zu

00:03:41: treffen. Das kann man ja machen, für mich jetzt überhaupt kein Problem, sage ich mal, dass ich

00:03:46: so einen Vermittler oder eine Vermittlerin habe, die dann für alle anderen spricht. Das kenne ich

00:03:54: und ich kenne Situationen, wo das einfach sehr gut funktioniert. Ist das nicht der Fall, ist das ein

00:04:00: Riesenproblem. Genau und es ist halt unheimlich wichtig, klare Ziele permanent benennen zu können.

00:04:08: Also ich helfe da gerne, aber ich kann es ja nur aus meinem Blickwinkel machen und es nützt ja

00:04:14: nichts, wenn ich Ziele vorgebe, die dann nicht mit den Kundenzielen zusammenpassen. Logischerweise

00:04:20: wird das nicht funktionieren und die übergeordneten Ziele sollten für so ein Projekt eigentlich stabil

00:04:26: sein. Klar, die Wege dahin, also Detailziele, die können sich permanent ändern. Das ist ja eben

00:04:32: genau das Agile Arbeiten, dass wir auf Feedback und Einfluss eingehen wollen und damit ändern sich

00:04:38: natürlich Unterziele. Finde ich vollkommen natürlich, aber die großen übergeordneten

00:04:42: Ziele sollten eigentlich definiert sein. Was will ich denn mit dem Projekt erreichen? Warum will ich

00:04:47: denn Geld ausgeben? Das kann man ja eigentlich, müsste man ja eigentlich fest von ausgehen, dass

00:04:53: das klar definiert ist. Ist aber manchmal nicht. Genau, das wäre so für mich ein großer Wunsch an

00:05:01: die Kunden. Sie sollten halt eben klar sein darüber, was das Projekt ist, was das Projekt erreicht und

00:05:09: sie sollten eben die Zeit für das Projekt einfach auch haben und nicht denken und das erlebe ich

00:05:15: halt immer und immer wieder. Jetzt habe ich ja jemanden anders, der mein Projekt erfolgreich

00:05:20: macht. Ich habe das jetzt mal auf die Straße gesetzt und ich gebe jetzt Geld aus und deswegen

00:05:25: wird mir etwas geliefert, das genau das tut, was ich will. Ja, das wird einfach nicht funktionieren

00:05:31: und trotzdem erlebt man es in der Praxis immer wieder. Richtig schlimm wird es in dem Moment, wo

00:05:35: der Kunde halt selber schon bei Anfrage irgendwie sagt und ich möchte gerne, dass wir Scrum nutzen.

00:05:41: Also erlebe ich auch immer wieder. Da wird dann irgendwie so eine Methode in den Raum geworfen.

00:05:46: Damit ist ja gar nichts erreicht. Komme ich später auch noch mal drauf. Das nächste ist dann das Team,

00:05:51: das dieses Projekt macht. Damit meine ich jetzt erst einmal natürlich das Umsetzungsteam. Dieses

00:05:57: Team muss natürlich in der Lage sein, all die Leistungen zu erbringen, die für das Projekt

00:06:01: nötig sind. Und falls das nicht der Fall ist, kenne ich auch, dass Teams nicht alles, alles in dem

00:06:08: Projekt können. Da muss die Vernetzung zu anderen Teams sehr gut sein, die die anderen Leistungen

00:06:13: erbringen. Und es ist wichtig, diese anderen Teams auch immer in the loop zu halten. Also die

00:06:19: müssen auch immer wissen, wo steht dieses Projekt, wann sind wir dran, welche Teile können wir

00:06:23: zuliefern, welche Ziele hat das Projekt. Also sind weitere Teams oder weitere Personen involviert,

00:06:29: dann müssen die den gleichen Kenntnisstand haben wie alle anderen Projektbeteiligten. Sonst wird

00:06:34: auch das im Projekt ein Riesenproblem werden. Das Team muss natürlich auch ein Verständnis von

00:06:39: agilem Arbeiten haben. Es braucht alle Methodiken und auch alle Tools, um eben agil arbeiten zu

00:06:46: können. Also Methodiken und Tools ist natürlich sehr weit gefasst. Ich will das auch gar nicht

00:06:51: groß detaillieren hier. Ich denke mal, es ist vollkommen klar, dass das Team eben auch

00:06:56: dieses Verständnis haben muss. Ich kann in der Praxis sagen, das Team ist eigentlich nie das

00:07:02: Problem. Logischerweise nicht, finde ich, denn ja, also wenn die es nicht verstanden haben, wie will

00:07:08: man verlangen, dass so ein Kunde oder Stakeholder das kann. Gut, wir haben also die Kunden und ich

00:07:14: sage mal jetzt meine Wünsche an den Kunden und wir haben das Team und meine Wünsche an das Team.

00:07:19: Das nächste große Thema ist dann die Planung. Wir müssen, wenn wir so ein Projekt starten,

00:07:26: gerne sogar in der Anwarnung von so einem Projekt gemeinsam mit allen Stakeholdern entlang der Ziele

00:07:34: planen. Für mich ist es wichtig, dass ganz am Anfang ein grober Gesamtplan besteht. Wenn das

00:07:44: Projekt ein halbes Jahr geht oder auch ein ganzes Jahr, ist es trotzdem wichtig, ganz am Anfang zu

00:07:49: sagen, das sind unsere oberübergeordneten Ziele. So viel wissen wir heute über das Projekt und mit

00:07:56: dem Wissenstand, den wir heute haben, gehen wir in eine Gesamtplanung. Auch das stelle ich fest,

00:08:01: wird oft nicht gemacht, weil, naja, wir gehen ja iterativ vor. Also warum soll ich denn jetzt

00:08:08: irgendwas planen, was da hinten in einem dreiviertel Jahr kommt? Ja, planen muss man das schon. Die

00:08:14: Frage ist, wie detailliert plant man es und wie gut stellt man sich auf, um diese Details der

00:08:19: Planung später anzupassen. Ich denke, ganz am Anfang macht es einfach Sinn, zum Beispiel mit

00:08:25: Hilfe von User Story Mapping und Dimensional Planning, das Projekt zu zerlegen, damit man

00:08:31: überhaupt identifizieren kann, was sind erst einmal die wichtigsten Elemente. Mit User Story

00:08:39: Mapping und dann in der Folge mit Dimensional Planning habe ich die Möglichkeit zu sagen, das

00:08:45: sind die ersten Dinge und bitte möglichst in die Breite und nicht in die Tiefe, die wir als erstes

00:08:51: liefern wollen, die eine erste Iteration ausmachen. Ich habe übrigens auch eine Folge gemacht, auch

00:08:57: den Link findest du in den Shownotes zu User Story Mapping und Dimensional Planning. Also wir

00:09:03: wollen alles, was wir vorhaben, in dem Projekt nehmen und wir wollen das mit Hilfe von Methodik

00:09:10: visualisieren und auch schon in Iterationen aufteilen. Es ist dabei so, die erste Iteration

00:09:18: sollte natürlich möglichst konkret sein. Die nächsten Iterationen sind sicherlich die, die

00:09:23: man auch permanent anpasst und das ist genau der wichtige nächste Punkt. Eine Iteration soll

00:09:31: stabil sein, wenn sie fertig ist für die Umsetzung. Wenn wir innerhalb einer Iteration permanent noch

00:09:39: was ändern, bekommen wir auch ein Riesenproblem. Wenn keiner mehr weiß, was ist diese Iteration,

00:09:45: was ist das Ziel der Iteration und wann sagen wir diese Iteration ist abgeschlossen, kriegt man

00:09:51: auch so ein Kaugummi-Projekt. Das ist auch etwas, was ich in der Praxis erlebe, dass man plant und

00:09:57: eigentlich auch einen guten Plan hat und auch eine stabile Iteration und dann innerhalb der

00:10:04: Iteration doch auf einmal keine Einigkeit mehr herrscht, wenn denn die ersten Teile zu einer

00:10:10: Iteration geliefert werden und dann so eine Kette entsteht von, oh dann müssen wir das auch machen,

00:10:17: oh dann müssen wir das auch machen und eigentlich die Argumentation nicht mehr valide ist,

00:10:22: zumindest für mich nicht mehr valide ist, warum das jetzt noch in diese Iteration kommt. Ich habe

00:10:27: manchmal das Gefühl, dass Kunden denken, das würde es dann schneller machen, aber das ist ja

00:10:32: überhaupt nicht der Fall, sondern der Gegenteil ist der Fall. Also wenn man denn die neuen

00:10:37: Erkenntnisse begrüßt und neue Erkenntnisse entstehen sofort, das ist ganz normal, aber sie

00:10:43: wieder einplanen in den Gesamtplan, wird die Geschwindigkeit dadurch deutlich höher sein.

00:10:48: Ich sage ja nicht, Moment mal, das stellen wir ganz hinten an, am Ende von dem Projekt machen wir

00:10:54: dann noch irgendwelche Anpassungen. Darum geht es überhaupt nicht. Es geht darum, dann zu überlegen,

00:10:58: ist das etwas, was vielleicht in die nächste Iteration kommt, weil diese unheimlich wichtig

00:11:03: ist und wie sieht denn unsere nächste Iteration aus? Denn wir wollen während eine Iteration

00:11:10: umgesetzt wird ja weiter planen. Wir wollen die Erkenntnisse einfließen lassen. Wir wollen dann

00:11:15: eben sagen, wie sieht jetzt wirklich unsere nächste und vielleicht sogar die übernächste Iteration mit

00:11:21: den neuen Erkenntnissen aus? Und das finde ich ist total valide und schafft auch super viel Wert.

00:11:26: Mein nächster großer Punkt ist das Thema Information und Informationen verteilen. Auch

00:11:32: das kann ich sagen, stelle ich immer wieder fest. Es ist eine ganz große Kunst, allen Beteiligten

00:11:39: die gleichen, im Zweifelsfall sogar die relevanten Informationen permanent zur Verfügung zu stellen.

00:11:45: Die Informationen zu verbreiten, da ist eigentlich gar nicht schwer. Also wenn man jetzt an Tooling

00:11:52: guckt, wie kann man Informationen für alle zur Verfügung stellen? Überhaupt kein Ding. Gibt es

00:11:57: Confluence oder gibt es Jira Stories oder keine Ahnung. Ihr kennt tausend Tools, mit denen man

00:12:03: Informationen gut bereitstellen kann. Was ich feststelle, es ist unheimlich schwer,

00:12:07: allen die Informationen zur Verfügung zu stellen. Auch da ist Zeit ein großer Faktor. Auch da merke

00:12:14: ich, dass viele, also vor allem Kunden oder Stakeholder, sagen, schön, aber sich die

00:12:21: Informationen auch nicht durchlesen und dann Informationen verloren gehen. Oder sie selber,

00:12:26: wenn sie ihre Teile der Informationen dokumentieren, müssten das nicht tun. Und ja, da kann ich auch

00:12:33: nur sagen, das macht es unheimlich schwer, wenn man später feststellt, Moment mal, das ist ja

00:12:37: anders, als ich gedacht habe. Und wir dann feststellen, ja, aber die Information ist nie

00:12:43: bis zu uns gekommen. Ja, dann wird es halt schwer, neue Informationen auch einfließen zu lassen,

00:12:49: offensichtlicherweise. Also es ist unheimlich wichtig, alle Beteiligten permanent auch im

00:12:56: Bereich Informationen auf dem neuesten Stand zu halten. Dann habe ich noch einen ganz schönen

00:13:00: Punkt, das stelle ich nämlich auch immer wieder fest. Was machen wir mit Prioritäten? Also wir

00:13:05: haben so eine Planung und wir haben unsere Iterationen und dann kommt sehr oft die Komponente

00:13:10: von Priorität rein. Kunden denken, Priorität wäre eine wichtige Komponente, um zu steuern. Und sie

00:13:18: sagen dann, ja, das ist auch Prior 1 und das ist auch Prior 1. Und ich habe überhaupt kein Problem

00:13:23: damit, innerhalb einer Iteration noch eine Reihenfolge zu bauen. So interpretiere ich

00:13:28: nämlich Priorität. Ganz im Gegenteil, ich glaube, das macht total Sinn, dass man so ein Backlog oder

00:13:33: so ein Up Next auch innerhalb einer Iteration gut sortiert, zusätzlich zu technischen

00:13:39: Abhängigkeiten, die das Team berücksichtigt. Aber es wird halt schwer, wenn man sagt, okay,

00:13:44: und das hier ist auch jetzt noch zu erledigen und das ist auch jetzt noch zu erledigen. Denn auch

00:13:50: da, das ist ein bisschen wie der Punkt, den ich vorhin bei Planung hatte, offensichtlicherweise

00:13:54: wird das das Projekt nicht schneller machen. Ich kenne eben auch die großen Probleme, die Kunden

00:14:00: haben, wirklich Reihenfolge zu machen statt Priorität. Kunden sind sehr oft sehr gut da drin

00:14:07: zu sagen, das ist Prior 1 und das ist Prior 1 und das jetzt auch und das auch und das auch. Und wenn

00:14:12: ich dann frage, okay, innerhalb dieser Priorität 1, was ist denn da wohl das Wichtigste, kommt

00:14:18: eigentlich immer, also 99% der Fälle, ja alles. Deswegen ist es ja Prior 1. Und ich erlebe auch

00:14:24: immer wieder, dass immer etwas Prior 1 ist. Also während einem Dreivierteljahr, während der

00:14:31: Laufzeit eines Projekts ist immer etwas Prior 1 oder viele Dinge. Und auch da denke ich, ja,

00:14:36: das wird es nicht heilen und das wird es, wie gesagt, nicht schneller machen. Vielleicht nochmal

00:14:42: ganz kurz zurück zu der Iteration. Also wir haben eine Iteration und wir setzen eine Iteration um

00:14:49: und mir ist es dann immer wichtig, dass auch innerhalb der Iteration das Ziel, das ist ein

00:14:55: Unterziel von dem Gesamtprojektziel oder vielleicht sind es sogar mehrere, klar benannt ist. Denn nur

00:15:00: dann kann ich eben sagen, Moment mal, wir haben eine neue Erkenntnis, passt die denn noch zu dem

00:15:05: Gesamtziel oder gehört die zu einer anderen Iteration? Auch da, die Kunden tun sich unheimlich

00:15:11: schwer. Also zu einem Punkt kann ich sagen, ich versuche mit dem Kunden das zu erarbeiten,

00:15:16: ich versuche auch zu erklären, pass auf, das hat jetzt folgenden Vorteil, wenn du dir jetzt die

00:15:22: Zeit nimmst und dir darüber Gedanken machst, dann werden wir insgesamt da sicherlich besser sein in

00:15:27: dem, was wir liefern. Aber auch da stelle ich fest, Kunden tun sich einfach sehr schwer damit. Ja,

00:15:33: dann habe ich noch den Punkt Feedbackzyklen. Natürlich wollen wir Feedback und wir wollen

00:15:38: permanentes Feedback und wir haben viele Stufen des Feedbacks. Bei uns ist zum Beispiel so,

00:15:44: dass wir innerhalb einer Iteration auch fertige Elemente oder Teile der Iteration liefern, um dem

00:15:50: Kunden die Möglichkeit zu geben, möglichst früh Feedback zu geben. Wenn das nicht passiert oder

00:15:56: nicht die richtigen Leute Feedback geben, dann ist es auch sehr schwierig, zumindest sage ich mal.

00:16:02: Es ist ganz wichtig, dass die richtigen Leute möglichst zeitnah, möglichst schnell ein gutes

00:16:09: und qualifiziertes Feedback geben, damit wir dieses Feedback eben einfließen lassen. Es nützt

00:16:14: überhaupt nichts, wenn ich einen Monat später zu etwas, was ich vor einem Monat geliefert habe,

00:16:19: nochmal Feedback bekomme. Das hält den Laden auf. Natürlich lasse ich das einfließen, das Feedback,

00:16:25: das wäre ja, also Hanebüchen ist nicht einfließen zu lassen, aber es hält den Laden auf. Ja und

00:16:31: eigentlich war es das schon. Das sind für mich die ganz großen Fundamente, die ein Projekt erfolgreich

00:16:37: machen. Was euch vielleicht aufgefallen ist, ich habe überhaupt nicht über irgendwelche Methoden

00:16:42: gesprochen. Ich glaube ganz fest daran, dass irgendeine Methode, Scrum kann man, was auch

00:16:49: immer, komplett unwichtig ist. Also natürlich kann man eine Methode benutzen, also wir nutzen

00:16:55: kann man und man kann auch Scrum benutzen, aber es ist überhaupt nicht wichtig, früh in einem Projekt

00:17:01: über eine Umsetzungsmethode oder ein Framework zu sprechen. Vollkommen egal. Ihr könnt Methoden

00:17:09: benutzen, das ist gut, aber diskutiert nicht zu lange über irgendwelche Methoden. Viel wichtiger

00:17:15: und das ist mein abschließender Punkt, ist tatsächlich das agile Manifest und die zwölf

00:17:20: agilen Prinzipien. Da solltet ihr sicher drin sein. Das sind verallgemeinerte Leitplanken. Ich glaube,

00:17:28: die helfen vielmehr zur Orientierung, die helfen euch und die helfen meiner Meinung nach auch den

00:17:34: Kunden und den Stakeholdern viel viel mehr als, ja sage ich mal, wir machen Scrum, also gibt es eine

00:17:41: Iteration, also haben wir einen Review-Termin und damit wird das Projekt auch super werden. Die

00:17:47: Denke ist einfach an der Stelle falsch. Gut, das soll es gewesen sein. Wie gesagt, kleiner Überblick

00:17:54: darüber, wie ich das so sehe. Was ist wohl ein ideales Projekt und immer wenn Dinge fehlen, ja,

00:17:59: versuche ich zumindest zu gucken, wie kriege ich diese Dinge noch geheilt. Für mich ist es wie

00:18:06: immer interessant, wie seht ihr das? Was habt ihr hier für Feedback? Habe ich Quatsch erzielt? Eurer

00:18:11: Meinung nach sagt ihr, Mensch, sehe ich genauso. Gebt mir dazu gerne Feedback, schreibt mir gerne,

00:18:16: ihr findet alle Kanäle, wie ihr mich erreichen könnt, ja natürlich auch in den Shownotes. Und

00:18:22: ich habe noch eine ganz große Bitte, wenn dir das hier gefallen hat, vielleicht hat es dir sogar

00:18:25: geholfen, dann teile das, teile es gerne mit deinen Kollegen und Kolleginnen, teile es auf

00:18:31: Social Media. Je mehr Leute über den Podcast erfahren, desto größer wird, ja, die Diskussion

00:18:37: zu Agilem Arbeiten und ich glaube, das hilft uns einfach allen. Vielen, vielen Dank dafür. Habt

00:18:44: noch eine ganz tolle Woche und bis zur nächsten Folge bei No Bullshit Agile.