Sie haben Fragestellungen, die Sie mit anderen Teilnehmer:innen diskutieren möchten? Sie möchten mit Ihrer Erfahrung anderen Teilnehmer:innen eine Perspektive auf Fragen anbieten? Dann sind Sie beim Lean Coffee genau richtig. Denn im Lean Coffee bestimmt die Gruppe, welche Themen für wie lange diskutiert werden, um den maximalen Nutzen des Austauschs zu erreichen. 

Lean Coffee ist ein strukturiertes agenda-loses Meeting-Format, bei dem die Teilnehmer:innen die Tagesordnung durch die Themen, die sie einbringen, selbst bestimmen. 

Treten Sie in den Austausch mit Gleichgesinnten und diskutieren die aktuellen Themen rund um das Thema „Testen", „Qualität“ oder was auch immer in diesem Moment gerade wertvoll ist.

Corona hat vieles verändert und vieles möglich gemacht, was vorher nicht denkbar war. Wie hat sich das auf die Ausbildung der Mitarbeiter und die Möglichkeiten für Trainer ausgewirkt.
Vorher waren in bei vielen Unternehmen nur Präsenz-Schulungen denkbar. Während Corona haben alle Schulungen mit Online-Präsenz und neuen Methoden stattgefunden und was bleibt uns nun? Kehren wir zu alten Verhaltensweisen zurück? Machen wir alles Online oder gibt es gute und neue Wege für die Ausbildung. 
Sind vielleicht auch die Art und Weise und die Inhalte der Schulungen nun andere. Müssen wir anders bzw. anderes schulen?

Wie sieht ein optimales Zusammenspiel zwischen automatisierten Regressionstests und weiterhin notwendigen manuellen Tests für ein Release aus? Mehrere Teams arbeiten in Sprints an Wartung und Weiterentwicklung der Beispielanwendung, das vor der monatlichen Produktivsetzung in mehreren Umgebungen zu testen ist. Auf automatisierte Regressionstests folgen in den Testumgebungen je Deployment manuelle Tests. Vorbereitung und Durchführung der automatisierten Tests sind mit den manuellen Tests abzustimmen, um im finalen Quality Gate zu einer fundierten Freigabeentscheidung zu kommen. Optimierungschancen bieten sich mit jedem Release.

Ever wondered how experienced testers provide feedback quickly, discover unknown unknowns, and find that issue yet again on the first touch of the application? Let's lift the curtain together and discover the magic behind exploratory testing - as an ensemble. Whether you identify yourself as a developer, product person, tester, or anything else, whether you consider yourself a newbie or rather experienced, you are welcome to join this ensemble. Let's practice and explore together!

Maximum number of participants: 25

Target Audience: Testers, developers, product owners, UX, business analysts - anyone on a product development team
Prerequisites: Participant required equipment: Laptop with permission to install applications
Level: Basic

Documentation costs money and time. Still it is required in regulated industries and is needed to be able to maintain large scale software projects.Most projects are trapped in a world with a limited ability to e.g. maintain versions and baseline. It puts people in silos, requires handovers with cost and loss of information.Coming from waterfall, Siemens Healthineers identified documentation handling as major enabling for engineering efficiency. A process and tool change was initiated to introduce collaborative, seamless, actionable documentation.Follow me on the journey from first pilot to successful migration a project.

Target Audience: Testers, QA Engineers, Test Managers, Developers, Business/Product Owners
Prerequisites: None
Level: Advanced

Extended Abstract:
Nobody likes writing documentation. It costs money and time, it is boring, nobody knows when and how it is used. Still it is required in regulated industries. Software development documentation like requirements and test cases etc. is needed to be able to maintain large scale software projects.Most software projects are trapped in a documentation tooling with a limited ability to maintain versions, baseline, trace between dependencies and link between planning and documentation. Often documentation tooling is project phase specific (e.g. requirements management or test case design) and puts people in silos and requires handovers with cost and loss of information. Coming from waterfall, Siemens Healthineers identified software development documentation handling as major enabling for engineering efficiency in agile. A process and tool change was initiated to introduce collaborative, comprehensive, seamless, actionable, lightweight, controlled documentation that is always up-to-date with the software itself. Follow me on a journey from first pilot to successful migration in a whole project. Learn about culture change and return on invest. Celebrate with me the results, there is something in for everybody. Most benefits are for testers who get early and flexible design input. Testers can showcase the impact of any test results to requirements and release at a push of a button. Even the product can benefit from the ability to focus on value stream.

Die Testpyramide von Mike Cohn dürfte den meisten Entwicklern ein Begriff sein. Aber beinhalten die Tests in Ihrem Projekt auch die Verifikation der Anwendungssicherheit? Im Kontext von agiler Entwicklung und Continuous Delivery ist ein 'Shift-Left' mit konkreten Security-Anforderungen und einer kontinuierliche Prüfung der Sicherheit essentiell. In diesem Talk werden wir die bekannte Testpyramide einmal aus der Sicherheitsperspektive betrachten. Wir werden lernen wie man effektive Sicherheitstests auf jeder Ebene der Pyramide hinzufügt. Dies wird durch entsprechende Live-Demos begleitet.

Zielpublikum: Architekten, Entwickler, Tester
Voraussetzungen: Grundlegende Java-Kenntnisse
Schwierigkeitsgrad: Advanced

Extended Abstract:
Die Testpyramide von Mike Cohn dürfte den meisten Entwicklern ein Begriff sein und wird innerhalb der testgetriebenen Entwicklung vielfach in Projekten eingesetzt.
Aber beinhaltet die Testpyramide auch die Verifikation der Anwendungssicherheit?

Im Kontext von agiler Entwicklung und Continuous Delivery ist eine kontinuierliche Prüfung der Anwendungssicherheit essentiell. Das heute häufig immer noch praktizierte Muster mit Penetrationstests kurz vor dem Produktivgang skaliert hier nicht mehr. 

Vielmehr müssen in jedem Sprint konkrete Anforderungen an die Sicherheit formuliert werden, welche dann mit entsprechenden (möglichst automatisierten) Tests verifiziert werden können. Nur so läßt sich ein wirkunsvolles Shift-Left für die Sicherheit erreichen.

In diesem Talk werden wir die bekannte Testpyramide einmal aus der Sicherheitsperspektive betrachten. Wir werden uns anschauen wie man effektive Sicherheitstests auf jeder Ebene der Pyramide hinzufügt. Auf diese Weise läßt sich tatsächlich ein großer Teil der OWASP Top 10 Sicherheitskategorien automatisch abtesten. 

Dies wird anhand von Live-Demos auf Basis einer Spring Boot Java Applikation mit automatisierten Tests u.a. für Authentifizierung, Autorisierung, Eingabevalidierung und SQL-Injection-Prevention praktisch veranschaulicht.

Historisch gewachsene Test-Suites testen oft gleichzeitig Zuviel und Zuwenig. Zuviel, da sie Tests enthalten, die Kosten erzeugen, aber kaum Mehrwert gegenüber ähnlichen Tests bieten. Zuwenig, da trotzdem wichtige Funktionalität ungetestet bleibt. Im Vortrag stelle ich Analysetechniken vor, die das auf Basis der eigenen Daten aufzeigen (u.a. Test-Gap-Analyse, Historienanalyse von Fehlern und Pareto-Optimierung von Tests). Ich zeige für jede Analyse die zugrundeliegenden Konzepte aus der Forschung und unsere Erfahrungen im Einsatz in der Praxis.

Zielgruppe: Tester, Test-Manager, Entwickler, Architekten.

Die Auswahl von Testfällen aus einer Menge vorhandener Tests erfolgt in aller Regel anhand der Erfahrungen der Test-Manager oder Tester. Wir haben untersucht, inwiefern dabei Methoden der Künstlichen Intelligenz Unterstützung bringen. Welche Metriken können hier zum Einsatz kommen? Ist ein Neuronales Netz oder doch ein Entscheidungsbaum der effektivere Algorithmus? Und lässt es sich mit wenigen Zeilen Code in eine bestehende Testautomatisierung einbauen?

Zielpublikum: Tester, Testautomatisierer, Testmanager, Projektleiter
Voraussetzungen: Grundlagen SW-Test und Testautomatisierung, Grundlegende Java-Kenntnisse von Vorteil, aber nicht zwingend
Schwierigkeitsgrad: Advanced

Extended Abstract:
Eine Glaskugel, ob ein Test bei der Ausführung in Zukunft PASSED oder FAILED liefern wird, können wir leider nicht anbieten. Einen Algorithmus, der anhand von Daten früherer Testausführungen eine Wahrscheinlichkeit berechnet, ob ein Tests FAILED sein wird, hingegen schon. Im Rahmen des Vortrags werden wir diesen Ansatz vorstellen, verschiedene Metriken diskutieren (Letzte Ergebnisse, Ähnlichkeit von Testnamen, ...) und einen Vergleich verschiedener Machine-Learning-Methoden durchführen (kNN, DNN, SVM, Hoeffting-Tree). Die dabei entstandene Bibliothek 'CurrantRunner' ist auf GitHub als OpenSource verfügbar , demonstriert das Vorgehen am Beispiel von TestNG + JaCoCo + Maven und ist im entsprechenden Kontext sofort einsetzbar.

Continuous Security testing is becoming more and more a key factor for success. Especially if we consider that the development and release process is speeding up enormously. Just imagine that your potential shippable product is going to production with a huge vulnerability or a back door open. The damage to your company and bad reputation would be even not measurable.
So how can we avoid this? How can we build- security -in? Let's leave the stone age behind, break down the security silo. In my talk I will show you how the four fists get implemented in your DevSecOps team and how they will improve your product's quality! 

Target Audience: Testers, Developers, Product Owner, decision makers
Prerequisites: none
Level: Advanced

Extended Abstract:
Continuous Security testing is becoming more and more a key factor for success. Especially if we consider that the development and release process is speeding up enormously. Just imagine that your potential shippable product is going to production with a huge vulnerability or a back door open. The damage to your company and bad reputation would be even not measurable.
So how can we avoid this? How can we build- security -in? Let's leave the stone age behind, break down the security silo and implement DevSecOps.

During my talk, I will tell you where you can implement and improve security testing. What different kinds of functional and non-function security testing methods are available and what are the low-hanging fruits.
On a high level, I will explain SAST / DAST / IAST / RASP and how your team could implement these methods with examples. Then I will lift it to the next level and show how you can add
security testing to your pipeline to get fast feedback to fix the vulnerabilities at a very early stage (shift left). By showing where to implement security tests in your software development lifecycle, I will explain where it makes sense
to have security as a deep skill part of your team and go for DevSecOps!

After I increased our transparency of security and showed you how to deal with 'the four fists', I will close my talk by presenting the 10 successful steps to DevSecOps.

Transformationen bedeuten gewollte Veränderungen. Wir ändern Rollen, Prozesse und Artefakte, mal mit mehr Erfolg, mal mit weniger. Aber wie sieht es mit unseren Testmetriken aus? Klar, Scrum und anderen agile Vorgehensweisen sind empirisch und bauen auf dem Dreiklang Transparenz, Inspektion und Adaption auf. Aber genügen unsere Testmetriken einem empirischen Anspruch und schaffen sie wirklich die Transparenz, die wir benötigen, um im Sinne von Inspektion und Adaption eine gezielte Qualitätssteuerung vornehmen zu können?
Im Rahmen dieses Vortrags zeige ich das Spannungsfeld auf, das sich aus traditionellen Testmetriken und dem agilen Manifest ergibt und welche Implikationen sich daraus ergeben. Sie lernen ergänzend mit dem CIRA-Modell einen Ansatz kennen, der Metriken nutzt, um die agile Selbststeuerung zu fördern. Weiterhin werde ich eine Möglichkeit zur Bewertung von Testmetriken hinsichtlich ihrer Sinnhaftigkeit und ihres Nutzens aufzeigen, der die Ideen Cem Kaners zu diesem Thema aufgreift, wie sie bspw. aus den BBST Kursen bekannt sind. Der Aufhänger werden agile Testmetriken sein, die Bewertungsmöglichkeit ist jedoch unabhängig vom Softwareentwicklungsmodell.

Zielpublikum: Tester*innen, Testmanager*innen, Projektleiter*innen, Agile Coaches
Voraussetzungen: Grundlegendes Verständnis von Softwareentwicklung und Testen
Schwierigkeitsgrad: Basic

Die Sicherheit von Web-Anwendungen ist ein schnell-lebiges Thema mit ständig neuen Schwachstellen. Als Tester ist es schwierig, damit in der täglichen Arbeit Schritt zu halten. Wir werden uns daher die neuen Einträge in den OWASP Top 10 der schwerwiegendensten Schwachstellen von Webanwendungen ansehen und wie man diese mit Methoden und Werkzeugen des Sicherheitstestens addressieren kann: Insecure Design, Software and Data Integrity Failures, sowie Server-Side Request Forgeries (SSRF). Konkret werden wir uns in Praxisaufgaben damit beschäftigen, wie man diese Schwachstellen mittels des Werkzeugs SonarQube finden und beheben kann.

Maximale Teilnehmerzahl: 15

Zielpublikum: Tester, Entwickler, Testmanager, Projektleiter mit Interesse an sicheren Web-Anwendungen
Voraussetzungen: Grundlegende Kenntnisse im Softwaretest
Schwierigkeitsgrad: Basic

Extended Abstract:
Jedes Jahr werden zigtausende Schwachstellen in Softwareanwendungen bekannt, mit desaströsen Auswirkungen für die Reputation der betroffenen Entwickler und die Daten ihrer Kunden, oft mit signifikanten finanziellen Schäden.
Die Sicherheit von Web-Anwendungen ist dabei ein schnell-lebiges Thema, bei dem ständig neue Schwachstellen relevant werden. Als Tester ist es schwierig, damit in der täglichen Arbeit Schritt zu halten
Wir werden uns daher die neuen Einträge in den OWASP Top 10 der schwerwiegendensten Schwachstellen von Webanwendungen ansehen und wie man diese mit Methoden und Werkzeugen des Sicherheitstestens addressieren kann: Insecure Design, Software and Data Integrity Failures, sowie Server-Side Request Forgeries (SSRF). Konkret werden wir uns in Praxisaufgaben damit beschäftigen, wie man diese Schwachstellen mittels des Werkzeugs SonarQube finden und beheben kann.
Beim Sicherheitstesten müssen wir dabei wie ein Angreifer denken können. In diesem Tutorial werden wir uns daher in das Gehirn des Angreifers schleichen und auf seine Art zu denken lernen. Dazu basiert das Tutorial auf einem praktischen Einsatz des Softwareanalysewerkzeugs SonarQube seitens der Teilnehmer. So werden wir lernen, wie wir die dort umgesetzten Sicherheitstests nutzen können und diese automatisch ausführen lassen können. Diese Tests spiegeln die Best Practices in der Entwicklung sicherer Web-Anwendungen wieder.
Das Tutorial ist entlang praktischer Übungen mittels open-source Werkzeugen für das Sicherheitstesten strukturiert, für die ein eigener Laptop mitgebracht werden sollte. Konkret sind dies u.a. die Software-QS-Plattform SonarQube, die wir für Sicherheitstests verwenden werden. Dabei werden wir aus erster Hand erfahren, wie Angreifer bei der Schwachstellensuche vorgehen, was uns dabei hilft, solche Schwachstellen zu vermeiden.

Je älter und größer Softwaresysteme sind, desto wichtiger ist eine verlässliche, automatisierte Testsuite. Da die Suite (und deren Ausführungsdauer) jedoch mit wächst, kommt ihr Feedback immer später, was das Lokalisieren von Fehlern erschwert. Eine wirksame Lösung ist, eine Teilmenge der Tests häufiger auszuführen. Zur Auswahl einer solchen Teilmenge haben wir Pareto-Testing und die Test-Impact-Analyse entwickelt. Im Vortrag stellen wir beide Ansätze vor und berichten vom Einsatz bei der Bayerischen Versorgungskammer, wo wir sie auf der großen automatisierten Testsuite eines komplexen Softwaresystems angewendet und verglichen haben.

Zielpublikum: Tester, Testmanager, Projektleiter
Voraussetzungen: Basiswissen über automatisiertest Testen.
Schwierigkeitsgrad: Advanced

Extended Abstract:
Je älter und größer ein Softwaresystem ist, desto wichtiger ist eine verlässliche, automatisierte Testsuite. Insbesondere, wenn viele Änderungen umgesetzt und kurze Release-Zyklen angestrebt werden. Mit der Größe des Systems wächst jedoch die Testsuite, und damit steigt auch deren Ausführungsdauer. Wir sehen bei unseren Kunden immer öfter Testsuites, die mehrere Stunden oder sogar Tage laufen. Langlaufende Testsuites werden aber meist seltener ausgeführt als schnelle, z.B. wöchentlich statt täglich. Dadurch müssen Entwickler länger auf Feedback warten, was es ihnen erschwert, die Ursache für fehlschlagende Tests zu lokalisieren. Ironischerweise mindert das den Wert der Testsuites gerade für die Systeme, für die sie besonders wichtig sind.

Ein wirksamer Lösungsansatz ist, eine Teilmenge mit viel kürzerer Laufzeit häufiger auszuführen, z.B. stündlich. Wenn diese Teilmenge gut gewählt ist, findet sie einen Großteil der Fehler in sehr kurzer Zeit, und die gesamte Testsuite kann weiterhin wöchentlich ausgeführt werden, um den Rest der Fehler zu finden. Damit erreichen wir, trotz langsamer Testsuite, sehr schnelles Feedback für die meisten Fehler.

Dieser Ansatz steht und fällt natürlich mit der Auswahl der Teilmenge an Tests, die häufig ausgeführt werden. Hierfür haben wir in den letzten Jahren zwei unterschiedliche Ansätze entwickelt: Pareto-Testing und Test-Impact-Analyse. Im Vortrag stellen wir erst die Grundideen und Forschungsergebnisse vor und dann die Erfahrungen, die wir bei der Bayerischen Versorgungskammer damit gesammelt haben, als wir beide Ansätze auf der großen automatisierten Testsuite eines komplexen Softwaresystems angewendet und verglichen haben.

Applikationssicherheit gehört mittlerweile zu den höchsten Prioritäten in Unternehmen.

Doch während bzgl. Infrastruktur und Netzwerk die Sicherheitsstandards sehr hoch sind, gibt es noch häufig Sicherheitslücken auf Applikationsebene.

Dabei passieren die meisten Angriffe genau hier!

Um Applikationen möglichst sicher zu entwickeln, müssen die verantwortlichen Teams – Entwickler, Tester und die Sicherheits-Verantwortlichen – Hand in Hand arbeiten.

Gleichzeitig sollten die Vorgehensweisen und die entsprechende Lösung optimal in den DevOps-Prozess integriert sein. HCL stellt mit der Lösung HCL AppScan eine unternehmensweite Sicherheitsplattform zur Verfügung, die alle Kriterien abdeckt: Vom Code-Scanning über dynamisches Scanning (Simulation von Hackerangriffen) und das Auffinden von sicherheitskritischen 3rd-Party Bibliotheken (Stichwort: Log4J) bis hin zu einem einheitlichen Dashboard.

Sehen sie wie HCL AppScan all diese Teilbereiche über die verschiedenen Gates von der Entwicklung bis hin zur Produktion schützt und wie die verschiedenen Teams voneinander profitieren.

Außerdem wird gezeigt, wie die Ergebnisse in eine Value-Stream Management Lösung integriert werden können, um alle agilen- und DevOps-Aspekte auf einer einheitlichen Ebene zu veranschaulichen.

Dadurch kann der Ist-Zustand objektiv bewertet werden und ermöglicht zielgerichtete Verbesserungen.

During my career in IT and people development I had several turning points where I either was made to use journaling techniques or experimented with them myself to successfully tackle the next challenge. Over the years I reflected why those 'written self-reflection' techniques are so powerful and - at the same time - they are still quite rarely used in the business context.

Maximum number of participants: 40

Extended Abstract:
During my career in IT and people development I had several turning points where I either was made to use journaling techniques or experimented with them myself to successfully tackle the next challenge. Over the years I reflected why those 'written self-reflection' techniques are so powerful and - at the same time - they are still quite rarely used in the business context.

In this workshop I will happily share my experience and my findings backend by a scientific psychological model with you!

You want to leverage your resources?
You want to change habits in your life's 'departments'?
You want to harvest outstanding outcomes - at work and beyond?
YES? Then join us to get ready for ACTion and be inspired how to leverage journaling techniques for yourself, for teams and for your organization. We'll even use our hands, hearts and minds to directly try out some of them!

Seit Jahren spricht die Community über Automatisierung. Aber wie bringt man in der Praxis in kurzer Zeit Automatisierung ans Laufen? Wir zeigen Beispiele für erfolgreiche Automatisierung in Projekten der Deutschen Bundesbank. Die Projektteams haben einen modernen Open-Source Stack für Testautomatisierung mit BDD sowie Automatisierung im Bereich Infrastruktur aufgebaut. Stakeholder sind nun in der Lage auf Knopfdruck aus JIRA heraus komplette Testumgebungen zu erstellen, dort ihre Tests automatisiert auszuführen und Analysen der Ergebnisse zu bekommen. Du lernst hier wie ein solches Projekt aufgesetzt und die Lösung skaliert werden kann.

Zielpublikum: alle, die Kontakt zu Test haben
Voraussetzungen: keine
Schwierigkeitsgrad: Basic

Extended Abstract:
Seit Jahren sprechen wir in der Community über Automatisierung jeglicher Art wie bspw. Testautomatisierung oder Infrastruktur. Viele Ansätze aus Agile Testing, DevOps, etc. sind den meisten theoretisch bekannt. Aber wie sieht es in der Praxis aus? Wie schafft man es in kurzer Zeit die Methodik + Tools + Skills wirklich 'ans Laufen' zu bringen?In diesem Vortrag zeigen wir mehrere Beispiele für erfolgreiche Automatisierung in Projekten der Deutschen Bundesbank. Es handelt sich um Projekte von 10 bis >100 Personen. Diese Teams haben es geschafft einen modernen Open-Source Stack für Testautomatisierung mit BDD sowie komplette Automatisierung im Bereich Infrastruktur (Docker, Kubernetes, Rancher, Jenkins, etc.) aufzubauen und miteinander zu verheiraten. Jegliche Stakeholder in Projekten sind jetzt in der Lage 'auf Knopfdruck' innerhalb von wenigen Minuten komplette Umgebungen (komplexe Host-Systeme inkl. sämtlicher Einschränkungen eines Banking-Systems) zu erstellen, dort ihre Tests automatisiert auszuführen und Analysen der Testergebnisse automatisiert zu bekommen. Das ganze zentral aus JIRA heraus und im Umfeld komplexer Tests für den Zahlungsverkehr. So geht Testautomatisierung in der Bankwelt heute! Als Zuhörer:in lernst Du wie ein solches Projekt aufgesetzt werden kann, welche Stolpersteine wir dabei lösen mussten und wie eine solche Lösung skaliert werden kann. Das ganze sehr praxisnah an realen Beispielen aus Großprojekten mit einer guten Dosis Spaß an der Arbeit :)

In the digital economy, customer perception is the only reality, but the complexity of testing across digital interactions and physical transactions boundaries can blur the real user experience. 

In this session, we will explore two unique use cases that highlight the importance of testing the human experience within the digital world:

The challenges that millions of remote workers face today is how to collaborate better with more effective interactions and engagements. By design, digital workforce collaborations extend an integrated and immersive experience to meet that challenge, but it expands a chain of workflows across applications that can be difficult to test. 

Taking a shift-right testing approach is needed to engage directly with end-users to understand their behaviors and reactions to new choices and actions.

 Time to market impacts lives. Releasing faster means testing and building faster. Jonathon will also share real-world examples of testing the software for the introduction of COVID contact tracing, and the rollout to over 30 countries and different languages. 

It’s more important than ever to gain a better understanding of real-world user journeys. In this talk, you will learn: Simple Automated Tests (SAT), Model-Based Testing (MBT) patterns, and Image-Based Testing (IBT) of mobile wallets and blockchain.

Key Takeaways:

Real-world examples of the shift-right approach 

How to apply real-world patterns MBT from part 8 of the ISO 29119 standard

Observability of complex real-world oracle meta test data (i.e. hyper-baselining)

 Attend the session to learn about digital twin testing in the physical world (MBT/IBT), and test data engineering and analytics to discover how they are revolutionizing test automation.

Lewis Deep Democracy wurde von Myrna und Greg Lewis in Südafrika in der Nach-Apartheid-Zeit entwickelt. Die Methode dient im Kern dazu, alle Stimmen hörbar zu machen, die Minderheiten ernst zu nehmen, und ihre „Weisheit“ zu integrieren. Wenn Menschen nicht gehört werden, weil sie beispielsweise in der Minderheit sind, entstehen Spannungen. Wir erleben diese Spannungen häufig als Widerstand. In diesem Vortrag lernen wir, die Widerstände zu deuten, das darin liegende Wissen zu nutzen, und wie wir damit die Beziehungs- und Gruppendynamik in einen positiven Fluss bringen.