Schlagwortarchiv für: Training

Verändern wir die Welt mit Sprache durch Intent-Based Leadership!

Agile Organisationen erfordern einen neuen Führungsstil. Dieser zeichnet sich durch Befähigung, Motivation und Eigeninitiative jedes einzelnen Mitarbeiters aus.

Führungspersonen und auch jede KollegIn mit fachlichen und technischen Führungsaufgaben fokussieren sich hierbei darauf, die Teams möglichst gut in die Eigenverantwortung zu bringen und selbst Entscheidungen treffen zu lassen. 

Intent-Based Leadership (IBL) liefert hierzu den passenden Ansatz. 

Was bedeutet Intent-Based Leadership?

Während agile Arbeitsweisen darauf abzielen, flache Hierarchien zu schaffen und MitarbeiterInnen in den Teams mehr Freiraum einzuräumen, spiegelt sich dieser neue Führungsstil jedoch nicht in der Sprache der meisten Führungspersonen wider.

Intent-Based Leadership (IBL) schafft hier Abhilfe. IBL legt den Fokus auf die Kommunikation und Sprache, die Führungspersonen und Teams verwenden, um bei der Arbeit zu kommunizieren. Hierbei handelt es sich vornehmlich um die Wörter, die wir im täglichen Miteinander und bei Fragestellungen verwenden.

Ich möchte, dass ihr ein wöchentliches Kundenmeeting abhält und Trello verwendet.

Manager Kommunikation – klassisch

Mein Ziel ist, dass wir kundenzentrierter arbeiten und ein gemeinsames System verwenden, sodass die Arbeit des Gesamtsystems transparent dargestellt werden kann.

Kommunikation nach Intent-Based Leadership Prinzip

Bei der richtigen Wortwahl können TeamleiterInnen ihren Mitarbeitern die nötige Kontrolle vermitteln, ohne selbst in einen Befehlsmodus zu verfallen. Gleichzeitig können Teammitglieder eine Sprache benutzen, um Gespräche auf Augenhöhe zu führen. Bei diesem neuen Führungsparadigma wenden sich Teammitglieder an Führungspersonen, indem sie beschreiben, was sie sehen, denken und vorhaben. 

Wir brauchen mehr Marketing Ressourcen.

Klassisches Mitarbeiter-Statement

Unsere Intention ist, dass wir eine höhere Qualität in der Marketing Produktion liefern möchten, dazu fehlen uns die Fähigkeiten im Team. Daher ist unser Plan einen zusätzlichen Social Media Experten in unser Team aufzunehmen.

Mitarbeiter-Kommunikation nach Intent-Based Leadership

Hierdurch wird nicht nur die Effektivität, sondern auch die Motivation und die Zufriedenheit aller Mitarbeiter deutlich gesteigert. IBL bietet einen sicheren Leitfaden für Organisationen, um neu zu definieren, was agile Führung bedeutet.

Was sind die wichtigsten Grundsätze von Intent-Based Leadership?

Das Konzept von Intent-Based Leadership ist das direkte Ergebnis davon, wie David Marquet, ehemaliger U-Boot-Kapitän, die USS Santa Fe vom schlechtesten zum besten Schiff der US-Marine machen konnte. In seinem Buch „Turn the Ship Around!“ beschreibt David Marquet genau, wie er dies erreichen konnte. Das Buch ist nicht nur für agile Führungspersonen äußerst empfehlenswert. 

Als David Marquet das Kommando über die USS Santa Fe übernahm,hatte er nur drei Wochen Zeit, um alles über das Schiff zu lernen – eine unmögliche Aufgabe, selbst für erfahrene Kapitäne.

Als er das Kommando übernahm, musste er schnell feststellen, dass alte Muster nicht nur ineffektiv, sondern auch gefährlich sein können. Wenn er Befehle in einer Umgebung erteilt, von der er nicht alles wusste und Untergebene diesen Befehlen blind folgen würden, könnten Menschenleben auf dem Spiel stehen. Daher beschloss er, anstelle Befehle zu erteilen, die sehr konkret waren, nur das Vorhaben (den Intent) zu beschreiben, wie zum Beispiel “ich möchte das U-Boot dorthin manövrieren, anstelle von “Luken schließen, Abtauchen, so und soviel grad einschlagen, etc..” 

Dadurch verlagerte er das Denken und Nachdenken über das “Wie erreiche ich das Ziel” zu seinen Crew Mitgliedern, die auch viel besser verstanden, warum Sie eine Aktion durchführen. Er erwähnt hier einen Mitarbeiter im Maschinenraum, der selbstständig entscheiden konnte, ob es jetzt eine gute Idee ist Lärm zu machen oder besser ist, ruhig zu sein, da er wusste, ob man sich gerade in feindlichem Gewässer befindet oder nicht.

David Marquets Führungsstil fasst die Grundsätze von IBL bestens zusammen: Führungspersonen müssen nicht immer Antworten auf alle Fragen haben oder ihre Untergebenen dazu bewegen, etwas zu vollbringen. Vielmehr geht es darum, Kontrolle abzugeben, um hierdurch die Effizienz zu steigern. Menschen, die am vertrautesten mit der Aufgabenstellung sind, werden die bestmöglichen Lösungsvorschläge liefern. 

Anwendungsbeispiel

Eines der besten Werkzeuge von Intent-Based Leadership ist die sogenannte „Ladder of Leadership“. Diese enthält einige einfache Fragen, die Führungspersonen stellen können, je nachdem, wie ihre Mitarbeiter mit ihnen sprechen. 

Wenn jemand beispielsweise sagt: „Bitte sagen Sie mir einfach, was ich tun soll“, befindet sich diese Person auf der untersten Ebene der Leiter. Die Führungsperson möchte die Mitarbeiterinnen und Mitarbeiter nach oben bringen, damit diese die nötige Sicherheit erhalten, um eigenständig Probleme zu lösen.

Die Frage, die hierzu gestellt wird, lautet schlicht und einfach: „Was sehen Sie?“ Dies ist der nächste Schritt auf der Leiter und ermöglicht den Mitarbeitern, in einer psychologisch sicheren Umgebung zu antworten, da TeamleiterInnen lediglich um eine wertfreie Beobachtung bitten. 

Auf diese Weise gewinnen Menschen schnell an Sicherheit und können bereits in kurzer Zeit die nötige Eigenständigkeit und Kontrolle übernehmen, damit sie eine Ebene erreichen, auf der sie ihrem Chef mit einer Absicht, etwas zu verändern, begegnen. Somit wird die Effizienz jedes einzelnen Mitarbeiters um ein Vielfaches gesteigert.

Wir decken in unserem Training neben der “Ladder of Leadership” noch 5 weitere Prinzipien von Intent-Based Leadership ab. Mehr erfahren.

IBL schafft neue Verantwortungsbereiche

Agile Führungspersonen, die IBL in ihren Führungsstil integrieren, müssen nicht zwangsläufig alle Antworten parat haben. Es geht nämlich primär nicht darum, Mitarbeiterinnen und Mitarbeiter zu einem bestimmten Verhalten oder einer bestimmten Aktion zu bewegen, sondern stattdessen zu ermächtigen, eigenständig Entscheidungen zu treffen sowie ein Verantwortungsgefühl zu entwickeln indem man eine klare Richtung bzw Intention des Vorhabens formuliert.

Intent-Based Leadership, führt, ähnlich wie andere agile Führungsstile auch, einen gewissen Kontrollverlust der Führungspersonen herbei. Durch diesen „Kontrollverlust“ auf sprachlicher Ebene werden gleichzeitig neue Verantwortungsbereiche geschaffen, was die Effizienz jedes einzelnen Mitarbeiters erhöht und gleichzeitig weitaus bessere Ergebnisse liefert.

Hierdurch können agile Teams und agile Organisation geschaffen werden, die sich besonders dadurch hervorheben, dass sie sich in kürzester Zeit an neue Veränderungen und Gegebenheiten anpassen können. Dies geschieht vornehmlich durch ein „Intent-based“ bzw. proaktives Verhalten der Belegschaft, was durch die Verwendung von IBL zielgerichtet gefördert wird.

Intent-Based Leadership ist die neue Grundlage agiler Unternehmen

Intent-Based Leadership hilft agilen Führungspersonen, ihren Führungsstil weiter auszubauen und Kompetenz und Eigeninitiative durch die richtige Wahl der Sprache zu vermitteln. Darüber hinaus hilft IBL selbst scheuen Mitarbeitern, Selbstbewusstsein zu entwickeln, um eigenständig die Initiative zu ergreifen.

Auch wenn das Grundprinzip nun klar sein sollte, erfordert IBL noch einiges mehr, um agile Führungspersonen in Intent-Based Leader zu verwandeln. Unser Training vermittelt neben den Grundprinzipien der Methodik auch anwendbare Werkzeuge, mit denen Sie Ihre Sprache in einer agilen Umgebung optimieren können.

Intent-Based Leadership: Ein Training mit Jenni Jepsen, einer international erfahrenen Expertin, am 12. Mai 2022 in Wien.

Nur unsere Newsletter Abonnenten bekommen alle Artikel!

Bleiben Sie Up2Date mit unseren Interviews und Artikeln zu Agile Transformation. Für Agile Experts, Change Leader, Digital Transformation Experts.

SAFe in Österreich: Eurofunk Kappacher

Bei diesem Meetup berichtete Martin Jörg von Eurofunk Kappacher von der SAFe Transformation, die mit einem Release Train gestartet hat und mittlerweile bei drei Release Trains angekommen ist. Organisiert wurde das Meetup von Susanne Bauer (Kegon AT) und mir.

Dabei hat Martin Jörg folgende Themen behandelt:

  • Warum haben wir uns für SAFe entschieden? 
  • Was waren die Probleme, was haben wir uns davon versprochen?
  • Wie hat SAFe in die Organisation skaliert?
  • Wo hat Eurofunk jetzt noch Verbesserungspotential?

Eurofunk Kappacher ist Marktführer für Leitstellentechnik im deutschsprachigen Raum und wächst stetig. Hier wurde auf das Scaled Agile Framework gesetzt.

Ausgewählte Highlights aus der Diskussion:

  • Das Framework hat uns geholfen, viele Dinge auch nicht diskutieren zu müssen, weil viele Prozesse und Rollen dokumentiert sind. Das hat den Start vereinfacht.
  • Das schwierigste war die Cross funktionalen Teams zu bilden, um von Silo Teams wegzukommen.
  • Durch das Framework verbessern sich laufend unsere Prozesse. Die Dokumentation der Prozesse hat uns die ISO 9001 erleichtert.
  • Wir haben es geschafft, kürzere Feedbackzyklen aufzubauen, was einen positiven Impact auf unsere Produkte hat.

Mit unserem Leading SAFe® 5.1 Training können Sie von erfahrenen Experten lernen wie Sie Fähigkeiten zur Unterstützung und Durchführung von PI Planning Events, Koordinierung mehrerer Agile Release Trains (ARTs), Anwenden der Prinzipien aus den Bereichen Lean, Systemdenken, agile Entwicklung und vieles mehr.


Lassen Sie uns weitersprechen!

Sie wollen mehr zum Thema Leading SAFe erfahren? Sie wollen in Ihrem Unternehmen ein Umfeld entwickeln, um die Arbeit nach agilen Methoden zu ermöglichen?

Kontaktieren Sie mich:

Richard Brenner
Agile Coach bei TechTalk
richard.brenner@techtalk.at


Der Weg von inperson zu remote & hybrid – Wie wir uns auf die neuen Gegebenheiten umgestellt haben

Auf bessere Zeiten verschieben, absagen, oder unter Vorbehalt fixieren? Jeder, dessen Arbeitsleben von Meetings geprägt ist, hat dies in den vergangenen Monaten vernehmen müssen. Man scheitert oft daran, keinen ausreichend großen Raum zu haben oder nicht über die technische Ausstattung zu verfügen, um ein hybrides Meeting optimal durchführen zu können.

Vor dieser Situation standen auch wir und die Folge war Stillstand. Natürlich wurden alle Veranstaltungen abgesagt. Die Räume leer und die Rückkehr ungewiss. Nach der Schockstarre wurde uns rasch bewusst, wenn wir das Projekt DC Spaces weiterbringen und am Laufen halten wollen, müssen wir uns anpassen und reagieren. Die Antwort auf die Frage wie diese Reaktion aussehen sollte war genau vor unseren Augen: Was brauchen wir als TechTalk für eine sichere und nachhaltige Zusammenarbeit?

Zunächst haben wir als Trainingsanbieter von TechTalk online Events & Trainings durchgeführt, bei denen wir die verschiedenen Tools zur idealen Online-Zusammenarbeit akribisch studiert und zu nutzen gelernt haben. Damit hatten wir schon einmal die online Werkzeuge als Grundlage bereit. Klar war auch, dass der Zeitpunkt kommen wird, an dem Meetings und Veranstaltungen wieder vor Ort möglich sein werden. Davor jedoch werden Hybridmeetings Einzug halten und die Schedules bestimmen.

Gesehen und verstanden werden –  Jeder soll teilnehmen, nicht nur Zuschauer sein.

Mit diesem Blick in die Zukunft haben wir unsere Ausstattung, Infrastruktur und unser Wissen zu hybriden Meetings spezialisiert. Denn für Remote- als auch Vor-Ort-Teilnehmer gilt dasselbe: Sie wollen involviert und abgeholt und ihre Stimme soll gehört werden. So waren wir nach dem ersten Lockdown schon so vorbereitet, dass wir Veranstaltungsort für kleine Meetings und Workshops von Kunden waren, die uns ihr Vertrauen gaben und wir es bestätigen konnten.

Wir sorgen dafür, dass Personen, die von zu Hause aus teilnehmen, kein Gefühl des stillen Zuschauers haben und sich ins Meeting einbringen können. Über Mikrofone und Kameras wird unser großer Meetingraum „Eastside Gallery“ sowohl akustisch als auch visuell in Gänze erfasst. Die Teilnehmer daheim haben somit eine gute Möglichkeit, alle anderen Personen zu sehen, zu hören und gleichzeitig selbst gut gesehen und verstanden zu werden.

Das Know-How, das wir als Trainingsanbieter in diversen remote Trainings sammeln konnten, lassen wir hier einfließen und geben es an unsere Kunden weiter. Sei es, wenn es um die Entscheidungsfindung des richtigen Remote-Tools oder des technischen Setups der Kamera- und Soundeinstellungen geht.

DC Spaces als Facilitator der Agile Tour Vienna/ Vom Experiment zur Konferenz

So waren die DC Spaces Veranstaltungsort für die Agile Tour Vienna 2020. Auch das Organisations-Team der Agile Tour Vienna stand vor der Entscheidung, ob und wie man die Konferenz durchführen kann. Mehreren hundert Personen sollte eine spannende und interaktive Konferenz geboten werden. Lesen Sie hier mehr über die Planung und Durchführung der Agile Tour Vienna 2020. Mit dem technischen Know-How und der Größe unserer Räume konnte bei uns diese online Konferenz im hybriden Format durchgeführt werden. Wir durften sogar einige wenige Teilnehmer vor Ort begrüßen und ihnen ein angenehmes und sicheres Konferenzerlebnis bereiten. Zusätzlich zu den klassischen Talks standen auf der Agenda „Panel Discussions“. Diese wurden hybrid (Speaker vor Ort als auch remote) gehalten. Passend dazu thematisierte die Panel Discussion „Remote Austria“ wie man sich auf die neuen Gegebenheiten auf Unternehmensebene und im Privatleben einstellen musste.

Die Vorbereitung auf die Konferenz war ebenfalls absolutes Neuland für uns als Team. Wie sollen wir etwas organisieren, was wir noch nie praktisch durchgeführt haben? Da das „TechTalk Teamevent 2020“, eine TechTalk interne Veranstaltung bei dem normalerweise eine Fahrt in ein Hotel geplant und einige Open Space Diskussionsrunden mit anschließenden Abendessen, abgesagt werden sollte, haben wir dieses Event hybrid über Hopin (ein Konferenz-Tool welches wir bei der Agile Tour Vienna einsetzen wollten) durchgeführt. Dieses interne Event, als Vorbereitung für die eigentliche Konferenz, in einem Safe-To-Fail Environment abzuhalten und daraus zu lernen, war für uns besonders wichtig. Das Feedback, welches wir von unseren Kollegen erhalten haben, zeigte uns die Stolpersteine auf, sowie Verbesserungsvorschläge, die wir sowohl für die Agile Tour Vienna also auch für alle weiteren hybriden Veranstaltungen nutzten.

Standards und Vertrauen

Mit der Erfahrung und dem Wissen, welche wir in verhältnismäßig kurzer Zeit generieren konnten, haben wir es geschafft, dass Meetings, Workshops und Kurse wieder zuverlässig geplant und veranstaltet werden können. Präventiv bieten wir für Veranstalter und ihre Teilnehmer Antigen-Schnelltests an, um sicher zu gehen, dass niemand unbewusst Überträger ist.

Natürlich finden alle unsere Veranstaltungen im Rahmen der von der Regierung vorgegebenen Maßnahmen statt. Zusätzlich vertrauen wir auf die Vernunft unserer Gäste, sich an Abstandsregeln zu halten und bei etwaigen Symptomen ihre Eventteilnahme abzusagen.

Mit unserem Konzept und dem Verständnis unserer Gäste haben wir es geschafft, nach dem ersten Lockdown eine Normalität und Sicherheit in die Planung und professionelle Durchführung von Meetings sowie jeglichen hybriden Veranstaltungen zu gewährleisten.

Wenn Sie auch Unterstützung bei einem Meeting oder Kunden-Event benötigen, ganz egal in welchem Format, dann kontaktieren Sie uns. Wir evaluieren gemeinsam die beste Lösung und unterstützen Sie bei der erfolgreichen Durchführung Ihrer Veranstaltung.

Selbstorganisation und Verantwortung in der agilen Welt – Müssen jetzt alle Häuptlinge sein?

Im Rahmen des agilen Arbeitens erhält Selbstorganisation einen sehr hohen Stellenwert und damit auch die Rolle der Verantwortung. Man möchte weg von einer HiPPO-Entscheidung (Highest Paid Persons Opinion) oder dem LVD (loudest voice dominates) hin zu einer Entscheidung, die dort getroffen wird, wo die Information liegt, die notwendig ist, die beste Entscheidung zu treffen (siehe auch Intent-Based Leadership). 

Bei agilen Transformationen und bei neu aufgestellten Agilen Teams kommt es bei dieser Neuverteilung der Entscheidungskompetenz manchmal zu Widerständen. Es gibt Ängste für Fehlentscheidungen verantwortlich gemacht zu werden und eine Unsicherheit aufgrund der neuen „Last“, die die neue Verantwortung mit sich bringt.  

Es stellt sich die Frage – „Inwiefern müssen alle Menschen selbstbestimmt sein und Verantwortung übernehmen?“. Diese Frage stellte Markus Knopp im Rahmen einer Open Space Session der Freiräume Unkonferenz, die Mitte November stattfand. Aus dieser Session möchte ich zwei Erkenntnisse teilen.  

Räume aufmachen und Räume schließen 

Es ist wichtig, v.a. in der Rolle als Scrum Master, Agile Coach oder Führungskraft, zu reflektieren welche Freiräume offen sind und wo es hilft einzelnen Personen und dem Team diese auch wieder zu schließen. Beispiele für das „Schließen“ von Freiräumen sind z.B. das detailliertere Vorgeben von Regeln und Rahmenbedingungen oder Entscheidungen für das Team (vorläufig) treffen. Das Schließen von Räumen kann helfen den Fokus auf ein Thema zu lenken und dem Team oder Einzelnen auch Schutz und Sicherheit zu geben, um voran zu kommen. 

Ein Beispiel aus der Praxis: Es kann den Mitarbeitern helfen einen Fokus in der Weiterbildung zu treffen, wenn eine strategische Technologieentscheidung im Unternehmen klar getroffen und kommuniziert wird.  

Für die Gestaltung und Diskussion dieser Freiräume, z.B. in Bezug auf ein Team, gibt es auch methodische Möglichkeiten zum Beispiel mit dem Delegation Poker, um Verantwortlichkeiten zu diskutieren, sichtbar zu machen und zu vereinbaren.  

Das Team als wichtiges Element in der Selbstorganisation 

Ein weiterer wichtiger Kernpunkt in der Diskussion war auch, dass die Verantwortlichkeit und Selbstorganisation nicht auf individueller Ebene betrachtet und gefordert werden soll, sondern dass dies auf Teamebene betrachtet wird.  

 „The best architecturesrequirements, and designs emerge from self-organizing teams.“ (Agile principle) 

Dabei ist es sinnvoll, das Team als eine Einheit zu betrachten – die einzelnen Individuen in diesem Team sind dann mehr oder weniger selbstorganisiert, sind diverse Persönlichkeiten und ergänzen sich im Idealfall gut. In einem Teamgefüge ist es sogar wünschenswert, dass nicht alle Personen Häuptlinge sind.  

Die Conclusio für uns zur Selbstorganisation und Verantwortung war: Das Team ist selbstorganisiert und verantwortlich, und nicht das Individuum. Das Team trägt das Individuum mit. 

„Für eine wirklich gelungene Veranstaltung braucht man sowohl Bühnenmenschen als auch Publikum.“ (Zitat Teilnehmerin im Open Space) 

Und manchmal muss die Selbstorganisation auch über eine Teamgrenze hinaus betrachtet werden, vor allem, wenn Teams zusammenarbeiten bzw. Abhängigkeiten haben. Dies ist z.B. in Scrum of Scrums oder SAFe relevant. Hier spielt dann wieder das Öffnen und Schließen von Räumen eine Rolle, denn es kann nicht jedes Team völlig unabhängig von anderen Teams selbstorganisiert Entscheidungen treffen, sondern es müssen klare Verantwortlichkeiten und Entscheidungsrahmen vorhanden sein. 

Von „Doing Agile“ zu „Being Agile“

Bleiben Sie Up2Date mit unseren Interviews und Artikeln zu Agile Transformation. Für Agile Experts, Change Leader, Digital Transformation Experts.

Für einen tiefergehenden Austausch stehen meine Coach-Kollegen gerne zur Verfügung. Mehr zur Stärkung der Verantwortung im Team durch eine neue Art des Leadership gibt es auch im Rahmen des Intent-Based Leadership Trainings von Jenni Jespen. 

Weiterführende Literatur:  

Questions About Test Frameworks: Q&A Part #3 with J.B. Rainsberger

This is the third chapter of our three-part Q&A blog series with J. B. Rainsberger. In this chapter he adresses questions about „Questions About Test Frameworks. The first chapter and the second chapter is in our blog in case you missed it.

On June 3, 2020 J.B. Rainsberger spoke in our remote Intro Talk about managing the various kinds of uncertainty that we routinely encounter on projects that involve legacy code. He presented a handful of ideas for how we might improve our practices related to testing, design, planning, and collaboration. These ideas and practices help us with general software project work, but they help us even more when working with legacy code, since legacy code tends to add significant uncertainty and pressure to every bit of our work. Fortunately, we can build our skill while doing everyday work away from legacy code, then exploit that extra skill when we work with legacy code.


J. B. Rainsberger helps software companies better satisfy their customers and the business that they support.

Our next remote course Surviving Legacy Code from 12 – 15 April 2021.


If the code base is too old even for any available test frameworks, how you handle it?

**Testing does not need frameworks. Testing never needed frameworks.** You can always start by just writing tests and refactoring them. If you do this long enough, you will extract a testing framework. If you’ve never tried it, then I recommend it! Kent Beck’s _Test-Driven Development: By Example_ included this exercise.

Every test framework began life with `if (!condition) { throw Error(„Test failure.“) }`. If you can write this, then you can build a testing framework; if this suffices, then you don’t need a testing framework. Start there!

If you can execute one part of the system in isolation from the rest, then you can write unit tests. In the early days of web browsers, we could only execute Javascript in the browser, because even so, we could (and did!) write unit tests without frameworks. We merely had to run those tests in a browser window. Eventually, someone decided to run Javascript outside the browser, which made it easier to write microtests for Javascript code. This made it _easier_ to write tests, but we were writing tests long before NodeJS existed.

If you can invoke a function (or procedure or division or block of code) and you can signal failure (such as by raising an error), then you can write tests without waiting for someone else to build a framework.

In addition, you don’t need to write your tests in the same language or environment as the running system. Golden Master technique helps us write tests for any system that offers a text-based interface. Any protocol could help us here: for example, think of HTTP as „merely“ a special way of formatting requests and responses with text. If you have (or can easily add) this kind of interface or protocol to your system, then you can write tests in any language that might offer a convenient test framework. Use Python to test your COBOL code. Why not?

Finally, not all testing must be automated. As I wrote earlier, programmers have a strong habit of forgetting alternatives to techniques that they’ve found helpful. If you don’t know how to automate your tests easily, then don’t automate them yet. Instead, make them repeatable and document them. One day, someone will have a good idea about how to automate them.

You may have to write your own test framework but it can prove a daunting task.

In addition to what I wrote in the previous answer, I encourage you to follow the general advice about building any software with a Lightweight (Agile, Lean, …) approach: build the first feature that you need, then start using it, then add more features one at a time. You don’t need to build a fully-featured testing framework before you start to benefit from it. Start with `if (!assertion) throw Error()` and then use it! The testing framework SUnit was built incrementally. All the testing frameworks you know began from there. You can do it, too. Merely start, then take one step at a time.

You also need this refactoring-without-tests skill, to effectively refactor your tests!

Maybe! I don’t say you _need_ it, but it would probably help you. Your production code helps you to refactor your tests: if you change your tests and they now expect the wrong behavior, then your production code will fail that test for „the right reasons“. It doesn’t provide perfect coverage, but it helps more than you might expect. In that way, the production code helps to test the tests.

There are testing frameworks for COBOL and NATURAL. What could be older?

Indeed, the „framework“ portion of testing relates to identifying tests, collecting test results, and reporting them in a unified way, as well as adding standard mechanisms for „set up“ and „tear down“. We don’t need those things to start writing tests, although eventually we will probably want to have them. **Simply start writing tests, then remove duplication in any way that your programing language allows.** I don’t know what might be older than COBOL or NATURAL.


➡️ Also read our last two Q & A Blogposts with J.B. Rainsberger Part #1 „Managing the Uncertainty of Legacy Code“ and Part #2 „The Risks Related to Refactoring Without Tests„! Follow us on Twitter or LinkedIn to get new posts.


The Risks Related to Refactoring Without Tests: Q&A Part #2 with J.B. Rainsberger

This is the second chapter of our three-part Q&A blog series with J. B. Rainsberger. In this chapter he adresses questions about „The Risks Related to Refactoring Without Tests. The first chapter and the third chapter is in our blog in case you missed it.

On June 3, 2020 J.B. Rainsberger spoke in our remote Intro Talk about managing the various kinds of uncertainty that we routinely encounter on projects that involve legacy code. He presented a handful of ideas for how we might improve our practices related to testing, design, planning, and collaboration. These ideas and practices help us with general software project work, but they help us even more when working with legacy code, since legacy code tends to add significant uncertainty and pressure to every bit of our work. Fortunately, we can build our skill while doing everyday work away from legacy code, then exploit that extra skill when we work with legacy code.


J. B. Rainsberger helps software companies better satisfy their customers and the business that they support

Our next remote course Surviving Legacy Code from 12 – 15 April 2021.


What we should say to project planners who are afraid to let us do refactoring without tests, because some folks in our team are not very good at refactoring and make mistakes? How to convince them it can work for some good programmers?

First, I recognize that if I were the project planner, then I would worry about this, too! I probably don’t know how to judge the refactoring skill of the programmers in the group, so I wouldn’t know whom to trust to refactor without tests. Moreover, I probably can’t calculate the risk associated with refactoring without tests, so I wouldn’t know when to trust _anyone_ to refactor without tests, even if I feel confident in their skill. Once I have thought about these things, it becomes easier to formulate a strategy, because I can ask myself what would make _me_ feel better in this situation? I encourage you to ask yourself this question and write down a few ways that you believe you could increase your confidence from the point of view of the project planner. I can provide a few general ideas here.

I encourage you to build trust by telling the project planner that you are aware of the risks, that you care about protecting the profit stream of the code base, and that you are prepared to discuss the details with them. It often helps a lot simply to show them that you and they are working together to solve this problem and not that you are doing what helps you while creating problems for them.

I would ask the project planners what specifically they are worried about, then matching my strategies to their worries. For example, microcommitting provides one way to manage the risk of refactoring without tests, because it reduces the cost of recovering from a mistake. At the same time, if the project planner worries about different risks than the ones I have thought about, then my strategies might not make them feel any more secure! If I know more about which risks affect them more or concern them more, then I can focus my risk-management work on those points, which also helps to build trust.

I would emphasize that we do not intend to do this as a primary strategy forever. We don’t feel comfortable doing it, either! Even so, we _must_ make progress _somehow_. We refactor without tests because it would be even more expensive to add „enough“ tests than to recover from our mistakes. Of course, we have to be willing to explain our judgment here and we have to be prepared that we are wrong in that judgment! I am always prepared to take suggestions from anyone who has better ideas, but outside of that, they hired me to do good work and make sound decisions, so if they don’t trust me, then I must try to earn their trust or they should give my job to someone that they trust more. I don’t mean this last part as a threat, but merely as a reminder that if they hire me to do the job, but they never trust me, then they _should_ hire someone else!

How about pair-refactoring?

I love it! Refactoring legacy code is often difficult and tiring work, so pair-refactoring fits well even in places where „ordinary“ pair programing might not be needed. Refactoring legacy code often alternates periods of difficulty understanding what to do next with long periods of tedious work. Working in pairs significantly increases the profit from both of those kinds of tasks.

You also need this refactoring-without-tests skill, to effectively refactor your tests!

Maybe! I don’t say you _need_ it, but it would probably help you. Your production code helps you to refactor your tests: if you change your tests and they now expect the wrong behavior, then your production code will fail that test for „the right reasons“. It doesn’t provide perfect coverage, but it helps more than you might expect. In that way, the production code helps to test the tests.

Moreover, tests tend to have simpler design than the production code. This means that we might never need to refactor tests in certain ways that feel common when we refactor production code. I almost always write tests with a cyclomatic complexity of 1 (no branching), so the risk when refactoring tests tends to be much lower than when refactoring legacy code. This makes refactoring tests generally safer.


➡️ Also read our two Q&A Blogposts with J.B. Rainsberger Part #1 The Risks Related to Refactoring Without Tests“ and Part #3 „Questions About Test Frameworks„! Follow us on Twitter or LinkedIn to get new posts.


Agile at Scale: How „The Spotify Model“ came to life and how it can be applied in a remote-work environment

Joakim Sunden
Consultant at Crisp

Joakim Sunden was one of the Agile Coaches at Spotify working together with the CTO to develop a new approach to Agile at scale, aka “The Spotify Model” with Tribes, Squads, Chapters and Guilds. He is also a well-known figure in the agile community, having organized and spoken at many international conferences and community events over the years. In 2016 he held a keynote at Agile Tour Vienna, since then we partner with Joakim and also offer a training course about SAFe and the „The Spotify Model“. For this post, we asked Joakim how „the Spotify Model“ came to life and how it evolved since then.

How would you explain the Agile at Scale (Spotify Model) to someone who has never heard about it?

There’s no short answer to that so you’ll have to bear with me for some background story. Back in 2011 when I joined Spotify we had fewer than ten teams, or squads as we could come to call them. But we already experienced some growing pains and we knew that we would grow a lot as we had big plans and a lot of VC funding. We wanted to desperately avoid the increased bureaucracy and slow speed many of us had experienced with other big companies so we tried to come up with a new way of organizing ourselves to stay agile even at scale.

At it’s core it’s all about trusting the people you hire to do a great job and support them the best you can without getting in their way. This is why we called the core of our org an “autonomous squad”, a 5-10 people small and empowered product development team who are free to make a lot of more choices than any other team I had ever worked with in the past. Not just how to build things, but also to a large extent what to build. Within bounds of course.

One example of such bounds is the product direction, or goal, of your tribe. Each squad was part of a mission, or product area, called a “tribe”, together with maybe four to ten other squads. The Tribe Trio leadership would set a direction in dialogue with the squad and upper management, within which the squads would have freedom to explore different experiments to push the metrics the right way. Leadership is all about supporting you, making sure you have clarity of direction and everything you need to get there, in terms of skills, resources, decision power, etc.

How can you apply some of Spotify’s organizational structures and practices to your SAFe ARTs?

That’s also true for your closest manager who leads the functional area, or Chapter as our name was, you’re part of together with 5-10 coworkers with similar skill sets. Kind of a matrix model where the manager is a servant leader responsible for your development and success rather than for making decisions and relaying information, and so on.

On a surface level this is what most people understand as “the Spotify Model”; Squads, Chapters, and Tribes. Because that’s the visible most apparent structural parts of it. In practice it’s much more about mindset, culture, leadership, all those things that’s really different and makes it tick, but harder to observe and understand. And that’s what we drill down into in the course. That and the finer mechanics of some of what we learned along the way and from living with this model and evolving it  for several years.

So the first white paper on the Spotify model came out in 2012. What has happened since then?

Wow, a lot really… One of the most concrete things that we abandoned rather quickly after the paper came out was the idea that a Chapter Lead, that is, an engineering manager, should work 50% as a manager and 50% as an individual contributor in a squad. That simply didn’t work, it was too much. Which is not to say that it’s not the right thing for other companies to be doing, but it didn’t work for us with very high expectations on the people development part of the role.

Great experience. Completely realistic view. Down to earth presenter.

– Attendee feedback, Agile at Scale Workshop with Joakim Sunden in 2019

This is by the way a reason I don’t want to talk a lot about changes to Spotify’s way of working, since people seem to perceive it as some kind of evolution and “what Spotify’s doing now must be so much better than the old white paper, so let’s take a short cut and go straight to where they are now”. How Spotify evolved is not necessarily the way your organization needs to evolve. What was working well at some point in one context may not be working well in another context. In an organizations of Spotify’s size there’s now also multiple different solutions to similar problems in different parts of the company. Some held on to the Chapter Lead model while others tried other approaches to solve for other problems, reach other goals.

So rather than talking about the evolution of a specific model we spend a lot of time in the course talking about what we learned from different things, the thinking behind it, how things evolved. All with the goal of course participants being better equipped to solve their own issues themselves when they get back to work. Using Spotify as an inspiration, for different types of solutions, but also the approach to change and problem solving that we applied. And not just Spotify, we drew inspiration from plenty of sources ourselves, and so should you of course.

Can the Spotify model also be applied in a remote work environment?

Absolutely! Spotify was early on a distributed company with product development in Stockholm, Gothenburg, New York and San Francisco. Later we added Boston, where I lived and worked for a few years, and more recently London. So a remote work environment was there pretty much from the start for me.

Working in a remote environment it’s even more important to let go of control and trust your people and teams to work autonomously to solve problems. It’s even more important to have good practices in place for collaborating and communicating, to create clarity of direction and communicate progress when working remotely.

When I left Spotify and started consulting with companies I was shocked to learn how bad most of them were at remote work practices and how many companies just lack the tools to be able to collaborate efficiently in a remote environment. Even though the course is very little about remote work practices per se, indirectly it’s a lot about supporting that way of working. Since we’re also running it remote, participants will be able to learn some really good tools for remote workshops, should they not already be familiar with them.  

Managing the Uncertainty of Legacy Code: Q&A Part #1 with J.B. Rainsberger

In this first chapter of our three-part Q&A blog series he adressed questions that came up during his session.

On June 3, 2020 J.B. Rainsberger spoke in our remote Intro Talk about managing the various kinds of uncertainty that we routinely encounter on projects that involve legacy code. He presented a handful of ideas for how we might improve our practices related to testing, design, planning, and collaboration. These ideas and practices help us with general software project work, but they help us even more when working with legacy code, since legacy code tends to add significant uncertainty and pressure to every bit of our work. Fortunately, we can build our skill while doing everyday work away from legacy code, then exploit that extra skill when we work with legacy code.

Our next remote course Surviving Legacy Code from 12 – 15 April 2021.

J. B. Rainsberger helps software companies better satisfy their customers and the business that they support.

Here are some questions that came up during this session and some answers to those questions.

One of the issues is that the legacy code base consists of useful code and dead code and it’s hard to know which is which.

Indeed so. Working with legacy code tends to increase the likelihood of wasting time working with dead code before we feel confident to delete it. I don’t know how to avoid this risk, so I combine monitoring, testing, and microcommitting to mitigate the risk.

Microcommits make it easier to remove code safely because we can recover it more safely. Committing frequently helps, but also committing surgically (the smallest portion of code that we know is dead) and cohesively (portions of code that seem logically related to each other) helps. If our commits are more independent, then it’s easier to move them backward and forward in time, which makes it easier to recover some code that we mistakenly deleted earlier while disturbing the live code less. We will probably never do this perfectly, but smaller and more-cohesive commits make it more likely to succeed. This seems like a special case of the general principle that as I trust my ability to recover from mistakes more, I feel less worried about making mistakes, so I change things more aggressively. When I learned test-driven development in the early years of my career, I noticed that I become much more confident to change things, because I could change them back more safely. Practising test-driven development in general and microcommitting when working with legacy code combine to help the programmer feel more confident to delete code—not only code that seems dead.

Even with all this, you might still feel afraid to delete that code. In that case, you could add “Someone executed this code” logging statements, then monitor the system for those logging statements. You could track the length of time since you last saw each of these “heartbeat” logging messages, then make a guess when it becomes safe to delete that code. You might decide that if nothing has executed that code in 6 months, then you judge it as dead and plan to remove it. This could never give us perfect confidence, but at least it goes beyond guessing to gathering some amount of evidence to support our guesses

More testing, especially microtesting, puts more positive pressure on the design to become simpler: less duplication, better names, healthier dependencies, more referential transparency. I have noticed a pattern: as I simplify the design, I find it easier to notice parts that look irrelevant and I find it clearer that those parts are indeed dead code. Moreover, sometimes obviously dead code simply appears before my eyes without trying! This makes it safer to delete that code, using the microcommitting and monitoring as a recovery strategy in case I get it wrong.

So not all legacy code adds value to the business… but it is hard to know which part does.

Indeed so. We have to spend time, energy, and money to figure this out. I accept responsibility as a programmer to give the business more options to decide when to keep the more-profitable parts running and to retire the less-profitable parts. As I improve the design of the system, I create more options by making it less expensive to separate and isolate parts of the system from each other, which reduces the cost of replacing or removing various parts. Remember: we refactor in order to reduce volatility in the marginal cost of features, but more-generally in the marginal cost of any changes, which might include strangling a troublesome subsystem or a less-profitable feature area.

The Strangler approach describes incrementally replacing something in place: adding the new thing alongside the old thing, then gradually sending traffic to the new thing until the old thing becomes dead. Refactoring the system to improve the health of the dependencies makes this strangling strategy more effective, which gives the business more options to replace parts of the legacy system as they determine that a replacement would likely generate more profit. As we improve the dependencies within the system, we give the business more options by reducing the size of the smallest part that we’d need to replace. If we make every part of the system easier to replace, then we increase the chances of investing less to replace less-profitable code with more-profitable code.

This illustrates a general principle of risk management: if we don’t know how to reduce the probability of failure, then we try reducing the cost of failure. If we can’t clearly see which parts of the legacy code generate more profit and which ones generate less, then we could instead work to reduce the cost of replacing anything, so that we waste less money trying to replace things. This uses the strategy outlined in Black Swan of accepting small losses more often in order to create the possibility of unplanned large wins.

What do you think about exploratory refactoring? Do you use this technique sometimes?

Yes, I absolutely do! I believe that programmers can benefit from both exploratory refactoring and feature-oriented refactoring, but they need to remain aware of which they are doing at any time, because they might need to work differently with each strategy to achieve those benefits.

When I’m refactoring in order to add a feature or change a specific part of the code, I remind myself to focus on that part of the code and to treat any other issues I find as distractions. I write down other design problems or testing tasks in my Inbox as I work. I relentlessly resist the urge to do those things “while I’m in this part of the code”. I don’t even follow the Two-Minute Rule here: I insist on refactoring only the code that right now stands between me and finishing the task. Once I have added my feature, I release the changes, then spend perhaps 30 minutes cleaning up before moving on, which might include finishing a few of those Two-Minute tasks.

The rest of the time, I’m exploring. I’m removing duplication, improving names, trying to add microtests, and hoping that those activities lead somewhere helpful. This reminds me of the part of The Goal, when the manufacturing floor workers engineered a sale by creating an efficiency that nobody in the sales department had previously thought possible. When I do this, I take great care to timebox the activity. I use timers to monitor how much time I’m investing and I stop when my time runs out. I take frequent breaks—I use programming episodes of about 40 minutes—in order to give my mind a chance to rise out of the details and notice higher-level patterns. I don’t worry about making progress, because I donI ’t yet know what progress would look like—instead I know it when I see it. By putting all these safeguards in place, I feel confident in letting myself focus deeply on exploring by refactoring. I avoid distracting feelings of guilt or pressure while I do this work. I also feel comfortable throwing it all away in case it leads nowhere good or somewhere bad. This combination of enabling focus and limiting investment leads me over time to increasingly better results. As I learn more about the code, exploratory refactoring turns into feature-oriented refactoring, which provides more slack for more exploratory refactoring, creating a virtuous cycle.

What is your experience with Approval Tests, in cases where writing conventional unit tests might be to expensive?

I like the Golden Master technique (and particularly using the Approval Tests library), especially when text is already a convenient format for describing the output of the system. I use it freely and teach it as part of my Surviving Legacy Code course. It provides a way to create tests from whatever text output the system might already produce.

I get nervous when programmers start going out of their way to add a text-based interfaces to code that doesn’t otherwise need it only for the purpose of writing Golden Master tests. In this case, checking objects in memory with equals() tends to work well enough and costs less. I notice it often that programmers discover a helpful technique, then try to use it everywhere, then run into difficulties, then invest more in overcoming those difficulties than they would invest in merely doing things another way. Golden Master/Approval Tests represents merely another situation in which this risk comes to the surface.

I get nervous when programmers start choosing to write integrated tests for code where microtests would work equally well. When programmers think about adding Golden Master tests, they tend to think of these as end-to-end tests, because they often judge that as the wisest place to start. Just as in the previous paragraph, they sometimes fall into the trap of believing that “since it has helped so far, we must always do it this way”. No law prevents you from writing unit tests using Golden Master/Approval Tests! Indeed, some of the participants of my Surviving Legacy Code training independently discover this idea and use it to great effect. Imagine a single function that tangles together complicated calculations and JSON integration: it might help a lot to use Approval Tests to write Golden Master tests for this function while you slowly isolate the calculations from the JSON parsing and formatting. The Golden Master tests work very well with multiline text, such as values expressed in JSON format, but probably make the calculation tests awkward, compared with merely checking numeric values in memory using assertEquals().

When programmers use Golden Master/Approval Tests, they need to treat it as just one tool in their toolbox. This is the same as with any technique! I tend to treat Golden Master as a temporary and complementary technique. I use it when I focus on writing tests as a testing technique, even though I tend to prefer to write tests for design feedback. Not everyone does this! If you find yourself in the stage where you’re drowning in defects and need to focus on fixing them, then Golden Master can be a great tool to get many tests running early. Once you’ve stopped drowning, it becomes easier to look at replacing Golden Master with simpler and more-powerful unit tests—eventually microtests.


➡️ Also read our two Q&A Blogposts with J.B. Rainsberger Part #2 The Risks Related to Refactoring Without Tests“ and Part #3 „Questions About Test Frameworks„! Follow us on Twitter or LinkedIn to get new posts.


Unsere Trainings: Natürlich auch Remote!

Genau wie alle anderen Teile der TechTalk musste auch der Trainingsbereich, dessen Herz natürlich die erst kürzlich neu geschaffenen DC Spaces sind, auf die neue Situation reagieren.

Daher stellen wir unser Trainingsangebot auf Remote-Kurse um, bei denen Sie mit unseren internationalen Speakern virtuell interagieren können. Da wir bei TechTalk sowie unsere Trainer langjährige Erfahrung mit Remote-Arbeit haben, können wir auf dieses Wissen bei der Organisation von unseren neuen Kursformaten zurückgreifen.

Die ersten Trainings, die wir vollständig remote durchführen, sind:

Agile at Scale, Inspired by Spotify

mit Joakim Sunden, 19-22 April 2021

Automated Acceptance Testing and Story- Driven Development

mit Dave Farley, 23.-24 September 2021

Weitere Remote-Kurse und kostenfreie Meetups/Workshops werden wir in Kürze bekanntgeben. Folgen Sie uns auf LinkedIn oder Twitter, um die Ankündigung nicht zu verpassen.