#002 | Agile Bullshit

00:00:00: wieso denn AG agil fühlt sich immer so an wie Wolke wie diffus was machen den Zeh Leute im Meeting was macht hier do fucking Job dieses Meeting hat jetzt 4000 € gekostet war das wirklich wert die schätzen mit Tieren oder mit T-Shirt oder mit T-Shirt sizes ja der Schlüssel von agen arbeiten ist man hat ein Inkrement geschaffen kann Feedback einholen und dann weiter etieren K geht zu giono zurück Toyota Zeiten die Japaner sind da sehr gut darin es muss nicht zi Stunden refin werden es muss nicht zi Stunden geplant werden wenn

00:00:38: alles klar ist zack fertig bedarf es diese ganzen Rollen Product Owner Scrum Master wann bekomme ich mein Ergebnis AG [Musik] Bullshit herzlich willkommen zur zweiten Folge hier bei Simon und Heining ich bin kurz Simon ich bin Christian Heining und heute geht's um Bullshit chrtian ich denk wir haben da genug Stories und ich bezweifel ist dass wir das in eine Folge packen können wahrscheinlich muss man das Splitten und irgendwann später noch mal so eine Folge drüber machen was wir alles in agilen Kontext erlebt haben

00:01:16: aber wir haben auch ein claim und zwar wann seid ihr endlich fertig und zwar ist es genau die Frage die ein agiles Team hört vom CEO vom Stakeholder diese ganze girira Schlacht back etc einfach nicht versteht und sagt ich brauche ein Datum wann kann ich das Produkt verkaufen oder das Feature zu meinem Kunden bringen oder und so weiter und so weiter das heißt die alte Welt denkt immer noch oder nicht die alte Welt die Welt denkt ich muss was liefern und wann kann ich liefern und agil fühlt sich immer so an wie Wolke wie diffus und da

00:01:51: wollen wir und da wollen wir da wollen wir den wollen wir aus dem Grund gehen wieso wieso eigentlich agil also ich meine doch früher ich mache mal eine ketzerische Aussage Excel ist einfach Magic redest du gerade von Excel Projekt nur vom Original gut kanchuldigung man kann do das alles schön in so eine Liste packen ja schön nacheinander abarbeiten erledigt also was ist also woher kommt das denn über was ist denn das eigentlich also wieso denn AG vielleicht um deine Frage zu beantworten das mit Excel und G und

00:02:25: Projektplanung das funktioniert das funktioniert wan nicht ich würde das ganz einfach sagen wenn die Randbedingungen die die das Problem das zu lösen ist wenn das relativ klar ist ein klaren klaren scope hat klaren Ablauf ein klares Ziel hat dann funktioniert de excelmethode hervorragend du hast jetzt klares Ziel gesagt schwierig klares es ist meistens Ziel ist meistens immer ganz klar aber ich weiß ich glaub du meinst wenn die Schritte die zu tun sind klar sind ja wenn ich den den Elefanten zerschneiden

00:03:01: kann in drei Häppchen Häppchen 1 2 D ich kann die stückweise abarbeiten und komme dann zu meinem Ziel aber leider ist es oft so der Elefant den kann ich nicht einfach Zerschneiden der ist sehr groß der ist ich weiß gar nicht wie groß er vielleicht ist und da hilft agil sehr sehr komplexe nebulöse Probleme klein zchneiden und iterativ anzugehen kann man auch einfache Ziele Probleme mit agilen Ansatz oder sollte man kann man auf jeden Fall ganz klar ganz klares Ja und vielleicht ich denke bevor wir

00:03:37: jetzt zu tief da reinsteigen würde ich erstmal versuchen zu definieren was ist eigentlich agil oder was was was macht denn eigentlich ein ein ein agiles Projekt Produkt agile Arbeit überhaupt aus und wir sollten mal ein bisschen in die in die Geschichte zurückblicken was meinst Du ja können wir gerne machen ich ma mal auch wieder etwas was man also ement gerade Unternehmen die weniger agil sind wenn du mit so agilen Sätzen anfängst dann kommt immer sowas wie die sitzen ganzen Tag in Meetings z.B ja arbeitet ihr eigentlich oder was

00:04:12: macht die eigentlich und solche Sachen aber da kommen wir glaube ich später auch noch dazu ja klar was kann ich dazu sagen wir werden am Ende darf ich nicht vergessen Buch empfehlen und werde da paar noch dazu sagen ich glaube der einfachste Einstieg W do wenn man zu sag wenn man sagen was sind denn so die bekannten agilen Methoden fange mal so an also ich denke angefangen hat es mit mit Jeff Sutherland heiß du wirklich so m Jeff Sutherland genau also angefangen hat es mit Jeff Sutherland und der so der

00:04:46: Begründer der der agilen agilen Werte agilen Arbeit war und daraus abgeleitet haben sich dann konkrete Methoden Frameworks etabliert wie beispielweise Scrum wie beispielsweise Kanban äh die letztendlich die an die Arbeitsweise in Teams beschreiben gewisse Vorgänge gewisse Artefakte definieren wie ein Team oder wie ein eine Konstellation aus aus Individuen zu arbeiten hat und darauf aufbauen gab es ähm weitere Konzepte die jemand erfunden hat wo ich tatsächlich persönlich etwas kritisch den ganzen gegenüber stehe wo

00:05:25: man sich gedacht hat ja wie passiert denn das wie kann ich dann agil skalieren ich habe ein Team ich habe zwei Teams ich habe drei Teams ich hab sehr komplexe Produkte Systeme dann sowas wie wie wie safe less Nexus Scrum wie sie alle heißen also sehr sehr viele Begriffe aber ich denke so die Grundlagen Scrum Kanban m das waren so die allerersten Prinzipien die entwickelt wurden und nachdem heute ser willele arbeiten aber trotzdem es immer noch nicht angekommen ist was das wirklich bedeutet und mit sehr sehr viel

00:05:57: Fragestellung mit denen auch Manager heute immer noch zu kämpfen haben kanan geht zu taiono zurück Toyota Zeiten wer Toyota eben dieses kanan Arbeitsmodell erfunden und ich ich ma schon mal schon mal ein Spoiler und zwar habe ich jetzt Spoiler gesagt ja ja ma mal Spoiler und zwar viele Unternehmen viele Produktionsstätte arbeiten schon agil die nenn nicht so einopf läuft nach ein ganz klassischen kanprinzip ab ganz ganz wie Buche steht ja gesagt Tai ona könnt ihr gerne mal in Bücher nachschauen komm

00:06:38: von Toyota damals auch die Japaner sind da sehr gut darin es gibt zahlreiche Beispiele in verschiedensten Büchern darüber und das ist eine agile Arbeitsweise und zwar dass man genau weiß oder möglichst gut weiß was die nächsten Schritte sind die wir tun wollen um ein Mehrwert zu stiften ja also kam auf J und Jeff sland wie gesagt da komme ich am Ende noch dazu da geht's auch darum zu erfahren nicht nur okay die IT möchte modern arbeiten was ist das eigentlich sondern woher kommt das eigentlich ja und auch da wieder ein

00:07:11: Spoiler kommt eigentlich alles da wo wir es nicht hören wollen und zwar vom Militär tatsächlich sehr sehr viele Methoden Taktik Strategie kommt aus der aus diesem militärischen Umfeld ja wie gesagt später mal dazu mal eine kleine Empfehlung dann aber jetzt trotzdem wieder zurück zur Frage warum warum warum ist ist das warum funktioniert das oft nicht oder warum gibt es oft den den den Konflikt zwischen einem g Management und einem agil arbeitenden Team ich zitiere mal Management man könnte also

00:07:44: das ist für den Moment in Ordnung man sagt na ja also die machen nicht wieso machen die eigentlich nicht hat so bisschen Generationskonflikt vielleicht auch schon ein bisschen ja weil man nicht versteht was algiles arbeiten jetzt bedeutet also was ist das was ist denn jetzt die schätzen mit Tieren oder mit T-Shirt oder mit T-Shirt sizes ja oder nehmen mal Fachbegriff Fibonacci zahlen ja wieso hä me jemand der sich mit Fibonacci zahlen nur bisschen beschäftigt hat dann wird das logisch ne das entfernte ist komplexer zu schätzen

00:08:15: als das was nah ist also ne einfach genau komm sehr guter Punkt du sprichst die ein ein ein ein Konfliktthema an was glaube ich relativ oft bei Management zu Problemen führt das Thema zeitabschätzung also als Manager möchtest du immer wissen ich habe Geld investiert und was möchte ich dafür haben ich möchte irgendein Output dafür haben und das Output soll idealerweise plus mehr bringen als ich investiert habe ansonsten kann ich gleich zur Bank gehen und 1% Zinsen ja wann bekomme ich mein Ergebnis und

00:08:44: andersum gesagt machen wir mal andersum und zwar Deadline ihr müsst fertig werden B Ende des Monats genau ihr hab das das dieses Budget zur Verfügung und müsst das und das Liefern wo ist der Konflikt also ich erlebe ja folgendes ich habe Sel Management erlebt die so ich sag mal strickt waren was eben Kosten angeht die drei Punkte waren kosten Zeit Qualität Qualität also selten erlebt also ich habe meistens sehr humane Familienunternehmen Geschäftsführer private equities die wollen eent die wollen die Lösung ja ich

00:09:19: habe aber sehr komplizierte Entwickler erlebt ja ich war selberentwickler weil man irgendwo mittendrin den Faden verloren hat zu diesem minimum value die man liefern muss und zwar in every piece also letztlich Iteration alle zwei Wochen genau da sprichst einen der wichtigen Punkte von agiler Arbeit an iterativ Mehrwert zu generieren also das heißt im Vergleich zu einem zu einem Projekt was ein Start hat und ein Ende hat dazwischen hat man durchaus auch Zwischenschritte aber man liefert erst am Ende ab und eigentlich der Schlüssel

00:09:56: von agilen arbeiten ist schnell iterativ kleine Stücke auszuliefern kleine Inkremente auszuliefern wie es wie es auch wie es auch im Fachbegriff heißt die einen Mehrwert schaffen das ist eigentlich der der der Schlüssel und das und das Gute an diesen an diesen Inkrementen ist man hat ein Inkrement geschaffen kann Feedback einholen und dann weiter etagieren ja aber ich sag mal andersum wieso können wir nicht einfach sagen komm Leute da wollen wir hin das müsst ihr hinbekommen ich brauche eine Lösung

00:10:28: ich will eine Plattform aufbauen oder oder ich möchte eine Software Lösung entwickelt haben von meiner Entwicklungsabteilung ihr habt seit d Monate in drei Monaten ist Messe bis DAH müsst ihr fertig werden wönde ich doch tun ja kommen wieder zum Punkt zurück am Anfang wei unter umst zu komplex ist okay und und wieder mein das Beispiel des dieses Dreiecks du hast immer drei Faktoren Qualität Zeit und Budget du kannst nicht alle drei gleichzeitig vorgeben geht einfach nicht funktioniert nicht du kannst durchaus

00:11:03: sagen okay in dre Monaten möchte ich mein Ergebnis auf der Messe haben dann wird es aber irgendwas hingebasteltes was vielleicht gerade an der Messe funktioniert aber sobald man es anstupst fällt das ganze Kartenhaus in sich zusammen also man kann nicht alle diese drei Dimensionen gleichzeitig einschränken perfektes Beispiel hab ich gleich ein tolle Story ja Real Life also jetzt muss ich aufpassen was ich sag auch wieder ein tolles Projekt und ich könnte jetzt sagen ich kann nichts dafür aber ich war der verantwortliche ich

00:11:30: kann wahrschein bestimmt was dafür also da hieß es so ne so in zwei Monaten da muss jetzt ein Release hin wir mussten auf einer sehr fremden Plattform eine komplett eigene Lösung basteln weil man sollte sozusagen solutions also das heißt nichts anders wie der Kunde kennt seine Oberfläche seine Plattform das sind Applikationen und da klickt er nur an und sagt installieren so wie im App Store ne und wir haben ja eine senderloh Lösung gehabt und D man das reinbringen müssen es war super also es war der Hammer wir

00:11:56: haben auf so eine riesen Messe das vorstellen soll auf eine riesen Bühne wir haben nur noch Oberfläche glatt gezogen wie so eine Bühne wie so eine Theaterbühne ne kennst du das Theaterbühne so wo man nur die vordere Seite sieht und hinten ist eigentlich nur nur Holz ja nichts also quasi klappt das um wir haben das so hingerotzt wie es nur irgendwie geht und danach hat aber auch niemand danach gefragt komischerweise jetzt also ne aber und das ist so ein Punkt wenn man auch mal auf die Entwickler nicht hört wenn man

00:12:22: sagt ich schaff man das nicht was wäre was wäre dein learning gewesen wie hätte man das anders machen können na ja in dem Fall war es so kommen vielleicht zweiten größeren Punkt und zwar sind wir bei Thema Prinzipien Werte ja also wir ein Wert ist ja also ich sag mal die klassischen agilwerder sind Mut Offenheit Respekt Kommunikation commitment Feedback Fokus so sehr gut ausfig gelernt V vor 7 Jahren schon deswegen bleibt im Kopf aber was ich sagen will ist das geht los mit commitment Feedback Fokus und solche

00:12:53: Sachen ja aber es trifft nicht nur auf die Entwickler oder auf die auf die Teams sondern du brauchst auch ein commitment von der Geschäftsführung von Stakeholder ja du brauchst das also jemand wo dir Rückendeckung gibt und auch mal sagt okay ihr sagt mir diese 12 Features bekommt ihr nicht hin wen mir ger noch fällt mir gerade noch eine noch ein Projekt ein wo man sagen muss hey wir schaffen damals war es du 12 12 Features wollt die Geschäftsführung haben wir haben aber gesagt wir schaffen maximal acht mit abendsarbeiten und

00:13:22: Pizza kosten los ne so wirklich ehrlichag also Kat mal irwi aber Max a und wir würden eher sechs sagen weil wahrscheinlich da geht noch einiges kaputt währendessen wie man das machen ne die wollten nicht hören die wollten nicht hören also um die Entwickler mal zu verteidigen die wollten nicht hören da war mal da war aussweise mal war ich da in einem Team die wirklich sehr gut miteinander gearbeitet haben unterschiedliche Typen aber gute Truppe willst du damit sagen es ist immer noch eine diskrebanz im agilen Verständnis

00:13:52: zwischen Management und wenn du ein Team hast also GT Beispiel du hastag Team von dem du gesprochen hast du hast ein Management was glaubt agil zu verstehen aber dann doch in in Drucksituationen wieder zurückfällt in alte Muster und denkt ja Bud abliefern Zeitpunkt ich würde nicht sagen das was du aufgezählt hast würde ich sagen ist quasi unser unser unser borders W mus so schön da also die wir sind auf eine Wiese das sind die R Rahmenbedingungen okay das das bleibt was oldschol ist ist dieses das muss jetzt bis morgen fertig werden

00:14:26: dieses Unverständnis von hey das sind keine faulen Leute vielleicht sind sie das auch sondern das sind wirklich das ist wirklich kompliziert ich sage immer wenn die gut werden würden die programmieren können ne ich übertreibe das immer nach dem Mut weil das ist eine komplexes Verständnis an programmieren ist was komplett was anderes ne so und dann weil wir das nicht verstehen können kleiner Seitenhieb mal Richtung die aktuelle Politik aber wenn wir es nicht verstehen suchen wir einfache Lösungen

00:14:52: es muss einfach sein einfach ist so zu sagen es hat doch acht Leute wieso bekommt ihr das nicht hin ich habe doch vor halben Jahr schon zurch gesagt ich will das bis dein haben was S das schwer erklär es dir mal dass du eine Datenbank Update brauchst weil irgendein hiopai mongob eingesetzt hat der aber gekündigt und sonst kann das keiner jetzt muss man umstellen auf MSSQL du du sprichst aber auch ein du hast gerade gesagt ich möchte bis in X Monaten das das das und das haben ich sehe das tatsächlich aus

00:15:20: der natürlich ein ein Team ein Scrum Team muss Leistung bringen muss z gewissen Punkt Leistung bringen ist ganz klar ansonsten ansonsten äh sind sie fehlernplatze aber was man was ich aus aus meiner Sicht immer auch als als großen Punkt od großen Fehler sehe in agilen Teams ist äh die Zusammenarbeit mit stacon oder die aber richtige Erwartungshaltung also was was du es gerade gesagt hast und das kann ich kann ich voll bestätigen Stakeholder Geschäftsführer Abteilungsleiter haben gewisse Wünsche Erwartungen und die

00:15:51: müssen umgesetzt werden und eigentlich das das der Kern von einer von einer agilen Arbeit ist ja eben ähm in die ja in die in die in die product Discovery zu gehen in die den Kunden zu verstehen erstmal das Problem auch zu erarbeiten und iterativ zu lösen also weniger hinzugehen von topd mehr in ownership in das Team zu geben also es gibt ja auch in den diese klassischen Rollen Product Owner und das Team etc also das heißt dem Team wirklich ownership zu geben und oft ist es so dass die ownership gar nicht da ist s

00:16:25: das Team muss einen gewissen Plan von wo auch immer der kommt ausführen exekutieren und dazu brauchst du keine keine dann bist du ganz klar wieder in einer normalen ganz klassischen wasserfallentwicklung also ich wollteamit sagen dass Teams oft gar nicht befähigt sind gar nicht diese ownership haben agil zu arbeiten hatte ich einmal mal ein ein Positiv Paradebeispiel mal ich war in einem Projekt da war ich damals no Entwickler lange her einmal war ich in einem Unternehmen das habe ich da noch nie

00:16:58: woanders erlebt ich glaube weiß ich nicht ob man das ob ich das je wieder erleben werde und zwar da hatte der Product Owner wirklich das Sagen über das Produkt wie war aber in einem großen Software also ein ein ein riesen Produkt ein Teil davon war unser Team wir haben für iOS und Android zuständig ich war ein der seniorentwickler und Product Owner war wasch echt wieesen Buche steht ich weiß wie wir kickof hatten mit der Geschäftsführung also Geschäftsführung ist sech Level drüber und die haben uns

00:17:28: quasi angeb dass wir das machen ein Feature umsetzen aber pass auf Merkmale die wichtig sind zu erwähnen der Product Owner hatte direkten Kontakt zu Kunden der produkter wusste was auf dem Markt abgeht und der produkter wusste was die Kunden wollen und was Markt hergibt aber die Geschäftsführung wollte eine Idee umgesetzt haben für die Frau von der Geschäftsführung so mach das doch bitte ja das gab's also auch in diesen großen Unternehmen gibt's das auch aber unser Po war wirklich waschecht Holländer

00:17:59: übrigens gewesen er hat gesagt nee das will der Kunde das machen wir jetzt und das dauert jetzt so lang weil wir machen das ja fürs Unternehmen und nicht hier für irgendwelche Sonderwünsche da hast du wirklich ein tolles Team tolles techen tollen product lass wir die stor kurz zu endezen das ist zu lustig ja und dann könen wir fachlich weitermachen dann die Geschäfts ich WD es nie vergessen dann haben gesagt ja aber hey können wir nicht ir können das nicht irgendwie machen was braucht man denn dann kam der

00:18:23: Teamleiter dieser unser Teamleiter dazu ja was ist den los und so ja da gibt's ein Feature und meine Frau würde gern das und das gerne der App sehen und ob man das nicht einbauen können ist ja nicht so schwierig ne kennst wenn man die Komplexität nicht kennt und dann hat er gesagt ja nee wir sind alle voll belastet und so und ich meine wiren von der Geschäftsführung die das Sagen haben der gesch Geld die das Geld haben okay ja braucht ihr mehr Entwickler hat der halt flossg der teamleider gesagt ja wir

00:18:49: buchen Hal mehr dann ja kein Problem okay stell zwei ein und dann war mal Buff so oh oh okay ja ja und dann kam paar Entwickler dazu um das mal abzurund haben die gesagt ja aber wir könnten viel besser arbeiten wenn wir jetzt endlich mal zwei Bildschirme hätten die 4k können und diese Story se einfach richtig geil und zwar hat er dann gesagt okay dann könnt ihr dann besser arbeiten schneller arbeiten dann haben die natürlich ja gesagt was großer Fehler ist was hat das mit Bildschirm zu tun ne okay okay alles kein Problem hey ihr

00:19:18: kriegt jetzt alle 4k Bildschirme die alten Bildschirme die nimmt ihr und die Verkauf die Buchhaltung als neue Bildschirme drei stopwerker weit unten haben die dann diese neuen Bildschirme den der Buchhaltung dann als neue Bildschirme verkauft he ihr kriegt jetzt Full HD Bildschirme so ne also alles wurde ermöglicht aber dennoch war unser Po damals sehr standhaft hat durchgezogen aber ich habe es nie wieder so erlebt nie wieder und meistens genau das Gegenteil erlebt ich glaube dass ich glaube auch dass viele Product Owner

00:19:47: entweder fachlich wirklich schwach sind auch gar nicht befähigt sind sowas zu sagen musst du da brauchst du wirklich Eier in der Hose wenn du sowas sagen wenn du sowas sagst und PR auch hast ein sehr guten Punkt angesprochen auch Product Owner die müssen auch wissen was Sache ist das heißt die haben müssen Kundenkontakt haben die müssen den Kunden verstehen vielleicht gemeinsam auch mit eux Personen und dann können Sie genau sagen das braucht der Kunde aktuell das ist der größte Schmerz das ist jetzt das

00:20:16: wichtigste was ich entwickeln muss wenn dann irgendjemand kommt wer auch immer das ist kann man auch sagen Nein und noch ein ein Schritt kann man oben drauf setzen was ich glaube dass das eigentlich die besten produt product Teams sind wenn sie ihre argum auch noch mit metri KPIs untermauen können K ich sagen ja ich habe das Gefühl der Kunde sondern ich habe hier diese Befragung gemacht 27 Kunden befragt die sagen das und deswegen machen wir das auch nicht ja aber Butter bei die Fische die produ

00:20:42: die ich jetzt kenne die du wahrscheinlich auch kennst das sind ja eigentlich so verkabberte exellisten Betreuer oder ich schlag mir doch gir auf dann zeig mir backlock so was machst du ja das S User Story hey du bist Product Owner ich s mal ein durchschnittlicher er ist jemand der backlock verwaltet ganz genau SC Zertifizierung ganz genau der hat mal hier 150 € ausgegeben und hat sich zertifizieren lassen und die guten Product Owner sind beim Kunden kenen ihre Metriken wollen zum Kunden wollenum K anders wollen zum Ken die

00:21:16: sagen hey wie komme ich an die ran wo kann ich die mal besuchen kann ich mal mit zur Messe kann ich mal das kann ich mal dies du musst es ja wollen das ist ja beim Projektmanager wieder was anderes ne man V verwechselt das immer wieder ja ich hatte mal ein guten Mentor der hat gesagt du wenn du Product Manager sein möchtest geh zu 20 Kunden vorher nehme ich dich nicht ernst sehr gut wer das auch war schöne Grüße Grüße gehen raus ja sehr gut sehr gut ja ja haben wir den Product Owner haben wir jetzt

00:21:46: schon genügend gequält ja ja also mein was also auf gar keinen Fall soll wir den scrwmas vergessen ja genau den dürfen auf garentsldig dass ich unche ich noch noch noch ein wenn wir schon bei den Rollen sind ja so dass der der die die alte in Anführungszeichen alte Rolle im im product ownership ist ja der Produktmanager mhm was ich oft auch erlebt habe ist wenn Teams grer wenn Produkte komplexer geworden sind dass dass auch neue Rollen in so ein Team integriert wurden wie z.B es gab einen Scrum einen einen Product Owner der den

00:22:21: backlock verwaltet hat und dann gab es einen Product Manager der dann strategisch gearbeitet hat der dann mit mit toalll nicht strategisch zu denken also warum braucht man diese beiden Rollen also ich finde das ist manchmal werden Organisationen aufgeblasen warum auch immer ob der jetzt Product Owner oder Product Manager heißt für mich ist gleiche er muss in der Lage sein den Kunden zu verstehen er muss in der Lage sein die richtigen Metriken zu verstehen und das gemeinsam mit dem Team in einen in einen backlock

00:22:55: gießen und bedarf es diese ganzen Rollen product owners Scrum Master habe ich noch irwas vergessen also ich habe ich habe sehr stark immer die die die Product Manager Rolle auf ich denke ich denke man braucht definitiv das Kundenverständnis das muss irgendwo in Team Team sein ich meine Scrum schreibt auch irgendwie so eine schreibt do diese Rolle vor zwischen den Entwicklern da zu unterscheiden zwischen den front and Backend kommt aufs Produkt an und ich meine die dritte Rolle die es jetzt noch

00:23:26: gibt in dem ganzen agilen Kontext ist ja das CR Master und da gibt's auch immerwo gelesen das crumm macht dann sein Job richtig wenn wenn ja nicht mehr wenn überflüssig ist hat alles richtig gemacht ja aber ich muss sagen jetzt das trifft auch für trifft auch auf Management die besten Manager sind die also da ziti jetzt mal horor Business Dezember Ausgabe November Ausgabe das finde ich super ein me Lieblingssprüche du musst da sein wenn die Kontrolle verloren wird oder wenn man dich braucht dass wieder neu

00:24:00: justierst du musst aus dem Weg gehen wenn die Leute funktionieren oder funktionieren klingt jetzt wieder so oldschol aber wenn die Leute wissen was sie tun müssen musst du aus dem Weg gehen dann los ja s Mikro Micromanagement also das E nicht tun ja ja also absolut absolut du musst aus dem Weg gehen wenn die funktionieren weil wir haben ja immer die Ansicht okay wenn jemand nichts tut dann tut er ja nichts nein der tut sein Job sehr gut scheinbar also ich mache mal ein Sternchen dran ne also ich habe auch oft wie gesagt ich

00:24:28: komme ja direk rein wenn sowas schief läuft und dann sind die Leute wirklich die machen wirklich nichts ja die machen wirklich nichts und dann komme ich meistens und bau es um also aber gute Manager die ihren Job sehr gut machen erkennst du sofort die müssen nicht immer dabei sein ich sag das immer in meinem Meeting sage ich das immer müsste mich dabei haben muss ich das jetzt muss ich da eine Stunde Meeting sitzen nee okay tschüs bin raus alles richtig gemacht oder auch solche Sachen wie also wir schweifen jetzt ab aber auch da mal

00:24:55: gesagt so ich erzäh mal eine Story dass wir uns mal das mal kurz merken ich bin mal im Meeting reingegangen und dann haben mich die Leute nicht mehr gegrüßt am nächsten Tag weil ich gesagt was macht ihr hier was machen den Zeh Leute im Meeting was macht hier kann do niemals sein dass Zeh Leute mitentscheiden müssen also wie kleinteilig haben wir das denn jetzt aufgeteilt so ne die Message war zwei haben gesprochen acht haben zugehört und von den acht haben was weiß ich keine Ahnung ob die überhaupt zugehört haben

00:25:20: ich hatte auch ein Schlüsselerlebnis und einer mein ersten ersten Manager Grüße gehen raus der hat einmal gesagt so ze Leute im imum hab er hat jetzt irgendeine handypp und da gesagt jetzt gibt dir mal ein wie viele Leute sitzen hier senior business vice president irgendwas Stundensatz und so und so und D gesagt so Start so eine Stunde gequatscht und D gesagt so dieses Meeting hat jetzt 4000 € gekostet war es das wirklich wert alle haben gesagt nee und das hat mir ein Mal gezeigt ich war junger junger junger Berufsanfänger hab

00:25:52: wir gezeigt man muss sich fokussieren man muss es muss nicht immer jeder dabei sein also ich machst mal hart ich sag do your fucking Job ja ja knallhart also die sitzen da drin und denkst was ist denn los mit dir raus also habe ich ja irgendwann habe ich mal gemacht ja also das soll jetzt gar nicht so hart klingen aber man muss ein mal sagen hör zu du bist da ich wiederhole mich du bist da und ich bin da weil wir für dieses Unternehmen in dem was wir tun Mehrwert stiften sollten wir es nicht mehr tun

00:26:20: müssen wir uns in Frage stellen ja apropos Mehrwert zurück zum scramteam ja ja was ist denn eigentlich jetzt mit also z.B zu den ich habe dich gefragt nach den Rollen ich finde Product Owner wenn ein Product unit piece of product da ist wenn größere Produkte sind ja dann sollte immer ein Product piece auch ein Product Owner haben wenn es Sinn macht man muss es aber immer wieder mal neu justieren und der scwmas finde ich kann auch mehrere Teams betreuen oder unterstützen wenn die Teams eigenverantwortlich gut arbeiten wenn er

00:26:54: seine Arbeit gut macht ich bin der Meinung dass ein scrwmas pro Team man sich wirklich leisten muss und ich weiß nicht ob das wirklich notwendig ist aber vielleicht bin ich auch zu weit weg ich weiß es nicht ja weil wir haben immer damals gesagt Scrum Master ist wie wie Mutti im Team ja klärt alles schaut dass die Meetings laufen dass keiner den anderen beißt und kratzt ja bisschen guckt und managed und vermittelt das habe ich aber nur einmal erlebt in den letzten 10 Jahren letzten 12 Jahren habe

00:27:21: ich no einmal erlebt dass wirklich jemand das so gemacht hat und ich habe es wirklich gefeiert fand das toll weil ich meine das man halt erwachsen Jungs sage ich jetzt mal war das in dem Fall und das wurde gut gemanaged aber ich sehe da keinen großen Bedarf man verbrennt da Geld also wenn wir für jede Kleinigkeit jetzt Personal brauchen dann dann muss man das alles mal in Frage sehe ich dass ich genauso ich finde auch gute Scrum Master sind sehr sehr selten ich habe tatsich auch zu meinen letzten

00:27:48: Jahren eigentlich wirklich nur einen Scrum Master gesehen der sein Job wirklich gut macht der hätte auch zwei Teams betreuen können und mhm wie du sagst der scmas wird oft gesehen so als der Kümmerer im Team der bisschen die meetingsmer geht das ist viel zu wenig es reicht nicht bisschen Miro Tickets rumzuschieben und bisschen die Leute bei guter Laune zu halten das reicht nicht er muss die Team die das Team coachen er muss die er muss er muss dafür sorgen natürlich dass der Prozess läuft aber aber vor allem auch die

00:28:21: Mitarbeiter befähigen oder die die Entwickler befähigen eigenverantwortlich zu arbeiten dass man letztlich dass er dass er nicht mehr notwendig ist und dazu gehört dazu ja auf den Mitarbeiter einzugehen sie sie genau zu verstehen die Probleme zu verstehen im Team auch die letztich die klassischen impediments aus dem weg zu schieben und das habe ich auch erst erst tatsächlich einmal gesehen in einem Scrum Master was ist den mit Werte weil also agile wir sind jetzt in verschiedene teamen eingetautt wir hab

00:28:50: mal Scrum Event kanan das sind so die großen zwei Brocken aus der agilenwelt die verwendet werden angewendet werden verschiedenen Kontext im Bereich IT Infrastruktur z. wird sehr oft kan verwendet weil das meistens klassischerweise der braucht keine Ahnung neue virtuelle Maschinen dann braucht i andere neuen Access Point das sind sehr ich sag mal klar messbare Tasks deswegen kann man von links nach rechts ne um die um die Belastung zu steuern aber was ist denn allgemein mit Werte weil agil agile Prinzipien agile

00:29:20: werte ich habe es jetzt gerade gefühlt auswendig ja schon vorgetragen wie wichtig sind die die weiß nicht auswendig die brauch wissen ich hab vor wie witig sind die was was ist denn das also weil wir reden ja wir reden ja ständig davon ich finde es auch okay weil das sind schau mal die Themen die auffallen z.B höre ich oft und verstehe es auch verstehe beide Seiten agile Teams sitzen ganzen Tag in Meetings Backlog refirement grooming Retro Retro geht ja teilweise ganzen Tag lang die sitzen ganzen Tag

00:29:53: zusammen kleben bunte Blätter an die Wand und vereinbaren dass sie jetzt nicht mehr kratzen und jetzt ja also um mal aus den Gedanken mal zu spielen ja also ich finde das schon gut ich finde ich weiß was für ein Hintergrund an Retro hat ich finde es auch gut wenn es gut gemacht wird wenn wir diese Leute haben worüber wir gerade reden wenn der outcome wirklich Verbesserung bringt ja und outcome nicht nur eine bunte Wand ist ne wie oft habe ich irgendwelche Posts an irgendwelchen Wänden gehabt und da ist nichts passiert

00:30:19: nichts hauptsache mal an die Wand geschrieben er mich so so einkaufsitze zu Hause wir schreiben mal an die Wand wenn es irgendjemand kauft ist gut wenn nicht hat's auch keiner vermisst so ne also werte ich muss ich wde also mein Eindruck wä Werte geht ja sch mal über alles es geht er mal um wert wenn wir Gil s also dass wir un respektieren dass wir gemeinsam ein Ziel verfolgen wollen ja dass wir wenn wir sagen wir beide schaffen das oder wenn wir sagen wir machen das dann machen wir es auch okay

00:30:48: dass wir uns abholen genauso wie vorin wir in einer unserer anderen Folgen mal gesagt haben dass wenn jemand sich bewirbt im auch dann rechtzeitig absagen z.B Respekt genau dast und das sind glaube ich Dinge dass wenn wir das hätten wenn wir da stärker drauf schauen würden würde der autumweise wie wir mit Teams die vielleicht nicht performen Geld verbrennen wäre ganz anders weil wenn Werte im Fokus stehen dann kannst du auch mal kann von mir 1000 Beispiele geben wo ich dann sag hör zu du respektierst mich nicht und so können

00:31:19: wir nicht arbeiten ich bin dein Chef solche Gespräche habe ich öfter gehabt sag ich mal so du respektierst mich und das ist so können wir nicht arbeiten wir beide ja also ich muss das das Le ich muss leider die Weitsicht vorlegen und du musst dir überlegen wie du in dieser Zone wo ich freigebe dich frei bewegen kannst und was du dafür tun kannst nicht wo du auf der Welt was tun kannst genau und du und du du sprichst es an die die Werte ist eigentlich das was agile Arbeit ausmacht und in der Praxis sieht

00:31:45: es leider oft aus agil bedeutet ich habe diese drei Rollen ich habe ein Sprint planning Sprint Review was auch aus meiner Sicht ganz ganz oft falsch gemacht wird können wir auch noch drüber sprochen sprechen was da schief sondern dass man eher sich auf diese Artefakte konzentriert man hat ein backlock das macht man ja aber ganz ganz viele dieser Werte werden eigentlich komplett missachtet bin bei dir okay aber komm mal auf die erste Frage wieder zurück ja also wann wär wir denn endlich fertig also wie kann den ein

00:32:18: agiles agile wie können denn Ziele die agil umgesetzt werden wie können die denn zu Erfolg führen W wer die den erfolgreich was muss man denn tun also was sind denn die rahmbedingungen für sowas also ein Punkt habe ich schon angesprochen man braucht einen das Team muss befähigt sein oder auch der producter muss befähigt sein Entscheidungen zu treffen dazu gehört ganz ganz klar dazu er muss Zeit haben oder auch die die die die Befähigung mit Kunden zu sprechen also wirklich das Problem zu erkunden sehr sehr oft

00:32:53: springt man meiner mein nach in in agilen Teams oder oder grundsätzlich sehr sehr schnell in die Lösung ich wie du vorhin gesagt hast der Chef hätte gern dieses Feature das Feature ist eigentlich schon die Lösung aber was ist denn eigentlich das Problem und das kann ich nur dann verstehen wenn ich den Kunden verstehem und das ist ein wichtiger Punkt das heißt Product Owner das Team muss befähigt sein äh mit dem Kunden zu sprechen ähm zu recherchieren zu lernen das ja auch eine eine der ein der Werte also

00:33:25: immer dazu zuulernen ähm das ist ein wichtiger wichtig Bestandteil und dann äh kann man nämlich auch eine richtige Lösung finden und diese Lösung dem Kunden präsentieren mhm Feedback einholen und das geht das ganze spielb von vorne los das ist dieses dieses kleinschneiden dieses kleinschneiden aber nicht auf kleinschneiden auf der lösungsebene wenn die Lösung bereits vorgeschrieben ist sondern das kleinschneiden in den Weg erstmal finden das Problem verstehen und dann den richtigen Weg dazu finden mir

00:34:01: ist noch ein Punkt eingefallen zum Thema wieso agil und wieso nicht wasserfallprinzip und so weiter und guter Punkt glaube ich was man auch im Hinterkopf haben sollte ist it Probleme sind komplexe Probleme weswegen solche Methoden wie agile Prinzipien agile Vorgehensweisen meistens in itpjekten umgesetzt werden so erster Punkt zweite Punkt ist auch weil weil wir haben wir reden no immer davon dass wir immer ein Stück Mehrwert liefern dem Kunden und was wir auch noch erwähnen sollten ist weil sich die

00:34:34: Anforderungen auch sich ändern können um die auf die Änderung zu reagieren in dem wasserfallprinzip bekommst Du vielleicht in halben Jahr eine Lösung die war von einem halben Jahr wichtig we jetzt halbes Jahr später hat sich die Welt verändert und wir brauchen das eigentlich gar nicht und es gibt so viele Dimensionen die sich ändern können das kann der Markt sein der Kunde es kann es können eigene Infrastruktur sein die sich geändert hat also es gibt unendlich viel Gründe was sich ändern kann absolut und ein ein wichtiger Punkt

00:35:01: wo dieser dieser Konflikt eigentlich zustande kommt zwischen Management und wann kriege ich eigentlich was wann kommt mein Feature ist das Teams zwar oder letl Scrum zwar releasen sollen Inkremente haben wir schon gesprochen äh diese Inkremente auch Mehrwerte liefern sollen das aber oft nicht der Fall ist aus zwei Gründen entweder ist das Inkrement kein Mehrwert dass der Mehrwert für wen auch immer also idealerweise für den Kunden oder eigentlich nur für den Kunden oder für den Stakeholder der das Produkt nutzt

00:35:32: oft sind das keine keine Mehrwerte wenn es Mehrwerte wären würde der Stakeholder oder auch ein Geschäftsführer oder ein businessleiter würde das Sehen W okay es geht voran ich habe ein Mehrwert und oft releasen Teams auch nicht schnell son ein Team das nicht alle zwei Wochen released allerspätesten vier Wochen das arbeitet einfach nicht agil ist der produ der einzige der da so viel drüber bescheid wissen musst oder würdest du sagen die Entwickler müssen da auch ein Interesse daran haben zu verstehen

00:36:05: ähm was sie da gerade umsetzen habe ich eine ganz klare Meinung natürlich gibt's gibt's ich beschreibbe das so in verschiedenen Kreisen natürlich hat ein ein Product Owner Product Manager aus der Produktsicht natürlich eine sehr starke produktbrille Kunden Kundenfokus aber seine Aufgabe ist es auch natürlich diese dieses Wissen ins Team zu bringen und genauso ist es auch Aufgabe der Entwickler it oder Software Knowhow dem Produktmanager beizubringen letich natürlich jede Produktentwicklung Software Entwicklung unterliegt

00:36:40: technischen Grenzen man kann nicht alles entwickeln man kann nicht man kann zwar zum wir können Zar mittlerweile zum Mond und zum Mars fliegen kostet auch sehr viel Geld aber jede technische Entwicklung hat seine Grenzen und das geht nur dann wenn Product Management und Entwickler auf Augenhöhe zusammenarbeiten wie gesagt natürlich hat jeder seine spezialgewiet aber ich sehe das als eine sehr sehr starke Synergie und ich würde sogar noch eine dritte Rolle reinbringen auch wenn die in Scrum nicht beschrieben ist es ist

00:37:07: Thema UX und zwar nicht gemeint mit bunte Bildchen malen sondern die User Experience den User verstehen das heißt die User Experience Experten bringen die Sicht ganz starke Sicht auf den Kunden hinein haben Methoden die keiner von diesen anderen beiden Gruppen kann von Befragungen Interviews 1000 Methoden und wenn diese drei Gruppen zusammenarbeiten auf Augenhöhe kann man gutes Produkt entwickeln ja was ist denn jetzt mit die Meetings eigentlich also wenn ich so überlegt haben wir vorhin schon mal kurz

00:37:37: angerissen backlock refinement Retro haben die also bei so einem zwei wochenzyklus also ein zwei Wochen Iteration das heißt ein Scrum Team liefert alle zwei Wochen einen Mehrwert so ich sag mal nach Buch ein Mehrwert und jetzt haben dir fast ein ganzer Tag geht ja auf so Retrospektive dann hast du Review man hast sogar Review 1 und 2 Entschuldigung du hast Review Review du hast planning 1 du hast planning 2 manchmal du hast daily wieso macht man eigentlich so viele Meetings geht das nicht mit weniger ja wollen die mal

00:38:15: arbeiten also muss mal punktingen ja also noch mal ne aber ich habe auch noch was dazu was ich was ich oft sehe ist diese diese irgendwo steht im Scrum Guide steht drin man braucht Review man braucht planning und so weiter und das wird dann oft wird dieses dieses wie soll ich sagen wird wird verheiligt man macht einfach dieses Meeting und auch wenn man es vielleicht gar nicht braucht und es gibt dieses Parkin schche Gesetz das besagt Arbeit Dent sich aus auf die Zeit die zu Verfügung steht das heißt wenn es Meeting da ist dann wird

00:38:51: halt einfach zwei Stunden diskutiert und gute Teams elich wie jetzt mit dem Meeting vorhin wenn schneller geht geht schneller also es muss nicht zi Stunden refined werden es muss nicht zwei Stunden geplant werden wenn alles klar ist zack fertig m wenn nicht dann dann wenn wenn es Unklarheiten gibt dann kann es auch mal so lange dauern ja ich denke da manchmal so an Meetings wie die Retros zurück ich habe teilweise selber welche organisiert für also bei manchen Team war es notwendig bei manchen anderen habe ich das nicht notwendig

00:39:22: gefunden da wieder sehr spielerisch sage ich jetzt mal versucht aus den Leuten was rauszukitzeln was jetzt gerade los ist lustigerweise auch wenn nichts los ist also keine Probleme da sind weil man eben aus dem Buch gelesen hat gesagt okay da muss jetzt ein Retro alle zwei Wochen ja F ich eigentlich auch spannend und da war ich wieder bei dem Punkt wo ich gesagt habe bloß um bunte Posts an die Wand zu kleben braucht jetzt kein Retro machen was gibt's für ein Problem wie können wir das sofort lösen ja ein

00:39:50: Problem können wir nicht lösen wenn ich jetzt bin kann ich jetzt nicht lösen ja müssen andere lösen aber alle anderen Probleme könnte ich lösen und übrigens nach de neuesten Versionen vom Scrum Guide ist die die das refinement kein Meeting mehr kein kein fixes Meeting sonder ein kontinuierliche Prozess der immer stattfindet also auch in einem daily kan refin werden oder spontan refin werden wen ich also es ist nicht mehr ein fixes meeting was irgendwie vier Stunden dauern muss steht übrigens irgendwo drin kann dauern

00:40:17: zwischen so und so viel Stunden und so viel Stunden was machen alle okay wir setzen es auf so und so viel Stunden an also wird wieder laut äh Buch das gemacht was irgendwo steht aber der der gesunde Menschenverstand der bleibt of auf der Strecke Pack wir mal dann Mehrwert rein wir haben jetzt Stories erzählt und unsere Sicht und aus der Erfahrung heraus ich pack mal noch eine dritte interessante Version rein die ich live miterleben durfte in im Unternehmen und zwar nennt sich das Spotify Engineering culture du weißt das ich

00:40:47: glaube ich habe damals auch mal mitgebracht ich glaub hab dir vielleicht auch schon erzählt bei dem die Arbeitsweise von Spotify sagen gepredigt wird spotif verarbeitet dahinter steckt Daniel Eck gerne mal google mal nachschauen sehr spannend da gibt's da schöne Videos dazu ganz tole Videos ja ja jetzt schon schon ze aber super spannend wie das wieder gearbeitet wird und ich finde sehr interessant also wen es interessiert und mehr über SC mehr wissen will als nur Scrum kanan und Derivate und und deren Versionen

00:41:20: dann würde ich empfehlen Spotify Engineering anzuschauen das ist so das was man sich als Unternehmer wünscht ja das Team eigentlich unternehmerisch denken also was würde denn passieren wenn diese Abteilung dieses Team ein Unternehmen wäre für dieses Produkt zuständig das ist super spannend viele werden Bankrott übrigens ja also weil diese katastrophale Umsetzung ist aber das würde dann jeden auch so ein bisschen mit dem was er tut enger zusammenschweißen ja genau und bringst wieder guten Punkt fürele Teams wären

00:41:52: Bankrott weil sie tatsächlich auch gar nicht ihre Metrik kennen das heißt sie liefern ein Mehrwert WT können das vielleicht auch gar nicht messen wie soll ich wie soll ich ein Mehrwert liefern wenn ich das gar nicht messen kann und das messen kann sein das muss nicht un unbedingt Geld sein muss nicht unbedingt sein ich krieg mehr subscribers ich krieg mehr mach mehr Verkauf das kann können auch andere Metriken sein wie wie wie wie z.B Klickzahlen oder wie wie Zeit verbind bringt man User auf der

00:42:17: Plattform kann man mal kann man mal nachschauen also auch die ganzen großen Unternehmen haben sehr interessante Metriken wie Airbnb oder wie YouTube Youtube z.B misst dein Erfolg in den Stunden hochgeladener Musik pro Zeiteinheit also sind sehr sehr interessante Metriken die leading sein können laging sein können aber die am Schluss zu den Erfolg messen und das sind eigentlich die guten Teams haben eine Metrik nach der Sie arbeiten ganz oft erlebt auch und wieder eine Folge Wert über über data Analytics mal zu reden und die

00:42:52: Analytics die gar nicht existieren ja wo es dann heißt so ja wir müssen auf die Zahlen auf Metrik gucken du kannst ervorrag Dashboards machen mit in Azure z.B ja aber jetzt kannst du auch super Dashboards machen wo du analysieren kannst was läuft wie was kannst es verschmelzt mitan und anderen Tools also in den wirklich WM wichtigen Projekt habe ich das nie gesehen ja ja wo man eigentlich sagt hey wir müssen noch wissen wie wir vorankommen um dann auch dem Management ehrlich in die Augen zu gucken und zu sagen hör zu das bringt

00:43:19: jetzt hier Gade nichts mehr die T den Leuten ein Gefallen irgendjemand bezahlt das ganze ja auch ja auch da alle Entwickler Product Owner und Leute die Teams arbeiten auch an mittleres Management Teammanagement Teamleiter sagt das euren Geldgebern Stakeholdern oderoder Shareholdern wie auch immer sagt es denen diesind heil froh über diese Info auch wenn es nicht schön ist ja ja die Message hätte man gern ich sag mal so ich habe zwei Erlebnisse gehabt also immer in eine Richtung einmal hassen s dich erstmal dann feiern Sie sich weil

00:43:50: die sagen okay gut der hat ja genug gehabt das zu sagen oder die die sagen die sind sofort froh und sagen hey okay gut was machen wir jetzt dann sagst du okay jetzt platziiehen neu machen neuestalten oder er nie wieder die Finger da reinlangen weil ihr habt da keine Expertise im Unternehmen um solche neuen Sachen zu probieren hatte ich auch schon da ging es um verschlüssung und so weiter ja die haben sich da Finger verbrannt ich habeag ihr müsst da raus also geht anders ran so war das dann auch genau ja ja aber

00:44:17: wie gesagt gute gute Teams kennen ihre Zahlen und und und es ist oft sehr sehr erleuchtend wenn man wenn man so Teams kommt die keine Metriken haben und dann erstmal versucht eine metik zu finden und dann sehr sehr er nüchtern feststellt man entwickelt Feature und Feature die Metrik ändert sich nicht ja live Beispiel P g mal wieder ein Beispiel dazu ich kann mal in einem Unternehmen rein da hieß es so hey da hat man einen Startup gegründet und die wollen jetzt ger vorankommen und müssen dafür einen großen Kundenkreis also so

00:44:46: eine Plattformstrategie ne dann bin ich reingekommen und habe dann auch den Geschäftsführer gesagt hey ich komme jetzt rein aber ich werde schon mal zwei Wochen mal nichts sagen mal alles anschauen anhören ich will mal wissen was machen die denn hier die wendee waren voll mit Persona und so weiter alles was bietet persona und Planung und was umsetzen und so weiter so Ziel Plattform bauen dann hab ichag der Daily nach zwei Wochen ich was macht eigentlich sorry WN so frag was macht den ihr ja aber wir machen noch das aber

00:45:14: was macht ihr denn gerade we was die Antwort war die haben die Webseite gebaut von dieser kleinen Unternehmen seid ihr wahnsinnig was war der Webseite ich DEP also ne bin auf hier so auf irgend so eine so eine wie heiß Customer Relationship Management Tool kostenlos dazu Template gekauft für ein Zehner 10 hab das über Nacht hingebastelt ich habe gesagt das ist jetzt die Webseite WordPress ja WordPress genauchuldigung das ist jetzt die Webseite und jetzt entwickeln wir Produkt okay was will denn der Kunde ne

00:45:49: und dann habe ich schon erfahren da gab es einen sehr affinen Technik begeisterten Architekt S der hat erstmal eine komplette Architektur gebaut auf einer Cloud Plattform dann bin ich zum geschäftsf ich seid ihr wahnsinnig das kannst du niemanden zeigen also man kann s nicht mal zeigen was willst den zeigen hier Cloud bitteschön al ihr müsst sofort Oberfläche basteln ihr müsst in die kundenköpfe reindenken quellt schaut geht in die Werke keine Ahnung geht in die Discovery versteht den Kunden welches Problem möchte ich eigentlich

00:46:21: lösen bevor ich eine Architektur baue muss ich den den Kunden verstehen ja red hör mal zu vielleicht hat ein ganz anderes Problem den löst du jetzt einfach mal in deiner Plattform und zack hast du den da bist du im Kopf dann ich weißt du ich sage mal auch wenn es noch so klein ist quickwins löst das irgendwie dann hast du den schon mal ja und und so eine Discovery kann tatsächlich auch dazu führen dass Unternehmen ihr Geschäftsmodell komplett ändern das heißt sie stellen sie haben eine Idee mm denken sie können mit mit

00:46:50: einer gewissen technischen Lösung ein Problem lösen stellen aber fest der Kunde das ist gar kein Kundenproblem und und das wird dann dazu dass vielleicht das ganze Unternehmen wirklich Pivot hinlegen und komplett ein anderes Geschäftsmodell machen kann aber auch dazu führen dass es uns nehmen wenn es wenn diese diese PIV nicht stattfindet einfach pleite geht das was du gesagt hast passt auf sehr viele Beispiele ich finde jetzt gerade die Studie nicht wo ich das gelesen habe kein Startup oder keine Idee war also die Anfangsidee war

00:47:21: nie womit ein Startup irgendwann das das den riesen Erfolg hatte ja da gibt's da gibt's ich habe auch so Artikel gelesen gibt sehr sehr viele bekannte Unternehmen wo man sagt okay wir schauen mal zurück in Historie was habt i eigentlich früher gemacht da denkt sich okay das hab ihr mal früher gemacht ja sie sind irgendwn drauf gekommen das was sie gemacht das was funktioniert nicht und sie haben komplett umgeschwenkt und schon sind wir wieder bei Mehrwert bei Kunden bei itativen Lösungen ja richtig

00:47:44: siehst du jetzt hab wieder bekommen ich habe ein ein Thema das hast Du vorhin gesagt darüber haben wir noch nicht gesprochen das Sprint Review ja oder das revw allgemein finde ich ein extrem wichtiges ein wichtiges Mittel auch wieder um um Feedback einzusammeln und was leider oft passiert ist das sprin finde statt zwischen Product Owner Entwickler fertig komplett nutzlos wo soll ich hier Feedback einsamen für wen muss ich reporten idealerweise weiß der Product Owner und das Team die sind jeden Tag zusammen da

00:48:18: gibt's nichts zu reporten wenn da kein Kunde dabei ist kein Stakeholder einfach weglassen ich habe ja auch schon erlebt wo das dann ausgelagert worden ist dann ist der salesman los und hat einfach eine Lösung irgendwo gezeigt und hat dann halbes Feedback dann mitgenommen weißt du das die die die Infos werden verwessert weil ich ich habe immer damals gesagt ich will dass die Entwickler auch da zum Kunden vielleicht auch mal hinfahren ja spür das wie sagt er es was sagt der Kunde also ne so dieses du du weißt also ich sag mal

00:48:50: beidische Mentalität ne so wenn man einfach so so ein Brocken hinschmeißt hör das mal dass man das gespürt okay wir müssen das irwie g anders lösen genau ja das fehlt das reicht nicht nur diese reine textliche information was der Kunde will oder muss ja nicht der Kunde sein der Auftraggeber was er will du musst das Hören D du diese pains raushörst und das deswegen war vorhin meine Frage ob man die Erwartung hat dass in einem Team nicht nur der Product Owner alles weiß im best case natürlich sehr viel weiß

00:49:19: sondern auch die Entwickler das mal hören und spüren und da was dazu sagen können mein Lieblingsbeispiel ist war z me entwicklerzeit da hat Apple ein ein Framework raus gebracht bei dem man die Social Networks sozusagen einblenden konnte in der App das war ein neues Feature im neuen iOS Version und m wir wollten eigentlich aus diesen Social Networks nur eins davon und zwar wollten man eigentlich den nur zeigen so diesen Framework einzubinden hat eine Woche gedauert und ich habe noch bevor das gestartet habe ich gesagt lass doch

00:49:50: den Scheiß wir rufen einfach instagram/irgendwas auf und dann kommt ein Browser so gelöst in zwei Stunden paar Unit Tests raus ne nein irgendein Fuchs kam dazu und hat eine Woche lang darum gespielt und nach einer Woche R mal was passiert ist wir haben es gelöscht wieder wieder alles rausgelöscht ja also einfach nur versemmelt wo ich gesagt habe hört mal zu wir müssen das war das Projekt mit den sehr vielen Features ich gesagt habe e komm scheiß drauf ein Feature abhaken jetzt auf zwei Tage ja weg weg weg weg

00:50:23: weg und solche Sachen sind das genau lieber lieber abhaken und und Feedback einsammeln ist es wirklich hat es mein Produkt nach vorne gebracht wenn nein okay haben wir was falsch gemacht können wir wieder drauf lernen und weiter weiter Zehen ja auf jeden Fall ja das muss nicht immer diese große rieseng Glocke sein der der Kunde draußen der versteht das im Detail sowieso nicht ja der hätte gern seine Daten jetzt will er Zugriff haben hatte ich vor vier Jahren und neulich auch wieder so ein Thema

00:50:50: irgendjemand will auf Daten zugreifen die sind nicht im Unternehmen also Kunde oder Lieferant ey vergiss es Cyber Security hochsicherheit dann darft überhaupt auf unsere tenen zugreifen und daravon nicht wer überhaupt hat er überhaupt ein E-Mail e come on also Wahnsinn Wahnsinn und ich habe dann natürlich müsste ich fast schon mein mein mein mein exciio Grüßen von dir aber dann war so ich habe gesagt ja Leute l doch das einfach unter wie heißt das irgwie diese ganzen Plattformen LCH das irgendwo hoch l hoch einfach und

00:51:27: Download bereitstellen fertig we transansfer ja genau l du einfach hoch was wo wird das gehostet hey gelöst gelöst abhaken was passiert jetzt wenn jemand diese Bilder bekommt ja NIS das sind ja g nicht mal die wichtige Daten gewesen ne aber ja also noch mal einfachit der Lösung manchmal brauchst du die Entwickler dazu und deswegen meine Frage die müssten das wollen aber ich verstehe auch wenn wir sagen na ja du kannst ja nicht alle davon überzeugen sozusagen unternehmerisch für das Unternehmen zu denken die harte weheit

00:51:57: ist ich sag mal so F Prinzip na ja die kommen der arbeitet und geh wieder nach Hause und abends Tack hat noch an seinem Haus noch rum Haus noch abbezahlen muss ja gedanklich war ich schon wieder vier Tage we wo die Leute Freitags schon wieder auf der Baustelle auf der hauseigenen Baustelle Sitz DonsTag schon aufhören zu denken ja ja und D wo du denkst so okay alles klar ja gut ich habe noch ein paar ganz tolle Sätze dabei ich nenn es ages Bullshit Bingo okay hau raus ich würde einfach sagen ich lese das mal vor ja ein kommentierst

00:52:28: du anderen kommentiere wieder ich agiles Bullshit Bingo was man oft hört und wo man drüber schmunzeln kann alle schon 1us mal gehört Satz das Backend ist schon auf Def natürlich Backend ist auf death natürlich so wie zum Thema Mehrwert gar keiner ja gar kein dann nächster Punkt das kommt in den nächsten Sprint ja oder Stakeholder Feedback Team Team kann nicht ja kann nicht reagieren und packt das einfach mal den backlock alles alles alle Anforderung kommen irgendwo in den backlock kommt irgendwann immer in der Zukunft

00:53:06: Klassiker ja gleich mal ein Tipp weil ich ne wieder gelesen habe alles was im backlock ist älter als d Monate kannst du löschen sehr guter Punkt backlock ist auf le Liste des Todes haben wir glaube ich damals noch gemacht zusammen gearbeitet hab löschen Brau nicht ja aber ne lösch lösch ist so alt Check eh keiner ja aber was ich habe wenn es wichtig ist kommt doch wieder richtig richtig ja gut nächster Punkt das sprintziel ist das Backend nutzt jetzt den neuen Service von AWS ja totaler Schwachsinn sindmer

00:53:39: wieder bei Thema Mehrwert für den Kunden total Null das Backend nutzt sagst mal noch mal das Backend nutzt jetzt den neuen Service von AWS also Backend sind ja die eigen Mitarbeiter ja quatsch ist totaler Quatsch ja totaler qu oft hört man oft denkt sich denken sich Team ja wir müssen jetzt l wir müssen ein sprintziel definieren das ist unser Ziel und nachdem sie kein ordentliches Kunden sprintziel definieren denken sie sich irgendwas aus irgendwelche technischen Blabla ja genau also Ziel damit einfach

00:54:12: nur ein Ziel ist aber eigentlichöigig ja aber die versteh da sindmer wieder bei der Interpretation Ziel Mehrwert für den Kunden deswegen wir so komplexe Projekte mit agil machen und dann solche Dinge geben all den Menschen dann letztendlich und auch nicht bös gemeint die das vielleicht nicht verstehen genug Futter um zu sagen ja guck mal ihr macht das doch agil und alle s so kuschelig und ihr kriegt das ja trotzdem nicht hin ja das stimmt ja dann auch ja ja nächstes nächstes Bullshit Bingo das mal oft hört

00:54:43: wer wenn wenn wenn Leute von agil sprechen die nicht wissen was agil ist wer agil ist muss nicht planen natürlich muss man planen man plant auf kurzes richt man plant auf Länge längeres Sicht äh man plant natürlich den Sprint den plant man sehr sehr genau man schätzt man man teilt teilt das Problem in Inkremente auf haben wir elich über Schätzung schon gesprochen ach ich glaube da reicht die heutige Folge nicht mehr also alle die jetzt noch mit Tieren schätzen oder mit T-Shirt sizes also sofort agil heißt dass man jederzeit

00:55:17: alles ändern kann also ich würde sagen man kann auf neue Anforderungen durchaus reagieren aber es gibt sowas wie das produ goal z Z be das ist durchaus was was länger Bestand hat aber auch natürlich gilt da wenn das protocol aus irgendwelchen Grund obsolet wird änderne sich geänderte Marktanforderungen die eigene das eigene Unternehmen ändert sich in irgendeer Art und Weise dann kann auch das protocol was so der nordstein ist sich auch ändern also ich sage wir sind immer so hin und her ne es ist immer so ein ja

00:55:49: ändern ja geht aber jetzt nicht jetzt in der Sekunde sondern wir müssen das ein bisschen planen jetzt habe ich zu guter letzt noch fün Punkte dabei an denen du erkennst dass du garantiert nicht agil arbeitest an der Excelliste z.B ja gut auf der anderen Seite heißt natürlich agil wenn du mit Tiir arbeitest heißt es auch noch lange nicht dass du agil bist oder backlock heißt auch nicht ein voller Backlog heißt auch nicht dass du agil bist aber was ganz klares Zeichen ist der Abteilungsleiter oder der CEO

00:56:19: gibt die R vor ganz klar das ist nicht agil ja pass ich habe was das ist ein guter Punkt Road Map aus strategischen Sicht soll er ruhig zu soll ruhig vorgeben als strategischen Sicht aber Roadmap im Detail was du jetzt me die nä steps richtig eine Strategie ja ja vorgeben ja aber die ganz klaren next steps wird höchstwahrscheinlich funktionieren warum fünf Dinge an denen du erkennst dass du garantiert nicht agil arbeitest du Releas alle drei Monate so wie zum Thema schnell auf Markt umforderung Anforderung reagieren

00:56:54: schnell Mehrwert schaffen dre Monate di Monate ist definitiv also früher hte man ja noch gesagt früher gab's noch Jahreszyklen du hast do Produkt Releases gehabt so jährlich J so jahreszüen ja dein einziges Kundenfeedback ist eine Befragung von vor zi Jahren den du nicht selber gemacht hast genau die irgendein wstent mal gemacht hat genau und der ist auch nicht mehr da Wahnsinn oder dann Meetings dienen hauptsächlich dazu den Status zu berichten anstatt Probleme zu lösen ja in sehr viel n Teams übrigens noch

00:57:31: genauso man erzählt was man gemacht hat genau ich will aber gar nicht wissen was du gemacht hast was hast du jetzt dafür denn gemacht was hast dafür gemacht genau Dailys werden missbraucht das steh plötzlich der abteilungsim Daily ja oh ja das gibt aber ich meine wieso nicht also man darf doch dabei sein als Gast oder nicht ich darf man schon darf man schon aber es gibt auch welche die dann gerne auch dann sagen nee das machen wir anders ja das ist schon krass W kurz was sagen daily finde ich ja super ich hatte

00:57:59: mal einen mitarweiter der hat gesagt ja Kur du willst ja dass wir alle in den Daily reingehen aber super satzens aber mich interessiert gar nicht was die machen also das ist ja Wahnsinn oder was im Kopf vorgeht so interessiert gar nicht was sie machen okay aber interessiert dich nicht was wir da jetzt machen ja nee ich habe mit den NS zu tun Datenbank oder so newierig Klassiker ja übrigens Entschuldigung ein Satz dazu all diese Härtefälle ja und das muss ich jetzt all meine Managern und all den Menschen ich

00:58:34: kennengelernt habe und alle die in dieser Rolle sind unds zuhören sagen ihr könnt die Menschen nicht groß verändern ja ihr müsst euren Job tun und dann die Teams gegebenfalls verändern das muss nicht immer heißen Leute kündigen und so weiter aber ihr müsst ihr seidfahig für für den Erfolg e Abteilung whatever und damit müssten müsst ihr alle Maßnahmen die ihr für die ihr berechtigt seid m vollziehen Maßnahmen Konsequenzen das geht nicht an man kann nicht einfach wegducken und sagen na ja ja okay ja der

00:59:07: ist halt so oder das ist halt so nein passt nicht rein richtig wir tun diesen Menschen kein Gefallen Christian ich mein es wirklich ernst wir tun den wirklich kein Gefallen den Menschen wenn sie in Umgebungen Teams existieren bei dem sie sozusagen dem ja dem unternehmensklimaschaden im kleinen Bereich aber das geht R zu ruckzuck wir können den Leuten nicht helfen wir müssen Menschen zusammenbringen die Bock haben das was wir vorhen gemeinsam umzusetzen da kann man nichts hinzufügen let letzter satzz vom Sonntag zum

00:59:34: Sonntag ist letzter Satz an dem du erkennst dass du garantiert nicht Agel arbeitest dein Team besteht aus Mitarbeitern verschiedene Abteilungen die getrennt vinander reporten ich habe noch einen mag mag vielleicht ein Kommentar mag vielleicht funktionieren aber wenn das Team wirklich wirklich ja ein gemin geminsames produ goal hat ein gemeinsames Ziel wirklich auch auch ja an einem Strand zieht mag das auch funktionieren ich hab zwei Punkte noch ein noch ein Bullshit SCM ist Projektleiter habe ich

01:00:10: auch schon paar mal erlebt Kass scrum ist Projektleiter ich habe dann immer noch versucht zu verstehen wieso ist der Scrum Master Projektleiter also ich habe noch nicht diese auch schon crumm ist gleich teamleed ja ja alle alle wilden Kombinationen ja ja dann lieber gar nicht klingt Hal hart aber dann gar nicht lass i mal seinen Job machen und ich habe sehr oft solchen solchen teamle erklären müssen ich hör mal zu dass du jetzt was machst ist nicht das was ich von dir verlangen du sollst dein Job tun

01:00:42: ein Team führen Richtung vorgeben und zwar so wie ich es dir und deinen anderen Kollegen in deinem Level vorgebe gibt's wirklich ganz oft die machen das nicht aus verschiedensten Gründen was ich nur sagen wollte ist ja genau was oft problematisch wird ist wenn du ein Organigramm hast den musst du haben ja es gibt Product Manager die werden vom head of product geleitet z.B Softwareentwickler könnten von Head of software engineering geleitet werden so das ist eine personelle Verantwortung richtig das heißt der hat also je nach

01:01:13: Organisation aber die haben Verantwortung wie geht's denen klappt alles gibt's Probleme unter den Leuten das gilt es zu klären wie werden sie weitergebildet fachlich fachlich weiterentwickelt genau im Bezug auf die Unternehmensziele und das mal konkret mal zu definieren genau und dann haben wir ja eine Matrixorganisation die Leute die einen Mehrwert schaffen müssen müssen aus verschiedenen Abteilungen zusammenkommen ja und diese zusammenkommen jetzt immer beim Softwareentwickler Product Owner Scrum Master vielleicht ein paar andere

01:01:44: noch User Experience genau IX auf jeden Fall und das und das glaube ich führt als ob das habe ich das Gefühl dass ist für manche Köpfe zu viel so oh Gott ich komme nicht mehr weiter nein das ist dein Team und habe ich auch schon erlebt dass manche z.B du bist in einem Team Softwareentwickler das fand ich gut damals im anderen Team bist du Tester fand ich cool weil du hast fachliche Expertise bist aber nicht im Produkt kannst also testen das fand ich wieder auch cool aber wie gesagt wir reden über

01:02:16: verschiedenste Organisationen wenn sie dann überhaupt so existieren grundsätzlich wenn du ganz normaler Mensch bist mit Werten und Prinzipien hast du alle Werkzeuge um in jeglichem Team positiv aufzufallen oder ich wüsste nicht was ich wüsste nicht was ich besonders mache od anders mache als sie also ich gehe natürlich Nerv vielleicht hier und da mal ja wüst jetzt nicht was ich anders ma ich bin ein ganz normal ne ich sag was wenn es nicht gut läuft und sag auch wenn es schön läuft und gut läuft und fertig ja

01:02:45: ja haben wir noch was gut haben wir ich denke wir haben ganz viele Fragen oh beantwortet Bullshit Bingo hat mir sehr viel Spaß gemacht ja auf jeden Fall zum Abschluss würde ich noch ein Buch K empfehlen Christian und zwar früher habe ich das noch ganz hart formuliert heute sage ich noch okay gut ich sage les das Buch wo erklärt wird was scum bedeutet woher das herkommt wie immer und wie überall kommt das oder sehr oft kommen stategische und taktische Methoden aus dem Militär und da habe ich was

01:03:17: mitgebracht das Buch SCR art of doingce the work in timeon jeffland klingt eigentlich fast wie managertitel ne ja und ist schon uralt die ist schon uralt definitiv und Jeff S ist hier in dem Fall der der coautor wenn ihr über agil redet oder jedem der über agil verstehen reden will lest das Buch ist gar nicht so schwierig zu lesen aber dann würde man verstehen wo das herkommt wenn man versteht wo das herkommt dann versteht man auch wieso es ein Werte geht und dann wird man aber auch verstehen all dieses Anzahl der

01:03:55: Meetings und wieso ist einfach nur ein Zusatzwerkzeug um die Arbeit zu erleichtern und gar nicht verpflichtend um einfach nur ein Meeting zu haben ja deswegen also lesen und dann bitte hier nicht irgendwelchen hallunken oder Hop die irgendwie Scrum Buch geschrieben haben weil sie dreimal Scrum schreiben können also nicht bös gemeint aber wenn man die Quelle gelesen hat dann kann man da wesentlich freier darüber sprechen ja so das wär von mir ich denke ich denke es ist ein super Ende also auf jeden Fall empfehlung geht raus an

01:04:28: alle hat mir riesen Spaß gemacht und du frst sich schon ich würde sagen was denkt ihr was denkt ihr über was denkt ihr überes arbeiten ist es ein Konflikt mit Thema zeitabschätzung mit Thema budgetabschätzung würden uns freuen über jede Art der kommentage und Feedback genau danke schön