#192 Quartalsplanung ohne Drama: Weniger Overcommitment, mehr Tech

Wie geht man die Quartals- und Jahresplanung an und balanciert verschiedene Anforderungen?

Für viele ist es ein langweiliges und notwendiges Übel. Für andere die beste Zeit des Jahres - Die Quartals- bzw. Jahresplanung. Firmen lieben es zu planen. Firmen lieben es, den Kunden neue Features zu versprechen. Produktmanager können endlich alles in die nächsten 3 Monate einordnen, dann wird das gemacht und die Welt ist wieder in Ordnung.

Am Ende des Quartals fragt man sich dann aber: Wieso hat das alles so lange gedauert? Wieso haben wir für Feature X 2 Wochen geplant, aber es wurden 6 Wochen draus? Wieso werden wir bei der Software-Entwicklung langsamer und nicht schneller? Das ist ein bekanntes Bild in vielen Firmen, denn oft findet die Stimme der Software-Entwickler*innen keinen Platz in der Planung.

Technical Debt abbauen? Machen wir nächstes Quartal. Was für die eigene Team-Produktivität tun, um manuelle Aufgaben zu automatisieren? Das lohnt sich nicht. Kleine Bugs, sogenannte Papercuts, fixen um die Power-User glücklich zu machen? Zu klein, machen wir nebenher. Software updaten? Das ist Keep The Lights On Arbeit und kann doch Ops machen. So oder so ähnlich trägt es sich alle 3 Monate in Firmen zu.

In dieser Episode geben wir euch mal ein paar Leitfragen und ein spezifisches Framework an die Hand, wie man die Software-Entwicklungs-Ressourcen gut über das nächste Quartal balanciert, es genug Features in die Roadmap schaffen, aber auch Zeit für Tech Debt und Produktivitätsverbesserungen bleibt. Dabei klären wir, warum eine gewisse Planung eigentlich so wichtig ist, wer eigentlich immer die ganzen Anforderungen auf den Tisch knallt, was Over-Commitments und Rollovers sind, wie Ubuntu und Github mit Mission Papercut kleine Bugs zu einem großen Projekt gemacht hat aber auch warum eine Quartalsplanung in die Bereiche KTLO, Build New Stuff, Improve Stuff und Productivity eingeteilt werden sollte.

Das Thema klingt trocken. Dennoch kann dies euch eine Stimme im Planungsprozess geben, damit ihr endlich mal Zeug aufräumen könnt.

Bonus: Ist Jira das neue ERP-System?

Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners

Das schnelle Feedback zur Episode:

👍 (top) 👎 (geht so)

Anregungen, Gedanken, Themen und Wünsche

Dein Feedback zählt! Erreiche uns über einen der folgenden Kanäle …

EngKiosk Community: https://engineeringkiosk.dev/join-discord
LinkedIn: https://www.linkedin.com/company/engineering-kiosk/
Email: stehtisch@engineeringkiosk.dev
Mastodon: https://podcasts.social/@engkiosk
Bluesky: https://bsky.app/profile/engineeringkiosk.bsky.social
Instagram: https://www.instagram.com/engineeringkiosk/

Unterstütze den Engineering Kiosk

Wenn du uns etwas Gutes tun möchtest … Kaffee schmeckt uns immer

Buy us a coffee: https://engineeringkiosk.dev/kaffee

Sprungmarken

(00:00:00) Ausbalancierung von Engineering-Ressourcen

(00:06:14) Info/Werbung

(00:07:14) Die Priorisierung vom Backlog treiben lassen

(00:09:47) Wer alles bei der Priorisierung mitreden möchte

(00:13:20) Balancierung mit 4 Bereichen: KTLO, Build new stuff, Improve Stuff und Productivity

(00:20:20) Build new Stuff und Improve Stuff

(00:26:02) Productivity

(00:27:34) Zusammenhang zu OKR, Shape Up, Scrum und Co.

(00:31:05) Impact deiner Änderungen

(00:40:24) Leitfragen bei deiner Quartalsplanung

(00:44:46) Papcercuts: Kleine Fixes mit großem Effekt

Hosts

Wolfgang Gassler (https://gassler.dev)
Andy Grunwald (https://andygrunwald.com/)

Community

Diskutiere mit uns und vielen anderen Tech-Spezialist⋅innen in unserer Engineering Kiosk Community unter https://engineeringkiosk.dev/join-discord

Transkript

Das Transkript wurde automatisiert per Speech-to-Text erstellt und kann daher Fehler enthalten.

Wolfi Gassler (00:00:03 - 00:01:25)

Für viele ist es ein notwendiges Übel, für andere die beste Zeit des Jahres. Die Quartals oder Jahresplanung. Firmen lieben es ja zu planen, neue Features zu versprechen und Roadmaps zu füllen. Produktmanager ordnen ihre Ideen ein und alles scheint seinen Platz zu finden. Doch am Quartalsende fragt man sich warum hat das Feature sechs statt zwei Wochen gedauert? Warum werden wir langsamer statt schneller? Eine der möglichen die Perspektive der Entwickler innen fehlt häufig in der Planung. Kennt ihr vielleicht auch technical debt nächstes quartal. Automatisierung für weniger manuelle arbeit lohnt sich nicht. Kleine bugs fixen zu unwichtig. Können wir mal nebenbei machen. Software updates? Macht doch ops. Und genau so wiederholt sich das spiel regelmäßig alle drei Monate. In dieser Episode zeigen wir euch ein Framework, mit dem ihr Entwicklungsressourcen sinnvoll balancieren könnt zwischen neuen Features, Technical Depth und Produktivitätsboosts. Wir erklären, warum Planung wichtig ist, woher all die Anforderungen kommen, was Overcommitments und Rollovers sind und wie Projekte wie Mission Papercut bei GitHub und bei Ubuntu kleine Bugs groß gemacht haben. Mit klaren Kategorien wie Keep the lights on, build new stuff, improve stuff and productivity be bekommt ihr als Devs eine Stimme und endlich die Zeit, um mal aufzuräumen.

Andy Grunwald (00:01:25 - 00:02:42)

Los geht's. Beim heutigen Thema schlägt das Herz höher. Bei allen Produktmanagern und bei den meisten Software Engineern geht das Herz in die Hose. Denn es geht nämlich um Planung. Es geht um Quartalsplanung, es geht um Jahresplanung, es geht eigentlich um die woran arbeiten wir eigentlich in den nächsten Monaten? Denn Firmen lieben es zu planen und ihre Ressourcen zu verwalten. Und wenn man danach mal googelt, da kommt man relativ schnell auf den Begriff Enterprise Resource Planning ERP System. Und dann bin ich so von Höcksgen auf Stöcks gekommen und habe mir gedacht, ist JIra eigentlich ein ERP System bzw. Kann Jira als ERP System bezeichnet werden? Denn im Endeffekt hat Jira ja Tickets und Menschen arbeiten da. Und Menschen werden ja immer als Ressource bezeichnet. Deswegen heißt es ja auch Human Resources, zum Beispiel die Abteilung. Und da bin ich nach ChatGPT gegangen und hab ChatGPT die Situation erklärt. Hör mal, pass mal auf, wir haben Menschen, Programmierer, wir haben Jira Tickets und so weiter und so fort. Kann man Jira als ERP System bezeichnen? Und ChatGPT hat erst mal gesagt hör mal, Andi, das ist ein super Gedankengang, klingt auch im ersten Moment logisch, aber. Und dann kam dann eine Antwort warum das nicht geht. Kurzum ein ERP System ist viel größer und holistischer gedacht und Jira zählt da nicht dazu.

Wolfi Gassler (00:02:42 - 00:02:51)

Also ich bin so froh, dass es ChatGPT gibt, dann muss ich nicht mehr solche dummen Fragen beantworten. Also ich finde das wirklich super. Also danke dir, ChatGPT.

Andy Grunwald (00:02:51 - 00:02:56)

Naja, ChatGPT hat ja schon gesagt, war gar nicht so doof und der Gedanke ist nachvollziehbar.

Wolfi Gassler (00:02:56 - 00:02:57)

Ja, so nett wäre ich nicht gewesen.

Andy Grunwald (00:02:58 - 00:03:13)

Ich glaube, das ist auf jeden Fall eine gute Bierdiskussion in irgendeinem Meetup. Kann man Jira als ERP System bezeichnen? Aber dann bin ich wieder. Ich bin ja von Höxen auf Stöcks gekommen, habe ja gerade gesagt, habe ich den Hasenbau runter und dann habe ich wieder darüber nachgedacht. Sind Menschen Ressourcen bzw. Ist die Bezeichnung okay?

Wolfi Gassler (00:03:13 - 00:03:16)

War das jetzt eine Frage oder sprichst du noch mit dir selber?

Andy Grunwald (00:03:16 - 00:03:19)

Ne, das habe ich dann nicht ChatGPT gefragt. Das frage ich jetzt den Wolfgang.

Wolfi Gassler (00:03:19 - 00:03:43)

Ja, du bist ja immer der, der sagt, man darf nicht Ressource sagen zu einem Menschen. Ich denke mir immer das so, was du ja planst bei so einer Ressourcenplanung ist ja nicht der Mensch, sondern die Zeit, also die Ressource Zeit von diesem Menschen. Insofern kann man das dann schon natürlich sagen, wenn man nicht den Menschen an sich als Ressource sieht, sondern die Zeit dieses Menschen. Weil du tauscht ja Lebenszeit gegen Geld, wie du auch immer so schön sagst.

Andy Grunwald (00:03:43 - 00:03:50)

Das ist korrekt. Aber immer wenn man in einem Meeting sitzt und dann sagt jemand aber wir haben ja keine Ressourcen, dann redet er ja über Menschen. Wir haben ja nicht genug Menschen oder.

Wolfi Gassler (00:03:50 - 00:03:52)

Nicht genug Zeit von Menschen.

Andy Grunwald (00:03:52 - 00:04:00)

Da sind wir aber schon wieder beim Thema. Wenn wir nicht genug Zeit haben, dann ist für mich die haben wir richtig priorisiert? Und genau darum geht es heute.

Wolfi Gassler (00:04:00 - 00:04:09)

Wie kommt Zeit? Haben wir immer zu wenig? Also darum geht es ja. Darum kommst du ja erst zur Priorisierung eigentlich, weil du zu wenig Zeit hast. Wenn du genug Zeit hättest, dann ist.

Andy Grunwald (00:04:09 - 00:05:28)

Ja sowieso egal, sage ich ja. Und wenn jemand sagt, ich habe zu wenig Leute, dann heißt es für mich auch OK, man hat, man arbeitet in einem Rahmen und man hat zu schlecht priorisiert, weil man sich zu viel vorgenommen hat. Auf jeden Fall bin ich genau über dieses Problem die Tage wieder gestolpert. Ich durfte mal wieder eine Quartalsplanung machen. Ich habe natürlich wie immer zu wenig Leute und wie immer viel zu viele Produkte und Projekte auf dem Plan. Und dann war die woran arbeiten wir denn eigentlich? Packe ich einfach alles rein und sucht euch was aus und wir overcommitten den Monat oder wie schmeiße ich was raus? Also ich habe eine ganz klassische Quartalsplanung gemacht und dieses Thema habe ich heute mitgebracht, weil ich mich damit dann ein bisschen beschäftigt habe, wie wir auch Entwickler, ich sag mal so ein kleines Wort, in der Planung mitgeben können, aber auch hoffentlich das Business zufriedenstellen können. Denn in meiner anfangs Karriere als Softwareentwickler, da wurde mir immer so ein Quartalsplan vorgelegt und ich habe nicht verstanden, wie der zustande gekommen ist. Und dann habe ich ihn einfach abgearbeitet. Ich habe aber damals auch nie gefragt. Später, als ich mehr Erfahrung hatte, wollte ich immer technische Schulden abbauen und immer das Produkt stabiler machen. Da hatten wir dann aber nie Zeit dafür, weil die Quartalsplanung sowieso schon overcommitted war. Deswegen habe ich gedacht, machen wir heute mal eine Selbsthilfegruppe zur Quartalsplanung bzw. Zur Balancierung und Budgetierung von Engineering Ressourcen.

Wolfi Gassler (00:05:28 - 00:06:14)

Es klingt jetzt ziemlich langweilig, wie du das sagst, Budgetierung. Ich glaube, dass es ja auch sehr hilfreich ist, wenn du zum Beispiel dein eigenes Projekt managst. Also das ist ja auch so was als. Also egal, ob man jetzt alleine ist oder zu zweit, sobald man an dem Projekt arbeitet, musst du eigentlich priorisieren und dir überlegen, auch wenn es nur ein side Hustle ist, irgendein side Project, wie teile ich die paar Stunden, die ich habe, pro Woche ein und was für Features baue ich oder wie investiere ich meine Zeit? Und auch da, jeder, glaube ich, der side Hustle hat, weiß, wie schwierig das ist und wie overcommitted man meistens ist, weil das schafft man alles in dieser Woche und alles kein Problem in den zwei Stunden jeden Abend und dann ist eine Woche vergangen und man hat genau nichts geschafft. Also auch da ist Priorisierung absolut ein Thema.

Andy Grunwald (00:07:14 - 00:07:22)

Aber warum kann ich nicht einfach in meinem side Hustle mein Backlog abarbeiten? Ich meine, das ist sowieso immer voll und das wird auch nie leerer. Kann ich da nicht einfach von oben abarbeiten und abfahrt?

Wolfi Gassler (00:07:22 - 00:07:38)

Ja, ich glaube, das machen auch viele. Darum sind so viele side Project immer nur in der Schublade und nie online. Also die domain ist dann online mit einer leeren Seite oder coming soon, aber weil man halt dann immer an dem arbeitet, was eigentlich keine Bewegung nach vorne bringt. Und genau darum geht es eigentlich. Wie kommt man nach vorne?

Andy Grunwald (00:07:38 - 00:07:46)

Bei Seitenprojekten stimme ich dir zu. Ich glaube, ich habe auch wieder viel zu viele Domains, die ich langsam mal wieder kündigen müsste, denn ich glaube, ich kaufe die immer so kurz vorm Sommer und bald werden sie.

Wolfi Gassler (00:07:46 - 00:07:50)

Ich habe gerade kürzlich drei Domains gekündigt, bin ganz stolz auf mich.

Andy Grunwald (00:07:50 - 00:07:51)

Meine Frage ist, wie alt waren die?

Wolfi Gassler (00:07:51 - 00:07:57)

Ja, schon alt. Die waren teilweise sogar aktiv. Aber ich habe jetzt angefangen, mit dir nicht mehr aufzuheben und einfach wieder rauszukicken.

Andy Grunwald (00:07:58 - 00:09:02)

Respekt für deinen Mut. Glückwunsch. Hätte ich mich bisher nicht getraut. Aber in einer Firma, da kann man natürlich nicht einfach so vor sich hin arbeiten und nicht einfach das Backlog abarbeiten. Denn wir wissen alle, das Backlog ist immer voll, es wird nicht leerer und ich weiß ja nicht, wie euer Backlog zustande kommt, aber im Backlog sind auch viele, man müsste mal Tasks, so was, was einem aufgefallen ist. Man packt das ins Backlog und wissen wir sowieso, nach drei Jahren macht man einfach ein Backlog Cleanup. Alles, was älter als zwei Jahre ist oder älter als sechs Monate, kein Update hat, schmeißt man einfach weg. Denn Engineering ist in der Regel sehr, sehr teuer, denn es ist nicht umsonst, dass das Engineering Department einer Firma in der Regel der teuerste Headcount der Firma ist. Deswegen ist es zwar gut, wenn ihr immer, immer, immer wieder Tickets ins Backlog packt, aber es bringt eigentlich nichts, wenn die sowieso nicht angefasst werden. Denkst du, Wolfgang, wenn wir ein System haben zum Backlog abarbeiten, sei es OKRs, sei es VMOMs, sei es Scrum oder Kanban, dass das einen Unterschied macht? Oder denkst du, solche Systeme beheben das ursprüngliche Problem nicht?

Wolfi Gassler (00:09:02 - 00:09:47)

Was diese Systeme ja alle lösen wollen, ist in einer gewissen Weise Priorisierung, damit man weiß, auf was man sich konzentriert, also an was arbeitet man, damit man weiterkommt, dass man das side Hustle online bringt, dass man die Firma weiterbringt, dass man mehr Kunden gewinnt, was es auch immer ist. Oder aber auch die Produktivität der Entwicklerinnen erhöht. Also also ganz klassisch Technical Debt ist natürlich auch so ein Thema und dafür sind eigentlich die ganzen Frameworks da. Die Frage ist natürlich, wo finden diese Frameworks statt? Also gerade bei OKRs ist es natürlich so, dass das sehr stark von der Produktseite und von oben kommt, die OKRs. Und da natürlich gerade die technischen bereiche oft untergehen, weil man darf ja nicht vergessen, dass wir ganz viele Stakeholder haben in der Firma, die alle irgendwas anderes wollen.

Andy Grunwald (00:09:47 - 00:10:05)

Ich glaube besonders der letzte Satz, das ist das eigentliche Problem. Denn man kann ja okay, du bist ein Produktteam, du machst jetzt den Warenkorb in deinem E Commerce Shop. Wo ist denn also jetzt das Problem der Priorisierung, wenn das Team entscheiden kann, was am Warenkorb verbessert wird?

Wolfi Gassler (00:10:05 - 00:10:46)

Ja, du hast jetzt die Sicht vom Produktmanager, vom Product Owner, was es auch immer ist, aber du vergisst natürlich da, dass es da ein Developer Team gibt, was mitzureden hat bei der ganzen Technik. Es gibt vielleicht irgendein Security Team, Audi Team, Compliance Team, die da ständig reink grätschen mit der Security. Es gibt noch vielleicht ein DevOps Team, was in irgendeiner Form mit reinspielt. Du hast die klassische Management Ebene, irgendwo grätscht ein CEO rein in das Ganze. Da hat der PO dann auch nicht mehr viel zu reden. Also du hast ganz viele Leute, die in irgendeiner Form andere Prioritäten gerne hätten und natürlich die gegeneinander reiben und die man durch alle mitbedenken muss, wenn man so eine Planung durchzieht.

Andy Grunwald (00:10:46 - 00:11:01)

Gibt es von diesen Zielgruppen bzw. Von diesen Leuten, gibt es da jemanden oder einen Bereich, wo du immer wieder sehr stark grinsen muss, wenn die dir reingrätschen? Da wo du sagst, die schon wieder oder die hatte ich jetzt gar nicht mehr auf dem Schirm, aber irgendwie kommen sie doch jedes Quartal um die Ecke.

Wolfi Gassler (00:11:01 - 00:11:27)

Ja, ich würde ja sagen, dass man die meisten eigentlich mitdenken kann, wenn man sich ein bisschen den Kopf zerbricht. Außer natürlich diese C Level Projects, weil die stehen ja nirgends. Die kommen dann ja irgendwann um die Ecke plötzlich. Außer bei Amazon gibt es auch diese C Level Projects, die man dann wirklich einreicht und dann ganz großen Stellenwert haben. Aber noch schlimmer sind natürlich diese Sea Level Projects, die irgendwann während dem Quarter auftauchen und dann plötzlich ganz wichtig sind.

Andy Grunwald (00:11:27 - 00:11:40)

Bei mir anders. Da habe ich immer die Hoffnung, dass C Level nicht mehr so tief in die Produktteams reingrätscht, sondern das irgendwie ganz oben einkippt und dann fällt das wie so eine Murmel runter und irgendwann landet es bei dir als normales Projekt. Bei mir ist es immer der ja.

Wolfi Gassler (00:11:40 - 00:11:43)

Ja, aber die Murmel ist so hoch priorisiert, dass sie die fast erschlägt.

Andy Grunwald (00:11:44 - 00:12:32)

Bei mir ist es immer der Vertrieb bzw. Sales, weil die haben nämlich in der Regel immer schon alles verkauft, was die dir auf deinen Tisch setzen. Dann sagen wenn das Feature drin ist, dann unterschreibt der Kunde einen Vertrag. Und das ist ja prinzipiell eine super Sache für so Unternehmen, aber die sind dann immer so laut und gehen dir so auf die Nerven, weil die natürlich eine Provision kriegen, wenn der Kunde unterschreibt. Die haben natürlich dann noch einen persönlichen Incentive, wenn der Kunde unterschreibt und die haben denen dann wieder einem vom Pferd erzählt. Da denke ich mir immer so oh fuck, weil die kann es ja auch nicht planen. Die schließen ja nicht nur am Anfang oder am Ende vom Quartal irgendwelche Deals ab, die sind ja konstant am Telefon und du kannst ja nicht ausdenken, was Kunden wollen, weil du weißt ja, nur weil der Kunde etwas möchte, heißt das nicht, dass er das wirklich will. Der kennt nur diese eine Lösung und denkt, das löst sein Problem ja du.

Wolfi Gassler (00:12:32 - 00:13:12)

Hast natürlich recht, in den meisten Umfeldern, wo ich bisher natürlich klassisch gearbeitet habe, da gab es keine Kunden in dem Sinne oder Kundenprojekte, darum ist mir das auch nicht so im Kopf. Das wären dann wahrscheinlich diese c Level Projekte, weil die wichtigen Features entscheidet dann irgendwer anderer. Das ist immer das Problem. Aber ich habe gerade selber in einem side Project mit einem Kollegen genau dasselbe Problem gehabt. Wir haben gerade einen neuen Kunden diskutiert und mein Kollege sagt, ja, da brauchen wir eh nur das kleine Feature implementieren und dann sind wir fertig. Und ich hab so gemeint, naja, in meinem Sales Call habe ich eigentlich noch Feature x und Z versprochen und dann sind so die Augen auch nach oben gegangen von meinem Kollegen. Also ich scheine schon ein guter sales.

Andy Grunwald (00:13:12 - 00:13:15)

Mensch zu sein oder bist du jetzt der nervige Vertrieb?

Wolfi Gassler (00:13:15 - 00:13:20)

Kann auch sein, aber wir haben den neuen Kunden, hat er schon unterschrieben fast.

Andy Grunwald (00:13:20 - 00:15:12)

Also habt ihr noch keinen Kunden, von daher erst wenn die Tinte trocken ist. Also so gut im Sales bist du wohl noch nicht. Aber kommen wir zurück zur Quartalsplanung oder Jahresplanung oder drei Jahresplanung, wie auch. Und zwar habe ich mich da vor kurzem wieder mit beschäftigt und habe mir überlegt, okay, wie gehe ich da jetzt wieder ran und habe auch ein bisschen recherchiert und da bin ich über ein Framework gestolpert, was aus dem Hause Dropbox gekommen ist, was ich eigentlich ziemlich cool fand. Und zwar geht es darum, dass man eigentlich bei einer Planung vier Bereiche hat, wovon ein Bereich Pflicht ist und drei Bereiche, ich sag mal optional bzw. Können gefüllt werden. Die vier Bereiche heißen keep the lights on, also KTLO, also mach das, was gemacht werden muss, das ist der Pflichtbereich und die anderen Bereiche nennen sich build new stuff, improve existing stuff und increase your productivity. Wenn wir uns die einzelnen Bereiche mal anschauen, ist das eigentlich super smart, denn keep the lights on, das ist so die ehrliche Grundlinie. Du hast ein Produkt, da muss die Grundlinie gehalten werden und man stellt sich die was kostet uns diese Baseline zu halten? Für Dropbox wäre das jetzt okay, wir halten den Storage und so weiter, wir halten alle Features, welche Infrastrukturthemen müssen wir machen, damit wir einfach ein kontinuierliches Kundenwachstum bei gleichen Features haben und so weiter und so fort. Also die Mindestaufgaben zur Aufrechterhaltung des derzeitigen Dienstleistungsniveaus, würde ich mal so sagen, das, was auf der Webseite gerade steht. Dazu zählt natürlich dann sowas wie ganz klassische Audits, On call Updates von Dependencies für Security und so weiter und so fort. Das ist Pflicht. Weil wenn du die Lichter nicht anlässt, dann hört die Musik halt irgendwann auch auf zu spielen und dann hast du vielleicht auch keinen Job.

Wolfi Gassler (00:15:12 - 00:15:13)

Was ist mit Security?

Andy Grunwald (00:15:13 - 00:15:20)

Ja, habe ich ja gesagt, Updating von Dependencies und Co. Das zählt ja da rein. Audit zählt ja auch da rein. Sind ja auch alles Security Bereiche.

Wolfi Gassler (00:15:21 - 00:15:23)

Aber keine Verbesserung von Security?

Andy Grunwald (00:15:23 - 00:15:26)

Ne, das wird dann in das Bucket Improve Existing Stuff fallen.

Wolfi Gassler (00:15:26 - 00:15:41)

Du hast es jetzt so lapidar irgendwie aufgezählt, das gehört da rein und das kann man dann in den Bucket werfen, damit man da eine Übersicht hat. Also darum gibt es ja mehrere Buckets. Aber woher weiß ich denn jetzt im Vorhinein, wie viel Arbeit es ist im nächsten Quarter?

Andy Grunwald (00:15:41 - 00:15:47)

Bist du gerade im ersten Quartal mit deinem Produkt und ist das die erste Quartalsplanung oder hast du bereits ein Quartal gemacht?

Wolfi Gassler (00:15:47 - 00:15:50)

Na, kann ja auch im letzten Quartal schon was gegeben haben.

Andy Grunwald (00:15:50 - 00:15:52)

Ja, dann hast du eine Basislein oder.

Wolfi Gassler (00:15:53 - 00:15:57)

Ich führe ja gerade dieses neue System ein, ich habe nur ganz viele Tickets im letzten Quartal.

Andy Grunwald (00:15:57 - 00:16:10)

Ja, und die haben doch wohl eine Kategorie oder ähnliches. Dann setzt man sich halt mal hin und geht durch, okay, was habe ich im letzten Quartal so alles weggeballert und kategorisiere die einmal. Da kann ich ja ganz einfach mit Jira in meinem neu erlernten ERP System mit Labels machen.

Wolfi Gassler (00:16:10 - 00:16:14)

OK, also du setzt Labels voraus und dann noch Time Tracking.

Andy Grunwald (00:16:14 - 00:17:05)

Also Time Tracking würde ich jetzt nicht voraussetzen, aber ich würde eher mal sagen, die Anzahl der Tickets. Natürlich. Ich sage jetzt nicht, dass jedes Ticket zwei Stunden sein muss oder jedes Ticket zwei Tage. Kann durchaus sein, dass ein Ticket fünf Minuten ist. Offen gesprochen, in der Software Engineering Welt ist nichts fünf Minuten und das andere ein Tag. Alles gut. Aber da geht es mir ja nur um eine grobe Hausnummer. Also reden wir jetzt hier von zwanzig Tickets update Dependency oder reden wir von zwei hundert. Und dann ist ja hoffentlich ein anderes Bauchgefühl. Wenn du zwanzig Tickets hast, da wo jedes Ticket vier Tage dauert, dann solltest du vielleicht mal ein Ticketing ein bisschen anpassen oder ähnliches. Aber gehen wir mal von einer ausgewogenen Zeit Balance pro Ticket aus. Manche fünf Minuten, manche Tag. Dann hebt sich im Mittel irgendwann auf und dann kriegst du ja ein Gefühl dafür. Es geht ja nicht darum, dass du eins zu eins das ganze Quartal bis auf die letzte Minute verplanst.

Wolfi Gassler (00:17:05 - 00:17:19)

Es gibt ja diese Daumenregel, dass es zwanzig Prozent von den Herstellungskosten sind, die dann als Wartung quasi entstehen pro Jahr. Kannst du das nachvollziehen in der Praxis? Ist das eine Regel, mit der du arbeitest?

Andy Grunwald (00:17:19 - 00:18:39)

Zwanzig Prozent. Also die Zahl kannte ich noch nicht, aber vielleicht nicht immer nur in einem Quartal. Aber wenn man mehrere Quartale übereinander legt, könnte das so im Mittel schon hinkommen. Ich meine, es gibt Quartale, da wirst du mehr Ausfälle haben und da muss dann mehr Arbeit in die Behebung der Ausfälle gesteckt werden. Es gibt Quartale, wo du mehr Dependencies updaten musst. Nehmen wir mal das Quartal, wo Logj, die Sicherheitslücke im Java Code veröffentlicht wurde. Da wurden die zwanzig Prozent wahrscheinlich gerissen in vielen Firmen. Aber ich glaube, so im mittel über vier bis sechs Quartale kann ich mir das schon vorstellen. Und man muss ja auch mal sagen, ich habe gerade Updates von Dependencies gesagt, wir müssen nicht jede Dependency updaten. Natürlich muss man mit dem Lifecycle irgendwie mitgehen und allem drum und dran. Aber was man ja auch machen kann, ist, man kann ja auch einen Sicherheitslückenscanner kaufen, den auf seine Infrastruktur lasten und dann warnt er dich, wenn irgendwo eine Sicherheitslücke in deiner Dependency ist und dann updatest du die Dependency. Du musst ja nicht immer nur updaten des updaten wegen, weil auch beim neuen updaten kann ja neue Bugs reinkommen und allem drum und dran. Und es gibt ja auch LTS Versionen, wo du fünf bis zehn Jahre Support hast. Also deswegen muss man da gucken, okay, was ist gegeben und muss man jetzt alle Dependencies updaten. Aber on call sind da, audits sind da, die kommen jährlich, wenn du mit Kreditkartendaten arbeitest, PCI, DSS, HIPAA Compliance, wenn du mit Gesundheitsdaten arbeitest und ähnliches.

Wolfi Gassler (00:18:39 - 00:18:45)

Wie war das jetzt bei deinem Team, wenn du das gerade angewandt hast? Wie viel Prozent hast du für Keep delights on eingerechnet?

Andy Grunwald (00:18:45 - 00:19:00)

Leider viel zu viel. Also mehr als mehr als zwanzig Prozent, weil wir in einer größeren Firma arbeiten, wo wir aktuell sehr viel migrieren von einer alten Infrastruktur, die deprecated ist, von einem anderen Team maintain wird und so weiter. Also da haben wir.

Wolfi Gassler (00:19:00 - 00:19:08)

Moment, aber ist Migration dann schon keep the lights on? Weil Migration ist ja eigentlich, was ein Improvement darstellt, oder?

Andy Grunwald (00:19:08 - 00:19:35)

Es kommt darauf an, was du migrierst. Begriffst du jetzt ein altes Framework auf ein neues und dieses neue Framework hat Performance Verbesserungen und erhöht deine Produktivität später, dann ist das das eine. Sagst du jetzt, okay, du änderst jetzt die Service Discovery API von Consul auf irgendwas anderes, dann hat das ja keinen Feature Mehrwert, sondern es ist einfach nur das gleiche, weil das andere System abgeschaltet wird.

Wolfi Gassler (00:19:35 - 00:19:44)

Okay, also du gehst davon aus, dass du Druck hast, dass du wechseln musst, dass dir das sonst unter dem Arsch weggerissen wird. Dann gibt dir Le, weil sonst sind die Lichter aus.

Andy Grunwald (00:19:44 - 00:19:52)

Ja, weil es immer noch dieselbe Firma ist, wird das nicht einfach so weggerissen, aber dann werden andere Timelines gerissen und dann klopfen da Leute bei dir an. Das willst du ja auch nicht.

Wolfi Gassler (00:19:52 - 00:20:09)

Okay, gut, dann haben wir jetzt da, sagen wir mal, ungefähr zwanzig Prozent oder so veranschlagt. Ich glaube auch, dass es vielleicht eher sogar mehr sein könnten, je nachdem, was man natürlich macht im Team. Was mache ich jetzt mit den restlichen achtzig Prozent? Füße hochlegen finde ich mal gut. Guter Ansatz.

Andy Grunwald (00:20:09 - 00:20:13)

Bier kalt stellen, vielleicht noch eine Gulaschsuppe machen und dann Füße hochlegen.

Wolfi Gassler (00:20:13 - 00:20:20)

Also du plädierst für die Ein tages Woche, nicht die vier Tages Woche, sondern die Ein tages Woche sind ungefähr die zwanzig Prozent.

Andy Grunwald (00:20:20 - 00:21:08)

Ich habe so viele Vorschläge und so viele Ideen, gebe zu, ist vielleicht nicht immer die beste dabei, aber. Nein. Also falls du noch drei weitere Tage arbeiten möchtest, könnten wir eine zweite Kategorie einführen, die würde bedeuten Build new stuff. Und da geht es dann wirklich wir bauen neue Features. Neue Features für unsere Kunden. Und das ist wohl, wo die meisten Software Engineers auch wirklich tagtäglich dran arbeiten. Neue Features bauen, neue Produkte launchen und so weiter. Also wirklich einen Mehrwert für die Firma schaffen und für die Kunden. Und da könnte man sagen, okay, da soll natürlich die Maße der Zeit drauf verwendet werden. Wenn wir jetzt von den ein hundert Prozent ausgeben, haben wir schon zwanzig Prozent für keep the lights on verschenkt. Dann würde man jetzt sagen, okay, für Bild News, da könnte man so circa sechzig Prozent allokieren, weil da ist ja auch wirklich, wo das Fleisch steckt, wo das Geld herkommt.

Wolfi Gassler (00:21:08 - 00:21:12)

Also du meinst jetzt mit sechzig Prozent die sechzig Prozent der verbleibenden achtzig Prozent?

Andy Grunwald (00:21:13 - 00:21:31)

Ja, wie gesagt, Zeiten sind ja immer recht schwierig. Du overcomitest ja in der Regel sowieso, dann geht vielleicht noch, dann ist noch wer krank und so weiter. Deswegen bin ich da nicht so auf diese sechzig und zwanzig Prozent fest, sondern eher akzeptiere in deinem Kopf, dass ein Großteil neue Features sein sollen.

Wolfi Gassler (00:21:31 - 00:21:37)

Okay, bring mir ja neue Kunden. Darum kann man die Kunden ja auch so viel in den Sales Gesprächen versprechen.

Andy Grunwald (00:21:38 - 00:21:45)

Genau, musst du den Vertrieb fragen. Aber da du jetzt der Vertrieb bei deinem side Project bist, wäre das toll, wenn du die drei Features, die du versprochen hast, auch bauen würdest, oder?

Wolfi Gassler (00:21:45 - 00:21:46)

Die bauen ja dann gemeint.

Andy Grunwald (00:21:46 - 00:21:47)

Verstehe, verstehe.

Wolfi Gassler (00:21:48 - 00:22:08)

Okay. Also sechzig Prozent oder der zweite Bucket build new stuff. Ganz klassisch Produkt driven die ganzen Features jetzt bei ganz vielen Firmen hört es eigentlich jetzt schon auf. Also bei ganz vielen Product Ownern, die machen jetzt eigentlich zu. Die sagen, wir haben die neuen Features, wir haben das Nötigste, was zum Betrieb eigentlich verfügbar ist und das war es dann eigentlich jetzt schon.

Andy Grunwald (00:22:08 - 00:23:24)

Ja und das finde ich sehr schade, weil da gibt es nämlich jetzt noch zwei Kategorien, die sprechen mir eigentlich aus dem Herzen. Und das eine ist nämlich existierende Features und existierende Funktionalität verbessern. Da wirklich mit der Priorität auch wieder auf Kunden, da kannst du es so bezeichnen, die Qualität des Produktes erhöhen. Nehmen wir mal zum Beispiel jetzt den Merge Button bei GitHub. Wenn der jetzt ganz oben in der UI einen Pull Request wäre, dann würde ich sagen, was macht der da? Weil du machst ja den Code Review, liest die Kommentare und am ganz unten am Ende der Seite entscheidest du, willst du mergen oder nicht? Da musst du wieder hoch scrollen, den Button, den Merch Button dann ganz nach unten zu verschieben, das wäre dann improve existing stuff, weil da erhöhst du die Qualität des Produktes. Da bügelst du mal so ein UI Fehler aus. Oder andere Beispiele, die mit deinen Sinn kommen, sind so Startseite schneller machen oder die Optimierung des Kunden onboarding. Also wenn du neuen Kunden in dein System. GitHub ist aber außerdem auch ein sehr, sehr gutes Beispiel, weil die bloggen auch sehr, sehr viel über diese kleinen Änderungen. Jetzt haben wir das und jetzt haben wir die UI ein bisschen gestreamlined und so. Also diese ganz kleinen Features, zum Beispiel in ganz vielen Produkten wird jetzt auch Dark Mode eingeführt. Das wäre so eine Verbesserung von vorhandenen Funktionalitäten und da freuen sich ja ganz viele.

Wolfi Gassler (00:23:24 - 00:23:33)

Woher weiß ich denn, ob etwas ein Improvement ist oder eigentlich ein neues Feature? Weil Dark Mode könnte ich ja jetzt sagen, ist eigentlich ein neues Feature, oder?

Andy Grunwald (00:23:33 - 00:23:40)

Was wäre die Begründung, dass Dark Mode ein neues Feature wäre? Es blendet die User bei Nacht nicht und kann deswegen besser den Kaufen Button klicken, oder?

Wolfi Gassler (00:23:41 - 00:23:46)

Ja, ich glaube, dass es in vielen Roadmaps eigentlich als Feature drinsteht und weniger als kleines UI Improvement.

Andy Grunwald (00:23:46 - 00:23:47)

Gib mir eine Begründung.

Wolfi Gassler (00:23:47 - 00:24:01)

Weil wenn du Improvement siehst, irgendwo am bestehenden System etwas zu verbessern, dann sind wahrscheinlich sehr viele Features auch eigentlich nur eine Verbesserung von irgendeinem Workflow oder so. Also wo zieht man dann die Grenze?

Andy Grunwald (00:24:01 - 00:24:36)

Ich würde sagen, wenn es halt keine neue Funktionalität ist. Dark Mode ist für mich jetzt keine neue Funktionalität, aber anscheinend siehst du das anders vielleicht. Ich sage halt, wenn es zum Beispiel, wenn man die Usability ein bisschen verbessert, das wäre jetzt einfach eine Verbesserung und das wäre kein neues Feature, wenn man die Batterie Lifetime eines hardware Geräts verbessert, würde ich auch nicht als neues Feature. Also ich meine, Apple verkauft das als neues Feature, kaufe ich den aber nicht ab in der Hinsicht. Also ich kaufe das Produkt dann schon, aber für mich ist das ein Feature, dass die Batterie Lifetime jetzt zum zwei Stunden Dinge, wenn die Webseite jetzt schneller ist, dann ist das eine Verbesserung.

Wolfi Gassler (00:24:36 - 00:25:06)

Ja, ich hätte gesagt, vielleicht wenn man es auf der Feature Liste auf der Webseite anzeigt, aber auch da könnte man natürlich verbesserte Battery Life auch anzeigen. Also ich glaube, es ist schwierig zu trennen, ist aber auch wahrscheinlich gar nicht so wichtig. Es geht halt darum, dass man da irgendeine Trennung findet und eine Einkategorisierung. Es gibt wahrscheinlich ganz viele Bereiche, die jetzt nicht so klar sind. Muss man sich halt einfach entscheiden. Es geht ja immer bei so einem Framework um eine grobe Einschätzung und weniger um was ganz Hartes, was dann in irgendeiner Formel runtergebrochen.

Andy Grunwald (00:25:07 - 00:25:27)

Ich stelle mal die Gegenfrage bzw. Die Testfrage, welches Problem löst man, wenn man sich jetzt darauf einigt, ob Dark Mode jetzt eine Verbesserung oder ein neues Feature ist? Also wenn du konstant so viel diskutierst, nur um die Dark Mode Zeit dann in einen dieser Buckets zu allokieren, dann würde ich sagen, ganz im Ernst, lass das mit der Roadmap sein, ich glaube, du hast größere Probleme.

Wolfi Gassler (00:25:27 - 00:25:39)

Also man nimmt einfach so ein Label oder ein Post it, je nachdem, wo man arbeitet und klebt da einfach möglichst schnell diese Labels dazu. Und in einem schnellen Prozess einigt man sich da einfach auf irgendwas.

Andy Grunwald (00:25:39 - 00:25:53)

Ich würde jetzt auf das Feature Dark Mode in der Kategorie Zoom jetzt nicht so viel Zeit verschwenden. Wenn du später noch Zeit über hast, dann könnte man darüber noch diskutieren. Aber während du in dem Prozess bist, ist es glaube ich mehr dem Team geholfen, diese Roadmap zu machen.

Wolfi Gassler (00:25:53 - 00:26:02)

Okay, aber spätestens jetzt würde der Product Owner sagen, jetzt haben wir neue Features und alte Features verbessern für den Kunden, aber jetzt ist Schluss.

Andy Grunwald (00:26:02 - 00:27:33)

Genau, und jetzt kommt nämlich die Power der Entwicklung. Und zwar gibt es nämlich noch ein viertes Bucket, das nennt sich die Erhöhung, die Produktivität. Und das ist in der Regel nicht Kunden sichtbar. Das ist oft engineering driven, also für uns alle. Und da geht es zum Beispiel die Erhöhung der Testabdeckung oder die Test Automation, die Verbesserung der Uptime der Webseite oder des Monitorings, damit zum Beispiel bei Keep the lights on später weniger Alerts kriegt, damit man weniger Keep the lights on Zeit allokieren muss. Das wäre zum Beispiel die Erhöhung der Produktivität. Oder ihr setzt Cursor jetzt in der Firma ein und integriert Cursor mit eurem GitHub und allem drum und dran und verwendet da ein bisschen Zeit drauf, damit ihr dann Vibe Coding machen könnt oder was weiß ich nicht. Punkt ist, ihr sorgt dafür, ihr allokiert ein bisschen Zeit, um euch produktiver zu machen. Und dazu zählt unter anderem auch vielleicht technische Schulden abbauen oder diese lange Klasse da endlich mal ein bisschen aufsplitten oder nutzbar machen oder, oder oder. Sollte natürlich dann schon euch wirklich, ich sage mal, produktiver machen. Denn nur Refactoring des Refactorings wegen, hatten wir ja auch schon mal drüber gesprochen, bringt es halt auch nichts, wenn es euch nicht kurz, mittel oder langfristig schneller in der Arbeit macht. Wenn ihr zum Beispiel Arbeit ins Alerting steckt und das Alerting somit genauer wird und ihr euch deswegen zehnmal weniger gepaged werdet. Das würde ich sagen, ist ein mega Boost. Nicht nur für die Produktivität, weil ihr dann weniger an den Computer müsst, sondern auch für die mentale Gesundheit, würde ich mal sagen.

Wolfi Gassler (00:27:34 - 00:28:01)

Jetzt habe ich da meine vier Buckets und versuche mein Planning anhand dieser vier Buckets zu machen. Jetzt habe ich aber ganz klassisch in meiner Firma vielleicht OK oder irgendein anderes Framework schon im Einsatz, also was auf höherer Ebene das Ganze auch koordiniert. Funktioniert es im OKR Setting? Kann ich sowas einsetzen in einem OKR Setting oder in einem anderen Space als Methode noch? Also spielt es in irgendeiner Form zusammen?

Andy Grunwald (00:28:01 - 00:28:27)

Ja, ich denke nicht, denn ich kann jetzt relativ wenig zu Space selbst sagen, aber OKR oder shape up oder ähnliches, das sind ja alles nur irgendwelche Frameworks, die Ziele vorgeben und dann gegebenenfalls noch einen Zeitrahmen obendrauf setzen. OKR setzt irgendwie wir wollen jetzt die Kundenbindung erhöhen oder wir wollen fünfzig neue Kunden haben. Aber wie die ganze Sache thematischen umgesetzt wird und auch womit, womit wäre dann in diesem Fall, welche Features bauen wir? Das entscheidet ja immer noch das Team bzw. Der Product auch noch.

Wolfi Gassler (00:28:27 - 00:28:28)

Also passt schon zusammen.

Andy Grunwald (00:28:29 - 00:28:49)

Achso, ja, also ja, schon irgendwie, aber es ist jetzt nicht relevant, ob du OKRs nutzt oder Scrum oder ShapeUp oder VMoms oder ob sich der Chef einmal im Jahr irgendwo auf die Bühne stellt und sagt unser Jahresziel sind ein hundert Kunden und er das dann Chef Framework nennt. Also das ist ja egal, das ist ja die Zielsetzung.

Wolfi Gassler (00:28:50 - 00:29:10)

Okay, also ich kann das auch, wenn ich OKRs verwende, kann ich das genauso einsetzen in meinem Planning dann. Ich muss natürlich das, was von oben kommt, die Ziele, die Richtung, in die ich gehen will, beachten. Aber wie ich dann in diese Richtung gehe, in welche Schritte habe ich immer noch meine vier Buckets und meine vier Buckets zur Verfügung, um eben die Ziele zu erreichen.

Andy Grunwald (00:29:10 - 00:29:34)

Da hoffe ich, dass die Teams diese Freiheit haben. Wenn nicht, dann sollte man das OK Framework vielleicht noch mal durchlesen. Und dasselbe passiert ja auch mit Scrum zum Beispiel. Wenn du sagst okay, mein Team arbeitet in Scrum, ist ein zwei Wochen Sprint. Ich meine, die Sachen, die du da selektierst, die du bauen möchtest, kannst du ja trotzdem in Milestones unterteilen. Die kannst du trotzdem sprintable machen. Gibt es das ich mache was sprintable, dass das in zwei Wochen passt?

Wolfi Gassler (00:29:34 - 00:29:53)

Aber ja, Scrum wäre ja eigentlich eine Ebene darunter. Also ich mache mein Quarterly planning zum Beispiel jetzt mit meinen vier Buckets, einfach um, um eigentlich die Zeitallokation irgendwie zu schaffen überhaupt, um nicht ständig over commitment zu betreiben. Und danach kommt eigentlich erst Scrum ins Spiel darunter, eine Ebene darunter.

Andy Grunwald (00:29:53 - 00:31:05)

Ja, ich teile diese Art von Frameworks und jetzt völlig egal, ob wir über OKRs, Shape up, scrum kann man usw. Sprechen, halt immer nur in zwei Themen ein. Die eine Thematik ist okay, an was arbeite ich? Das Zielsetzungs Frameworks. Was ist das Ziel, was mein Chef mir vorgibt, mein Management vorgibt, die Firma erreichen möchte und so weiter. Und dann die andere in welchen Rhythmen arbeite ich? Bei Kanban ist es ich pull mir immer ein Ticket und bei Scrum sind es dann irgendwie die Sprints. Bei Shape Ups sind es, glaube ich, sechs Wochen Cycles. Also das ist ja dann eher nur der zeitliche Horizont. In welchen Zyklen arbeite ich? Und das andere ist, an welchem Ziel arbeite ich? Und dieses Framework, was wir hier erzählt haben mit keep the lights on, build new stuff, improve existing stuff und increase your productivity. Das ist ja eher daran woran arbeitet man und wie allokiert man es und wie hält man auch eine Balance dazwischen, zwischen den einzelnen Aufgaben? Weil wie du sagtest, die meisten Product Owner, die knallen da einfach ein hundert Prozent der Zeit für neue Features rein. So, dann kippt die Infrastruktur hinten rüber und dann wird das, dann fragt man sich nach zwei Jahren, wieso wird das Team immer langsamer und so weiter und so fort. Und mit diesem Framework versuchst du halt, ich sag mal, ein Gleichgewicht zu halten. Ich finde, das habe ich schön gesagt.

Wolfi Gassler (00:31:05 - 00:31:44)

Aber meine Frage wäre ja jetzt, jetzt habe ich meine vier Buckets und habe da irgendeine Prozentzahl dran geschrieben. Also zwanzig Prozent Produktivity, zwanzig Prozent Improvement, sechzig Prozent neue Features und dann natürlich keep the lights on. Da kann man keine Prozentzahl dazuschreiben, weil die muss man sowieso immer machen. Also den verbleibenden Zeitraum teile ich dann ein in sechzig, zwei tausend zwanzig zum Beispiel. Und jetzt habe ich da auf meinem Whiteboard die Labels dazu gehängt. Was ist Improvement? Was ist New stuff? Was ist Productivity? Aber jetzt schaue ich in meine Buckets und in meine Kübel. Heißt es bei euch Kübel oder Eimer? Eimer ist Deutschland, oder? Wir sagen Kübel.

Andy Grunwald (00:31:44 - 00:31:48)

Ein Kübel ist eher so wie ein Blumenkübel, aber ein Backen wäre eher ein Eimer.

Wolfi Gassler (00:31:48 - 00:32:14)

Okay, ja, also bei uns ist es kübel in Österreich. Jetzt habe ich da meine vier Kübel. Da haben wir nicht unendlich Projekte Platz. Also ich habe jetzt ganz viele gelabelte Tasks, Projekte, Initiatives, wie du sie auch immer nennst, aber nur einen begrenzten Space durch die Prozentzahl von meinen Kübeln oder Eimern. Also wie wähle ich danach aus, was kommt jetzt in meine Eimer? Also das löst mir noch gar nichts. Ich habe zwar jetzt eine begrenzte Kübelgrösse, aber immer noch zu viel Arbeit.

Andy Grunwald (00:32:14 - 00:33:52)

Ja, hätte ich darauf die Allerweltslösung, dann würde ich nicht mit dir Podcast machen, sondern wäre nämlich sehr reich. Weil im Endeffekt ist es das wieder. Okay, was ist mir wichtig genug und was hat den größten Impact? Also an diese Frage bin ich dann auch gekommen, nachdem ich diese Framework gefunden habe. Und da bin ich mal mit dem Hund spazieren gegangen und dann sind mir ein paar Fragen eingefallen, die ich mir zumindest so gestellt habe, so Leitfragen. Und zwar sind das zwei Bereiche. Einmal pro Planung, Cycle, habe ich mir die Frage gestellt, also für das Quartal jetzt, was sind die ein oder zwei Dinge, die ich wirklich vorantreiben möchte? Also wo machen wir, wir als Team wirklich einen Unterschied? Stell dir vor, du bist jetzt ein Produktteam und du hast fünf große Baustellen. Jetzt kannst du sagen, ich arbeite an diesen fünf großen Baustell ganze Quartal und treib jede Baustelle zwanzig Prozent nach vorne. Im Endeffekt ist dann jeder irgendwie unglücklich, weil niemand das gekriegt hat, was er haben wollte, weil alles nur zwanzig Prozent nach vorne geschoben. Oder du stellst dir die was sind die ein oder zwei Dinge, die du wirklich vorantreiben möchtest und limitierst deine Arbeit auf ein oder maximal zwei Dinge. Und schiebst ein Ding um ein hundert Prozent nach vorne oder zwei Dinge um fünfzig Prozent nach vorne, werden Leute schreien. Ja, natürlich, weil drei Leute sind ja hinten rübergefallen, die werden nichts kriegen. Das ist richtig, aber es bringt ja nichts, wenn du alles um zwanzig Prozent nach vorne schiebst. Deswegen, das ist hart, das kann dir keiner abnehmen. Da muss man wirklich gucken, okay, was hat den größten Impact? Da würde ich mal sagen, wenn du ein ganz klassisches Produkt hast, was benutzen deine Kunden, wie sehen deine User Metriken aus? Und so weiter und so fort. Oder was sind deine Profit Margins für diese Produkte und für diese Bereiche? Also ganz, ganz wirtschaftlich einfach mal daran.

Wolfi Gassler (00:33:52 - 00:33:56)

Aber du hast jetzt gesagt, pro Planung Cycle müsstest du es nicht pro Kübel machen.

Andy Grunwald (00:33:56 - 00:34:21)

Kann man auch. Hoffentlich hast du aber die Elemente, die in dein Kübel sind, haben Synergien. Also ich hoffe nicht, dass du. Also im perfekten Fall hast du bei increase productivity Sachen drin, die das Monitoring oder die Uptime verbessern. Um einfach mal bei dem Beispiel zu bleiben für Zeug, was du vielleicht sogar verbessern möchtest oder wo du ein neues Feature drauf bauen möchtest mit you build stuff.

Wolfi Gassler (00:34:21 - 00:34:41)

Ja, aber die Gefahr besteht ja, wenn du jetzt sagst, die zwei Dinge, die uns wirklich vorantreiben, dann kommen da zwei Features, weil die bringen uns wirklich voran mit ganz großen neuen Kunden. Und dann hebelst du ja deine eigenen Buckets wieder aus eigentlich, wenn du dann nur zwei Features machst, wenn das wirklich die wichtigsten sind. Also müsstest du das ja eigentlich wirklich pro bucket machen.

Andy Grunwald (00:34:41 - 00:35:11)

Ja, was ich mit Bereiche meinte ist eigentlich dein Team ist jetzt das Member und Retention Team. Das bedeutet, das Member und Retention Team kümmert sich um den User Login, um das Profil, um den Newsletter und all sowas. Jetzt kannst du verbessere ich jetzt die Login Maske und die Registrierungsmaske, ich verbessere den Newsletter, ich verbessere das Edit my Profil feature und ich verbessere die Bonuspunkteanzeige. Oder du kannst sagen, ich kümmere mich jetzt einfach nur um den Newsletter. Ein Quartal brauche ich den richtig aufbringen, richtig nach vorne.

Wolfi Gassler (00:35:11 - 00:35:14)

Ja, aber dann hättest du ein hundert Prozent Improvement.

Andy Grunwald (00:35:14 - 00:36:49)

Nein, komm mal aus deinen Kübeln da wieder raus. Es geht ja nicht. Zum Beispiel nehmen wir ein Plattformteam. Ein Plattform Team managt ein Kubernetes und ein Plattformteam managt die Docker Registry. Und ein Plattform Team managt sogar noch ein Interface, wo du neue Cron Jobs eingeben kannst und so weiter und so fort. Jetzt kannst du okay, das Plattform Team packt jetzt die einzelnen Tasks, die in deinem Bucket sind build new stuff, improve existing stuff, increase your productivity und so weiter und fokussiert sich einfach nur auf Kubernetes. Increase your productivity. Die bauen sich Tooling, um neue kubernetes nodes in den Cluster zu hängen und alte zu drainen. Sieht kein Kunde, aber dafür können die Nodes rein und rausnehmen ohne Probleme und ohne die Produktionsworkloads anzupassen. Improve existing stuff. Jede neue Applikation, die auf dem Kubernetes Cluster jetzt gelauncht wird, kriegt automatisch ein Sidecar daneben, der die Ressourcen anhand der Usage immer updated. Keine Ahnung, dein Java Prozess braucht acht GB RAM, der knallt immer zwei GB RAM drauf. Oh, der braucht auf einmal zehn, dann updatet er sich automatisch zwölf. Und committee sogar noch in Git. Das wäre jetzt improve existing stuff. Und build new stuff wäre dann jetzt zum Beispiel jede App, die im Kubernetes gelauncht wird, kriegt automatisch ein fertiges Grafana Dashboard. Dadurch wurde dann zum Beispiel jetzt die Funktionalität Cron Jobs vernachlässigt. Aber du hast verschiedene Aufgaben in verschiedenen Buckets, die alle aber auf ein großes Ziel einzahlen, dann die kubernetes Plattform jetzt nach vorne treiben. Das meinte ich eigentlich mit was sind die ein oder zwei Dinge, die wir vorantreiben und nicht was sind die ein, zwei Dinge in deinem Bucket? Improve existing stuff. Bucket.

Wolfi Gassler (00:36:49 - 00:38:35)

Okay, wenn du so übergreifende Projekte hast oder Bereiche, dann ging das natürlich. Das stimmt. Ich glaube auch da, ich habe jetzt erst über die POs immer so geschimpft oder halt mich lustig gemacht. Die POs sind ja eigentlich Leute, die gerade wenn es um Priorisierung geht, eigentlich normalerweise super Fähigkeiten haben. Die kennen ja viele Frameworks. Also das Rise Framework ist eines, was recht bekannt ist. Moskau, wo es einfach darum geht, ich teile meine ganzen Initiativen, meine Features noch mal ein und betrachte einfach, was bringt uns am meisten weiter? Genau wie du es jetzt gesagt hast, das ist halt dann mathematisch noch wie viel Impact haben wir dadurch? Wie konfident sind wir zum Beispiel, dass wir irgendwas erreichen? Und dann gibt es eine Formel, am Schluss kommt noch ein Wert raus oder ich habe da Matrizen, wo ich das eintrag. Ist ja ganz egal, was eigentlich. Aber ich habe Priorisierungsmöglichkeiten und vielleicht kann mir der DPO wirklich in dem Bereich dann helfen. Also wie kann ich in einem Bucket oder auch übergeordnet über alle Buckets, je nachdem, wie die Initiativen oder oder Tasks aufgeteilt sind, wie kann ich die dann priorisieren? Aber der große Vorteil bei den Buckets ist ja, dass ich mir am Anfang einmal überlege, wie viel Prozent kann ich für Produktivitätstasks verwenden und dann steht es mal fest, weil sonst muss man ja immer diskutieren, ist das Feature wichtiger oder ist die Produktivität wichtiger? Und so habe ich schon mal im Vorhinein aufgeteilt anhand von Prozenten und kann danach innerhalb von dem Bucket zum Beispiel diese ganzen Priorisierung Frameworks wie Rise oder Moskau oder Eisenhower Matrix, um ein ganz simples Ding zu erwähnen, einfach anwenden. Wenn es natürlich übergeordnete Initiativen sind, kann ich das auch vor der Bucket Einordnung eigentlich. Und dann sind wir wieder bei deinen finde die zwei Initiativen, die uns am weitesten weiterbringen.

Andy Grunwald (00:38:35 - 00:39:52)

Ich finde, dieses Framework nimmt halt super viel Spannung aus der ganzen Thematik, denn ich habe auch Product Owner gesagt, ne, wir haben keine Zeit da jetzt irgendwie unsere Produktivität zu verbessern und dann hat man da relativ wenig irgendwie Gegenwehr. Ich meine natürlich, dieses Framework muss natürlich auch vom Management getragen werden, das muss sinnhaftig sein. Ich meine im Endeffekt, wenn ein Schreiner die ganze Zeit nur an Möbeln arbeitet und das Werkzeug nie sauber macht und das Werkzeug nie wegräumt und das Werkzeug nicht kontrolliert, ob es noch gut ist, dann leidet die Produktivität nämlich später auch. Und unter der Produktivität leidet dann natürlich dann auch sein Bestellvolumen, weil auf einmal der Bohrer kaputt ist und er keinen Ersatzbohrer da hat und deswegen neue Bohrer bestellt werden müssen und deswegen dauert der Schrank jetzt eine Woche länger, weil Amazon die Bohrer gerade nicht vorrätig hat und so weiter und so fort. Sie ist ja genau dasselbe. Und jetzt ein Thema noch mal zu dem, was du gesagt hast. Was ist denn, wenn ich pro Bucket ganz viel Sachen habe? Weil wenn du jetzt dein aktuelles Backlog einfach kategorisiert, dann laufen die Kübel, wie du sie schön nennst, auch über. Da kannst du dir natürlich auch relativ einfache Fragen stellen. Und die habe ich nämlich für jede dieser Initiative in den einzelnen Eimern gestellt und die habe ich auch aufgeschrieben. Was ist das Problem, welches wir lösen wollen? Also das Aka, warum macht es überhaupt Sinn, dieses Ticket, dieses Projekt oder so zu machen?

Wolfi Gassler (00:39:52 - 00:40:05)

Moment mal, bevor du da jetzt in die Tiefe gehst, das nennen wir Andi Framework, oder? Also da gibt es Moskau und Rise und dann gibt es Andy. Andy, du musst dann noch Akronyme dafür finden. A, N D Y, ne, vielleicht nennen.

Andy Grunwald (00:40:05 - 00:40:20)

Wir es einfach nur logisch denken. Auf jeden Fall schreibst du einfach. Ich meine, hoffentlich ist dein Ticket oder dein Projekt oder das, was du da in deinem Kübel hast, bereits schon so geschrieben, denn wir schreiben ja alle ordentliche Tickets und Design Dokumente und allem drum und dran. Richtig, Wolfgang?

Wolfi Gassler (00:40:21 - 00:40:24)

Natürlich, natürlich ist alles schon im Andy Framework kategorisiert.

Andy Grunwald (00:40:24 - 00:41:37)

So, also kannst du eigentlich musst du in der Lage sein, folgende drei Fragen für jedes dieser Dinge zu beantworten. Was ist denn eigentlich das Problem, welches wir lösen? Aka warum machen wir das? Wie sieht Erfolg aus bzw. Wie wird Erfolg gemessen? Das könnte sein, dass das seine Definition of Done ist. Definition of Done finde ich aber immer so ein bisschen kurz gegriffen, denn Definition of Done ist, was wir am Ende haben und nicht wie man dann Erfolg misst. Wir wollen ja den outcome messen und nicht den output. Output ist ich habe einen pull request gemacht und ich habe die farbe geändert. Ein outcome ist durch die geänderte buttonfarbe gibt es fünf prozent mehr bestellungen und wir wollen den outcome messen. Und die dritte Frage ist, wenn das nämlich ein sehr großes Projekt ist und gegebenenfalls über mehrere Quartale geht, würde man sagen, was werden wir dieses Quartal erreichen bzw. Was werden wir dieses Quartal genau tun? Und das ist halt sehr sinnvoll bei Multi Quarter Projekten. Und so stellt man halt sicher, dass man kleine erreichbare Milestones und an alle Hörerinnen und Hörer, die uns gerade zuhören, der Wolfgang hat gerade in unserem Vorbereitungsdokument diesen Text markiert. Er wird ihn mit hoher Wahrscheinlichkeit jetzt gerade bei ChatGPT reinpacken und nach einem Akronym fragen. Was kann man daraus machen? Ein Beispiel wäre Space Rise. Und was kam da raus, Wolfgang?

Wolfi Gassler (00:41:37 - 00:42:07)

Es ist unglaublich. Du kannst es scheinbar wirklich vorhersagen. Also das andere Framework sagt Auftrag klären, Nutzen definieren, dieses Quartal im Fokus, also d schräg und Wort Etappenziel setzen. Okay, das ist eine kreativ, aber ich glaube, das ist Deutschland eigentlich nur ein bisschen ein Problem, aber ja, knapp dran. Vielleicht muss man da noch ein bisschen feilen am andi Framework.

Andy Grunwald (00:42:07 - 00:43:04)

Naja, aber kommen wir noch mal zu dem andi Framework und zu der ersten Frage was ist eigentlich das Problem, was wir lösen? Und Achtung, ich bin dann mit sehr vielen Leuten ins Gespräch gegangen und du glaubst gar nicht, wie viel Tickets und wie viel Initiativen dann da rausgefallen sind, weil man mir das Problem nicht erklären konnte, welches wir lösen. Und mit Problemen meine ich nicht immer wirklich ein Problem, was wir haben, sondern eigentlich einen Sinn, einen Grund, warum wir das tun sollten. Ich hatte ja gerade gesagt Updaten des Updatens wegen der saubere Software Engineer sagt Jo, updaten ist immer gut, der Produktmensch. Warum tun wir das? Und die Wahrheit liegt wahrscheinlich irgendwo in der Mitte, weil ist die Version end of life? Gibt es da ein Sicherheitsproblem? Ist die Version vielleicht eine LTS Version? Da gibt es ja so viel drumherum, was man klären sollte. Aber das ist faszinierend. Viele man müsste man Dinge machen wir, weil wir denken, sie sind richtig, aber haben die irgendeinen Wert? Oft glaube ich nicht, zumindest nicht fürs Produkt oder für das Ziel der Firma.

Wolfi Gassler (00:43:04 - 00:43:09)

Sollte man, glaube ich, in side Projects auch immer überlegen. Die Frage vergisst man eigentlich ganz oft.

Andy Grunwald (00:43:09 - 00:43:19)

Naja, side Project ist ja die Frage okay, warum mache ich das hier? Also Motivation, weil ich weiß, ich habe super viele side Projects gestartet, um was Neues zu lernen.

Wolfi Gassler (00:43:19 - 00:44:46)

Ja, aber da hast du ja auch Ziele. Du musst immer schauen, zahlt dieses Ziel, zahlt dieses Ziel, zahlt dieser Task dem Ziel ein? Und wenn das Ziel Learning ist, ist es natürlich was anderes, als wenn das Ziel ist, ich bringe das Produkt online oder ich möchte dann auch mal Kunden bekommen oder was es dann auch immer ist. Also das sollte man im Auge behalten. Auf jeden Fall. Aber jetzt sind wir der Podcast mit den Praxistipps. Jetzt haben wir ja schon quasi ein Framework geliefert, wo man als Engineer und Entwicklerin vielleicht mehr von den eigenen Lieblingsprojekten reinbringen kann dadurch Keep Delights on ist natürlich ganz klassisch Techn und auch die Productivity, dass man da schon Kübeln zur Verfügung hat. Aber ein anderes sehr häufiges Problem, was in der Praxis auftritt, ist, dass man ganz kleinteilige Tasks, Verbesserung Tasks hat, die dann in diesem Kübel landen. Der Kübel geht über. Sagt man bei euch auch geht über oder ist das nur deutsch oder ist das auch schon österreichisch? Ne, er läuft aber siehst du, bei uns geht er über völkerverbindender Podcast. Also der Kübel läuft über, der Eimer läuft über, der Kübel geht über. Und dann fallen natürlich diese kleinteiligen Tasks natürlich weg, weil die anderen großen sind viel wichtiger. Aber man könnte auch sagen, diese feinen, diese vielen kleinen Tasks sind natürlich auch irgendwie sinnvoll und müssen vielleicht in irgendeiner Form erledigt werden. Und nachdem Andy uns ja schon das Andy Framework jetzt quasi geboren hat, hat er darauf sicher auch eine Antwort, oder?

Andy Grunwald (00:44:46 - 00:45:11)

Ich habe da auch eine Antwort, aber die kommt nicht von mir. Die ist aber auch bei der Recherche von diesem ganzen, von dieser ganzen Thematik hier aufgekommen. Und zwar nennt sich das Paper Cuts. Kleine Fixes mit großem Effekt. Also stellt euch vor, einfach, ihr habt ganz viele Dinge, die zwar nie kaputt waren, aber ihr trotzdem jedes Mal stöhnt, wenn sie euch begegnen. Also wachsender Haufen kleiner täglicher Ärgernisse.

Wolfi Gassler (00:45:11 - 00:45:22)

Also vielleicht die Paper Cuts, falls es jemand nicht kennt. Es gibt ja diesen Spruch Tod der ein hundert, ein tausend Paper Cuts oder ein tausend Paper Cuts. Gibt es das auf Deutsch eigentlich?

Andy Grunwald (00:45:22 - 00:45:30)

Ich kenne das auch nur unter Death by Paper. Ja, Death by Thousand Paper Cuts kenne ich nur.

Wolfi Gassler (00:45:30 - 00:45:41)

Aber wer sich mal mit einem Papier geschnitten hat, so zwischen den Fingern idealerweise, der weiß, wie schmerzvoll das ist, wenn man das mal ein tausend multipliziert. Die ganzen kleinen Bugs, die tun halt auch weh. Daher kommt es.

Andy Grunwald (00:45:41 - 00:48:37)

Und das ubuntu Projekt, also die Linux Distro, hat zwei tausend neunzehn Mission Paper Cuts ausgerufen. Und zwar wollten sie ein hundert Paper Cut bugs in einem Release beheben. Und was ist ein Papercut? Ein Papercut ist etwas, wo ein kompetenter Programmierer nicht länger als einen Tag pro Bug braucht. Und deren Ziel war halt, ein hundert Paper Cuts in einem Release zu fixen. Da gibt es sogar einen Wikipedia Artikel zu. Finde ich auch geil, dass so eine Open Source Mission für den Release auch ein Wikipedia Artikel kriegt. Und dieses Konzept selbst hat GitHub dann irgendwann mal auch übernommen. Ihr wusstet, ihr erinnert euch sehr wahrscheinlich noch, GitHub wurde ja von Microsoft gekauft und danach wusste man gar nicht, was passiert da jetzt und so weiter und so fort. Und dann gab es noch mal auch eine Initiative, die nannte sich dir GitHub. Also liebes GitHub, ich hab da mal ein Anliegen. Wo dann ein Repository erstellt wurde und ganz viele Issues erstellt wurde über diese kleinen Paper Cutscenes, weil wir wissen ja alle, wir sind sehr eigen, wenn ein Button verschoben wird. Und diese kleinen Papercuts findet man auf GitHub überall. Und GitHub hat sich dieses Mission Paper Cuts von Ubuntu genommen und einfach mal gemacht. Und zwar sind die in dieses DIR GitHub Repository gegangen, haben das priorisiert und haben dann diese kleinen Issues einfach mal behoben. Und die sagten, das war super, denn die sind immer hinten rüber gefallen, die waren nie wichtig. Und was die jetzt gemacht haben, die sagten, hey, pass mal auf, das fixen dieser Paper Cuts ist kein Zeit Hassel, das machen wir nicht, wenn mal Zeit ist, sondern die haben das als großes Projekt gemacht. Das war deren Erfolg. Auf Basis von jedem Paper Cut, den die gefixt haben, da haben die Social Media gemacht, die haben das auf ihrem Blog gepostet, einfach nur eine kleine Newsmeldung, hey Jungs und Mädels, wir haben jetzt diesen Button grün gemacht und so weiter. Und warum hat die ganze Thematik funktioniert? Aus drei Gründen. Sie haben daraus wirklich ein Projekt gemacht und das nicht einfach zur Seite geschoben. B die haben bewiesen, dass sie dann der Community auch zuhören. Und der Community, das sind ja im Endeffekt ihre Kunden, wenn man so möchte. Und c weil man jetzt natürlich kontinuierlich diese kleinen Bugs vorgehoben hat, hat man Momentum aufgebaut. Und das ist, glaube ich, ganz wichtig, dass man natürlich auch den Software Engineers, dem eigenen Team zeigt, okay, wir kümmern uns wirklich darum und wir hören auch zu. Sehr, sehr schöne Story, wie ich finde. Und das könnt ihr natürlich auch adaptieren. Also ihr könnt einfach mal sagen O okay, wir sammeln jetzt einfach mal diese kleinen Bugs, die mir einfach immer auf die darf ich auf den Sack gehen? Auf die Nüsse gehen? Auf die Nerven gehen? Auf die Nerven gehen, sagt man hier, glaube ich jetzt. Und dass man, dass man die vielleicht sammelt und vielleicht habt ihr ja dreiig Paper Cuts, dieses man müsste mal, ich müsste das mal beheben, aber. Und dann könnt ihr das auch so eintüten und dann kriegt das vielleicht in improve existing stuff unter in the bucket.

Wolfi Gassler (00:48:37 - 00:48:48)

Also es ist so was ähnliches wie was zur finanzkrise zwei tausend acht geführt hat oder wo man die ganzen faulen kredite in so pakete geht, gepackt hat in große, dass man sie nicht mehr gesehen hat und die hat man dann verkauft.

Andy Grunwald (00:48:48 - 00:48:59)

Aber die faulen Kredite wurden ja dadurch nicht besser. Also wenn du den Paper Cut löst, kannst du dich ja nicht mehr an dem Papier schneiden. Also ist das ja eine Verbesserung. Und ich wüsste nicht, wie das jetzt mit einem vollen Kredit in einem neuen Format.

Wolfi Gassler (00:48:59 - 00:49:12)

Okay, also wir nehmen nur das Paketieren davon, dass man Pakete schnürt, um dann ein größeres Projekt zu haben, was nicht automatisch so schnell verdrängt wird und das Ganze auch noch marketingmässig gut vermarktet wird am Ende. Vielleicht für den User ideal.

Andy Grunwald (00:49:13 - 00:49:57)

Du sagst das so salopp. Ich denke wirklich, dass das der essentielle Erfolg war, dass du okay, du hast eine ganz kleine Sache gefixt und du machst einen Tweet darüber. Und das sehe ich auch bei ganz vielen side Projects so. Diese ganzen Indie Hacker, die machen zum Beispiel immer so Weekly Logs oder die schippen eine Sache und machen einen LinkedIn Post. Da denkt man sich, ist ja lächerlich, ne? Aber das hält das Momentum hoch, das hält die Traction hoch und auch mein Vertrauen zum Indie Hacker wird dadurch irgendwie gesteigert. Ich weiß nicht warum, aber ich finde das super, weil ich denke mir hey, das aktive Entwicklung hinter verlinken wir auf jeden Fall in den Shownotes einmal die ein hundert Paper Cuts Mission von Ubuntu, einmal eine Papercut Wikipedia Artikel und natürlich das GitHub Repository und die Story von GitHub.

Wolfi Gassler (00:49:57 - 00:51:14)

Das heißt, das nächste Mal, wenn ihr wieder in so einem Planning steckt oder auch euer side Project plant, dann versucht mal diese ganzen Frameworks anzuwenden. Also vom Matt Ecclestone von Dropbox, der die vier Buckets definiert hat, dann als Andy Framework natürlich dann, um innerhalb von den Buckets zu optimieren und zu sortieren. Und wenn ihr wirklich ganz viele kleine bugs habt, die alle kleine Papercuts sind oder eigentlich das Papier ist, das schneidet, dann versucht mal das Ganze zu paketieren. Und ich glaube, da sind paar ganz coole Ansätze dabei, wo man dann das einfach mal ausprobieren kann und auch ganz lightweight einführen kann. Also da braucht es keine große Firmenumstellung, irgendwie großen Support von der obersten C Ebene. Das kann man wirklich im Team einführen. Natürlich braucht Support schon vom Product owner Seite, von den ganzen Leuten im Team. Also auf der Ebene muss natürlich schon das Commitment da sein, aber es ist jetzt kein Framework, was man irgendwie firmenweit einführen muss. Das kann man einfach mal ausprobieren, losstarten. Auch das Paketieren der Papercuts ist kein Problem. Das kann man einfach mal vorschlagen und eine coole Initiative draus machen, wo dann vielleicht auch alle Mitwirkenden Spaß dabei haben, irgendwie veröffentlichen kann jeden Tag, was man cooles erreicht hat. Also das ist motivationstechnisch sicher auch ein guter Ansatz, den man einfach mal ausprobieren kann.

Andy Grunwald (00:51:14 - 00:52:38)

Ihr könnt auch noch kleiner starten. Ihr könnt zum Beispiel diese vier Buckets einfach mal auf einen Scrum Sprint anwenden. Angenommen eure Sprintlänge ist zwei Wochen, plant doch einfach den Sprint einfach mal innerhalb dieser vier Buckets. Und bezüglich der Kommunikation nutzt doch einfach euren internen Slack Channel oder vielleicht den Engineering Slack Channel oder den random Slack Channel oder was auch immer ihr da habt. Oder vielleicht habt ihr eine interne Blogging culture oder so einen internen Mastodon Server oder ähnliches in eurer Firma. Was ich euch sagen kann, wenn ihr das auf großem Stil ausrollen wollt im Quartal und echt viele Initiativen habt, diese was ist eigentlich das Problem, welches wir lösen wollen? Wie sieht Erfolg aus? Wie messen wir Erfolg und was erreichen wir dieses Quartal? Das ist schon, also mich hat das schon ein paar Stunden gekostet und man muss sehr viel nachdenken. Man hinterfragt sich auch konstant, ist das jetzt wirklich das Problem, was wir lösen? Aber das tolle dabei ist, wenn ihr das einmal habt, also bei mir kann jetzt zumindest für dieses Quartal kann jetzt jeder VP um die Ecke kommen und ich habe sofort antworten parat. Und man fängt nicht an zu stammeln und man kann wirklich sagen, welches Problem man denkt zu lösen. Ob die Person, die mich dann challenge, dann sagt, das ist ein Problem, das ist dann immer noch was anderes. Aber das ist dann natürlich eine andere Sichtweise aus einer anderen Flughöhe. Aber startet klein, quatscht einfach mit eurem Scrum Master, mit eurem Projektleiter, Vorgesetzten oder ähnliches. Einfach mal, ob ihr das nicht vielleicht auf einen im nächsten Scrum Sprint ausprobieren wollt.

Wolfi Gassler (00:52:38 - 00:53:04)

So und nachdem das schon so gut geklappt hat mit den Akronymen, jetzt kommt das Ende von dem Podcast. Also denkt daran, das Kiosk Framework zu verwenden. Also einmal klicken und teilen. I ins Gespräch kommen, bei uns in der Discord Community vorbeischauen. Oh, wie offenes Feedback geben. Sag, was du von dieser Episode hältst. S wie Sterne da lassen in deiner Podcast App. Spotify, Apple und was es sonst noch so gibt. Und K kurzes Review schreiben, besonders auf.

Andy Grunwald (00:53:04 - 00:53:21)

Apple kurzes Review schreiben. Ja, wundervoll. Ich hasse zwar Abkürzungen, Akronyme, weil ich muss immer fragen, was heißt aber das Kiosk Framework werden wir natürlich auch veröffentlichen. Kriegen wir auch ein Logo dafür, Wolfgang?

Wolfi Gassler (00:53:21 - 00:53:34)

Ja, bekommen wir vielleicht hin. Und zum ins Gespräch kommen, wer irgendwie Ideen hat, wie man das Andy Framework besser noch umsetzen kann, akronym technisch, bitte natürlich uns auch wissen lassen, am besten auf Discord.

Andy Grunwald (00:53:34 - 00:54:16)

Aber jetzt, jetzt mal ohne Flachs. Mich interessiert auch wirklich, wie ihr eigentlich eure Produktivitäts Tasks bei euch in die Arbeit mit einplant. Kommt einfach mal in die Discord Community vorbei oder schreibt uns über Mastodon und lasst es mich wissen. Mich würde wirklich interessieren, wie schafft ihr es, euren Product Owner oder euren Engineering Manager oder euer Management zu überzeugen, dass ihr jetzt mal ein bisschen was für eure Team Produktivität tun müsst oder das Alerting anpassen muss oder oder. Weil das ist ja immer wieder eine Herausforderung. Mich wird paar Antworten von euch freuen. Ansonsten hoffen wir natürlich, dass ihr etwas Inspiration mitgenommen habt. Würde ich sagen, viel Spaß beim Testen. In den Shownotes findet ihr alle Links. Bis zur nächsten Episode und tschüss.