SlideShare ist ein Scribd-Unternehmen logo
1 von 110
Downloaden Sie, um offline zu lesen
Verträge in Agilen
Softwareprojekten
„Vertrauen & Kooperation“
Björn Schotte // @BjoernSchotte // bjoern.schotte@mayflower.de
MAYFLOWER GmbH
Disclaimer: keine Rechtsberatung!
http://creativecommons.org/licenses/by-sa/3.0/deed.de
Über den Referenten: Björn Schotte
‣ Unruhestifter ;-)
‣ Geschäftsführer MAYFLOWER GmbH
‣ Senior Consultant
‣ hilft Kunden, die Herausforderungen ihres Geschäfts im Online
Umfeld zu lösen. Berät konzeptionell & im Umfeld Agiler Methoden
(Scrum, Enterprise Lean Startup)
‣ MAYFLOWER: 60+ Devs, Individualsoftware Web, Mobile & E-
Business/E-Commerce
Ausgangslage Software-Entwicklung
‣ Cynefin (/ˈkʌnɨvɪn/) Modell
Softwareentwicklung:
Complex & Chaotic
Antwort auf Komplex & Chaotisch
‣ Agiles Projektvorgehen, emergente Praktiken
‣ Ich weiss heute nicht genau, was morgen sein
wird
‣ Ich setze enge Korridore (Sprints), um
kontinuierlich kleine Pläne „auf Sicht“ zu
schmieden
Antwort auf Komplex & Chaotisch
‣ Upfront Design nur so viel wie notwendig und
möglich
‣ ... denn ich will gerade Flexibilität im Vorgehen
haben
‣ Lasten-/Pflichtenheft: Irrglaube, die Dinge „im
Griff“ zu haben, teure CRs, sehr viel höhere TCO
Ausgangslage Vertragswesen
‣ Verträge versuchen, Bekanntes zu regeln
‣ Verträge versuchen, Sicherheit zu bieten
‣ Verträge versuchen, Risiken zu verteilen
‣ Verträge versuchen, Lösungen für Probleme zu liefern
‣ Verträge werden (gemeinhin) dann genutzt, wenn sich die
Parteien nicht mehr vertragen
Ausgangslage Vertragswesen
‣ Kunden haben oftmals schlechte Erfahrungen mit
Dienstleistern gemacht und versuchen sich durch Verträge
abzusichern (Risiko komplett auf Dienstleister abwälzen)
‣ dt. Werkvertragsrecht aus einer Zeit, als es noch keine
Softwareentwicklung gab
‣ ... was heisst denn eigentlich „Werkvertrag“?
Ausgangslage Vertragswesen
Definition Werkvertrag, Wikipedia:
„der Werkunternehmer schuldet dem Werkbesteller die Herstellung
eines Werkes, das heißt die Herbeiführung eines bestimmten Erfolges
tatsächlicher Natur.“
„Die Fälligkeit der Vergütung des Werkvertrages tritt mit der Abnahme
des Werkes ein.“
Ähm ...
Softwareentwicklung ...
KOMPLEX ...
Ich habe ein Problem, für das ich
die Lösung noch nicht genau
kenne
!= Werkvertrag
Hey, lass uns doch
einfach T&M machen!
Pures T&M = Risiko 100%
auf Auftraggeberseite
Conclusio?
1.
Verträge eignen sich scheinbar
nicht für agile Vorgehensweisen
2.
Software-Entwicklung
=
„für (un)bekannte Probleme mit noch
unbekannten Lösungen“ (Scrum)
Komplex!
3.
Software-Entwicklung
=
„für unbekannte Probleme mit noch
unbekannten Lösungen“ (Lean Startup)
Chaotisch!
Drama, Baby?
Annäherung, Teil 1
GPL, GNU General
Public License
Kooperation durch
Tit-for-Tat
Nutze den Source,
verändere ihn. Das
ist okay.
Verteilst du die neue Software,
liefere den gesamten Quellcode
mit. Inklusive deiner Änderungen.
Verhinderung von
Missbrauch durch Hack
des Vertrages (Lizenz).
Erzwingt Kooperation.
Übertragbar auf
unsere
Problematik?
Annäherung, Teil 2
„missbrauche“
Vertragsrecht zum
Kooperationszwang
Zweck des
Vertrages wandelt
sich
weg von Definition von Bekanntem
(wir wissen es eh nicht 100%ig)
hin zur Definition Rahmen, der
Kooperation regelt und Verletzung
von Kooperation ahndet
Auch im Vertrag
Konzentration auf
die Stärken agilen
Vorgehens
Emergente
Erkenntnisse
nutzen, um flexibel
am Markt zu agieren
Konzentration auf
Generierung von
hohem Business
Value
Rahmen gestalten, der
Kooperation ermöglicht
und Pflichten/Rechte
definiert
Mangelnde
Kooperation
ahnden
Nein, nicht mit
Pönalen. Es gibt viel
schlauere Lösungen.
Conclusio?
1.
Vertragsgestaltung „hacken“
2.
Konzentration auf Kooperation
und Generierung von Nutzen
3.
Realität anerkennen. Empirie &
emergentes Wissen zu Lösungen entsteht
während des Projekts
Ergebnis:
Auflösung Unvereinbarkeit
Agiles Vorgehen - Vertragsrecht
Beispiele für Vorgehens-/
Vertragsmodelle
Disclaimer - für alles gilt:
‣ fragen Sie Ihren Anwalt
‣ fragen Sie Mayflower :-)
‣ have fun & viele erfolgreiche Projekte!
T&M - the „good old one“
‣ bei klassisch T&M Bezahlung jeder Stunde (zB Sprint-weise)
‣ Risiko 100% auf Auftraggeber-Seite
‣ ohne weitere Elemente (zB enges Scrum, hohe Motivation etc)
wenig Anreiz für den Dienstleister, hohen BV zu liefern
‣ dennoch: je nach Situation, Klarheit von Anforderungen,
Möglichkeiten des Kunden kann pures T&M Sinn ergeben
„T&M mit Abbruch“
‣ bei klassisch T&M Bezahlung jeder Stunde (zB Sprint-weise)
‣ Kunde merkt nach N Sprints, dass nicht mehr viel Business
Value zu holen ist
‣ mit einem Vorlauf von zB 1 Sprint kann der Kunde jederzeit
nach einem Sprint das Projekt beenden
‣ Vorlauf notwendig, damit der Dienstleister die Ressourcen
umplanen kann
„T&M mit Abbruch“: Beispiel
‣ Projekt ursprünglich auf 10 Sprints geplant
‣ gegen Ende Sprint 6 stellt der Kunde fest, dass kaum mehr BV
zu holen ist, da sich die Marktbedingungen geändert haben
‣ Ende Sprint 6: Ankündigung, dass das Projekt mit dem Ende von
Sprint 7 beendet wird
‣ Vorteile für beide Seiten, Kooperation wird gestützt:
‣ kein BV mehr realisierbar? Abbruchmöglichkeit
‣ DL hat genügend Vorlauf zur Umplanung
T&M on steroids
Warnung: nur für
echte Männer
Regel 1:
T&M, sprint-weise Abrechnung
aller Stunden
Steroids!
Regel 2:
Kunde kann ohne Angabe von
Gründen einen Sprint nicht bezahlen
Steroids!
Regel 3:
Sonderkündigungsrecht DL,
wenn der Kunde das 2. Mal einen
Sprint nicht bezahlt
Ergebnis:
Verkettung beider Seiten in
Kooperation
der Kunde überlegt sich sehr
genau, wann er einen Sprint
nicht bezahlt
der Dienstleister hat ein
Interesse an guter,
ergebnisorientierter Arbeit
Achtung: macht nur Sinn für Projekte, bei
denen DL-Wechsel sehr schmerzhaft
(teuer) ist und somit eine Garantie zur
Kooperation benötigt wird
Steroids!
MAYFLOWER nutzt „T&M on
steroids“ erfolgreich in
Projekten.
Na, schon Herzrasen
bekommen?
Ok, schalten wir
einen Gang zurück.
Vertrag, klassisch, mit
Gewerk und Jedöns...
Klassischer Vertrag, Agil mit Festpreis
‣ Regel 1: im Vertrag ist Scrum-Vorgehen definiert
‣ Regel 2: beiden Parteien bewusst, dass kein fixes Feature-Set
geliefert werden kann. Das Budget ist fix definiert.
‣ Regel 3: es kann kein Gesamtwerk definiert werden
„Ein Gewerk brauche ich für Gewährleistung. Ich brauche Sicherheit.
Hilfe, was kann ich tun?“
Klassischer Vertrag, Agil mit Festpreis
‣ Regel 4 (!): eine einzelne User Story stellt ein Mini-Gewerk da,
auf das Gewährleistungsregeln angewandt werden
‣ Regel 5 (!): das Team kann User Stories ablehnen, wenn diese
aus ihrer Sicht nicht ausreichend spezifiziert/schätzbar sind
(„können wir das Werkvertragsrisiko hier übernehmen?“)
‣ Regel 5 (! Variation): nach beidseitiger Rücksprache kann eine
einzelne User Story dienstvertraglich behandelt werden
„Puh... ich hab Gewerk drin. Check. Doch wie ist das mit der
Abnahme?“
Klassischer Vertrag, Agil mit Festpreis
‣ Regel 6 (!): Abnahme des Mini-Gewerks im Sprint Review. Bei Nicht-Abnahme
(weil Story nicht errreicht!) kommt die Story zurück ins Backlog und wird zB
für den nächsten Sprint wieder eingeplant.
‣ Regel 7 (!): monatlicher Zahlungsplan aufgrund der erbrachten Leistungen
‣ Regel 8 (!): wird eine bereits realisierte User Story durch eine neue US
erweitert/ersetzt, so beginnt die Gewährleistung neu
„Ok. Entkopplung Bezahlung von Gewährleistung/Abnahme. Nur
wenn im Nachhinein, also im Betrieb, etwas Abgenommenes
nachweislich nicht stimmt, muss kostenlos gefixt werden.
Das ist fair.“
Kooperation auf
beiden Seiten.
Vorgehen im
Vertrag festgelegt.
Mini-Gewerke statt
großes Gewerk.
Stakes von Legal &
Procurement erfüllbar.
MAYFLOWER nutzt „Klassisch-
agiler Festpreis“ erfolgreich in
Projekten.
Back to Innovation:
Money for Nothing,
Changes for Free
Exkurs zurück ...
Verträge, old school:
„Ich kenne die Features, ich kenne den
ROI, ich kann alles definieren und regeln.“
Das stimmt so nicht
Daher Agile Logik:
Ich investiere (und
bezahle) Arbeitszeit
Ich erzeuge maximalen
Business Value
und mache so lange
weiter
bis es sich nicht mehr lohnt
(Kosten Feature >> BV)
=
bis es sich nicht mehr lohnt,
weiter zu machen
Ausprägung dieses Prinzips ist
„Money for nothing, Changes for free“
Regel 1:
Standard fixed price Contract
mit T&M für Changes
Regel 2:
Tausch von Features gleicher SP
Zahl möglich, sofern an US noch
nicht begonnen
(Changes for Free)
Regel 2a:
Neue Features möglich,
wenn Low Prio Features
gleicher SP-Zahl wegfallen
Anforderung an Kunde & DL:
es gibt ein qualitativ gutes
Backlog, Gesamt-Features
sind gut schätzbar!
Achtung!
Regel 3:
hält der Kunde sich nicht
an Scrum, wandelt sich
das Projekt in reines T&M
Nun zum „Money
for Nothing“ ...
Regel 4:
ebenfalls nur gültig, wenn
Scrum Vorgehen
eingehalten
Regel 5:
beide Parteien können sich auf
SP Estimates einigen.
Ansonsten Umwandlung in
T&M
Regel 6:
wenn
Kosten Feature >> BV
dann Projekt-Abbruch
Regel 7:
Ausgleich für frühzeitige Beendigung
des Projekts: 20% des übrig
gebliebenen Budgets geht zusätzlich
an DL
(„Money for Nothing“)
Hmm.
Wann ist der Einsatz
von M4NC4F sinnvoll?
Nur bei BV Optimierung!
Nur wenn klar ist, dass ich
das Budget nicht bis zum
Ende aufbrauchen will.
Achtung!
M4NC4F lohnt sich nicht,
wenn das Budget sowieso
gut und sinnvoll genutzt
werden kann.(iSv gute Business Value Generierung regelmäßig möglich)
Achtung!
MAYFLOWER nutzt M4NC4F
erfolgreich in Projekten.
Finale ...
ein paar Empfehlungen
Konzentrieren Sie sich auf
vertrauensvolles Arbeiten auf
Augenhöhe
Setzen Sie im Vertrag nur einen Rahmen,
der Kooperation garantiert und
Verletzung von Kooperation ahndet.
Typische aus Legal & Procurement
getriebene Pönalen sind tabu. Sie
ergeben im agilen Kontext keinen Sinn.
Ahnden Sie Verletzung der Kooperation
mit Abbruchmöglichkeiten
(= Hebel für Auftraggeber)
oder T&M Wandlung
(= Hebel für Auftragnehmer)
Legal & Procurement
müssen mit ins Boot. Und
intensiv beraten werden.
Noch ein Tipp für Ihre
Feature-Planung.
Steroids!
Die User Story muss den
Nachweis erbringen, dass
der Wert erwirtschaftet wird
Steroids!
Es wird der erwartete
Wert angehangen.
(Business Value Poker)
Steroids!
Ich beschreibe den Test, was
ich mir durch dieses Feature
erwarte
(zB 5% mehr Conversion Rate)
Steroids!
Nach Release validiere
ich meine Erwartung.
Steroids!
Lerne & Adaptiere.
Steroids!
Liege ich regelmäßig mit meinen
Erwartungen daneben? Hmm. Dann
werden meine Feature-Wünsche
nicht mehr berücksichtigt.
Steroids!
Buch- und
Linktipps
Buch „Der Agile
Festpreis“ (Boris Gloger)
mit weiteren Ideen
Google-Suche zu „10
contracts for your next
agile project“
„Lasst uns agile Projekte besser
machen. Durch gegenseitiges
Vertrauen & Kooperation“
http://mayflower.de/

Weitere ähnliche Inhalte

Was ist angesagt?

Getting Started - Introduction to Sprint Reviews
Getting Started - Introduction to Sprint ReviewsGetting Started - Introduction to Sprint Reviews
Getting Started - Introduction to Sprint ReviewsEasy Agile
 
IIT Academy: 204 User stories and acceptance criteria
IIT Academy: 204 User stories and acceptance criteriaIIT Academy: 204 User stories and acceptance criteria
IIT Academy: 204 User stories and acceptance criteriaSteven HK Ma | 馬國豪
 
[오픈소스컨설팅]Jira 한글패치가이드 1
[오픈소스컨설팅]Jira 한글패치가이드 1[오픈소스컨설팅]Jira 한글패치가이드 1
[오픈소스컨설팅]Jira 한글패치가이드 1정명훈 Jerry Jeong
 
The 5 Levels Planning in Agile
The 5 Levels Planning in AgileThe 5 Levels Planning in Agile
The 5 Levels Planning in AgileDimitri Ponomareff
 
Agile Estimating
Agile EstimatingAgile Estimating
Agile EstimatingMike Cohn
 
What is the purpose of Sprint planning meeting in Agile?
What is the purpose of Sprint planning meeting in Agile?What is the purpose of Sprint planning meeting in Agile?
What is the purpose of Sprint planning meeting in Agile?Mario Lucero
 
Introduction to Flutter
Introduction to FlutterIntroduction to Flutter
Introduction to FlutterApoorv Pandey
 
Phing: Building with PHP
Phing: Building with PHPPhing: Building with PHP
Phing: Building with PHPhozn
 
Introduction to User Stories
Introduction to User StoriesIntroduction to User Stories
Introduction to User StoriesMike Cohn
 
Oracle Cloud Infrastructure:2022年1月度サービス・アップデート
Oracle Cloud Infrastructure:2022年1月度サービス・アップデートOracle Cloud Infrastructure:2022年1月度サービス・アップデート
Oracle Cloud Infrastructure:2022年1月度サービス・アップデートオラクルエンジニア通信
 
Business Requirements Document Template
Business Requirements Document TemplateBusiness Requirements Document Template
Business Requirements Document TemplateEdmond Cheng
 
Innovation Game & Rétrospective
Innovation Game & RétrospectiveInnovation Game & Rétrospective
Innovation Game & RétrospectiveGuillaume LOURS
 
A. Kamran's DoD and DoR: Definition of Done and Definition of Ready in Scrum
A. Kamran's DoD and DoR: Definition of Done and Definition of Ready in ScrumA. Kamran's DoD and DoR: Definition of Done and Definition of Ready in Scrum
A. Kamran's DoD and DoR: Definition of Done and Definition of Ready in ScrumArman Kamran
 
Outlook アドイン開発入門
Outlook アドイン開発入門Outlook アドイン開発入門
Outlook アドイン開発入門Hiroaki Oikawa
 
Ccpm jako metoda planowania i kontroli projektów
Ccpm jako metoda planowania i kontroli projektówCcpm jako metoda planowania i kontroli projektów
Ccpm jako metoda planowania i kontroli projektówmagda3695
 
GetScrumban Game Facilitator Guide
GetScrumban Game  Facilitator GuideGetScrumban Game  Facilitator Guide
GetScrumban Game Facilitator GuideAjay Reddy
 

Was ist angesagt? (20)

Agile overview
Agile overviewAgile overview
Agile overview
 
Getting Started - Introduction to Sprint Reviews
Getting Started - Introduction to Sprint ReviewsGetting Started - Introduction to Sprint Reviews
Getting Started - Introduction to Sprint Reviews
 
IIT Academy: 204 User stories and acceptance criteria
IIT Academy: 204 User stories and acceptance criteriaIIT Academy: 204 User stories and acceptance criteria
IIT Academy: 204 User stories and acceptance criteria
 
User Stories
User StoriesUser Stories
User Stories
 
Scrum cheatsheet
Scrum cheatsheetScrum cheatsheet
Scrum cheatsheet
 
[오픈소스컨설팅]Jira 한글패치가이드 1
[오픈소스컨설팅]Jira 한글패치가이드 1[오픈소스컨설팅]Jira 한글패치가이드 1
[오픈소스컨설팅]Jira 한글패치가이드 1
 
The 5 Levels Planning in Agile
The 5 Levels Planning in AgileThe 5 Levels Planning in Agile
The 5 Levels Planning in Agile
 
Agile Estimating
Agile EstimatingAgile Estimating
Agile Estimating
 
What is the purpose of Sprint planning meeting in Agile?
What is the purpose of Sprint planning meeting in Agile?What is the purpose of Sprint planning meeting in Agile?
What is the purpose of Sprint planning meeting in Agile?
 
Introduction to Flutter
Introduction to FlutterIntroduction to Flutter
Introduction to Flutter
 
Phing: Building with PHP
Phing: Building with PHPPhing: Building with PHP
Phing: Building with PHP
 
Introduction to User Stories
Introduction to User StoriesIntroduction to User Stories
Introduction to User Stories
 
Oracle Cloud Infrastructure:2022年1月度サービス・アップデート
Oracle Cloud Infrastructure:2022年1月度サービス・アップデートOracle Cloud Infrastructure:2022年1月度サービス・アップデート
Oracle Cloud Infrastructure:2022年1月度サービス・アップデート
 
Business Requirements Document Template
Business Requirements Document TemplateBusiness Requirements Document Template
Business Requirements Document Template
 
Innovation Game & Rétrospective
Innovation Game & RétrospectiveInnovation Game & Rétrospective
Innovation Game & Rétrospective
 
A. Kamran's DoD and DoR: Definition of Done and Definition of Ready in Scrum
A. Kamran's DoD and DoR: Definition of Done and Definition of Ready in ScrumA. Kamran's DoD and DoR: Definition of Done and Definition of Ready in Scrum
A. Kamran's DoD and DoR: Definition of Done and Definition of Ready in Scrum
 
Outlook アドイン開発入門
Outlook アドイン開発入門Outlook アドイン開発入門
Outlook アドイン開発入門
 
Ccpm jako metoda planowania i kontroli projektów
Ccpm jako metoda planowania i kontroli projektówCcpm jako metoda planowania i kontroli projektów
Ccpm jako metoda planowania i kontroli projektów
 
Estimation and Release Planning in Scrum
Estimation and Release Planning in ScrumEstimation and Release Planning in Scrum
Estimation and Release Planning in Scrum
 
GetScrumban Game Facilitator Guide
GetScrumban Game  Facilitator GuideGetScrumban Game  Facilitator Guide
GetScrumban Game Facilitator Guide
 

Ähnlich wie Vertraege in Agilen Projekten

Bessere Software schneller liefern
Bessere Software schneller liefernBessere Software schneller liefern
Bessere Software schneller liefernMayflower GmbH
 
Warum Vertrauen und Ehrlichkeit so wichtig sind in einer Geschäftsbeziehung
Warum Vertrauen und Ehrlichkeit so wichtig sind in einer GeschäftsbeziehungWarum Vertrauen und Ehrlichkeit so wichtig sind in einer Geschäftsbeziehung
Warum Vertrauen und Ehrlichkeit so wichtig sind in einer GeschäftsbeziehungYUHIRO
 
22 wichtige Erkenntnisse aus 5 Jahren YUHIRO
22 wichtige Erkenntnisse aus 5 Jahren YUHIRO22 wichtige Erkenntnisse aus 5 Jahren YUHIRO
22 wichtige Erkenntnisse aus 5 Jahren YUHIROYUHIRO
 
Vertragsgestaltung für agile Softwareentwicklung (OOP 2018, München)
Vertragsgestaltung für agile Softwareentwicklung (OOP 2018, München)Vertragsgestaltung für agile Softwareentwicklung (OOP 2018, München)
Vertragsgestaltung für agile Softwareentwicklung (OOP 2018, München)Stefan ROOCK
 
Einfangen eines technisch kaputten projektes
Einfangen eines technisch kaputten projektesEinfangen eines technisch kaputten projektes
Einfangen eines technisch kaputten projektesJohann-Peter Hartmann
 
Auf zu neuen Ufern! Mit „Lean Startup“ den Kundengeschmack treffen. Elmar Bor...
Auf zu neuen Ufern! Mit „Lean Startup“ den Kundengeschmack treffen. Elmar Bor...Auf zu neuen Ufern! Mit „Lean Startup“ den Kundengeschmack treffen. Elmar Bor...
Auf zu neuen Ufern! Mit „Lean Startup“ den Kundengeschmack treffen. Elmar Bor...SYNGENIO AG
 
Vertrauen als Vertragsbasis (Agile Contracts 2015, München)
Vertrauen als Vertragsbasis (Agile Contracts 2015, München)Vertrauen als Vertragsbasis (Agile Contracts 2015, München)
Vertrauen als Vertragsbasis (Agile Contracts 2015, München)Stefan ROOCK
 
BizDevOps - der nächste Schritt in der Teamzusammensetzung (PM Forum 2019)
BizDevOps - der nächste Schritt in der Teamzusammensetzung (PM Forum 2019)BizDevOps - der nächste Schritt in der Teamzusammensetzung (PM Forum 2019)
BizDevOps - der nächste Schritt in der Teamzusammensetzung (PM Forum 2019)Christoph Schmiedinger
 
FMK2017 - Wichtige Regeln in jedem Programmierauftrag by Christoph Kluss
FMK2017 - Wichtige Regeln in jedem Programmierauftrag by Christoph KlussFMK2017 - Wichtige Regeln in jedem Programmierauftrag by Christoph Kluss
FMK2017 - Wichtige Regeln in jedem Programmierauftrag by Christoph KlussVerein FM Konferenz
 
Agiles Schätzen im Team - Joachim Seibert, OBJEKTspektrum 5/2012
Agiles Schätzen im Team - Joachim Seibert, OBJEKTspektrum 5/2012Agiles Schätzen im Team - Joachim Seibert, OBJEKTspektrum 5/2012
Agiles Schätzen im Team - Joachim Seibert, OBJEKTspektrum 5/2012Martin Seibert
 
Lean Startup: Wie sieht der Einsatz von MVPs in der deutschen Praxis aus?
Lean Startup: Wie sieht der Einsatz von MVPs in der deutschen Praxis aus?Lean Startup: Wie sieht der Einsatz von MVPs in der deutschen Praxis aus?
Lean Startup: Wie sieht der Einsatz von MVPs in der deutschen Praxis aus?Gregor Gross
 
Mobile Apps für Unternehmen: White Paper mit Praxistipps
Mobile Apps für Unternehmen: White Paper mit PraxistippsMobile Apps für Unternehmen: White Paper mit Praxistipps
Mobile Apps für Unternehmen: White Paper mit PraxistippsSterzerPR
 
10 Tipps für ein erfolgreiches CRM-Projekt
10 Tipps für ein erfolgreiches CRM-Projekt 10 Tipps für ein erfolgreiches CRM-Projekt
10 Tipps für ein erfolgreiches CRM-Projekt Uwe Laufer
 
Vorsicht Schuldenfalle - Was die IT aus der Finanzwelt lernen kann
Vorsicht Schuldenfalle - Was die IT aus der Finanzwelt lernen kannVorsicht Schuldenfalle - Was die IT aus der Finanzwelt lernen kann
Vorsicht Schuldenfalle - Was die IT aus der Finanzwelt lernen kannTammo van Lessen
 
FMK2015: Software Engineering Basics by Jan Rüdiger
FMK2015: Software Engineering Basics by Jan RüdigerFMK2015: Software Engineering Basics by Jan Rüdiger
FMK2015: Software Engineering Basics by Jan RüdigerVerein FM Konferenz
 
IT Beschaffungskonferenz, 28.8.2013 - Agile IT Beschaffung - Best Practices
IT Beschaffungskonferenz, 28.8.2013 - Agile IT Beschaffung - Best PracticesIT Beschaffungskonferenz, 28.8.2013 - Agile IT Beschaffung - Best Practices
IT Beschaffungskonferenz, 28.8.2013 - Agile IT Beschaffung - Best PracticesReto Maduz
 

Ähnlich wie Vertraege in Agilen Projekten (20)

Bessere Software schneller liefern
Bessere Software schneller liefernBessere Software schneller liefern
Bessere Software schneller liefern
 
Warum Vertrauen und Ehrlichkeit so wichtig sind in einer Geschäftsbeziehung
Warum Vertrauen und Ehrlichkeit so wichtig sind in einer GeschäftsbeziehungWarum Vertrauen und Ehrlichkeit so wichtig sind in einer Geschäftsbeziehung
Warum Vertrauen und Ehrlichkeit so wichtig sind in einer Geschäftsbeziehung
 
22 wichtige Erkenntnisse aus 5 Jahren YUHIRO
22 wichtige Erkenntnisse aus 5 Jahren YUHIRO22 wichtige Erkenntnisse aus 5 Jahren YUHIRO
22 wichtige Erkenntnisse aus 5 Jahren YUHIRO
 
Vertragsgestaltung für agile Softwareentwicklung (OOP 2018, München)
Vertragsgestaltung für agile Softwareentwicklung (OOP 2018, München)Vertragsgestaltung für agile Softwareentwicklung (OOP 2018, München)
Vertragsgestaltung für agile Softwareentwicklung (OOP 2018, München)
 
Einfangen eines technisch kaputten projektes
Einfangen eines technisch kaputten projektesEinfangen eines technisch kaputten projektes
Einfangen eines technisch kaputten projektes
 
Auf zu neuen Ufern! Mit „Lean Startup“ den Kundengeschmack treffen. Elmar Bor...
Auf zu neuen Ufern! Mit „Lean Startup“ den Kundengeschmack treffen. Elmar Bor...Auf zu neuen Ufern! Mit „Lean Startup“ den Kundengeschmack treffen. Elmar Bor...
Auf zu neuen Ufern! Mit „Lean Startup“ den Kundengeschmack treffen. Elmar Bor...
 
Vertrauen als Vertragsbasis (Agile Contracts 2015, München)
Vertrauen als Vertragsbasis (Agile Contracts 2015, München)Vertrauen als Vertragsbasis (Agile Contracts 2015, München)
Vertrauen als Vertragsbasis (Agile Contracts 2015, München)
 
BizDevOps - der nächste Schritt in der Teamzusammensetzung (PM Forum 2019)
BizDevOps - der nächste Schritt in der Teamzusammensetzung (PM Forum 2019)BizDevOps - der nächste Schritt in der Teamzusammensetzung (PM Forum 2019)
BizDevOps - der nächste Schritt in der Teamzusammensetzung (PM Forum 2019)
 
FMK2017 - Wichtige Regeln in jedem Programmierauftrag by Christoph Kluss
FMK2017 - Wichtige Regeln in jedem Programmierauftrag by Christoph KlussFMK2017 - Wichtige Regeln in jedem Programmierauftrag by Christoph Kluss
FMK2017 - Wichtige Regeln in jedem Programmierauftrag by Christoph Kluss
 
Agiles Schätzen im Team - Joachim Seibert, OBJEKTspektrum 5/2012
Agiles Schätzen im Team - Joachim Seibert, OBJEKTspektrum 5/2012Agiles Schätzen im Team - Joachim Seibert, OBJEKTspektrum 5/2012
Agiles Schätzen im Team - Joachim Seibert, OBJEKTspektrum 5/2012
 
Lean Startup: Wie sieht der Einsatz von MVPs in der deutschen Praxis aus?
Lean Startup: Wie sieht der Einsatz von MVPs in der deutschen Praxis aus?Lean Startup: Wie sieht der Einsatz von MVPs in der deutschen Praxis aus?
Lean Startup: Wie sieht der Einsatz von MVPs in der deutschen Praxis aus?
 
Mobile Apps für Unternehmen: White Paper mit Praxistipps
Mobile Apps für Unternehmen: White Paper mit PraxistippsMobile Apps für Unternehmen: White Paper mit Praxistipps
Mobile Apps für Unternehmen: White Paper mit Praxistipps
 
10 Tipps für ein erfolgreiches CRM-Projekt
10 Tipps für ein erfolgreiches CRM-Projekt 10 Tipps für ein erfolgreiches CRM-Projekt
10 Tipps für ein erfolgreiches CRM-Projekt
 
Vorsicht Schuldenfalle - Was die IT aus der Finanzwelt lernen kann
Vorsicht Schuldenfalle - Was die IT aus der Finanzwelt lernen kannVorsicht Schuldenfalle - Was die IT aus der Finanzwelt lernen kann
Vorsicht Schuldenfalle - Was die IT aus der Finanzwelt lernen kann
 
FMK2015: Software Engineering Basics by Jan Rüdiger
FMK2015: Software Engineering Basics by Jan RüdigerFMK2015: Software Engineering Basics by Jan Rüdiger
FMK2015: Software Engineering Basics by Jan Rüdiger
 
Agil vs. Kunde
Agil vs. KundeAgil vs. Kunde
Agil vs. Kunde
 
Agiles bpm
Agiles bpmAgiles bpm
Agiles bpm
 
IT Beschaffungskonferenz, 28.8.2013 - Agile IT Beschaffung - Best Practices
IT Beschaffungskonferenz, 28.8.2013 - Agile IT Beschaffung - Best PracticesIT Beschaffungskonferenz, 28.8.2013 - Agile IT Beschaffung - Best Practices
IT Beschaffungskonferenz, 28.8.2013 - Agile IT Beschaffung - Best Practices
 
Advanced Continuous Integration
Advanced Continuous IntegrationAdvanced Continuous Integration
Advanced Continuous Integration
 
Teil 1 - BIM Planung die Spass macht
Teil 1 - BIM Planung die Spass machtTeil 1 - BIM Planung die Spass macht
Teil 1 - BIM Planung die Spass macht
 

Mehr von Björn Schotte

Stakeholder zu Fans des Produkts machen
Stakeholder zu Fans des Produkts machenStakeholder zu Fans des Produkts machen
Stakeholder zu Fans des Produkts machenBjörn Schotte
 
Product Owner 2 Product CEO
Product Owner 2 Product CEOProduct Owner 2 Product CEO
Product Owner 2 Product CEOBjörn Schotte
 
Technologiemanagement Agile Transformationen
Technologiemanagement Agile TransformationenTechnologiemanagement Agile Transformationen
Technologiemanagement Agile TransformationenBjörn Schotte
 
Wie ein kleiner Product Owner Grossartiges bewirken kann
Wie ein kleiner Product Owner Grossartiges bewirken kannWie ein kleiner Product Owner Grossartiges bewirken kann
Wie ein kleiner Product Owner Grossartiges bewirken kannBjörn Schotte
 
Employer branding braucht niemand
Employer branding braucht niemandEmployer branding braucht niemand
Employer branding braucht niemandBjörn Schotte
 
OKR, Ziele und Zielsysteme im Agilen
OKR, Ziele und Zielsysteme im AgilenOKR, Ziele und Zielsysteme im Agilen
OKR, Ziele und Zielsysteme im AgilenBjörn Schotte
 
Agile in Marketing HR Business Teams
Agile in Marketing HR Business TeamsAgile in Marketing HR Business Teams
Agile in Marketing HR Business TeamsBjörn Schotte
 
Lean Requirements - von 0 auf 100
Lean Requirements - von 0 auf 100Lean Requirements - von 0 auf 100
Lean Requirements - von 0 auf 100Björn Schotte
 
Gehaltsworkflow Mayflower
Gehaltsworkflow MayflowerGehaltsworkflow Mayflower
Gehaltsworkflow MayflowerBjörn Schotte
 
Mentale Modelle für bessere Zusammenarbeit
Mentale Modelle für bessere ZusammenarbeitMentale Modelle für bessere Zusammenarbeit
Mentale Modelle für bessere ZusammenarbeitBjörn Schotte
 
Digitalisierung alles in Bewegung
Digitalisierung alles in BewegungDigitalisierung alles in Bewegung
Digitalisierung alles in BewegungBjörn Schotte
 
E-Commerce Organisationsstrukturen
E-Commerce OrganisationsstrukturenE-Commerce Organisationsstrukturen
E-Commerce OrganisationsstrukturenBjörn Schotte
 
Die Leiden des Jungen Konsumenten
Die Leiden des Jungen KonsumentenDie Leiden des Jungen Konsumenten
Die Leiden des Jungen KonsumentenBjörn Schotte
 
20 tips for product owners 2014 NewYearEdition
20 tips for product owners 2014 NewYearEdition20 tips for product owners 2014 NewYearEdition
20 tips for product owners 2014 NewYearEditionBjörn Schotte
 
2013 OS E-Commerce Magento OXID Shopware
2013 OS E-Commerce Magento OXID Shopware2013 OS E-Commerce Magento OXID Shopware
2013 OS E-Commerce Magento OXID ShopwareBjörn Schotte
 

Mehr von Björn Schotte (17)

Stakeholder zu Fans des Produkts machen
Stakeholder zu Fans des Produkts machenStakeholder zu Fans des Produkts machen
Stakeholder zu Fans des Produkts machen
 
Product Owner 2 Product CEO
Product Owner 2 Product CEOProduct Owner 2 Product CEO
Product Owner 2 Product CEO
 
Technologiemanagement Agile Transformationen
Technologiemanagement Agile TransformationenTechnologiemanagement Agile Transformationen
Technologiemanagement Agile Transformationen
 
Wie ein kleiner Product Owner Grossartiges bewirken kann
Wie ein kleiner Product Owner Grossartiges bewirken kannWie ein kleiner Product Owner Grossartiges bewirken kann
Wie ein kleiner Product Owner Grossartiges bewirken kann
 
Employer branding braucht niemand
Employer branding braucht niemandEmployer branding braucht niemand
Employer branding braucht niemand
 
OKR, Ziele und Zielsysteme im Agilen
OKR, Ziele und Zielsysteme im AgilenOKR, Ziele und Zielsysteme im Agilen
OKR, Ziele und Zielsysteme im Agilen
 
Agile in Marketing HR Business Teams
Agile in Marketing HR Business TeamsAgile in Marketing HR Business Teams
Agile in Marketing HR Business Teams
 
Lean Requirements - von 0 auf 100
Lean Requirements - von 0 auf 100Lean Requirements - von 0 auf 100
Lean Requirements - von 0 auf 100
 
Gehaltsworkflow Mayflower
Gehaltsworkflow MayflowerGehaltsworkflow Mayflower
Gehaltsworkflow Mayflower
 
Mentale Modelle für bessere Zusammenarbeit
Mentale Modelle für bessere ZusammenarbeitMentale Modelle für bessere Zusammenarbeit
Mentale Modelle für bessere Zusammenarbeit
 
Digitalisierung alles in Bewegung
Digitalisierung alles in BewegungDigitalisierung alles in Bewegung
Digitalisierung alles in Bewegung
 
E-Commerce Organisationsstrukturen
E-Commerce OrganisationsstrukturenE-Commerce Organisationsstrukturen
E-Commerce Organisationsstrukturen
 
IT Probleme loesen
IT Probleme loesenIT Probleme loesen
IT Probleme loesen
 
Die Leiden des Jungen Konsumenten
Die Leiden des Jungen KonsumentenDie Leiden des Jungen Konsumenten
Die Leiden des Jungen Konsumenten
 
20 tips for product owners 2014 NewYearEdition
20 tips for product owners 2014 NewYearEdition20 tips for product owners 2014 NewYearEdition
20 tips for product owners 2014 NewYearEdition
 
Scrum im Marketing
Scrum im MarketingScrum im Marketing
Scrum im Marketing
 
2013 OS E-Commerce Magento OXID Shopware
2013 OS E-Commerce Magento OXID Shopware2013 OS E-Commerce Magento OXID Shopware
2013 OS E-Commerce Magento OXID Shopware
 

Vertraege in Agilen Projekten