https://videos.devteams.at/about/instance/homehttps://videos.devteams.at/videos/browse?scope=localhttps://videos.devteams.at/homehttps://videos.devteams.at/w/c69FzbsWxoTfR2fDFTwUiPhttps://videos.devteams.at/lazy-static/thumbnails/c23a157f-cffe-4b8d-87eb-7e57ea038b34.jpgIntro: Quick Glance At: Agile EngineeringWebseite: https://quickglance.at/https://videos.devteams.at/static/streaming-playlists/hls/59cc9841-c09f-43a7-8088-fb178b36aad9/7080741e-e1fe-4170-8abd-b2ae9cafdf3f-master.m3u8https://videos.devteams.at/videos/embed/c69FzbsWxoTfR2fDFTwUiP890152024-02-12T14:48:19.175ZYESquick_glance_at_agile_engineeringNOhttps://videos.devteams.at/w/bgUy4HBv8LycLd5dXfPDtVhttps://videos.devteams.at/lazy-static/thumbnails/669c391e-2b1d-4df0-8d62-5f17d8b90b0e.jpgKapitel 01: Warum Agile Engineering?Der Überbegriff "Agile Engineering" beschriebt Praktiken und Vorgehensweisen, die uns dabei helfen, die Ziele der agilen Softwareentwicklung zu erreichen. Um die Vorteile von agilen Vorgehensweisen wirklich realisieren zu können, brauchen wir eine Engineering-Kultur, welche nichts mehr damit zu tun hat, wie man früher Software gebaut hat. Und die nur in wenigen Organisationen durchgängig vorherrscht. In diesem und den folgenden Teilen des Kapitels "Warum Agile Engineering?" erkläre ich, warum es eine eigene Kultur und spezielle Vorgehensweisen und Praktiken in der Entwicklung braucht, um Agilität erreichen zu können. Links Blog Post + Transkript: https://quickglance.at/01_warum_agile_engineering/ Notizbuchseite: https://quickglance.at/notizen/01_warum_agile_engineering.pdf Email-Kurs: https://quickglance.at/email/ Consulting / Coaching / Training: https://www.devteams.at/ Mastodon: https://social.devteams.at/@dtanzer Bluesky: https://bsky.app/profile/dtanzer.bsky.social Agiles Manifest: http://agilemanifesto.org/https://videos.devteams.at/static/streaming-playlists/hls/5333ee13-4667-4695-a02f-7654a2c7bb1f/6e746893-f040-45a7-8024-32496f3dee21-master.m3u8https://videos.devteams.at/videos/embed/bgUy4HBv8LycLd5dXfPDtV4250112024-02-14T11:42:56.872ZYESquick_glance_at_agile_engineeringNOhttps://videos.devteams.at/w/t2jg7kQ79mCbHE7k6Ee7eYhttps://videos.devteams.at/lazy-static/thumbnails/c998d260-2d70-4a71-bc92-5c291d0b5b9e.jpgKapitel 01 - Teil 01: Ziele der agilen EntwicklungUm zu verstehen, wie wir im Engineering die Agilität der Softwareentwicklung unterstützen können, müssen wir uns zuerst darüber unterhalten, welche Ziele die agile Softwareentwicklung eigentlich erreichen will. In diesem Teil erkläre ich die Herausforderungen in der Softwareentwicklung, welche Ziele sich daraus ergeben, wie eine agile Doktrin unser Handeln leiten kann und wie wir, im Softwareengineering, all das unterstützen können. Text zum Nachlesen: https://quickglance.at/01_warum_agile_engineering/01_ziele_der_agilen_entwicklung/ Notizbuchseite: https://quickglance.at/notizen/01_warum_agile_engineering/01_01_ziele.pdf Das Agile Manifest: http://agilemanifesto.org/ 12 Prinzipien der agilen Entwicklung - Agiles Manifest: http://agilemanifesto.org/principles.html Jason Yip: What is Agile doctrine?: https://jchyip.medium.com/what-is-agile-doctrine-45dd0c165f7a Five Underplayed Premises of TDD: https://www.geepawhill.org/2017/08/15/five-underplayed-premises-of-tdd/ Email-Kurs: https://quickglance.at/email/ Consulting / Coaching / Training: https://www.devteams.at/ Mastodon: https://social.devteams.at/@dtanzer Bluesky: https://bsky.app/profile/dtanzer.bsky.social https://videos.devteams.at/static/streaming-playlists/hls/dad5bdb3-e69c-4e49-bdc0-25008031d04a/1220106a-5b37-40af-b83d-5a3771a19829-master.m3u8https://videos.devteams.at/videos/embed/t2jg7kQ79mCbHE7k6Ee7eY511082024-02-21T05:32:29.347ZYESquick_glance_at_agile_engineeringNOhttps://videos.devteams.at/w/jAABZVrNuVkye1BG1wDm8Bhttps://videos.devteams.at/lazy-static/thumbnails/dc2315e5-80a2-4a2a-b194-b08d65619637.jpgKapitel 01, Teil 02: Weniger, dafür früher, ist besserIterative Entwicklung, kleine Arbeitspakete, DevSecOps, Continuous Delivery: Alles läuft darauf hinaus, dass wir schneller liefern können. Warum ist das wichtig? Weil kleinere Lieferungen, schneller geliefert, immer besser sind als größere. In diesem Video erfährst du alles darüber. Blog-Post und Transkript: https://quickglance.at/01_warum_agile_engineering/02_weniger_dafuer_frueher_ist_besser/ Notizbuchseite: https://quickglance.at/notizen/01_warum_agile_engineering/01_02_weniger_dafuer_frueher_ist_besser.pdf Das Agile Manifest: http://agilemanifesto.org/ Email-Kurs: https://quickglance.at/email/ Consulting / Coaching / Training: https://www.devteams.at/ Mastodon: https://social.devteams.at/@dtanzer Bluesky: https://bsky.app/profile/dtanzer.bsky.socialhttps://videos.devteams.at/static/streaming-playlists/hls/96991eab-70f4-41b4-9b47-52d30d083bb1/be022b8f-cdbb-49e8-9747-a77a676b0ecc-master.m3u8https://videos.devteams.at/videos/embed/jAABZVrNuVkye1BG1wDm8B621012024-02-29T07:55:38.875ZYESquick_glance_at_agile_engineeringNOhttps://videos.devteams.at/w/6fCPMgnrFik6WF84eMPbWKhttps://videos.devteams.at/lazy-static/thumbnails/9537f5f9-0008-4f59-baee-fefc2a9dc2ae.jpgKapitel 01, Teil 03: Mean Time to FeedbackValidate every step - Überprüfe jeden Schritt. Wir brauchen in der agilen Softwareentwicklung überall schnelles und gutes Feedback. Die Zeit, bis wir brauchbares Feedback zu unserer Arbeit bekommen - die Mean Time to Feedback - ist entscheidend. Blog-Post und Transkript: https://quickglance.at/01_warum_agile_engineering/03_mean_time_to_feedback/ Notizbuchseite: https://quickglance.at/notizen/01_warum_agile_engineering/01_03_mean_time_to_feedback.pdf The Cycles of TDD: https://blog.cleancoder.com/uncle-bob/2014/12/17/TheCyclesOfTDD.html Agile Manifesto: http://agilemanifesto.org/ Email-Kurs: https://quickglance.at/email/ Consulting / Coaching / Training: https://www.devteams.at/ Mastodon: https://social.devteams.at/@dtanzer Bluesky: https://bsky.app/profile/dtanzer.bsky.socialhttps://videos.devteams.at/static/streaming-playlists/hls/2a88ccaf-8707-4fc4-9722-cc9a63435d57/8ad396c1-68d0-4b51-89e0-9e22bb9edd31-master.m3u8https://videos.devteams.at/videos/embed/6fCPMgnrFik6WF84eMPbWK516062024-03-07T10:57:51.265ZYESquick_glance_at_agile_engineeringNOhttps://videos.devteams.at/w/iZyu3ug7xviMg5Rf2kkRpehttps://videos.devteams.at/lazy-static/thumbnails/9d387896-db17-4c26-9ab6-e2886a3adfd7.jpgKapitel 01, Teil 04: Doing things right vs. Doing the right thingWie gut verstehen wir die Bedürfnisse unserer Benutzer - und wie gut sind wir darin, diese in Aufgaben für die Softwareentwicklung zu zerlegen? Wie lange brauchen wir, bis wir solche Aufgaben lösen - durch Software, die in Produktion läuft, die diese Bedürfnisse erfüllt, funktioniert und fehlerfrei ist? Die Antwort auf die erste Frage gibt uns Hinweise darauf, wie sehr wir an den richtigen Problemen arbeiten - "Doing the right things". Die zweite Frage zeigt uns, wie gut wir darin sind, diese Probleme zu lösen - "Doing things right". Blog-Post und Transkript: https://quickglance.at/01_warum_agile_engineering/04_doing_things_right_vs_doing_the_right_thing/ Notizbuchseite: https://quickglance.at//notizen/01_warum_agile_engineering/01_04_doing_things_right_vs_doing_the_right_thing.pdf Gottfried Szing, Verification vs. Validation: https://www.linkedin.com/posts/gottfriedszing_businessananlysis-testing-developer-activity-7167963342425313281-xond/ Email-Kurs: https://quickglance.at/email/ Consulting / Coaching / Training: https://www.devteams.at/ Mastodon: https://social.devteams.at/@dtanzer Bluesky: https://bsky.app/profile/dtanzer.bsky.social https://videos.devteams.at/static/streaming-playlists/hls/91b4c551-9f8a-4bcc-af14-b3fb8a5337ef/c7a63b4c-89db-45b2-8ad1-c2aa4a723db3-master.m3u8https://videos.devteams.at/videos/embed/iZyu3ug7xviMg5Rf2kkRpe588022024-03-13T07:58:20.529ZYESquick_glance_at_agile_engineeringNOhttps://videos.devteams.at/w/isQQW7B3J7eL4WfSjHPVXchttps://videos.devteams.at/lazy-static/thumbnails/4a7bd36a-495e-4d75-b3d0-bf79ba8ef47d.jpgKapitel 01, Teil 05: Agil? Das funktioniert doch gar nicht!Gegen agile Softwareentwicklung gibt es viele Vorbehalte. Manche davon kritisieren ein bestimmtes Framework, wie zum Beispiel Scrum oder SAFe; Andere wiederum agile Vorgehensweisen und Praktiken oder sogar agile Prinzipien und Werte. In diesem Teil gehe ich auf einige dieser Kritikpunkte ein. Blog-Post und Transkript: https://quickglance.at/01_warum_agile_engineering/05_agil_das_funktioniert_doch_gar_nicht/ Notizbuchseite: https://quickglance.at/notizen/01_warum_agile_engineering/01_05_agil_das_funktioniert_doch_gar_nicht.pdf Email-Kurs: https://quickglance.at/email/ Consulting / Coaching / Training: https://www.devteams.at/ Mastodon: https://social.devteams.at/@dtanzer Bluesky: https://bsky.app/profile/dtanzer.bsky.socialhttps://videos.devteams.at/static/streaming-playlists/hls/8d6acbd5-3b87-455a-8117-0544c252369d/1ed27b59-7927-458d-b4cb-8ceb22ddc09f-master.m3u8https://videos.devteams.at/videos/embed/isQQW7B3J7eL4WfSjHPVXc656032024-03-22T06:58:58.805ZYESquick_glance_at_agile_engineeringNOhttps://videos.devteams.at/w/t2WGcfhujKQaXoxKgxLkpvhttps://videos.devteams.at/lazy-static/thumbnails/e79ef14a-4df1-4d66-991d-d47e32c87bb5.jpgKapitel 01, Teil 06: Jetzt tun vs. Der richtige ZeitpunktMove fast and break things oder Move slow and mend things? Besser jetzt etwas liefern oder Optionen und Möglichkeiten für die Zukunft schaffen? Welche Aufgaben müssen wir sofort erledigen und was kann warten? Blog-Post und Transkript: https://quickglance.at/01_warum_agile_engineering/06_jetzt_tun_vs_der_richtige_zeitpunkt/ Notizbuchseite: https://quickglance.at/notizen/01_warum_agile_engineering/01_06_jetzt_tun_vs_der_richtige_zeitpunkt.pdf Commitment - A novel about managing project risk by Olav Maassen, Chris Matts and Chris Geary: https://commitment-thebook.com/ Tidy First? by Kent Beck: https://www.oreilly.com/library/view/tidy-first/9781098151232/ What is a bias for action (and how do you build it)?: https://www.fingerprintforsuccess.com/blog/bias-for-action Email-Kurs: https://quickglance.at/email/ Consulting / Coaching / Training: https://www.devteams.at/ Mastodon: https://social.devteams.at/@dtanzer Bluesky: https://bsky.app/profile/dtanzer.bsky.socialhttps://videos.devteams.at/static/streaming-playlists/hls/daec317f-38c0-47db-b3e2-47fe7012696f/7121714b-ef86-496c-adca-8cfb90f561dd-master.m3u8https://videos.devteams.at/videos/embed/t2WGcfhujKQaXoxKgxLkpv655042024-03-29T11:55:06.305ZYESquick_glance_at_agile_engineeringNOhttps://videos.devteams.at/w/hv54omEXdzgSPv5C5G6JDvhttps://videos.devteams.at/lazy-static/thumbnails/78268b2c-5f96-44ce-a4e2-3ff17fd74a7d.jpgKapitel 01, Teil 07: Der Code ist nicht der FlaschenhalsWie produktiv ist eine Softwareentwickler*in? Wie produktiv ist ein Team? Oft verbinden wir damit vielleicht nur unterbewusst, wieviel Code sie produziert haben. Also wieviele Zeilen sie geschrieben haben oder wieviele Function Points sie geliefert haben. Aber spielt gar keine so große Rolle: Der Code ist nicht der Flaschenhals. Blog-Post und Transkript: https://quickglance.at/01_warum_agile_engineering/07_der_code_ist_nicht_der_flaschenhals/ Notizbuchseite: https://quickglance.at/notizen/01_warum_agile_engineering/01_07_der_code_ist_nicht_der_flaschenhals.pdf Kent Beck, "Tidy First?": https://www.oreilly.com/library/view/tidy-first/9781098151232/ Manifesto for Software Craftsmanship: https://manifesto.softwarecraftsmanship.org/ GeePaw Hill, Re-Balancing Made, Making, and Makers: https://www.geepawhill.org/2020/07/28/re-balancing-made-making-and-makers/ Dave Farley, It's Time For Waterfall To DIE: https://www.youtube.com/watch?v=o3jDLVCpH1E Email-Serie: https://quickglance.at/email/ Consulting / Coaching / Training: https://www.devteams.at/ Mastodon: https://social.devteams.at/@dtanzer Bluesky: https://bsky.app/profile/dtanzer.bsky.social https://videos.devteams.at/static/streaming-playlists/hls/85a149f8-9248-4853-aff9-383c4e14522f/b7fe87d1-1524-40d1-85c0-5a7955019053-master.m3u8https://videos.devteams.at/videos/embed/hv54omEXdzgSPv5C5G6JDv660052024-04-06T05:36:23.627ZYESquick_glance_at_agile_engineeringNOhttps://videos.devteams.at/w/wnfu89JEfwYDeUJABGNze6https://videos.devteams.at/lazy-static/thumbnails/acf16a34-749a-4dff-a791-b68145b17851.jpgKapitel 01, Teil 08: Abschließende ÜberlegungenWir sind am Ende des Kapitels 'Warum Agile Engineering' angekommen. In diesem Teil stelle ich noch einige abschließende Überlegungen zu agiler Arbeitsweise und Agile Engineering an. Blog-Post und Transkript: https://quickglance.at/01_warum_agile_engineering/08_abschliessende_ueberlegungen/ Notizbuchseite: https://quickglance.at/notizen/01_warum_agile_engineering/01_08_abschliessende_ueberlegungen.pdf GeePaw Hill, Five Underplayed Premises of TDD: https://www.geepawhill.org/2017/08/15/five-underplayed-premises-of-tdd/ Dave Farley, Agile Uncertified | Philosophy Over Rituals: https://www.youtube.com/watch?v=U-u8xquguWE Email-Serie: https://quickglance.at/email/ Consulting / Coaching / Training: https://www.devteams.at/ Mastodon: https://social.devteams.at/@dtanzer Bluesky: https://bsky.app/profile/dtanzer.bsky.socialhttps://videos.devteams.at/static/streaming-playlists/hls/f5e9b4a1-fd3f-4ac0-8da2-5ca48fc48eab/410fea8a-15d3-4090-992c-e89c54e2cbb2-master.m3u8https://videos.devteams.at/videos/embed/wnfu89JEfwYDeUJABGNze6496042024-04-09T11:24:37.303ZYESquick_glance_at_agile_engineeringNOhttps://videos.devteams.at/w/5XB1kTN1odxntLWY1D83JFhttps://videos.devteams.at/lazy-static/thumbnails/d68cd282-ddc3-423d-a2fd-f8a52b437939.jpgKapitel 02: Die Praktiken, ein ÜberblickIm aktuellen Kapitel 'Die Praktiken: Ein Überblick' wird es etwas technischer als in den vorigen Teilen: In sieben Teilen werde ich genauer auf die einzelnen Praktiken und Vorgehensweisen eingehen. Blog-Post und Transkript: https://quickglance.at/02_die_praktiken_ein_ueberblick/ Notizbuchseite: https://quickglance.at/notizen/02_00_die_praktiken_ein_ueberblick.pdf Upside: Risk/Reward Definition and Examples: https://www.investopedia.com/terms/u/upside.asp Downside: Meaning, Examples, Protection Strategies: https://www.investopedia.com/terms/d/downside.asp Pia Nilsson, Knowing Me, Knowing You - Growing Teams to Continuously Deliver: https://www.youtube.com/watch?v=S92vVAEofes Email-Serie: https://quickglance.at/email/ Consulting / Coaching / Training: https://www.devteams.at/ Mastodon: https://social.devteams.at/@dtanzer Bluesky: https://bsky.app/profile/dtanzer.bsky.socialhttps://videos.devteams.at/static/streaming-playlists/hls/282808ff-a1f5-41f9-94af-0c8c5829a95b/9be5647e-f281-442d-b00a-1d88b5dfdca9-master.m3u8https://videos.devteams.at/videos/embed/5XB1kTN1odxntLWY1D83JF580062024-07-10T04:58:54.231ZYESquick_glance_at_agile_engineeringNOhttps://videos.devteams.at/w/cAHzUG6jsbrdQLAJn5H7oEhttps://videos.devteams.at/lazy-static/thumbnails/4bd2335f-bbe0-423a-9b6c-79453d9af977.jpgTalk proposal: Evolutionary Design in Bonsai and Software DevelopmentTalk proposal: Evolutionary Design in Bonsai and Software Developmenthttps://videos.devteams.at/static/streaming-playlists/hls/5ded70dd-602a-4342-b7b2-675ac71c6e42/be4b4c37-6f58-4b91-bae4-33c10df4c054-master.m3u8https://videos.devteams.at/videos/embed/cAHzUG6jsbrdQLAJn5H7oE71042025-03-30T08:55:06.274ZYESDavid TanzerNOhttps://videos.devteams.at/w/pUn4zXbqBS4UZgVgCQ74fkhttps://videos.devteams.at/lazy-static/thumbnails/1e5d667a-411c-4586-9167-b309ab814794.jpgTalk proposal: Tests as a Driving Force for DevelopmentTalk proposal: Tests as a Driving Force for Developmenthttps://videos.devteams.at/static/streaming-playlists/hls/c191d853-96bc-48a6-ae7b-71a32ff8f05b/8946b5f2-8c58-4633-a8cd-96f3dadbdb8c-master.m3u8https://videos.devteams.at/videos/embed/pUn4zXbqBS4UZgVgCQ74fk79052025-03-30T09:05:02.194ZYESDavid TanzerNOhttps://videos.devteams.at/w/pJ8jpt6tSbDX5MC1J178jDhttps://videos.devteams.at/lazy-static/thumbnails/5749f2f5-4fd1-4d7b-bf45-761e1e3fec96.jpgNow vs. LaterShould we implement a feature or work on the internal structure of our source code first? In this video, I talk about software development - Especially about tidying vs. feature development - while I work on a chinese elm pre-bonsai. And with the tree, I face a similar decision: Can I already remove some branches or should I wait while a wound on the tree is healing?https://videos.devteams.at/static/streaming-playlists/hls/c023efdd-d981-4e11-a374-d26677005c65/f7f320bd-352d-4224-b854-afc827025f5f-master.m3u8https://videos.devteams.at/videos/embed/pJ8jpt6tSbDX5MC1J178jD376082025-06-10T06:40:56.207ZYESDavid TanzerNOhttps://videos.devteams.at/w/93cqJ6Sw4emxJ6yYhXUwNihttps://videos.devteams.at/lazy-static/thumbnails/55b28355-d2eb-45d9-a975-46b1f372bd61.jpgEngineer, Craftsperson or Gardener?Is software deveopment like engineering or more like a craft? Or are we actually software gardeners, taming the growth of our code? In this video, I talk about metaphors for software development, like "software engineering", while I work on my weeping willow pre-#bonsai.https://videos.devteams.at/static/streaming-playlists/hls/4117a376-dfab-419c-91f2-5bf88f2df045/3312000d-308c-423d-b727-cab433ac7c8a-master.m3u8https://videos.devteams.at/videos/embed/93cqJ6Sw4emxJ6yYhXUwNi424062025-06-16T06:36:00.579ZYESDavid TanzerNOhttps://videos.devteams.at/w/cERFwoavuNxPt4s3EGGie9https://videos.devteams.at/lazy-static/thumbnails/f4e1df85-dd1f-4793-ba3e-754dd4378461.jpgConstraints and When to Remove themWhen we apply #constraints in #software #development or for our teams, we also have to think about when we can or should remove them again. For a #bonsai tree, the wires around the branches are constraints. We remove them for two different reasons, and the same is true for software development...https://videos.devteams.at/static/streaming-playlists/hls/5e8167e2-67bd-4b21-89fc-c55abff46b5e/18293481-a36d-4ba3-a091-610ffef808b1-master.m3u8https://videos.devteams.at/videos/embed/cERFwoavuNxPt4s3EGGie9270032025-06-24T12:36:31.081ZsoftwaretddconstraintsbonsaiYESDavid TanzerNOhttps://videos.devteams.at/w/hShB75H2H6fS2Fjeeaakrrhttps://videos.devteams.at/lazy-static/thumbnails/c107e962-46ef-4f32-882d-a33759e25b3e.jpg3X Thinking - Quick Intro: Three Phases3X thinking - or "eXplore, eXpand eXtract" - tells us that we need different tools, approaches and processes in different phases of an idea. I explain the basic concepts quickly based on Bonsai trees and software development.https://videos.devteams.at/static/streaming-playlists/hls/8897a3f2-1188-44b6-b6c9-d7c306e770c7/bcc11b16-033d-4631-b774-7d5681385bac-master.m3u8https://videos.devteams.at/videos/embed/hShB75H2H6fS2Fjeeaakrr4855692025-07-02T14:41:47.551ZYESDavid TanzerNOhttps://videos.devteams.at/w/x5Hkwz6ey1GeNF5sZRKAcPhttps://videos.devteams.at/lazy-static/thumbnails/c6d01233-08da-4e55-9598-e3dabe005ccd.jpgFeedback and Test-Driven DevelopmentWhile trees are very slow when giving feedback, in software development, we have many ways to speed up the feedback cycle. Test-Driven Development, or TDD, is one of them. In this video, I explain what TDD is and how it helps us getting good feedback faster. Then, I talk about reasons why developers and teams don't use it anyway - And how we could solve this situation.https://videos.devteams.at/static/streaming-playlists/hls/fbb3bf88-11ac-4da9-b0d1-c6923c852a5d/b83a135d-2b25-4855-ac96-c54d77979014-master.m3u8https://videos.devteams.at/videos/embed/x5Hkwz6ey1GeNF5sZRKAcP528052025-07-08T08:54:26.357ZTDDFeedbackBonsaiYESDavid TanzerNOhttps://videos.devteams.at/w/rgmPEaa82vRWWpcs2bS51Nhttps://videos.devteams.at/lazy-static/thumbnails/56514cca-cf95-463a-bc51-33dff8abfaed.jpgTechnical DebtThe original meaning of the term technical debt in software development was implementing a simplified design to get feedback faster. It meant a deliberate choice: To implement something where one already knew that it would not suffice, that it would have to be changed later. But teams would also get something in return; Usually faster feedback, but maybe also other things like having a demo ready for a trade show. In this video, I compare technical debt to sacrificial branches and sacrificial trunks in bonsai. Those are branches (or a part of the original trunk line of the tree) that we keep, even though they will not be part of the final design. We also get something in return here: We can use them to thicken everything below the sacrifice branch, to stimulate root growth or to improve the health of the tree.https://videos.devteams.at/static/streaming-playlists/hls/cc997472-6955-4d35-bfd9-5802692961ce/7d0f7b9c-e479-41dc-8473-a5aad9edf670-master.m3u8https://videos.devteams.at/videos/embed/rgmPEaa82vRWWpcs2bS51N2295162025-07-15T05:02:54.608ZSoftware DevelopmentTechnical DebtSoftware DesignBad CodeSacrificial BranchYESDavid TanzerNOhttps://videos.devteams.at/w/h3hkWFewRLw5oEeyH3LzVChttps://videos.devteams.at/lazy-static/thumbnails/9248ea7e-3d77-4c37-a5aa-1cfc77288c38.jpgNothing lasts forever - The other half of #3xThinkingNothing lasts forever - Not in software development, not in bonsai and not in nature. In my video about 3x thinking I talked about creating: eXplore new ideas, eXpand the ones that seem to be working, then eXtract value from those that are. But then, at the end of the life cycle of a feature, a product or a company, we also have to think about decline, death and decay (hat tip to @SleepyFox for coming up with this concept). In the video, I explain what is meant and I give some examples. My video about 3x thinking can be found here: https://videos.devteams.at/w/hShB75H2H6fS2Fjeeaakrr 3x3d by sleepyfox: https://gist.github.com/sleepyfox/14e99e75df785a056ac8bd8016db136b Follow sleepyfox on mastodon: https://hachyderm.io/@sleepyfox Follow me on mastodon: https://social.devteams.at/@dtanzer Follow me on bluesky: https://bsky.app/profile/dtanzer.bsky.social Follow me on LinkedIn: https://www.linkedin.com/in/david-tanzer-158a71157/https://videos.devteams.at/static/streaming-playlists/hls/81e3c741-deeb-472b-a364-3a8206ac1fea/49897994-bb8f-4407-91e1-8d9ea3d2990a-master.m3u8https://videos.devteams.at/videos/embed/h3hkWFewRLw5oEeyH3LzVC691042025-07-23T10:11:41.178ZYESDavid TanzerNOhttps://videos.devteams.at/w/eavqq9NeWQhPwJ7CxEUJDvhttps://videos.devteams.at/lazy-static/thumbnails/5d43951f-78e1-49d0-a523-e8a23d36f4f7.jpgAll Constraints will be Gamed AnywayAfter I posted my video about "constraints and when to remove them", Bob Marshall posted on Mastodon: "Moot point. All constraints will be gamed anyway". Which is true. But, when that's true, how can the behavior of a software team ever change? In this video I talk about one way to make it work, while I un-wire one of my pre-#bonsai trees. Original constraints video: https://videos.devteams.at/w/cERFwoavuNxPt4s3EGGie9 Bob Marshall on Mastodon: https://mastodon.social/@flowchainsenseisocial Find me on Mastodon: https://social.devteams.at/@dtanzer Find me on Bluesky: https://bsky.app/profile/dtanzer.bsky.social Find me on the web: https://www.davidtanzer.net or: https://www.devteams.athttps://videos.devteams.at/static/streaming-playlists/hls/6a9aa0b9-5ce6-4af8-8a24-eb8c81e0e147/67f03696-e63b-4bab-b907-92e257e42a04-master.m3u8https://videos.devteams.at/videos/embed/eavqq9NeWQhPwJ7CxEUJDv429042025-07-31T13:35:46.771ZSoftware DevelopmentScrumExtreme ProgrammingRetrospectiveBonsaiYESDavid TanzerNOhttps://videos.devteams.at/w/2mqhVsCwMfJpbmLAw99TFchttps://videos.devteams.at/lazy-static/thumbnails/7b00e728-1b35-4df7-aecd-88768838eb31.jpgDesign AlternativesWhen a design does not work out as we intended, or when it does not work anymore, we have to change it. In the case of the bonsai I am working on in this video, a branch had died - and it was necessary for the design I had intended. The best thing that we can do here is to create options. One of the worst things is treating this situation as a failure, but unfortunately, many software organizations do exactly that. They are change-averse, and that creates more problems and more risk in the future... The intro to #3xThinking I mentioned in the video: https://videos.devteams.at/w/hShB75H2H6fS2Fjeeaakrr Find me on Mastodon: https://social.devteams.at/@dtanzer Find me on Bluesky: https://bsky.app/profile/dtanzer.bsky.social Find me on the web: https://www.davidtanzer.net or: https://www.devteams.athttps://videos.devteams.at/static/streaming-playlists/hls/0af2fc00-a8a3-46fc-a144-52616eadb00d/998d16b2-58fe-4223-b070-6e66e047c7a5-master.m3u8https://videos.devteams.at/videos/embed/2mqhVsCwMfJpbmLAw99TFc487082025-08-06T07:32:16.190ZDesignOptionsSoftware DevelopmentIterative DevelopmentYESDavid TanzerNOhttps://videos.devteams.at/w/uYFQCuxhzpcHeCToWsK8dThttps://videos.devteams.at/lazy-static/thumbnails/4d326c17-142e-4cec-a11b-efa4f5808118.jpgCode is a Liability"Code is a liability, not an asset" - Have you heard this before? What does that even mean - without code, there would not be any software?! Just like without branches, there would not be any trees... While that's true, if you only treat code as an asset, that can lead to bad behavior. In this video, I explain why and how that can happen... Find me on Mastodon: https://social.devteams.at/@dtanzer Find me on Bluesky: https://bsky.app/profile/dtanzer.bsky.social Find me on the web: https://www.davidtanzer.net or: https://www.devteams.athttps://videos.devteams.at/static/streaming-playlists/hls/eaaa15bc-76bc-4245-9ad9-1ed7ad4ee9ff/3b9d0df8-09ce-497b-8cc5-92186d4ed5db-master.m3u8https://videos.devteams.at/videos/embed/uYFQCuxhzpcHeCToWsK8dT422042025-08-15T06:39:32.851ZSoftware DevelopmentBonsaiScrumIterative DevelopmentRefactoringYESDavid TanzerNOhttps://videos.devteams.at/w/rN5KRLwkAycaGaFaU4Txnmhttps://videos.devteams.at/lazy-static/thumbnails/05479d7a-73cb-460b-a6b1-31433eb9c366.jpgSimple Techniques, Applied ConsistentlyAndrew Robson from ⁨the "rakuyobonsai⁩" Youtube channel once said that creating bonsai is "simple techniques, applied consistently over long periods of time". And we have the same thing in modern software engineering: We do mostly simple things, over and over, like test-driven development or deploying continuously. But beware: Even though those things are not hard to do, they require experience and practice to do them in a way to reach a desired result. They are easy to learn, but often take a life time to master... Find me on Mastodon: https://social.devteams.at/@dtanzer Find me on Bluesky: https://bsky.app/profile/dtanzer.bsky.social Find me on the web: https://www.davidtanzer.net or: https://www.devteams.at If you are interested in a training about #tdd or agile engineering, or if you want to know more about how technical agile coaching could work for you, contact me at business@davidtanzer.nethttps://videos.devteams.at/static/streaming-playlists/hls/d0e39c6b-87c2-4426-9eb5-27130a5ee49a/c185a6df-40ca-4da5-abaf-c9fd76d30b00-master.m3u8https://videos.devteams.at/videos/embed/rN5KRLwkAycaGaFaU4Txnm474092025-08-19T06:15:13.686Zsoftware developmentagile engineeringtest-driven developmenttddbonsaiYESDavid TanzerNOhttps://videos.devteams.at/w/w1LVq3mkxWzihJKSk1XXNYhttps://videos.devteams.at/lazy-static/thumbnails/6e490814-6e1d-457e-a429-b82dc11b41b3.jpgAI: Possible FuturesCurrently, Artificial Intelligence has many possible futures, because we are still at the beginning. Should we prepare for those futures, and for which ones? Find me on Mastodon: https://social.devteams.at/@dtanzer Find me on Bluesky: https://bsky.app/profile/dtanzer.bsky.social Find me on the web: https://www.davidtanzer.net or: https://www.devteams.at If you are interested in a training about #tdd or agile engineering, or if you want to know more about how technical agile coaching could work for you, contact me at business@davidtanzer.nethttps://videos.devteams.at/static/streaming-playlists/hls/f30dd7e3-500b-44e6-9df5-ba2cf6be48d8/e88c2aac-2e75-4bae-8c01-6c489ab8e38c-master.m3u8https://videos.devteams.at/videos/embed/w1LVq3mkxWzihJKSk1XXNY561052025-08-27T11:48:12.608ZAIArtificial IntelligenceSoftware DevelopmentAGIBonsaiYESDavid TanzerNOhttps://videos.devteams.at/w/b2x3ZTiQpoczYUgL6QGgMFhttps://videos.devteams.at/lazy-static/thumbnails/be6017df-a767-4d19-bca7-19a17d813e25.jpgDo you enjoy writing code? Some don't...Some software developers seem to not enjoy writing program code. Sounds paradoxical, but with the rise of artificial intelligence (AI), it becomes more visible. It's OK to not like it, but there are some implications... Find me on Mastodon: https://social.devteams.at/@dtanzer Find me on Bluesky: https://bsky.app/profile/dtanzer.bsky.social Find me on the web: https://www.davidtanzer.net or: https://www.devteams.athttps://videos.devteams.at/static/streaming-playlists/hls/51324443-6a5e-49c3-b842-92c83e2b7555/1b782262-759e-44bf-bb10-fdfa5dbb8603-master.m3u8https://videos.devteams.at/videos/embed/b2x3ZTiQpoczYUgL6QGgMF4105142025-09-03T04:09:17.147ZSoftware DevelopmentMaintainable CodeWork EthicsAIBonsaiYESDavid TanzerNOhttps://videos.devteams.at/w/xhhjdKiBwgi4JhtNj6cTCfhttps://videos.devteams.at/lazy-static/thumbnails/14063fbd-66ed-487e-a699-ef73b3cbb854.jpgEthics of AI in Software DevelopmentIs it unethical to use generative artificial intelligence in software development? Is it unethical to NOT use it? What could be the long-term consequences of using it now? Hard questions that might not even have a definitive answer (yet). I'm trying to give you my answers anyway - In this video. Find me on Mastodon: https://social.devteams.at/@dtanzer Find me on Bluesky: https://bsky.app/profile/dtanzer.bsky.social Find me on the web: https://www.davidtanzer.net or: https://www.devteams.at If you are interested in a training about #tdd or agile engineering, or if you want to know more about how technical agile coaching could work for you, contact me at business@davidtanzer.nethttps://videos.devteams.at/static/streaming-playlists/hls/fd5140b2-6279-4b6c-a676-4d31165effaa/5b9e5a5c-b38a-4129-9993-477618e9325c-master.m3u8https://videos.devteams.at/videos/embed/xhhjdKiBwgi4JhtNj6cTCf4715122025-09-10T06:16:12.418ZSoftware DevelopmentBonsaiEthicsAIGenAIYESDavid TanzerNOhttps://videos.devteams.at/w/wGWwaKLWFLbypBzQ2wy1iZhttps://videos.devteams.at/lazy-static/thumbnails/70bcc70c-4514-487d-ae47-b1f0e15c539c.jpgSuccessful Software (and Bonsai) Development is a SystemAll successful software development methodologies - like eXtreme programming, Scrum and others - form a system. And since a system is more than the sum of its parts, one cannot take one part of the system and expect to get a part of the result. But also, since we are operating in a complex environment, we cannot expect to get the same result again when we do the same things we did before. How do we solve this dilemma? Actually, it's not THAT hard... Find me on Mastodon: https://social.devteams.at/@dtanzer Find me on Bluesky: https://bsky.app/profile/dtanzer.bsky.social Find me on the web: https://www.davidtanzer.net or: https://www.devteams.at If you are interested in a training about #tdd or agile engineering, or if you want to know more about how technical agile coaching could work for you, contact me at business@davidtanzer.nethttps://videos.devteams.at/static/streaming-playlists/hls/f8a98284-3f67-4940-8d55-d50cf8fd9613/43055433-2563-4ed5-9d57-c8320c33dd01-master.m3u8https://videos.devteams.at/videos/embed/wGWwaKLWFLbypBzQ2wy1iZ417062025-09-16T09:16:03.976ZScrumeXtreme ProgrammingCynefinSoftware DevelopmentBonsaiYESDavid TanzerNOhttps://videos.devteams.at/w/x4s6tn5cJigdm84qpARgpehttps://videos.devteams.at/lazy-static/thumbnails/601298db-4a5b-4305-8eb7-0d350841011a.jpgRefactoring: Inverting a DependencyIn this video, I refactor some java code to invert a dependency: In the original version, a controller was asking a clock object for the current time. I change the code so that the clock notifies the controller when the time changes in an interesting way. Find me on Mastodon: https://social.devteams.at/@dtanzer Find me on Bluesky: https://bsky.app/profile/dtanzer.bsky.social Find me on the web: https://www.davidtanzer.net or: https://www.devteams.at If you are interested in a training about #tdd or agile engineering, or if you want to know more about how technical agile coaching could work for you, contact me at business@davidtanzer.nethttps://videos.devteams.at/static/streaming-playlists/hls/fb869c69-19ec-4310-835e-9a36dbfe1607/409dfacf-f316-4854-acb9-967d95767b7a-master.m3u8https://videos.devteams.at/videos/embed/x4s6tn5cJigdm84qpARgpe13290112025-09-17T15:48:38.853ZYESDavid TanzerNOhttps://videos.devteams.at/w/orkDdvXUez84cdLysUAgfkhttps://videos.devteams.at/lazy-static/thumbnails/c06466fc-51c6-4009-9879-24b129bc2f98.jpgRefactoring: Rendering Stages get their own InterfaceWatch me continue refactor some Java code of a command line app: In the first video, I inverted a dependency between two object. That enables me to simplify some tests in this video. Then I continue by introducing an interface for the rendering stages and use it throughout the code that exists so far. Previous video: https://videos.devteams.at/w/x4s6tn5cJigdm84qpARgpe The git repo: https://codeberg.org/dtanzer/tzsh Find me on Mastodon: https://social.devteams.at/@dtanzer Find me on Bluesky: https://bsky.app/profile/dtanzer.bsky.social Find me on the web: https://www.davidtanzer.net or: https://www.devteams.at If you are interested in a training about #tdd or agile engineering, or if you want to know more about how technical agile coaching could work for you, contact me at business@davidtanzer.nethttps://videos.devteams.at/static/streaming-playlists/hls/b5b2bfd6-90ba-4d66-b0d2-41da74322f2b/b3a53190-4bca-416a-9cd6-b18eebb7b541-master.m3u8https://videos.devteams.at/videos/embed/orkDdvXUez84cdLysUAgfk12695122025-10-02T13:55:06.935ZYESDavid TanzerNOhttps://videos.devteams.at/w/5MwbsPo3ZS3R8Kvcju8yjghttps://videos.devteams.at/lazy-static/thumbnails/02a83eb4-d4ec-49db-b035-6f779e29e9b3.jpgAI in Software Development: Possible GainsAI in Software development can help us speed up the coding (at least sometimes - maybe). But how much does that matter? And is it something we should even strive to do? Since software development is not just "write some code", those questions are not as easy as they first look... Find me on Mastodon: https://social.devteams.at/@dtanzer Find me on Bluesky: https://bsky.app/profile/dtanzer.bsky.social Find me on the web: https://www.davidtanzer.net or: https://www.devteams.at If you are interested in a training about #tdd or agile engineering, or if you want to know more about how technical agile coaching could work for you, contact me at business@davidtanzer.nethttps://videos.devteams.at/static/streaming-playlists/hls/26bf9fa5-2044-4a8d-93ab-6ae643af7cfb/23e32b27-96aa-4f26-9ef2-7f6b06404e03-master.m3u8https://videos.devteams.at/videos/embed/5MwbsPo3ZS3R8Kvcju8yjg477052025-10-06T09:49:45.160ZAILLMSoftware DevelopmentLearningFeedbackYESDavid TanzerNOhttps://videos.devteams.at/w/n8TDBBWWPJxKaySi7yArxChttps://videos.devteams.at/lazy-static/thumbnails/68bb14ce-65ce-493b-a010-081b3e147dac.jpgJava Refactoring: Honest and Complete NamesIn the Java Code I was refactoring during the last two videos, I never really was happy with some of the names. So, inspired by Arlo Belshee's "Naming as a process" (*), I started to give some classes and variables "honest & complete" names. That makes them MUCH longer and more verbose, but it also helps thinking about what an object really does. (*) https://www.digdeeproots.com/articles/on/naming-process/ Previous video: https://videos.devteams.at/w/orkDdvXUez84cdLysUAgfk The git repo: https://codeberg.org/dtanzer/tzsh Find me on Mastodon: https://social.devteams.at/@dtanzer Find me on Bluesky: https://bsky.app/profile/dtanzer.bsky.social Find me on the web: https://www.davidtanzer.net or: https://www.devteams.at If you are interested in a training about #tdd or agile engineering, or if you want to know more about how technical agile coaching could work for you, contact me at business@davidtanzer.nethttps://videos.devteams.at/static/streaming-playlists/hls/ab29f2a1-c469-4c23-a842-e1dfc4f691fe/d9954326-8fc8-472e-9995-c6d6d0f49988-master.m3u8https://videos.devteams.at/videos/embed/n8TDBBWWPJxKaySi7yArxC897042025-10-08T13:33:15.795ZJavaRefactoringNamingYESDavid TanzerNOhttps://videos.devteams.at/w/pWB2wgi2CaMYQ32W736b1Yhttps://videos.devteams.at/lazy-static/thumbnails/2cf2511c-c595-469e-9412-e0b78269a664.jpgMake only Easy Changes in Software Development (First, make the change easy)In software development, make only easy changes. How can that ever be possible? By first making the change easy. Doing this in two steps - first, making the change easy, then making the easy change - provides major benefits over making the change in one big step... Find me on Mastodon: https://social.devteams.at/@dtanzer Find me on Bluesky: https://bsky.app/profile/dtanzer.bsky.social Find me on the web: https://www.davidtanzer.net or: https://www.devteams.at If you are interested in a training about #tdd or agile engineering, or if you want to know more about how technical agile coaching could work for you, contact me at business@davidtanzer.nethttps://videos.devteams.at/static/streaming-playlists/hls/c1e1f03d-fa08-4654-acfa-5c07a0b49848/905f3e78-f40f-4ef9-9f50-e02d4392559f-master.m3u8https://videos.devteams.at/videos/embed/pWB2wgi2CaMYQ32W736b1Y576062025-10-10T15:29:56.361ZSoftware DevelopmentRefactoringOpen/Closed PrincipleYESDavid TanzerNOhttps://videos.devteams.at/w/hqj87WvQpppegFxZLviidehttps://videos.devteams.at/lazy-static/thumbnails/06ebbcb6-3fbe-4554-a440-679497d82d30.jpgThe Value of a Community (Learning, Sharing, Fun)Our SoCraTesAT (Software Crafting and Testing Conference Austria) has shown me again how valuable having a community of software developers can be. Hear more about the value of a community in this video. SoCraTesAT Conference: https://socrates-conference.at Find me on Mastodon: https://social.devteams.at/@dtanzer Find me on Bluesky: https://bsky.app/profile/dtanzer.bsky.social Find me on the web: https://www.davidtanzer.net or: https://www.devteams.at If you are interested in a training about #tdd or agile engineering, or if you want to know more about how technical agile coaching could work for you, contact me at business@davidtanzer.nethttps://videos.devteams.at/static/streaming-playlists/hls/84f73cd2-3cc2-4bef-9a52-8d95615f63e1/3e9fef9c-7c5e-4e73-8ea2-b42c22d869aa-master.m3u8https://videos.devteams.at/videos/embed/hqj87WvQpppegFxZLviide282062025-10-16T11:21:06.407ZYESDavid TanzerNOhttps://videos.devteams.at/w/iqDz7Eg8HzrZrQnrmtxGm4https://videos.devteams.at/lazy-static/thumbnails/802fb949-4255-48db-918e-6f72cd7ae57e.jpgWhy Didn't You Use AI For That?!I often do tasks by hand where others us AI nowadays (as of October 2025). Why? Among other reasons: Because I enjoy it more and because I don't like the fact that the internet is currently flooded with generated stuff. Find me on Mastodon: https://social.devteams.at/@dtanzer Find me on Bluesky: https://bsky.app/profile/dtanzer.bsky.social Find me on the web: https://www.davidtanzer.net or: https://www.devteams.at If you are interested in a training about #tdd or agile engineering, or if you want to know more about how technical agile coaching could work for you, contact me at business@davidtanzer.nethttps://videos.devteams.at/static/streaming-playlists/hls/8d1c5c92-f663-4f5e-bf77-42c89367fcf3/bb41f4cd-27f5-47ab-8e80-89feee122165-master.m3u8https://videos.devteams.at/videos/embed/iqDz7Eg8HzrZrQnrmtxGm4202592025-10-21T14:39:19.615ZAIAI SlopSlopInternetEnjoy your workYESDavid TanzerNOhttps://videos.devteams.at/w/bCZdQYwQy4RCrX8KSWc49Qhttps://videos.devteams.at/lazy-static/thumbnails/ed4f9db6-4f66-4587-9be6-5d4b38c01189.jpgRefactoring to "Chain of Responsibility" Pattern: The "Necklace Kata"In this video, I am refactoring the "necklace kata" by ⁨@EmilyBache-tech-coach⁩ to use a chain of responsibility-pattern instead of an if-else-if cascade. And I am trying to use only IDE-refactorings and other safe code changes in the process. Did I succeed? Almost :) (Some operations were not completely safe or automatic, so I still had to rely on the tests). My fork of the kata: https://github.com/dtanzer/Necklace-Refactoring-Kata/tree/202510-java-ide-refactorings-from-main Micro step helpers (provable refactorings): https://github.com/digdeeproots/provable-refactorings/tree/master/recipes/micro-step-helpers Find me on Mastodon: https://social.devteams.at/@dtanzer Find me on Bluesky: https://bsky.app/profile/dtanzer.bsky.social Find me on the web: https://www.davidtanzer.net or: https://www.devteams.at If you are interested in a training about #tdd or agile engineering, or if you want to know more about how technical agile coaching could work for you, contact me at business@davidtanzer.nethttps://videos.devteams.at/static/streaming-playlists/hls/56256d21-a2cb-4737-a399-b89145f96304/b803aef9-0faf-4bf4-bbb1-2a3033ff64f5-master.m3u8https://videos.devteams.at/videos/embed/bCZdQYwQy4RCrX8KSWc49Q1285072025-10-23T14:44:19.274Zrefactoringtddchain of responsibilityintellijapproval testsYESDavid TanzerNOhttps://videos.devteams.at/w/8G9CtGM4Zfwf2Q22AEPLq5https://videos.devteams.at/lazy-static/thumbnails/7d5ea671-be12-4ace-a0b6-863afbe39118.jpgAI: Multiple Agents Working TogetherHow can two AI agents work together to achieve a goal? Like counting to ten together, which is somewhat simplistic but proves the point? This video and the resulting software were inspired by a great talk from Lada Kesseler - Link below. In the original video, Lada Kesseler shows an example where two AI agents (claude code) work together to count from one to ten. She uses AppleScript to facilitate the conversation, and since I'm on Linux, I wanted to try a similar thing using only bash and tmux. In this video, I am using claude code to create a bash script with several sub commands. AI agents - in my case, other claude code instances - can use this script to find out who they are and who else is there. Then, the agents can also use it to send each other messages. My first approach (using tmux pane titles) did not work, but together with the AI, I was able to create a working version in the end; And then, have two other agents count to 10 together. I edited the video for brevity - I removed detours and boring parts and sped up some other parts. The original video: https://www.youtube.com/watch?v=_LSK2bVf0Lc&t=8125s Find me on Mastodon: https://social.devteams.at/@dtanzer Find me on Bluesky: https://bsky.app/profile/dtanzer.bsky.social Find me on the web: https://www.davidtanzer.net or: https://www.devteams.at If you are interested in a training about #tdd or agile engineering, or if you want to know more about how technical agile coaching could work for you, contact me at business@davidtanzer.nethttps://videos.devteams.at/static/streaming-playlists/hls/3e4b0a07-f2a1-40ac-a71a-528ce314e75c/8805b053-bb66-4f84-9643-0da8a27caab0-master.m3u8https://videos.devteams.at/videos/embed/8G9CtGM4Zfwf2Q22AEPLq5608022025-11-04T15:24:53.369ZYESDavid TanzerNOhttps://videos.devteams.at/w/xjJCmmzdJVyd3c4uNCGU6ghttps://videos.devteams.at/lazy-static/thumbnails/fea46506-93e6-46a4-ae12-a4f5ab9e009d.jpgAI Agent Swarm: Three Claude Code Instances Working Together to Refactor some CodeI am again experimenting with multi-agent-communication: This time, I set up three claude code instances to work on some legacy code together. They have different roles and perform different tasks: One is the architect who keeps a high-level overview of the refactoring, one is the developer who implements every small step and one is the reviewer who reviews each step and commits when the change seems OK. The legacy code they are working on is the "BabySteps Timer": https://github.com/dtanzer/babystepstimer After some trial and error, I manage to make them do the first step of a bigger refactoring together, and the result looks good! Find me on Mastodon: https://social.devteams.at/@dtanzer Find me on Bluesky: https://bsky.app/profile/dtanzer.bsky.social Find me on the web: https://www.davidtanzer.net or: https://www.devteams.at If you are interested in a training about #tdd or agile engineering, or if you want to know more about how technical agile coaching could work for you, contact me at business@davidtanzer.nethttps://videos.devteams.at/static/streaming-playlists/hls/fda8f4bb-3959-4fb4-bcb5-7560907e8941/a6abd095-4348-4ab8-b2b5-db71bdd054c5-master.m3u8https://videos.devteams.at/videos/embed/xjJCmmzdJVyd3c4uNCGU6g8250112025-11-11T10:45:05.481ZYESDavid TanzerNOhttps://videos.devteams.at/w/2BKu8TDU9fT5S3TKn7Tinthttps://videos.devteams.at/lazy-static/thumbnails/3a97d9aa-e222-48d3-83a2-b0d7f61b7713.jpgCommunicate Design Ideas: Pair Programming / Mob Programming is Knowledge Tranfer"Pair programming is continuous code review". You have probably heard that one. But it is not the most important reason we do pair programming. We do it because we want to be more effective at developing software. And since a big part of software development is gathering and spreading knowledge, we can get more effective if we can streamline that. Pair programming and ensemble programming are a way to distribute knowledge in a very effective way: It is open-loop communication, so we can be fairly sure that we are on the same page after a session! Find me on Mastodon: https://social.devteams.at/@dtanzer Find me on Bluesky: https://bsky.app/profile/dtanzer.bsky.social Find me on the web: https://www.davidtanzer.net or: https://www.devteams.at If you are interested in a training about #tdd or agile engineering, or if you want to know more about how technical agile coaching could work for you, contact me at business@davidtanzer.nethttps://videos.devteams.at/static/streaming-playlists/hls/0d16f821-4497-4302-9650-26eafca590f9/a03b1db0-6e33-4f0e-ad3a-9bdc05d90c32-master.m3u8https://videos.devteams.at/videos/embed/2BKu8TDU9fT5S3TKn7Tint465572025-11-13T11:46:07.624ZYESDavid TanzerNOhttps://videos.devteams.at/w/9bVXQaRCfLAY6ftoDRfZBxhttps://videos.devteams.at/lazy-static/thumbnails/ff02d1d8-283e-40a1-a987-776213f47cd4.jpgTeaching 2 AIs Ping-Pong Pair-Programming (just for fun)After playing around with claude code instances prompting each other in the last few videos, I decided to try something with little practical use: I wanted to get them to do ping-pong pair-programming together. And they did finish their assignment togehter, but they also immediately forgot some instructions and jumped ahead too fast. So, some parts were impressive, other disappointing... But watch for yourself! Here's the video where I show how to set up multiple claude code instances: https://youtu.be/1s-IA2VRgBY Find me on Mastodon: https://social.devteams.at/@dtanzer Find me on Bluesky: https://bsky.app/profile/dtanzer.bsky.social Find me on the web: https://www.davidtanzer.net or: https://www.devteams.at If you are interested in a training about #tdd or agile engineering, or if you want to know more about how technical agile coaching could work for you, contact me at business@davidtanzer.nethttps://videos.devteams.at/static/streaming-playlists/hls/424fcd77-e5b8-4249-aa35-b9ecb2462871/a471de51-b954-4029-b8a9-34c37dd201c2-master.m3u8https://videos.devteams.at/videos/embed/9bVXQaRCfLAY6ftoDRfZBx764062025-11-21T10:13:45.628ZYESDavid TanzerNOhttps://videos.devteams.at/w/mk4HZayGMx9H6tbfCV5x6bhttps://videos.devteams.at/lazy-static/thumbnails/c187bba3-70d8-495f-849a-81e42bdc09b7.pngClaudeCode instances running in docker containers starting and stopping each other: General setupMy "agnt" command line tool got a powerful new update: You can run the agents in docker / podman containers now, and they can start and stop each other - on top of being able to communicate. The tool: https://codeberg.org/dtanzer/agnt Dockerfiles and scripts: https://codeberg.org/dtanzer/ai-agents-podman Highly recommended channel: ⁨@JoVanEyck⁩ Find me on Mastodon: https://social.devteams.at/@dtanzer Find me on Bluesky: https://bsky.app/profile/dtanzer.bsky.social Find me on the web: https://www.davidtanzer.net or: https://www.devteams.at If you are interested in a training about #tdd or agile engineering, or if you want to know more about how technical agile coaching could work for you, contact me at business@davidtanzer.nethttps://videos.devteams.at/static/streaming-playlists/hls/a4a03323-5cca-442c-a213-78d010369178/a288c7cd-3f1d-441b-bc6b-eaa828d75e77-master.m3u8https://videos.devteams.at/videos/embed/mk4HZayGMx9H6tbfCV5x6b426052026-03-25T15:42:44.860ZAIClaudeMulit-AgentYESDavid TanzerNOhttps://videos.devteams.at/c/quick_glance_at_agile_engineering/videoshttps://videos.devteams.at/c/david/videoshttps://videos.devteams.at/a/dtanzer/video-channels