Hand auf's Herz: Wusstest Du, dass Taylor die Work-Life-Balance erfunden hat?
Vermutlich nicht. Da ist im Laufe der Geschichte ein bisschen was schief gelaufen und verloren gegangen.
Damit das so nicht nochmal passiert, stelle ich die Frage: Was können Agilisten vom Taylorismus über New Work lernen?
Auf jeden Fall, wie eine eigentlich gute Idee, die aus moralisch integeren Motiven heraus sinnvolle und praktikable Konzepte beschreibt, kaputt geht. Denn vieles, was den Taylorismus zu dem hat werden lassen, das wir heute wieder aus der Arbeitswelt entfernen möchten, passiert genau jetzt auf die gleiche Weise wieder mit Bergmanns Ideen.
Dieser Vortrag ist mitnichten ein Plädoyer für eine Rückkehr zum Taylorismus, ebensowenig eines für Bergmanns New-Work-Ideen. Ich werde aber aus den Büchern beider vorlesen und zeigen, dass sie mit ihrem Bild von Arbeit gar nicht weit voneinander entfernt sind. Und warum das Verstehen um die Evolution des Taylorismus umso wichtiger ist, wenn New Work Realität werden soll.
Conway’s Law & Soziologie in der Software-ArchitekturGerrit Beine
Mit diesem Vortrag soll Conway’s Law aus einer Perspektive betrachtet werden, die in der IT üblicherweise gar nicht vorkommt: Systemtheorie & Konstruktivismus. Was denken Software-Architekten über Software- Architekten, die Software-Architekten beim Systemdesign beobachten? Und warum beeinflusst uns das mehr, als die Anzahl der Teile aus denen unsere Organisation besteht? Was unterscheidet eigentlich ein IT-System von einem sozialen System?
Beyond User Stories - Backlogs priorisieren, wenn es anspruchsvoll wirdGerrit Beine
Die Entscheidungen, die ein Product Owner bei der Priorisierung des Backlogs treffen muss, sind alles andere als einfach.
Was ist wichtiger: Security oder Usability?
Kommt als nächstes ein weiteres Feature oder werden technische Schulden abgebaut?
Welche der drei Funktionen soll als erstes realisiert werden?
In diesem Vortrag werden Wege vorgestellt, wie man diese Entscheidungen treffen kann und zwischen den hunderten Anforderungen nicht die Balance verliert.
Angeknüpft wird immer dort, wo die gängigen Modelle wie Business Modelling, Value Proposition oder Story Mapping aufhören - immer geleitet von der Frage: Wie kann eine Product Ownerin all die Ideen, Wünsche und Notwendigkeiten operationalisieren?
Dabei geht es auch um Anschlussfähigkeit agiler Anforderungsprozesse in klassischen Organisationen, mit all den anspruchsvollen Rahmenbedingungen, die Product Ownership in solchen Umgebungen mit sich bringt.
Was lernen die Zuhörer in dem Vortrag?
Wie funktionieren Backlog-Strukturen aus einer Anforderungsperspektive?
Wie funktioniert ein Anforderungsprozess, der ein Backlog strukturiert füllt?
Was macht das Scrum-Team in Anforderungsmanagement?
Wie treffe ich als Product Owner Entscheidungen zu Anforderungen?
Was passiert mit alten Anforderungen?
Wie balanciere ich konkurrierende Anforderungen aus?
Gut genug - Rahmenbedingungen für agile ArchitekturenGerrit Beine
Das elfte Prinzip des agilen Manifests besagt, dass die besten Architekturen in selbstorganisierten Teams entstehen. Aber wann benötigen wir die besten Architekturen? Und wie entstehen eigentlich Architekturen, die gut genug sind?
Dieser Vortrag ist eine kritische Auseinandersetzung mit der nicht immer leichten Beziehung zwischen agiler Softwareentwicklung und Softwarearchitektur. Es geht um den Architectural Runway, Architektur-Kanban und Tiger-Teams. Es geht um Communities of Practise, Senior-Softwarearchitekten und die Grenzen der Selbstorganisation. Und um Schwarmintelligenz und Schwarmdummheit in der Architektur. Darum, wie gute Architekten Patterns bauen und mit Optionen jonglieren. Es geht um die Frage, ob ein Scrum-Team einen Architekten benötigt und wie diese Rolle skaliert werden kann, wenn das Projekt zu groß wird. Außerdem beantworte ich noch die Frage, was Softwarearchitekten von Thales von Milet über den Handel mit Olivenöl lernen können und warum sie nicht alles wissen müssen.
Beyond Agile – Ungewissheit mit der Real Option Theory meisternGerrit Beine
Ungewissheit und Unsicherheit sind im Projektgeschäft ständige Begleiter. Wie geht man damit um, und wie gelingt es, sie als Chance zu nutzen? Der Vortrag nähert sich dem Thema, indem wichtige Fragestellungen – wie etwa: Wie erkenne ich Ungewissheiten? In welcher Beziehung stehen Ungewissheiten in Projekten zu Wissen und Unwissen? Wann ist der richtige Moment, eine Ungewissheit aufzulösen? – erörtert werden.
Hand auf's Herz: Wusstest Du, dass Taylor die Work-Life-Balance erfunden hat?
Vermutlich nicht. Da ist im Laufe der Geschichte ein bisschen was schief gelaufen und verloren gegangen.
Damit das so nicht nochmal passiert, stelle ich die Frage: Was können Agilisten vom Taylorismus über New Work lernen?
Auf jeden Fall, wie eine eigentlich gute Idee, die aus moralisch integeren Motiven heraus sinnvolle und praktikable Konzepte beschreibt, kaputt geht. Denn vieles, was den Taylorismus zu dem hat werden lassen, das wir heute wieder aus der Arbeitswelt entfernen möchten, passiert genau jetzt auf die gleiche Weise wieder mit Bergmanns Ideen.
Dieser Vortrag ist mitnichten ein Plädoyer für eine Rückkehr zum Taylorismus, ebensowenig eines für Bergmanns New-Work-Ideen. Ich werde aber aus den Büchern beider vorlesen und zeigen, dass sie mit ihrem Bild von Arbeit gar nicht weit voneinander entfernt sind. Und warum das Verstehen um die Evolution des Taylorismus umso wichtiger ist, wenn New Work Realität werden soll.
Conway’s Law & Soziologie in der Software-ArchitekturGerrit Beine
Mit diesem Vortrag soll Conway’s Law aus einer Perspektive betrachtet werden, die in der IT üblicherweise gar nicht vorkommt: Systemtheorie & Konstruktivismus. Was denken Software-Architekten über Software- Architekten, die Software-Architekten beim Systemdesign beobachten? Und warum beeinflusst uns das mehr, als die Anzahl der Teile aus denen unsere Organisation besteht? Was unterscheidet eigentlich ein IT-System von einem sozialen System?
Beyond User Stories - Backlogs priorisieren, wenn es anspruchsvoll wirdGerrit Beine
Die Entscheidungen, die ein Product Owner bei der Priorisierung des Backlogs treffen muss, sind alles andere als einfach.
Was ist wichtiger: Security oder Usability?
Kommt als nächstes ein weiteres Feature oder werden technische Schulden abgebaut?
Welche der drei Funktionen soll als erstes realisiert werden?
In diesem Vortrag werden Wege vorgestellt, wie man diese Entscheidungen treffen kann und zwischen den hunderten Anforderungen nicht die Balance verliert.
Angeknüpft wird immer dort, wo die gängigen Modelle wie Business Modelling, Value Proposition oder Story Mapping aufhören - immer geleitet von der Frage: Wie kann eine Product Ownerin all die Ideen, Wünsche und Notwendigkeiten operationalisieren?
Dabei geht es auch um Anschlussfähigkeit agiler Anforderungsprozesse in klassischen Organisationen, mit all den anspruchsvollen Rahmenbedingungen, die Product Ownership in solchen Umgebungen mit sich bringt.
Was lernen die Zuhörer in dem Vortrag?
Wie funktionieren Backlog-Strukturen aus einer Anforderungsperspektive?
Wie funktioniert ein Anforderungsprozess, der ein Backlog strukturiert füllt?
Was macht das Scrum-Team in Anforderungsmanagement?
Wie treffe ich als Product Owner Entscheidungen zu Anforderungen?
Was passiert mit alten Anforderungen?
Wie balanciere ich konkurrierende Anforderungen aus?
Gut genug - Rahmenbedingungen für agile ArchitekturenGerrit Beine
Das elfte Prinzip des agilen Manifests besagt, dass die besten Architekturen in selbstorganisierten Teams entstehen. Aber wann benötigen wir die besten Architekturen? Und wie entstehen eigentlich Architekturen, die gut genug sind?
Dieser Vortrag ist eine kritische Auseinandersetzung mit der nicht immer leichten Beziehung zwischen agiler Softwareentwicklung und Softwarearchitektur. Es geht um den Architectural Runway, Architektur-Kanban und Tiger-Teams. Es geht um Communities of Practise, Senior-Softwarearchitekten und die Grenzen der Selbstorganisation. Und um Schwarmintelligenz und Schwarmdummheit in der Architektur. Darum, wie gute Architekten Patterns bauen und mit Optionen jonglieren. Es geht um die Frage, ob ein Scrum-Team einen Architekten benötigt und wie diese Rolle skaliert werden kann, wenn das Projekt zu groß wird. Außerdem beantworte ich noch die Frage, was Softwarearchitekten von Thales von Milet über den Handel mit Olivenöl lernen können und warum sie nicht alles wissen müssen.
Beyond Agile – Ungewissheit mit der Real Option Theory meisternGerrit Beine
Ungewissheit und Unsicherheit sind im Projektgeschäft ständige Begleiter. Wie geht man damit um, und wie gelingt es, sie als Chance zu nutzen? Der Vortrag nähert sich dem Thema, indem wichtige Fragestellungen – wie etwa: Wie erkenne ich Ungewissheiten? In welcher Beziehung stehen Ungewissheiten in Projekten zu Wissen und Unwissen? Wann ist der richtige Moment, eine Ungewissheit aufzulösen? – erörtert werden.
Backlog Priorisierung 2020: Wertmodelle & Simulationen von Intangibles zur Pr...Gerrit Beine
Die richtige Priorisierung von Aufgaben ist entscheidend für den Projekterfolg. Der Vortrag demonstriert, wie mit Wertmodellen und Monte-Carlo-Simulationen Projektanforderungen optimal – am Kundennutzen orientiert – priorisiert werden. Als Beispiele dienen Softwareprojekte, in denen auch weiche Faktoren als Werttreiber eine wichtige Rolle spielen.
Backlog Priorisierung mit Cost of Delay & Monte Carlo SimulationenGerrit Beine
Das fünfte agile Wertepaar: Simulieren und Lernen über Planen und Schätzen
Die Entscheidungen, die ein Product Owner bei der Priorisierung des Backlogs treffen muss, sind alles andere als einfach.
Was ist wichtiger: Security oder Usability?
Kommt als nächstes ein weiteres Feature oder werden technische Schulden abgebaut?
Welche der drei Funktionen soll als erstes realisiert werden?
In diesem Vortrag wird ein Weg vorgestellt, der diese Entscheidungen leichter macht.
Dabei kommen zwei einfache Werkzeuge zum Einsatz: Wertmodelle und Monte Carlo-Simulationen.
Wertmodelle erlauben es, ein Thema hinsichtlich verschiedener Werttreiber zu erfassen und zu beschreiben.
Sie stellen eine elegante Möglichkeit dar, weiche Themen wie Usability und Security gegenüber von echten Features zu bewerten.
Damit eröffnen sie ganz neue Aspekte im Austausch mit Kunden und Anwendern.
Gleichzeitig bilden sie eine hervorragende Grundlage dafür, ein Backlog mit Hilfe einer Simulation zu priorisieren.
Priorisierungen, die auf einem solchen Weg entstehen, zeigen häufig überraschende Effekte und führen nicht selten zu besseren Entscheidungen.
Das macht diese Simulationen zu einer perfekten Ergänzung von Story Maps und anderen inhaltlich orientierten Methoden.
Feedback von Kunden und Anwendern zum gelieferten Produkt verbessert kontinuierlich das Wertmodell.
Diese Verbesserungen des Wertemodells wirken sich wiederum unmittelbar auf die Priorisierung des Backlogs aus und machen die Priorisierung zu einer leichten Aufgabe, die permanent passiert.
Im Vortrag wird anhand eines realen Großprojektes erklärt, wie Product Owner ein Wertmodell erstellen können,
wie es zur Simulation verwendet und wie daraus ein lernenes Wertmodell wird.
Die bisher einzige bekannte Methode, um den Wirkungsgrad von Führungskräften zu bewerten. Alle DAX-Unternehmen setzen es bereits ein. An den Fortune 500 arbeite ich gerade.
Der Product Owner ist maßgeblich für den Erfolg eines Projektes verantwortlich.
Warum der Product Owner für agile Projekte eine größere Bedeutung hat als ein Projektleiter und warum es für Projektleiter einen Karriereschritt bedeutet, Product Owner zu werden, möchte dieser Vortrag deutlich machen.
Dabei werden sowohl die unterschiedlichen Herangehensweisen des Projektmanagements gegenübergestellt als auch die Aspekte beleuchtet, die Product Owner gegenüber Projektleitern im Vorteil sein lassen.
Der Product Owner ist sicherlich die am häufigsten unterschätzte Rolle aus der agilen Welt. Dabei ist der Product Owner maßgeblich für den Erfolg eines Projektes verantwortlich. Warum der Product Owner für Projekt eine größere Bedeutung hat, als ein Projektleiter, warum es für Projektleiter einen Karriereschritt bedeutet, Product Owner zu werden und was diese Veränderung für Unternehmen bedeutet, möchte dieser Vortrag deutlich machen. Dabei werden sowohl die unterschiedlichen Herangehensweisen des wertorientierten und planorientierten Projektmanagements gegenübergestellt als auch die Methoden und Werkzeuge beleuchtet, die Product Owner gegenüber Projektleitern im Vorteil sein lassen.
Software-Architekturen sind stetigem Wandel ausgesetzt. Irgendwann muss DIE (unbekannte) Anforderung vom Software-Architekten berücksichtigt werden. Wie kann man diesem unvorhersehbarem Ereignis begegnen? Nicholas Nassim Taleb (Antifragilität: Anleitung für eine Welt, die wir nicht verstehen) hat aufgezeigt, dass solche Ereignisse die Grundlage zur Verbesserung sein können. Seine Thesen werden auf die Software-Architekturarbeit übertragen. Das Wissen über das Nichtwissen ist eine Grundvoraussetzung, genauso wie der bewusste Umgang mit Risiken und Chancen. Antifragilität ist ein Qualitätsaspekt des Software-Entwicklungsprozesses und nicht der entwickelten Software-Architektur. Agilität in der Software-Entwicklung bekommt damit eine neue Qualität und kann von Antifragilität profitieren.
Als Software-Architekten balancieren wir ständig auf dem Grat der Entscheidungen. Und nur allzu oft bewahrheitet sich, dass die Software-Architektur die Summe teurer Entscheidungen ist: Technische Schulden geißeln uns. An etlichen Stellen wird bereits der Ruf laut, dass der Begriff der technischen Schuld überholt ist – der von Anfang an falsch war. Die Suche nach einer neuen Metapher hat begonnen, wohin sie führt, wird sich zeigen.
Diese Keynote geht genau in die andere Richtung und zeigt, warum der Begriff der technischen Schuld genau ins Schwarze trifft. Es wird deutlich, dass eine Diskussion über die Zukunft von Software-Systemen mit Menschen, die keinen IT-Hintergrund haben, eine Brücke benötigt, die die Welten der Ökonomie und der IT zusammenführt. Abgerundet wird der Beitrag mit einer Methode zum Management technischer Schulden, die sich bereits in vielen agilen Projekten bewährt hat.
Als Software-Architekten balancieren wir ständig auf dem Grat der Entscheidungen. Und nur allzu oft bewahrheitet sich, dass die Software-Architektur die Summe teurer Entscheidungen ist: Technische Schulden geißeln uns. An etlichen Stellen wird bereits der Ruf laut, dass der Begriff der technischen Schuld überholt ist – der von Anfang an falsch war. Die Suche nach einer neuen Metapher hat begonnen, wohin sie führt, wird sich zeigen.
Diese Keynote geht genau in die andere Richtung und zeigt, warum der Begriff der technischen Schuld genau ins Schwarze trifft. Es wird deutlich, dass eine Diskussion über die Zukunft von Software-Systemen mit Menschen, die keinen IT-Hintergrund haben, eine Brücke benötigt, die die Welten der Ökonomie und der IT zusammenführt. Abgerundet wird der Beitrag mit einer Methode zum Management technischer Schulden, die sich bereits in vielen agilen Projekten bewährt hat.
Als Product Owner hat man die Verantwortung für den ökonomischen und fachlichen Erfolg eines Projektes. Und eine ganze Menge Werkzeuge, die in keinem der üblichen Product Owner-Seminare vorgestellt werden. Dieser Vortrag geht auf eben jene Werkzeuge ein, die dem Product Owner das Leben erleichtern, ökonomische Entscheidungen ermöglichen und Brücken zwischen agilen Teams, Kunden, Investoren jenseits von User Stories bauen.
Lessons Learned
- Wie kann ich als Product Owner ökonomische Aspekte meines Projektes bewerten und qualifizierte Entscheidungen treffen?
- Wie kann ich mein Team dazu bewegen, technische Entscheidungen, anhand von ökonomischen Faktoren zu bewerten?
- Wie wende ich Ideen wie Cost of Delay praktisch an, wie spreche ich mit Entwicklern, Kunden, Managern und Investoren darüber?
Over the years agile became a common way of software development. More and more companies adopt to the agile manifesto.
But there are some challenges on the way to become an agile organization. One is the question of how to deal with financial planning. The previous answer was: Budgeting. But butgeting does not scale with the velocity of agile projects. The idea to solve this problem exists much longer then the idea of agile itself: Go Beyond Budgeting.
Beyond Agile - Antifragilität in der Software-Entwicklung - mit NotizenGerrit Beine
In der Softwareentwicklung geschehen ständig Ereignisse, die nicht vorhersehbar sind. Sind deren Auswirkungen drastisch, entsprechen sie dem Typ von Ereignis, der seit Nassim Nicholas Taleb als Schwarzer Schwan bezeichnet wird.
Mit seiner Idee der Antifragilität zeigt Taleb, wie Schwarze Schwäne als Grundlage von Verbesserung genutzt werden können. Antifragilität kann in der Softwareentwicklung besonders in zwei Bereichen helfen: Software-Architektur und Projektmanagement.
Dieser Vortrag gibt Denkanstöße, wie man Schwarze Schwäne nutzen kann, um Software-Entwicklungs-Teams zur Antifragilität zu führen. Es geht dabei um Asymmetrien, kontrafaktisches Denken, richtige und falsche Fehler.
Und welche Rolle Softwarearchitektur in einer antifragilen Welt spielen muss.
Beyond Agile - Antifragilität in der Software-EntwicklungGerrit Beine
In der Softwareentwicklung geschehen ständig Ereignisse, die nicht vorhersehbar sind. Sind deren Auswirkungen drastisch, entsprechen sie dem Typ von Ereignis, der seit Nassim Nicholas Taleb als Schwarzer Schwan bezeichnet wird.
Mit seiner Idee der Antifragilität zeigt Taleb, wie Schwarze Schwäne als Grundlage von Verbesserung genutzt werden können. Antifragilität kann in der Softwareentwicklung besonders in zwei Bereichen helfen: Software-Architektur und Projektmanagement.
Dieser Vortrag gibt Denkanstöße, wie man Schwarze Schwäne nutzen kann, um Software-Entwicklungs-Teams zur Antifragilität zu führen. Es geht dabei um Asymmetrien, kontrafaktisches Denken, richtige und falsche Fehler.
Und welche Rolle Softwarearchitektur in einer antifragilen Welt spielen muss.
Agility Brainfucks - Von Menschen, Bildern und Steampunk-Management mit NotizenGerrit Beine
In dieser Session wird mit verbreiteten Irrtümern, falschen Versprechen und falsch verstandenen Philosophien aufgeräumt.
Es geht um die freie Zeit, die ein ScrumMaster hat. Um den Unterschied zwischen Agilität und inkrementellem Arbeiten.
Es geht um feste Preise und Termine. Darum, was Velocity wirklich bedeutet.
Warum Aufwand eine Rolle spielt und wer mit wem darüber reden darf.
Es geht um glückliche Entwickler, Kunden und Manager. Glückliche Manager, die skalieren. Und wozu man Manager benötigt.
Es geht um Kultur.
Darum, was geschätzt wird und warum KPIs Projekte töten.
Es geht um Business Value und warum Agilität gerade erst anfängt.
Backlog Priorisierung 2020: Wertmodelle & Simulationen von Intangibles zur Pr...Gerrit Beine
Die richtige Priorisierung von Aufgaben ist entscheidend für den Projekterfolg. Der Vortrag demonstriert, wie mit Wertmodellen und Monte-Carlo-Simulationen Projektanforderungen optimal – am Kundennutzen orientiert – priorisiert werden. Als Beispiele dienen Softwareprojekte, in denen auch weiche Faktoren als Werttreiber eine wichtige Rolle spielen.
Backlog Priorisierung mit Cost of Delay & Monte Carlo SimulationenGerrit Beine
Das fünfte agile Wertepaar: Simulieren und Lernen über Planen und Schätzen
Die Entscheidungen, die ein Product Owner bei der Priorisierung des Backlogs treffen muss, sind alles andere als einfach.
Was ist wichtiger: Security oder Usability?
Kommt als nächstes ein weiteres Feature oder werden technische Schulden abgebaut?
Welche der drei Funktionen soll als erstes realisiert werden?
In diesem Vortrag wird ein Weg vorgestellt, der diese Entscheidungen leichter macht.
Dabei kommen zwei einfache Werkzeuge zum Einsatz: Wertmodelle und Monte Carlo-Simulationen.
Wertmodelle erlauben es, ein Thema hinsichtlich verschiedener Werttreiber zu erfassen und zu beschreiben.
Sie stellen eine elegante Möglichkeit dar, weiche Themen wie Usability und Security gegenüber von echten Features zu bewerten.
Damit eröffnen sie ganz neue Aspekte im Austausch mit Kunden und Anwendern.
Gleichzeitig bilden sie eine hervorragende Grundlage dafür, ein Backlog mit Hilfe einer Simulation zu priorisieren.
Priorisierungen, die auf einem solchen Weg entstehen, zeigen häufig überraschende Effekte und führen nicht selten zu besseren Entscheidungen.
Das macht diese Simulationen zu einer perfekten Ergänzung von Story Maps und anderen inhaltlich orientierten Methoden.
Feedback von Kunden und Anwendern zum gelieferten Produkt verbessert kontinuierlich das Wertmodell.
Diese Verbesserungen des Wertemodells wirken sich wiederum unmittelbar auf die Priorisierung des Backlogs aus und machen die Priorisierung zu einer leichten Aufgabe, die permanent passiert.
Im Vortrag wird anhand eines realen Großprojektes erklärt, wie Product Owner ein Wertmodell erstellen können,
wie es zur Simulation verwendet und wie daraus ein lernenes Wertmodell wird.
Die bisher einzige bekannte Methode, um den Wirkungsgrad von Führungskräften zu bewerten. Alle DAX-Unternehmen setzen es bereits ein. An den Fortune 500 arbeite ich gerade.
Der Product Owner ist maßgeblich für den Erfolg eines Projektes verantwortlich.
Warum der Product Owner für agile Projekte eine größere Bedeutung hat als ein Projektleiter und warum es für Projektleiter einen Karriereschritt bedeutet, Product Owner zu werden, möchte dieser Vortrag deutlich machen.
Dabei werden sowohl die unterschiedlichen Herangehensweisen des Projektmanagements gegenübergestellt als auch die Aspekte beleuchtet, die Product Owner gegenüber Projektleitern im Vorteil sein lassen.
Der Product Owner ist sicherlich die am häufigsten unterschätzte Rolle aus der agilen Welt. Dabei ist der Product Owner maßgeblich für den Erfolg eines Projektes verantwortlich. Warum der Product Owner für Projekt eine größere Bedeutung hat, als ein Projektleiter, warum es für Projektleiter einen Karriereschritt bedeutet, Product Owner zu werden und was diese Veränderung für Unternehmen bedeutet, möchte dieser Vortrag deutlich machen. Dabei werden sowohl die unterschiedlichen Herangehensweisen des wertorientierten und planorientierten Projektmanagements gegenübergestellt als auch die Methoden und Werkzeuge beleuchtet, die Product Owner gegenüber Projektleitern im Vorteil sein lassen.
Software-Architekturen sind stetigem Wandel ausgesetzt. Irgendwann muss DIE (unbekannte) Anforderung vom Software-Architekten berücksichtigt werden. Wie kann man diesem unvorhersehbarem Ereignis begegnen? Nicholas Nassim Taleb (Antifragilität: Anleitung für eine Welt, die wir nicht verstehen) hat aufgezeigt, dass solche Ereignisse die Grundlage zur Verbesserung sein können. Seine Thesen werden auf die Software-Architekturarbeit übertragen. Das Wissen über das Nichtwissen ist eine Grundvoraussetzung, genauso wie der bewusste Umgang mit Risiken und Chancen. Antifragilität ist ein Qualitätsaspekt des Software-Entwicklungsprozesses und nicht der entwickelten Software-Architektur. Agilität in der Software-Entwicklung bekommt damit eine neue Qualität und kann von Antifragilität profitieren.
Als Software-Architekten balancieren wir ständig auf dem Grat der Entscheidungen. Und nur allzu oft bewahrheitet sich, dass die Software-Architektur die Summe teurer Entscheidungen ist: Technische Schulden geißeln uns. An etlichen Stellen wird bereits der Ruf laut, dass der Begriff der technischen Schuld überholt ist – der von Anfang an falsch war. Die Suche nach einer neuen Metapher hat begonnen, wohin sie führt, wird sich zeigen.
Diese Keynote geht genau in die andere Richtung und zeigt, warum der Begriff der technischen Schuld genau ins Schwarze trifft. Es wird deutlich, dass eine Diskussion über die Zukunft von Software-Systemen mit Menschen, die keinen IT-Hintergrund haben, eine Brücke benötigt, die die Welten der Ökonomie und der IT zusammenführt. Abgerundet wird der Beitrag mit einer Methode zum Management technischer Schulden, die sich bereits in vielen agilen Projekten bewährt hat.
Als Software-Architekten balancieren wir ständig auf dem Grat der Entscheidungen. Und nur allzu oft bewahrheitet sich, dass die Software-Architektur die Summe teurer Entscheidungen ist: Technische Schulden geißeln uns. An etlichen Stellen wird bereits der Ruf laut, dass der Begriff der technischen Schuld überholt ist – der von Anfang an falsch war. Die Suche nach einer neuen Metapher hat begonnen, wohin sie führt, wird sich zeigen.
Diese Keynote geht genau in die andere Richtung und zeigt, warum der Begriff der technischen Schuld genau ins Schwarze trifft. Es wird deutlich, dass eine Diskussion über die Zukunft von Software-Systemen mit Menschen, die keinen IT-Hintergrund haben, eine Brücke benötigt, die die Welten der Ökonomie und der IT zusammenführt. Abgerundet wird der Beitrag mit einer Methode zum Management technischer Schulden, die sich bereits in vielen agilen Projekten bewährt hat.
Als Product Owner hat man die Verantwortung für den ökonomischen und fachlichen Erfolg eines Projektes. Und eine ganze Menge Werkzeuge, die in keinem der üblichen Product Owner-Seminare vorgestellt werden. Dieser Vortrag geht auf eben jene Werkzeuge ein, die dem Product Owner das Leben erleichtern, ökonomische Entscheidungen ermöglichen und Brücken zwischen agilen Teams, Kunden, Investoren jenseits von User Stories bauen.
Lessons Learned
- Wie kann ich als Product Owner ökonomische Aspekte meines Projektes bewerten und qualifizierte Entscheidungen treffen?
- Wie kann ich mein Team dazu bewegen, technische Entscheidungen, anhand von ökonomischen Faktoren zu bewerten?
- Wie wende ich Ideen wie Cost of Delay praktisch an, wie spreche ich mit Entwicklern, Kunden, Managern und Investoren darüber?
Over the years agile became a common way of software development. More and more companies adopt to the agile manifesto.
But there are some challenges on the way to become an agile organization. One is the question of how to deal with financial planning. The previous answer was: Budgeting. But butgeting does not scale with the velocity of agile projects. The idea to solve this problem exists much longer then the idea of agile itself: Go Beyond Budgeting.
Beyond Agile - Antifragilität in der Software-Entwicklung - mit NotizenGerrit Beine
In der Softwareentwicklung geschehen ständig Ereignisse, die nicht vorhersehbar sind. Sind deren Auswirkungen drastisch, entsprechen sie dem Typ von Ereignis, der seit Nassim Nicholas Taleb als Schwarzer Schwan bezeichnet wird.
Mit seiner Idee der Antifragilität zeigt Taleb, wie Schwarze Schwäne als Grundlage von Verbesserung genutzt werden können. Antifragilität kann in der Softwareentwicklung besonders in zwei Bereichen helfen: Software-Architektur und Projektmanagement.
Dieser Vortrag gibt Denkanstöße, wie man Schwarze Schwäne nutzen kann, um Software-Entwicklungs-Teams zur Antifragilität zu führen. Es geht dabei um Asymmetrien, kontrafaktisches Denken, richtige und falsche Fehler.
Und welche Rolle Softwarearchitektur in einer antifragilen Welt spielen muss.
Beyond Agile - Antifragilität in der Software-EntwicklungGerrit Beine
In der Softwareentwicklung geschehen ständig Ereignisse, die nicht vorhersehbar sind. Sind deren Auswirkungen drastisch, entsprechen sie dem Typ von Ereignis, der seit Nassim Nicholas Taleb als Schwarzer Schwan bezeichnet wird.
Mit seiner Idee der Antifragilität zeigt Taleb, wie Schwarze Schwäne als Grundlage von Verbesserung genutzt werden können. Antifragilität kann in der Softwareentwicklung besonders in zwei Bereichen helfen: Software-Architektur und Projektmanagement.
Dieser Vortrag gibt Denkanstöße, wie man Schwarze Schwäne nutzen kann, um Software-Entwicklungs-Teams zur Antifragilität zu führen. Es geht dabei um Asymmetrien, kontrafaktisches Denken, richtige und falsche Fehler.
Und welche Rolle Softwarearchitektur in einer antifragilen Welt spielen muss.
Agility Brainfucks - Von Menschen, Bildern und Steampunk-Management mit NotizenGerrit Beine
In dieser Session wird mit verbreiteten Irrtümern, falschen Versprechen und falsch verstandenen Philosophien aufgeräumt.
Es geht um die freie Zeit, die ein ScrumMaster hat. Um den Unterschied zwischen Agilität und inkrementellem Arbeiten.
Es geht um feste Preise und Termine. Darum, was Velocity wirklich bedeutet.
Warum Aufwand eine Rolle spielt und wer mit wem darüber reden darf.
Es geht um glückliche Entwickler, Kunden und Manager. Glückliche Manager, die skalieren. Und wozu man Manager benötigt.
Es geht um Kultur.
Darum, was geschätzt wird und warum KPIs Projekte töten.
Es geht um Business Value und warum Agilität gerade erst anfängt.
2. Kontextwechsel und Geschwindigkeit
► Kontextwechsel zwischen unterschiedlichen Aufgaben kosten Zeit
► Beispiel: zwei Aufgaben
► Abarbeitung mit Kontextwechseln (Multitasking-Paradox):
► Abarbeitung ohne Kontextwechsel:
► Abschluss von A erfolgt signifikant später durch Kontextwechsel
► Fazit: Menge der Kontextwechsel auf absolutes Minimum reduzieren
16.11.14
A
B
A A A AB B B B
A
B
3. Paradox des rosaroten Elefant
► Menschen können sich nicht entscheiden, über etwas nicht nachzudenken
► Beispiel zwei Aufgaben:
► Wechselndes Beschäftigen mit zwei Aufgaben führt zur Vermischung
► Planende Aufgaben erst kurz vor Abschluss der vorherigen Aufgabe ausführen
► Beschäftigen mit neuen Aufgaben erst kurz vor Abschluss voriger Aufgaben
► Fazit: Detailplanung kurzfristig durchführen, Story Times für nächsten Sprint statt
nächstes Release
16.11.14 3
A B
A A A AB B B B
A AB B
4. Flüchtigkeit von Wissen
► Menschen können nicht länger als 2 Wochen anhand von Wissen planen
► Beispiel zwei Aufgaben:
► Zu frühes Bearbeiten führt zum Verlust von Wissen über die Zeit
(Schon-mal-erklärt-Paradox, Redundanzanteil in Erklärungen steigt)
► Wissen möglichst kurzfristig in Ergebnisse umsetzen
► Fazit: Unverzüglich nach Planung mit Realisierung beginnen, Klären von Details
während der Realisierung kostet weniger Zeit als vorher
16.11.14 4
A A A AB B B B
A B
A AB B
5. Entscheidungshilfe Architektur in agilen Projekten
08.05.2014
Impact
(Kosten
des
Nicht-
Handelns)
Investition
(Kosten des Handeln)
Kostengrenze
max(Impact, Investition)
6. Entscheidungshilfe Architektur in agilen Projekten II
08.05.2014
Impact
Investition
Kostengrenze
max(Impact, Investition)
max(Impact, Investition)