oose.
Welcome to your Competence Navigator oose
English

Baukasten für Kundenseminare

Projekte sind vielfältig. Schulungen hingegen häufig von der Stange. Das wollen wir ändern! Damit ihr eine Schulung bekommt, die euren Bedürfnissen entspricht, haben wir etwas neues entwickelt. Mit unserem innovativen Baukastensystem könnt ihr die Inhalte auswählen, die am besten zu euch passen. Klickt einfach auf die Kacheln, um weitere Infos zu den Modulen zu erhalten. Wenn euch der Inhalt interessiert, zieht die Kachel einfach in einen leeren Slot.

Falls ihr unsicher seid, welche Module für euch geeignet sind, oder wenn ihr bereits einige interessante Module habt und weitere Empfehlungen wünscht, stehen wir euch gerne zur Verfügung. Kontaktiert uns und wir helfen euch dabei, die richtige Auswahl zu treffen.

Bitte beachtet, dass das Absenden eurer Auswahl keine verbindliche Bestellung darstellt, sondern lediglich euer Interesse an den gewählten Modulen aus dem Baukastensystem bekundet. Nachdem ihr eure Auswahl abgeschickt habt, werden wir uns mit euch in Verbindung setzen und einen gemeinsamen Termin vereinbaren, um die Inhalte weiter zu präzisieren und die Rahmenbedingungen der Schulung zu klären. Wir freuen uns darauf, euch eine maßgeschneiderte Schulung zu bieten, die euren Anforderungen gerecht wird.

Jedes Modul hat eine Länge von 90 Minuten. Die Schulung beginnt am ersten Tag um 09:00 Uhr und endet um 17:00 Uhr, an den Folgetagen jeweils von 09:00 Uhr bis 17:00 Uhr und am letzten Tag von 09:00 Uhr bis 16:00 Uhr. DIe Zeiten sind jedoch individuell anpassbar.

i
+

Risikoorientierte Strategien entwickeln

Teamorientierter Umgang mit Produkt- und Projektrisiken

Risikoorientierte Strategien entwickeln

Produkt- und Projektrisiken sollten unterschiedlich behandelt werden. Aber wie?

Für jede Risikogruppe nutzen wir separate Methoden um die Risiken zu

  • bestimmen,

  • kategorisieren,

  • bewerten und

  • beherrschen.

Bei Projektrisiken liegt der Fokus auf Vermeidung der Eintrittswahrscheinlichkeit und besonders auf Notfallpläne wenn das Risiko eingetreten ist. hierzu lernen wir wie ein RisikoBoard uns dabei unterstützen kann.

Im Gegensatz dazu die Produktrisiken.

Hier fokussieren wir uns auf die Verringerung der Wahrscheinlichkeit des Eintretens von Risiken (Produktfehler). dies geschieht in .d.R. durch testen.

Mithilfe eines QualityTrees legen wir fest wo in unserem Produkt die Risiken mit dem höchsten BusinessImpact liegen.

Abgeleitet von der Risikohöhe, können wir uns dann im Team Regeln und Vorgehensweisen abstimmen (Z.B. in den DoD), um die Qualität des Produkts zielgerichtet zu steuern und zu messen.

Es gilt, das höchste Risiko zu verhindern, nämlich dass der Kunde die Fehler findet statt uns.

i
+

RiskStorming

Gemeinsam eine Risiko-Qualitätsstrategie entwickeln

RiskStorming

Wie sehen eigentlich die Produktrisiken aus?
Wie kann ich meine Strategie zur Risikominimierung verbessern?
Wer kümmert sich eigentlich um die Qualität?

Wenn dich diese Fragen umtreiben, kann Risk Storming helfen.

Das Testsphere-Kartendeck und die zugehörigen RiskStorming-Workshops haben die Testwelt im Sturm erobert.

In diesem Gamification-Workshop werden wir eine Methode kennenlernen, um Merkmale zu identifizieren, die eine Qualitätsstrategie leiten. Wir werden gemeinsam Risiken zu diesen Merkmalen aufdecken und festlegen mit welchen Vorgehensweisen und Techniken diesen am besten begegnet werden können.

i
+

Blackbox Testmethoden

Anforderungsbasierte Testfälle entwerfen

Blackbox Testmethoden

Abgeleitet von den Anforderungen, Userstorys und Spezifikationen ermitteln wir methodisch Testfälle. Zum Einen um nachzuweisen dass unser Produkt die Anforderungen erfüllt und zum Anderen dass es korrekt gebaut ist. hierfür lernen wir u. A. folgende Methoden:

  • Äquivalenzklassenbildung

  • Grenzwertanalyse

  • Entscheidungstabellentest

i
+

Exploratives Testen

Erfahrung und Intuition gezielt für Tests nutzen

Exploratives Testen

Exploratives Testen ist gleichzeitiges Erstellen und Durchführen von Tests, um über das System zu lernen, indem Erkenntnisse aus dem letzten Experiment genutzt werden, um das nächste anzuregen. In diesem Modul werden wir aktiv Methoden und Vorgehensweisen anwenden, um Erfahrung und Intuition zu nutzen, um Tests zu entwerfen und Erkenntnisse zu erlangen, die über das reine Abarbeiten eines anforderungsbasierten Klickleitfadens hinausgehen.

i
+

Whitebox Testmethoden

Strukturorientierte Testentwurfs-Methoden

Whitebox Testmethoden

Whitbox Testmethoden zielen auf die interne Struktur eines Testobjektes ab. Wir werden Methoden kennenlernen, um den korrekten Ablauf von Wegen durch bspw. den Code zu testen. Weiterhin werden wir Möglichkeiten kennenlernen, wie diese Methodiken auch gewinnbringend für das Testen von nutzerorientierten Abläufen wie etwa Prozessen nutzen können.

i
+

Abnahmetests

Ist unser Produkt auslieferungsfähig?

Abnahmetests

Wer macht eigentlich die Abnahmen? Und auf was muss ich eigentlich achten?

Um diese Fragen soll es u.a. gehen. Wir werden zunächst sehe welche Arten von Abnahmen es gibt und warum gerade in agilen Kontexten Abnahmen nicht ein erneuten Systemtest bedeuten. Vor diesem Hintergrund werden wir bewährte Ansätze und Hilfsmittel rund um das Thema Abnahmetests beleuchten.

i
+

ATDD Quick&Dirty

Akzeptanzkriterien frühzeitig klären und automatisieren

ATDD Quick&Dirty

Die Akzeptanzkriterien beschreiben was das Produkt leisten soll damit aus Sicht des Anfordernden die Userstory/Anforderung erfüllt ist. Diese Kriterien sollten im Team mit dem Anforderer oder einem Kundenvertreter besprochen und explizit gemacht werden.

ATDD (Acceptance test-driven development) geht noch einen Schritt weiter. Die testbaren Akzeptanz-Kriterien werden, zumeist in Tabellenform, mit real verwendbaren Daten und Werten versehen. Diese Tabellen sind so aufbereitet, dass sie direkt zur Automatisierung genutzt werden können.

Ansätze wie Datengetriebens Testen (data driven approach) und Schlüsselwort getriebenes Testen (keyword driven approach) unterstützen diesen Test-first-Ansatz.

Erwartungshaltung: Wenn alle Testfälle positiv durchlaufen sind, ist die Anforderung damit erfüllt.

Ziel ist es, die Anforderungen zu verstehen, die Akzeptanzkriterien anhand von Testfällen festlegen und die Tests zu automatisieren, dies alles bevor die erste Zeile Code geschrieben wurde.

i
+

Aufgaben- und Rollenschärfung im Team

Wer macht was im Team und über Teamgrenzen hinweg?

Aufgaben- und Rollenschärfung im Team

Das Team managt sich selbst. So in etwa ist der Ansatz z.B. bei Scrum. Nur wer oder besser welche Rolle im Team übernimmt denn welche aufgaben? Eventuell benötigen wir eine weitere Rolle um bisher offene Aufgaben zu übernehmen.

Des weiteren müssen wir uns Gedanken machen, wie wir Teamübergreifend Aufgaben verteilen und Koordinieren. Unser Team hat vielleicht eine Grenze, aber die ist nicht identisch mit den Tätigkeiten im Entwicklungsprozess.

Dies alles analysieren wir gemeinsam und schärfen das Rollenverständniss.

i
+

Testrahmenbedingungen

Testfokus und -Vorgehensweisen festlegen

Testrahmenbedingungen

Nicht jeder Test ist zu jedem Zeitpunkt sinnvoll. In diesem Modul werden wir uns der Thematik der Teststufen und der Schnittstellen widmen, um festzustellen, wann welche Tests sinnvollerweise durchgeführt werden können und über welche Schnittstellen wir mit dem Testobjekt interagieren wollen, um Dopplungen zu vermeiden. Im diesen Kontext werden wir uns auch der Frage widmen, warum es sinnvoll ist Testfälle und Testdaten voneinander zu trennen.

i
+

Grundlagen I

Warum testen wir?

Grundlagen I

Wir müssen Testen. Aber warum ist das so?

Ein Team sollte sich einmal die Zeit nehmen und sich da drüber einigen Warum wir Testen, Wer macht welche Aufgaben und wie werden die umgesetzt.

Ein gemeinsam verstandenes Konzept über die Vorgehensweisen und Ziele des Testens kann hilfreich sein um uns auf die Aufgaben zu fokussieren. Dies kann alle Tätigkeiten im Entwicklungszyklus betreffen. Am Ende soll ein gut getestetes Produkt das Team verlassen, von dem wir alle der Meinung sind, dass es dem Qualitätsanspruch genügt.

i
+

Grundlagen II

Unterschiedliche Sichtweisen auf das Testen

Grundlagen II

Testen ist nicht gleich Testen.

Es gibt eher Methodische Ansätze die eher normenorientiert sind aber auch agileAnsätze die eher auf die Intuition wert legen. Es gibt Richtungen die eher das kritische Hinterfragen in den Vordergrundstellen und weiter Schulen den Testens. Welche Ansätze und Grundsätze sind für unsere Aufgaben die richtigen? Wo liegen die Unterschiede und welche wollen wir nutzen? Diese Fragen klären wir mit dem Ziel zu verstehen was für euch die beste Vorgehensweise ist.

i
+

Reviewtechniken

Kosten sparen durch frühzeitige Qualitätssicherung von Dokumenten und Artefakten

Reviewtechniken

Laut Studien basieren etwa 80% der Fehlerkosten auf Anforderungsfehler. Diese Fehler Frühzeitig durch methodische und zielgerichtete Reviewtechniken erkennen und beseitigen ist Ziel dieses Blocks.

i
+

Testmetriken

Welche Metriken helfen mir?

Testmetriken

Wir nutzen Metriken zur Teststeuerung. Aber genügen unsere Metriken 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?

Wir werden eine Möglichkeit zur Bewertung von Metriken hinsichtlich ihrer Sinnhaftigkeit und ihres Nutzens kennenlernen, welche die Ideen Cem Kaners zu diesem Thema aufgreift, wie sie bspw. aus den BBST Kursen bekannt sind.

i
+

Usability-Testen (Grundlagen)

Wie benutzbar ist unsere Software? - Kommt der Kunde zurück oder das Produkt?

Usability-Testen (Grundlagen)

Lernt wie wir verständlich, erlernbar, benutzbar und selbsterklärend ist unser Produkt. Methodische Ansätze um die Usability messbar und vergleichbar zu machen. Testtechniken, wie User Interviews, Usabilitytests und Beobachtungen. Zeitgleich lernen wir, wie wir die Anforderungen an unser Produkt formulieren um die Messungen bewerten zu können. Wann ist gut wirklich gut genug?

i
+

Wissensverteilung

Methoden zur Wissensverteilung

Wissensverteilung

Interdisziplinäre, selbstorganisierte Teams haben alle Fähigkeiten im Team, um erfolgreich arbeiten zu können. Dies bedeutet auch, dass wir Wissen redundant verfügbar haben, um Ausfällen begegnen zu können und Wissensinseln und Flaschenhälse auflösen zu können. In diesem Modul werden verschiedene Methoden zur Wissensverteilung aktiv erlebt.

i
+

Kommunikation

Gemeinsames Verständnis schaffen mit BDD

Kommunikation

Kommunikation ist der vielleicht meistgenannte Faktor, wenn es um den Einfluss auf Projekterfolge geht - gleichzeitig aber auch, wenn es um Projektprobleme geht. Wir werden ausgehend von allgemeinen Kommunikationsmodellen Elemente des Behaviour Driven Developments kennenlernen, die die Kommunikation im Team stärken, um im Sinne des Dreiklangs aus Discovery, Formulation, Automation, den Austausch und das gemeinsame Verständnis zu schaffen, bevor wir überhaupt an das Schreiben und Automatisieren von Tests denken können.

i
+

Liberating Structures

Kollaborations- und Moderationstechniken für den gesamten Testprozess

Liberating Structures

Pair und Ensemble Testing haben ihren festen Platz im agilen Testens. Der Fokus liegt auf einer kollaborativen Testdurchführung. Aber wie kann man gemeinsam andere Testaktivitäten angehen? Hier kommen nun die Liberating Structures ins Spiel, deren Hauptaugenmerk darauf liegt, alle Anwesenden gleichermaßen zu involvieren. In diesem Modul werden Liberating Structures praktisch erfahren. Wir werden Kollaborations- und Moderationsmethoden kennenlernen, um in der Gruppe zusammen Lücken und Unzulänglichkeiten im Testprozess aufzudecken, Ideen zu generieren, diese Punkte zu adressieren, strukturiert nach Hilfe und Input für Testanalyse und Testspezifikation zu fragen und eine Teststrategie zu erstellen.

i
+

Fragentechniken für Tester

Techniken zum kritischen Hinterfragen

Fragentechniken für Tester

Wenn man Social Media glauben mag, steht Q.A. nicht nur für Quality Assurance, sondern auch für Question Asker. Das kritische Hinterfragen früh in den Entwicklungsphasen ist ein Aspekt der Testerrolle, der immer mehr an Bedeutung gewinnt. Aber wie stelle ich eigentlich Fragen? Oder wie stelle ich vielmehr die richtigen Fragen? Worauf muss ich beim Fragen achten, um für das Testen relevante Informationen zu bekommen? Genau diese Fragen werden wir nicht nur stellen, sondern auch eine erste Antwort darauf geben.

i
+

Übergreifende Qualitätsprozessanalyse

Gemeinsam im Prozess Fehlerquellen analysieren

Übergreifende Qualitätsprozessanalyse

Die beste Methode um qualitativ hochwertige Produkte herzstellen ist, wenn die Fehler gar nicht erst eingebaut werden. Hierzu muss der Entwicklungsprozess untersucht werden um mögliche "Kontaminierungspunkte" zu finden. Die Methode QualityStorming ist perfekt dafür geeignet um die eigenen Prozesse zu analysieren und da draus verbessernde Maßnahmen abzuleiten.

Um mit einem guten Prozess sehr gute Produkte zu erschaffen.

i
+

Entscheidungsmethoden für Teams

Methoden und Techniken um gemeinsam Entscheidungen zu treffen - Mehr als nur "Dafür/Dagegen"

Entscheidungsmethoden für Teams

Eine Abstimmung wo die Mehrheit entscheidet kann im schlechtesten Fall 49% der beteiligten verärgern. Besser sind Methoden die es ermöglichen Einwände zu integrieren, Widerstände zu messen oder Trends zu erkennen.

Gleichzeitig ist es hilfreich, wenn die Beteiligten den Unterschied, vor- und Nachteile zwischen Konsens und Konsent erkennen .

Methoden wir Fist-to-five, der Konsultative Gruppenentscheid oder eine einfache Widerstandsmessung sind Werkzeuge die Teams helfen tragfähige Entscheidungen zu treffen.

Alles unter dem Motto: Nichts ist in Stein gemeißelt oder auch "Always Beta"

i
+

Aus Fehlern lernen - HowTo Fehlerworkshops durchführen

Jeder Fehler ist ein Geschenk - Nutze diese Geschenke zu deinem Vorteil

Aus Fehlern lernen - HowTo Fehlerworkshops durchführen

Fehler als Chance nutzen um die eigene Entwicklung zu verbessern. Dies ist das Kredo was vermittelt werden soll. Mit Fehlerworkshops Maßnahmen entwickeln, die helfen Fehlerursachen zu bekämpfen und Fehler früher zu finden.

Weg von Fingerpointing, Schuldigensuche oder Verantwortungsabschieberei, hin zu konstruktiver Arbeit an den Grundursachen. So ist beispielsweise Komplexität eine typische Brutstätte von Fehlern.

Dies und viele weitere Gründe gilt es zu erkennen und zu bekämpfen

i
+

Pair und Ensemble Testing

Gemeinsam Testen

Pair und Ensemble Testing

Die Zeiten, in denen Tester alleine im stillen Kämmerlein saßen, sind zum Glück lange vorbei. Dennoch findet die Testdurchführung häufig alleine statt. Mit Pair Testing und Ensemble Testing gibt es jedoch Möglichkeiten auch dieses in der Gruppe zu gestalten, um vom vielfältigen Wissen vieler Köpfe profitieren zu können. Wir werden uns in diesem Modul also Möglichkeiten der kollaborativen Testdurchführung widmen.

i
+

DevOps-Testen

Testen in DevOps-Projekten verankern

DevOps-Testen

DevOps ist ein Begriff, der aktuell viel bemüht wird. In diesem Modul werden mit Flow, Feedback und Continuous Learning die drei Grundpfeiler von DevOps vorgestellt und beleuchtet, welche Auswirkungen diese auf das Testen haben.

Wie passen Testvorgehensweisen aus der klassischen Welt und insbesondere aus der agilen Welt mit DevOps zusammen? Welche Methoden können angewendet werden? Wo kommen etablierte Definitionen des Testbegriffs vielleicht auch an ihre Grenzen? Brauchen wir Shift Left? Brauchen wir Shift Right? Oder vielleicht beides?

Zu diesen Fragen wird es keine absoluten Wahrheiten geben, aber einige Gedanken und Praxiserfahrungen, die dabei helfen, sich selbst eine Antwort zu bilden, damit dem Thema Qualität auch in einer DevOps Welt der benötigte Stellenwert zukommt.

i
+

Automatisierungsarchitektur

Komponenten und Zusammenspiel innerhalb einer Testautomatisierung

Automatisierungsarchitektur

Architektur hat im Kontext des Softwaretestens zwei Ausprägungen. Einerseits müssen wir als Tester einen Überblick über die Architektur des Testobjektes haben, um dieses besser testen zu können. Andererseits müssen wir eine Testarchitektur haben, die uns sagt, wie die verschiedenen Werkzeuge interagieren und wie z.B. die Testdurchführungswerkzeuge mit dem Testobjekt interagieren. Mit Hilfe der generischen Testautomatisierungsarchitektur werden wir ein Werkzeug kennenlernen, um die individuelle Architektur des Projekts analysieren zu können.

i
+

Grundlagen der Testautomatisierung

Grundsätzliches Handwerkszeug der Testautomatisierung

Grundlagen der Testautomatisierung

Es ist nicht immer sinnvoll alles zu automatisieren.

Schlechte Testscripte sind schnell geschrieben aber meistens nicht Wartbar und sehr instabil. Handwerklich gute Testscripte setzen den Fokus von Anfang an auf die Wartung und Wiederverwendung.

Gleichzeitig klären wir, welche Arten von Scripten gibt es, wie wird ein agiler Regressionstest aufgebaut und wie was muss ein Testscript beinhalten.

Besonders in agilen Teams ist eine stabiler Regressionstest notwendig. Hierzu lernen was reife Testfälle sind und wie wir eine stabile Testausführen z. B. in der Nacht gewährleisten.

i
+

Transition

Übergang von klassischen zu agilen Projekten

Transition

Transition ist ja eigentlich nur ein schönes Wort für Schmerzen.

Stimmt nicht ganz, aber Transitionen können schmerzhaft sein und häufig auch wenig nachhaltig. Daher haben wir jetzt an dieser Stelle auch nicht die one size fits all Lösung, denn die gibt es nicht.

Was wir aber haben sind ein paar Strategien und Vorgehensweisen, die sich bewährt haben, um einer Transition höhere Erfolgschancen zu ermöglichen. Dazu gehören bspw. eine Vision oder der Umgang mit Hindernissen und betroffenen Personen.

i
+

Skalierungsframeworks

Agilität über Teamgrenzen hinaus

Skalierungsframeworks

Viele Frameworks gehen von einem Team, das an einem Projekt arbeitet, aus. In der Realität haben wir häufig Projekte, in denen mehrere Teams an einem Produkt arbeiten. Wir werden einen kurzen Überblick über möglichen Skalierungsframeworks bekommen, um möglichst wenig Reibungsverlust durch die Koordination der verschiedenen Teams zu bekommen. Weiterhin wird eine Bewertungsmethode vorgestellt, um verschiedene Frameworks anhand verschiedener Parameter zu beurteilen.

i
+

Teamübergreifende Strukturen und Abstimmungen

Wer entscheidet teamübergreifend im agilen Kontext? - Arbeit von Gilden, CoP und Boards

Teamübergreifende Strukturen und Abstimmungen

Ein Grund, warum viele erfolgreiche Unternehmen und Organisationen auf Agilität respektive selbstorganisierte Teams statt Management setzen ist: Gruppen treffen bessere Entscheidungen als einzelne Personen.

Aber um diesen Gruppenvorteil ausspielen zu können, bedarf es einer gewissen Grundhaltung. Hier gilt der Leitsatz, "Die Qualität eines Gruppenergebnisses lebt und stirbt mit der Qualität der Moderation und Kollaboration".

Die meisten agilen Frameworks betrachten das einzelne Team mit all seinen Aspekten. Weniger tief behandelt wird die Frage, wie und wer entscheidet bei 30 agilen Teams?

Hierzu könnte ein Gremien-Ansatz ähnlich wie eine Gilde oder Cop helfen. Der Teamübergreifende Aspekt einer solchen Gruppe ist dabei ausschlaggebend. Die Qualität der Ergebnisse dieser Gruppe allerdings... Da sind wir wieder bei dem Leitsatz von eben.

i
+

Retros für Tester

Methoden zur kontinuierlichen Testverbesserung

Retros für Tester

Retrospektiven und Lessons Learned sind ein fester Bestandteil agiler Ansätze wie bspw. Scrum, gleichzeitig werden sie häufig als zeitliche Belastung und überflüssig wahrgenommen und entfalten wenig Wirkung. In diesem Modul werden wir bewährte Moderationstechniken für Retrospektiven kennenlernen, um deren Wert und Akzeptanz zu steigern.

i
+

Scrum Intro für Tester und Teams

Das Grundwissenpaket für Scrum

Scrum Intro für Tester und Teams

Scrum ist das verbreiteste agile Vorgehensmodell. In diesem Modul werden wir die Grundzüge von Scrum beleuchten und mit einigen populären Missverständnissen aufräumen.

i
+

Agile Grundlagen für Tester und Teams

Grundlagen und Rahmenbedingungen von Agilität

Agile Grundlagen für Tester und Teams

Was ist eigentlich Agilität? In diesem Modul werden wir uns mit den Kernprinzipien von Agilität beschäftigen: Welche Leitsätze und Prinzipien tragen Agilität und welche Rahmenbedingungen werden benötigt, damit der Begriff nicht nur zum Buzzword verkommt.

i
+

Open Space

Ihr arbeitet moderiert an Euren eigene Themen

Open Space

Die eigentlich interessanten Gespräche auf Konferenzen finden an der Kaffeemaschine statt.

Diesem Gedanken folgend ist Open Space ein Format, dass den organisatorischen Rahmen für einen Austausch bereitet, die Themen selber jedoch von den Teilnehmenden kommen, so dass hier ein sehr breites Spektrum vom Themen potentiell addressiert wird. Im Open Space finden mehrere Themen gleichzeitig statt, so dass sich die Teilnehmenden auf die Themen konzentrieren können, an denen sie wirkliches Interesse haben.

i
+

Ask Me Anything

Nutzt die Möglichkeit das Wissen der Trainer anzuzapfen

Ask Me Anything

Der Name ist Programm. Die Teilnehmenden sammeln Fragen an die Trainer und priorisieren diese. Die Trainer versuchen diese dann zu beantworten. Und Ask Me Anything heißt nicht umsonst so: Die Fragen können sich wirklich um alles drehen.

i
+

World Cafe

Gemeinsam an Themen arbeiten

World Cafe

Mit einem World-Café eröffnen die Einladenden den Gästen mit relativ wenig Aufwand und professioneller Anleitung einen sicheren Raum, um die verschiedenen Sichtweisen auf – und verschiedene Herangehensweisen an ein Thema voneinander kennenzulernen, Muster zu entdecken und Ziele und Zusammenhänge zu erkennen, neue Umgangsformen kennenzulernen, kooperativ zu werden, genau hinzuhören, zu hinterfragen, konstruktiv zu diskutieren und so gemeinsam Probleme aufzulösen.

i
+

Lean Coffee

Gesprächsthemen sammeln, priorisieren und diskutieren

Lean Coffee

Lean Coffee ist ein Austauschformat, in dem die Teilnehmenden zunächst Themen sammeln, diese gemeinsam priorisieren und die Themen dann in festgelegten Zeitfenstern anhand der selbstgewählten Priorisierung besprechen.

design.day 1

close
add Tag hinzufügen
Du kannst maximal 4 Tage belegen.

FAQ

  • Wie funktioniert der Seminarbaukasten?

    Wähle die Themen aus die für dich interessant sind, fülle das Formular aus und wir melden uns mit einem Angebot bei dir zurück.

  • Wie lange ist ein Modul?

    Jedes Modus hat eine Länge von 90 Minuten.

  • Warum kann ich an Tag 1 und am letzten Tag nur 3 Module auswählen?

    Der jeweils erste und letzte Tag hat ein festes Modul.
    Anfang: Begrüßung, Vorstellung, Erwartungen
    Ende: Transfer, Retro, Feedback

  • Was passiert mit meinen Daten?

    Die Daten werden in einer E-Mail an uns geschickt und anschließend gelöscht.

  • Was ist, wenn ich nicht weiß, welche Module passen?

    Solltest du nicht wissen, welche Module passend sind, dann fülle einfach das Kontaktformular aus und wir melden uns zeitnah bei dir für ein Klärungsgesprach.

Anfragen

 Maximilian Voigt

Any questions? I'll be happy to help you.

Maximilian Voigt
maximilian.voigt@oose.de
+49 40 414250-17