Product Developers Practices - LeSS in Action
on-site course
-
Munich, Germany
München
-
English
Englisch
Deutsch
- FREE
- Kostenlos
.svg)
You Don't Like the Course
You Don't Like the Course
Organizational Agility is constrained by Technical Agility. The 5-day development practice course is 70% hands-on and 30% lecture and has three main focuses: Large-Scale Scrum, technical practices, and authentic team dynamics.
Organisatorische Agilität wird durch technische Agilität eingeschränkt. Der 5-tägige Entwickler-Praxiskurs besteht zu 70% aus praktischen Übungen und zu 30% aus Vorträgen und hat drei Schwerpunkte: Large-Scale Scrum, technische Praktiken und authentische Teamdynamiken.
Price
Preis
The standard price is 2,490.00€ (net) excl. VAT.
The early bird price, 5 weeks before the training is 1990.00€ (net) excl. VAT.
Group bookings of 3 people or more receive a 650.00€ discount per person on the standard price || Private courses on request.
Der reguläre Preis beträgt 2.490,00€ (netto) zzgl. MwSt.
Der Frühbucherpreis bis 5 Wochen vor dem Termin beträgt 1.990,00€ (netto) zzgl. MwSt.
Gruppenbuchungen ab 3 Personen erhalten pro Person 650,00€ Rabatt auf den regulären Preis || Privatkurse auf Anfrage.
Information about the course
Informationen zum Kurs
- A comprehensiveprovisionalCertified LeSS Practitioner Training on organizational agility
- Globally recognizedpCLP® &CLP® Certificate from the LeSS Company®
Experience true agility during a simulation building a product
Practice new thinking tools that guide you in your transformation
Leave with action plans and resources
The 5-day development practice course is 70% hands-on and 30% lecture and has three main focuses: Large-Scale Scrum, technical practices, and authentic team dynamics. It covers Scrum practices such as cross-team Sprint Planning, Backlog Refinement, working as a team, and many technical practices such as Test-Driven Development, Continuous Integration, Acceptance Test-Driven Development, and Refactoring. It also covers how to apply these practices in a legacy codebase situation.
Who is this class for:
We don't expect participants to have prior knowledge of the tech stack listed below, including the programming languages or domain. People are welcome to the class as long as they are fluent software developers.
We also allow 1~2 non-current developers (e.g., a ScrumMaster or PO) in each class, as long as they have some development experience and promise to work as a developer in a team in the class. So far, their feedback is even better than the developers:-) It's probably due to the opportunity to observe a team from within and the others doing their job.
Current Tech Stack:
We chose a particular stack so that people do real work in the class, but the specific stack doesn't matter so much for participation. Our current stack is:
- a web service (https://doughnut.odd-e.com)
- VueJS 3 on the frontend using TypeScript
- Spring Boot backend using Java and MySQL
- various external service dependencies
- Cypress for end-to-end testing
- Github Action for CI/CD
- Google Cloud for production
The source code is here: https://github.com/nerds-odd-e/doughnut
Monday:
- Requirement workshop / A-TDD
- Definition of Done
- Cucumber and Friends
- Sprint Plannings
Tuesday:
- Test-Driven Development
- Collaboration (Working in teams, SCM, Build Automation and other tools, Pair Programming, Continuous Integration and CI Systems, Collective Code Ownership)
Wednesday:
- Code Smells & Refactoring
- Thinking about test and test automation (Testing Pyramid, Mocking, Unit testing in other languages: JavaScript, Python, etc., Good Unit Testing
Thursday:
- Thinking about Design
- Feature Team Revisit
Friday:
- Working with Legacy Code
- Craftsmanship
- Retrospective
Details :
Product Backlog Refinement Workshop
In Large-Scale Scrum, the PBR workshop is one of the most critical activities. By doing the workshop in the sprint with multiple teams, we will cover the three essential aspects of this workshop: splitting big items, detailing the items, and estimating. Some optional techniques we might cover based on the situation include: impact mapping, storying mapping, specification by example, estimation ceremonies, etc.
Definition of Done
What is the purpose of the Definition of Done? We will also talk about what it is about, how to use it, and who should ensure it.
Sprint Plannings
(Cross-team) Sprint Planning Part One is mainly covered by the PBR workshop since there's only one sprint. Sprint Planning Part Two will be explained and practiced in detail.
Acceptance Test-Driven Development with Cucumber and Friends
This part explains how to drive the iteration with the examples derived from the PBR workshop. We will discuss the detailed technical approaches, good practices, and conventions.
The actual teaching or lecture is usually delayed to the next couple of days until the participants have real experience struggling with the tools and process. Most of the learning should be from the practices and on-time coaching from the course instructors. Same as all the other technical practices
Test-Driven Development
From day 2, all the code needs to be written by TDD. Same as described above, We will explain the philosophy very quickly with a simple exercise. Most of the learning should come from hands-on coaching and practicing.
Collaboration
This part explains the fundamental techniques and practices that enable teams to collaborate in a Large-Scale Scrum situation. Including:
- Working in teams
- SCM, Build Automation, and other tools
- Pair Programming
- Continuous Integration and CI Systems
- Collective Code Ownership
The above is getting the participant ready to understand why things are happening in the way they are in Large-Scale Scrum.
Code Refactoring
This part covers the why, what, and how of code refactoring. We'll train people to have the nose to smell bad code and the techniques to remove the bad smells.
More on Test Automation
With both the automated acceptance test and unit test covered in the course, in this part, we go deeper into (automated) testing. Including:
- Real testing/exploratory testing
- Product-wise testing strategies
- Good automated testing
- Unit testing other programming languages
Thinking about Design
Here we discuss the difference between emergent design and the traditional design style that often happens in a waterfall process.
On top of that, we also talk about the design principles and paradigms.
Thinking about "real testing", again
Feature Teams
With all gained knowledge from the first four days, we will finally explore this organizational structure topic again and see the links between the technical practices and team approaching and feature teams.
Legacy Code
Based on the book by Michael Feathers, Working Effectively With Legacy Code, we discuss the way of working when the code is without good test coverage, and the knowledge about how the code works is lost.
Craftsmanship
We will discuss the alternative metaphor for software practitioners to map their careers and guide them.
Retrospectives
The training is over, the teams created in the course won't continue (usually). We will try to give people an experience of a good retrospective, learn to identify bad smells in a retrospective, and learn good techniques for running a retrospective. We will also cover how large organizations do retrospectives.
It's hard to document what we do in the course precisely. Because every time the teams will be working on different product backlog items and continue the product left by the previous class, many contents will be emergent.
Monday:
- Requirement workshop / A-TDD
- Definition of Done
- Cucumber and Friends
- Sprint Plannings
Tuesday:
- Test-Driven Development
- Collaboration (Working in teams, SCM, Build Automation and other tools, Pair Programming, Continuous Integration and CI Systems, Collective Code Ownership)
Wednesday:
- Code Smells & Refactoring
- Thinking about test and test automation (Testing Pyramid, Mocking, Unit testing in other languages: JavaScript, Python, etc., Good Unit Testing
Thursday:
- Thinking about Design
- Feature Team Revisit
Friday:
- Working with Legacy Code
- Craftsmanship
- Retrospective
Details :
Product Backlog Refinement Workshop
In Large-Scale Scrum, the PBR workshop is one of the most critical activities. By doing the workshop in the sprint with multiple teams, we will cover the three essential aspects of this workshop: splitting big items, detailing the items, and estimating. Some optional techniques we might cover based on the situation include: impact mapping, storying mapping, specification by example, estimation ceremonies, etc.
Definition of Done
What is the purpose of the Definition of Done? We will also talk about what it is about, how to use it, and who should ensure it.
Sprint Plannings
(Cross-team) Sprint Planning Part One is mainly covered by the PBR workshop since there's only one sprint. Sprint Planning Part Two will be explained and practiced in detail.
Acceptance Test-Driven Development with Cucumber and Friends
This part explains how to drive the iteration with the examples derived from the PBR workshop. We will discuss the detailed technical approaches, good practices, and conventions.
The actual teaching or lecture is usually delayed to the next couple of days until the participants have real experience struggling with the tools and process. Most of the learning should be from the practices and on-time coaching from the course instructors. Same as all the other technical practices
Test-Driven Development
From day 2, all the code needs to be written by TDD. Same as described above, We will explain the philosophy very quickly with a simple exercise. Most of the learning should come from hands-on coaching and practicing.
Collaboration
This part explains the fundamental techniques and practices that enable teams to collaborate in a Large-Scale Scrum situation. Including:
- Working in teams
- SCM, Build Automation, and other tools
- Pair Programming
- Continuous Integration and CI Systems
- Collective Code Ownership
The above is getting the participant ready to understand why things are happening in the way they are in Large-Scale Scrum.
Code Refactoring
This part covers the why, what, and how of code refactoring. We'll train people to have the nose to smell bad code and the techniques to remove the bad smells.
More on Test Automation
With both the automated acceptance test and unit test covered in the course, in this part, we go deeper into (automated) testing. Including:
- Real testing/exploratory testing
- Product-wise testing strategies
- Good automated testing
- Unit testing other programming languages
Thinking about Design
Here we discuss the difference between emergent design and the traditional design style that often happens in a waterfall process.
On top of that, we also talk about the design principles and paradigms.
Thinking about "real testing", again
Feature Teams
With all gained knowledge from the first four days, we will finally explore this organizational structure topic again and see the links between the technical practices and team approaching and feature teams.
Legacy Code
Based on the book by Michael Feathers, Working Effectively With Legacy Code, we discuss the way of working when the code is without good test coverage, and the knowledge about how the code works is lost.
Craftsmanship
We will discuss the alternative metaphor for software practitioners to map their careers and guide them.
Retrospectives
The training is over, the teams created in the course won't continue (usually). We will try to give people an experience of a good retrospective, learn to identify bad smells in a retrospective, and learn good techniques for running a retrospective. We will also cover how large organizations do retrospectives.
It's hard to document what we do in the course precisely. Because every time the teams will be working on different product backlog items and continue the product left by the previous class, many contents will be emergent.
Certification
Furthermore, after attending the course, you can claim up to 25 SEUs (Scrum Education Units) of category C for the Scrum Alliance CSP (Certified Scrum Professional).
Team- and organizational coaches
Agile coaches
Scrum Master
Organizational leaders and senior managers
Product Owner, produkt managers and stakeholders
Software engineers, hands-on technologists, designers
Business consultants
Eveyone who wants to know more about Scrum
Prerequisites
The only prerequisite to this Large-Scale Scrum Course is basic Scrum knowledge. That can be picked up by attending a Certified Scrum Master or a Professional Scrum Master course, or thoroughly reading Scrum introduction material such as the Scrum Primer and practicing Scrum.
You need a stable and fast Internet connection, a webcam, a headset, and an environment where you can focus and interact with others online if needed.
Recommended Preparation
Large-Scale Scrum Course participants should review Scrum introduction material such as the Scrum Primer. Another great preparation for this Course is the Scrum Test on less.works. It’s strongly encouraged to do this test before attending the course.
Event Information
What awaits you in a Certified LeSS Practitioner course:
Centricity: Our locations are as central and as easy to reach as possible.
Engagement: Our courses are designed to incorporate interactive tasks as well as group exercises, in order to create the best possible learning experience.
Equipment: All equipment required for the course (e.g. workbooks) is provided for you by us.
Food & drink: We provide vegan and gluten-free catering options and are happy to accommodate other allergies/intolerances as well. Just let us know your preferences.
Das umfassendste Training zum Thema Business Agilität
- Weltweit anerkanntespCLP® &CLP®-Zertifikat der LeSS Company®
Interaktives Training mit Beispielen aus der Praxis
Vertiefung der Prinzipien zum Erreichen von Business Agilität
Konkrete Hilfestellung für den Einstieg
Der 5-tägige Entwicklungs-Praxiskurs besteht zu 70 % aus praktischer Arbeit und zu 30 % aus Vorträgen und hat drei Schwerpunkte: Large-Scale Scrum, technische Praktiken und authentische Teamdynamik. Es werden Scrum-Praktiken wie teamübergreifende Sprint-Planung, Backlog-Refinement, Teamarbeit und viele technische Praktiken wie testgetriebene Entwicklung, kontinuierliche Integration, akzeptanztestgetriebene Entwicklung und Refactoring behandelt. Es wird auch behandelt, wie diese Praktiken in einer Legacy-Codebase-Situation angewendet werden können.
Für wen ist dieser Kurs geeignet:
Wir erwarten nicht, dass die Teilnehmer über Vorkenntnisse des unten aufgeführten Tech-Stacks verfügen, einschließlich der Programmiersprachen oder der Domäne. Alle Teilnehmer sind willkommen, solange sie fließende Softwareentwickler sind.
Wir erlauben auch 1~2 Nicht-Entwickler (z.B. ein ScrumMaster oder PO) in jeder Klasse, solange sie einige Entwicklungserfahrung haben und versprechen, als Entwickler in einem Team in der Klasse zu arbeiten. Bis jetzt ist ihr Feedback sogar besser als das der Entwickler:-) Das liegt wahrscheinlich daran, dass man die Möglichkeit hat, ein Team von innen zu beobachten und die anderen bei ihrer Arbeit zu beobachten.
Aktueller Tech-Stack:
Wir haben uns für einen bestimmten Stack entschieden, damit die Leute in der Klasse auch wirklich arbeiten, aber der spezifische Stack ist für die Teilnahme nicht so wichtig. Unser aktueller Stack ist:
- ein Webservice (https://doughnut.odd-e.com)
- VueJS 3 auf dem Frontend mit TypeScript
- Spring Boot Backend mit Java und MySQL
- verschiedene externe Service-Abhängigkeiten
- Cypress für End-to-End-Tests
- Github Action für CI/CD
- Google Cloud für die Produktion
- Der Quellcode ist hier zu finden: https://github.com/nerds-odd-e/doughnut
Montag:
- Anforderungsworkshop / A-TDD
- Definition von Erledigt
- Cucumber & Friends
- Sprint-Pläne
Dienstag:
- Sprint-Pläne
- Testgetriebene Entwicklung
- Zusammenarbeit (Arbeiten in Teams, SCM, Build-Automatisierung und andere Werkzeuge, Pair Programming, kontinuierliche Integration und CI-Systeme, kollektives Code-Ownership)
Mittwoch:
- Code Smells & Refactoring
- Thinking about test and test automation (Testing Pyramid, Mocking, Unit testing in other languages: JavaScript, Python, etc., Good Unit Testing
Donnerstag:
- Nachdenken über Design
- Feature Team Besprechungen
Freitag:
- Arbeiten mit Legacy-Code
- Handwerkliches Können
- Retrospective
Einzelheiten:
Workshop zur Verfeinerung des Produkt-Backlogs
In Large-Scale Scrum ist der PBR-Workshop eine der wichtigsten Aktivitäten. Indem wir den Workshop während des Sprints mit mehreren Teams durchführen, werden wir die drei wesentlichen Aspekte dieses Workshops abdecken: Aufteilung großer Elemente, Detaillierung der Elemente und Schätzung. Einige optionale Techniken, die wir je nach Situation abdecken können, sind: Impact Mapping, Storying Mapping, Spezifikation anhand von Beispielen, Schätzungszeremonien usw.
Definition von Erledigt
Was ist der Zweck der Definition of Done? Wir werden auch darüber sprechen, was es damit auf sich hat, wie man sie verwendet und wer sie sicherstellen sollte.
Sprint-Planungen
(Teamübergreifend) Sprint Planning Part One wird hauptsächlich durch den PBR Workshop abgedeckt, da es nur einen Sprint gibt. Sprint Planning Part Two wird im Detail erklärt und geübt.
Abnahmetest-gesteuerte Entwicklung mit Cucumber & Friends
In diesem Teil wird erklärt, wie man die Iteration mit den Beispielen aus dem PBR-Workshop vorantreibt. Wir werden die detaillierten technischen Ansätze, guten Praktiken und Konventionen diskutieren.
Der eigentliche Unterricht bzw. die Vorlesung wird in der Regel auf die nächsten Tage verschoben, bis die Teilnehmer echte Erfahrungen im Umgang mit den Werkzeugen und dem Prozess gesammelt haben. Der größte Teil des Lernstoffs sollte aus den Übungen und dem zeitnahen Coaching durch die Kursleiter stammen. Wie bei allen anderen technischen Praktiken auch
Testgetriebene Entwicklung
Ab Tag 2 muss der gesamte Code nach TDD geschrieben werden. Wie oben beschrieben, werden wir die Philosophie sehr schnell mit einer einfachen Übung erklären. Der größte Teil des Lernens sollte durch praktisches Coaching und Üben erfolgen.
Zusammenarbeit
In diesem Teil werden die grundlegenden Techniken und Praktiken erklärt, die es Teams ermöglichen, in einer Large-Scale-Scrum-Situation zusammenzuarbeiten. Einschließlich:
Arbeit in Teams
SCM, Build Automation und andere Werkzeuge
Paarweise Programmierung
Kontinuierliche Integration und CI-Systeme
Kollektives Code-Besitzrecht
Die obigen Ausführungen bereiten die Teilnehmer darauf vor, zu verstehen, warum die Dinge in Large-Scale Scrum so ablaufen, wie sie ablaufen.
Code-Refactoring
Dieser Teil befasst sich mit dem Warum, Was und Wie des Code-Refactorings. Wir werden die Teilnehmer darin schulen, den Geruch von schlechtem Code zu erkennen und die Techniken zur Beseitigung dieses Geruchs zu erlernen.
Mehr über Testautomatisierung
Nachdem sowohl der automatisierte Akzeptanztest als auch der Unit-Test im Kurs behandelt wurden, gehen wir in diesem Teil tiefer in das (automatisierte) Testen ein. Einschließlich:
Reales Testen/Exploratives Testen
Produktspezifische Teststrategien
Gute automatisierte Tests
Unit-Tests in anderen Programmiersprachen
Über Design nachdenken
Hier besprechen wir den Unterschied zwischen emergentem Design und dem traditionellen Designstil, der oft in einem Wasserfallprozess stattfindet.
Darüber hinaus sprechen wir auch über Designprinzipien und Paradigmen.
Noch einmal über "echtes Testen" nachdenken
Feature-Teams
Mit all dem Wissen aus den ersten vier Tagen werden wir uns schließlich noch einmal mit dem Thema Organisationsstruktur befassen und die Verbindungen zwischen den technischen Praktiken und der Herangehensweise an Teams und Feature-Teams sehen.
Legacy-Code
Basierend auf dem Buch von Michael Feathers, Working Effectively With Legacy Code, diskutieren wir die Arbeitsweise, wenn der Code keine gute Testabdeckung hat und das Wissen darüber, wie der Code funktioniert, verloren geht.
Handwerkskunst
Wir diskutieren die alternative Metapher für Software-Praktiker, um ihre Karriere abzubilden und sie zu leiten.
Rückblicke
Die Schulung ist vorbei, die im Kurs gebildeten Teams werden (normalerweise) nicht weitergeführt. Wir werden versuchen, den Teilnehmern die Erfahrung einer guten Retrospektive zu vermitteln, zu lernen, wie man schlechte Gerüche in einer Retrospektive erkennt, und gute Techniken für die Durchführung einer Retrospektive zu erlernen. Wir werden auch darauf eingehen, wie große Organisationen Retrospektiven durchführen.
Es ist schwierig, genau zu dokumentieren, was wir im Kurs machen. Da die Teams jedes Mal an unterschiedlichen Product Backlog Items arbeiten und das Produkt aus dem vorherigen Kurs weiterführen, werden viele Inhalte neu entstehen.
Zertifizierung
Darüberhinaus können Sie nach dem Besuch des Kurses bis zu 25 SEUs (Scrum Education Units) der Kategorie C für die Scrum Alliance CSP (Certified Scrum Professional) in Anspruch nehmen.
An wen richtet sich der Kurs?
Team- und Organisations-Coaches
Agile Coaches
Scrum Master
Manager und Führungskräfte
Product Owner, Product Manager und Stakeholder
Software-Ingineure (Entwickler, Tester, Software-Architekten) und Designer
Unternehmensberater
Alle Interessierten, die mehr über Scrum erfahren wollen und die, die sich zum CLP (Certified LeSS Practitioner) zertifizieren lassen möchten
Voraussetzungen
Die einzige Voraussetzung für den Kurs sind grundlegende Scrum-Kenntnisse. Diese können durch den Besuch eines Certified Scrum Master oder eines Professional Scrum Master Kurses oder durch die gründliche Lektüre von Scrum-Einführungsmaterial wie dem Scrum Primer und das Üben von Scrum erreicht werden.
Sie benötigen eine stabile und schnelle Internetverbindung, eine Webcam, ein Headset und eine Umgebung, in der Sie sich konzentrieren und bei Bedarf auch mit anderen online interagieren können.
Empfohlene Vorbereitung
Die Teilnehmer sollten Scrum-Einführungsmaterialien wie z.B. den Scrum Primer (erneut) durchsehen. Eine weitere effektive Vorbereitung für diesen Kurs ist der Scrum Test auf less.works. Es wird zwecks Maximierung der Lernerfahrung dringend empfohlen, diesen Test vor der Teilnahme am Kurs durchzuführen.
Verantstaltungshinweise
(Nicht relevant, wenn Sie nur den pCLP®-Online-Kurs besuchen möchten).
Maßnahmen bei Präsenzschulungen
Die Gesundheit unserer Teilnehmer und Teilnehmerinnen hat oberste Priorität. Die folgenden Hygienemaßnahmen sind daher besonders wichtig:
Große Räume / Abstand: Unsere Schulungen werden in besonders großen Räumen durchgeführt, so dass alle Teilnehmer mit ausreichendem Abstand zueinander sitzen können, um am eigenen Platz jeweils keine Maske zu benötigen.
Masken: Natürlich legen wir weiterhin großen Wert auf Austausch zwischen den Teilnehmern. Für interaktive Übungen, brauchen daher alle Teilnehmer Masken.
Desinfektion: In den Trainingsräumen stehen Spender für Desinfektionsmittel jederzeit zur Verfügung.
Lüften: Während des Trainings werden die Räume dauerhaft gelüftet. Wenn Sie empfindlich auf Windzug reagieren, können wir das bei der Platzwahl beachten. Wir möchten Sie daher auch bitten, sich entsprechend passende Kleidung mitzunehmen.
Essen & Trinken: Wir bieten jedem Teilnehmer eine eigene Verpflegung an. Es gibt keine Büffets. Wir beobachten die Situation sehr genau. Sollte es notwendig werden, eine Schulung ins Online-Format umzustellen, werden Sie umgehend darüber informiert. Sie können sich dann entscheiden, ob Sie Ihre Teilnahme kostenlos auf einen anderen Termin verlegen möchten.
Wenn Sie über die notwendige technische Infrastruktur verfügen, können Sie u. U. von einer Online-Schulung mehr profitieren.
Feedback from participants
Feedback der Teilnehmer
About the Trainer
s
Über den Trainer
.jpg)
Terry Yin is a programmer for life, a reflective practitioner. He has rich experience in the software industry. Terry has been working at Nokia for 10 years mostly in R&D management and Adaptive transformation before joining Odd-e. He has coached Large Scale Scrum and software development technical practices in a large variety of software companies. Terry has been an active programmer for more than 25 years, crossing many domains. He’s open source software static analyser (https://github.com/terryyin/lizard) is used in many large organization, e.g. Nokia, Ericsson and even the Atlas experiment at CERN. He's also the developer of the https://less.works web site. He’s also an experienced trainer and conference speaker.
