Scrum mit Kunden – Warum Scrum alleine nicht reicht

Jeder der schonmal in einem Softwareprojekt mitgearbeitet hat weiß, wie schwer es ist konkrete Aussagen zu machen wie lange es dauert bis das Projekt abgeschlossen ist und die Software fertig ist. Viele Auftraggeber (=Kunden) müssen ein fixes Budget planen und vom Einkauf freigeben lassen, um überhaupt ein Softwareprojekt mit einem Entwicklungspartner beginnen zu können. Wie man das fixe Budget und eine Meilensteinplanung mit Scrum unter einen Hut bekommt, darüber geht es in diesen Artikel.

Viele Unternehmen machen Scrum BUT! Dieses Scrum ABER entsteht, weil Scrum zwar ein in sich griffiger Prozess ist und in der Theorie super funktioniert, aber in der Realität oft mit einigen anderen Ansprüchen und Einschränkungen konkurriert. So ist es beispielsweise in einem Unternehmen notwendig ein gewisses Budget zu planen, welches man für die Erfüllung eines Projekts benötigen wird. Das geplante Budget ist aber an einen gewissen Erfolg des Projekts gebunden. Doch wann ist eine Software erfolgreich umgesetzt und was verspricht Scrum?

Es können folgende Konfliktfelder zwischen SCRUM und anderen Kunden-Bedürfnissen gefunden werden:

  1. Fixes Budget vs. agile Umsetzung
  2. Fixe Meilensteine vs. agile Umsetzung
  3. fertige Software vs. kein Kompromiss hinsichtlich der Qualität
  4. variables Eingehen auf Feedback/Bugs vs. Entwicklung in Sprints
  5. Domänenwissen, Produkthaftung und die Rolle des Product-Owners

1. Fixes Budget vs. agile Umsetzung

Beim Wasserfallmodell muss zwar ein Initialaufwand zur Erstellung der Spezifikation des Funktionsumfangs investiert werden, das Lastenheft kann dann aber einem Auftragnehmer gegeben werden, der sich ein grobes Bild von der Software machen kann und eine Schätzung abgeben kann. Diese Schätzung gibt dann eine gewisse Planungssicherheit für den Auftraggeber (=Kunden) und den Auftragnehmer. Das klingt auf den ersten Blick sehr gut, hat aber mehrere Implikationen.

  1. Der Funktionsumfang ist nach der Schätzung und Beauftragung nicht mehr (so leicht) verhandelbar. Es müssen Change-Request gemacht werden, die jeweils einzeln extra spezifiziert, verhandelt bestellt implementiert, geliefert und bezahlt werden müssen.
  2. Geht die Schätzung die auf Basis des Lastenhefts erstellt wurde daneben, leidet die Qualität der Software, denn der Auftragnehmer versucht dann mit einem geringeren Budget die vielen Anforderungen des Lastenhefts zu erfüllen.
  3. Durch das Fixe Budget wird Kommunikation vom Auftragnehmer nur dann betrieben, wenn es unbedingt sein muss und zu seinen Gunsten ist. Diese fehlende Kommunikation und fehlende Bereitschaft auf Kundenwünsche einzugehen, entsteht aus dem starken Spannungsfeld zwischen dem fixen Budget und dem vereinbarten Funktionsumfang.
  4. Beim Wasserfallmodell besteht somit eine Blackbox-Ansicht der Implementierung aus Kundensicht. Der Kunde wird nicht einbezogen um nicht das Budget zu gefährden. Eine Entzweiung zwischen Kunde und Lieferant entsteht. Es besteht somit keine partnerschaftliche Umsetzung zwischen zwei Wirtschaftspartnern.
  5. Um das Risiko für den Auftragnehmer zu reduzieren werden große Sicherheitspuffer eingeplant und eingeschätzt. Diese „unnötig“ Kosten zahlt letzten Endes der Kunde.

Eine Umsetzung mit klassischen Wasserfallmodell ist somit aus Kundensicht oft nicht empfehlenswert. Als alternative kann agil vorgegangen werden beispielsweise mit Scrum.

Wasserfallmodell Aufwände Schätzungszeitpunkt, Aufwände fallen beim Wasserfallmodell verstärkt bei der Speifikation an.

Abb. 1. Aufwände des Wasserfallmodells

Sich für eine agile Umsetzung mit Scrum zu entscheiden, bedeutet sich für eine iterativ-inkrementelle Vorgehensmethode, mit zweiwöchigen Micro-Projekten (Sprints), Produkt-Release-Candidates und einer Just-In-Time Spezifikation zu entscheiden. Das heißt, die Spezifikation der Anforderungen der zu entwickelnden Features wird nicht (nur) zu Beginn, sondern laufend und regelmäßig gemacht. Das bringt natürlich einige Vor- und Nachteile mit sich. So muss vorab kein aufwändiges monolithisches Pflichtenheft (wie beim Wasserfallmodell) geschrieben werden, dessen Inhalt erfahrungsgemäß ohnehin nie alle benötigten Informationen und Szenarien beinhaltet. Scrum reduziert durch seine Just-in-Time Spezifikation in Form von Product-Backlog-Items, gekoppelt durch die Strategie „Kommunikation vor Dokumentation“ sowohl den Aufwand der Anforderungsdokumentation, als auch das Risiko, dass Anforderungen missinterpretiert werden oder fehlen. Es werden bei Scrum daher nur die wirklich für den Entwickler relevanten Informationen dokumentiert und Detailspezifikationen viel mit Kommunikation gelöst wird. Soweit so gut. Scrum bietet daher Unternehmen die Möglichkeit von der Produktvision weg sehr schnell mit der Umsetzung starten zu können. Das langwierige und schwierige Spezifizieren in einer Vorprojektphase fällt weg, stattdessen überlagern sich Spezifikationsphase und Implementierungsphase. (Siehe Abb. 1 Wasserfall-Modell Aufwände und Abb. 2 Scrum-Aufwände) Die Spezifikation wird somit laufend in Zusammenarbeit mit dem Product-Owner und dem Team gemacht.

Scrum - Aufwände in Sprints

Abb. 2. Scrum – Aufwände in Sprints

Der Nachteil dabei, Auftraggeber müssen in den allermeisten Fällen eine Budgetplanung für ihre Softwareprojekte durchführen. Abteilungsleiter, das Mittlere-Management oder Projektleiter müssen ihren Vorgesetzten reporten und eine Projekt- und Budgetplanung vorlegen und eine Planungssicherheit garantieren. Das sind Fragen auf die Scrum oft keine Antwort hat, bzw. oft erst verspätet oder nur teilweise beantworten kann.

2. Fixe Meilensteine vs. agile Umsetzung

Wie oben bereits erwähnt benötigen Kunden (=Auftraggeber von Softwareprojekten) sehr oft eine Projektplanung und Budgetplanung um ihren Vorgesetzten und der Geschäftsführung berichten zu können und das Projekt zu steuern. Als Product-Owner haben Kunden extrem viele sehr wirksame Möglichkein das Projekt positiv zu beeinflussen. Scrum bietet dabei jeder Expertengruppe genügend Freiräume, dass umzusetzen was sie gute können. Der Product-Owner konzentriert sich auf das Produkt, das Team auf die technische Umsetzung und der Scrum-Master auf den Umsetzungsprozess. Scrum bietet somit Freiheiten und zählt darauf, dass der Prozess mit Hilfe der beteiligten Experten und deren offener transparenter Kommunikation und deren Engagement den richtigen Umsetzungspfad findet. Scrum verspricht aber nicht ein gewisses Umsetzungsziel in einer gewissen Zeit mit einem gewissen Aufwand zu erreichen. Die Verantwortung diesbezüglich wird bei Scrum hin und her geschoben. Der Product-Owner spezifiziert und priorisiert das Produktbacklog. Das Team nimmt Spezifikationen ab und schätzt die Aufwände. Das Team commitet sich auf Sprintziele. Nicht mehr aber auch nicht weniger. Es gibt laut Scrum kein Commitment auf Meilenstein-Ebene, da es auch wenig bis keinen Sinn macht. Es ist nicht realistisch, ohne fixes Projektziel (vollständige Spezifikation des Funktionsumfangs) eine Meilensteinplanung zu erstellen oder gar ein Projektcontrolling durchzuführen. Es ist aber ebenfalls unrealistisch eine detaillierte, vollständige Spezifikation vor Beginn eines Softwareprojekts zu erstellen, welche dann inklusive Umsetzung, wirtschaftlich an eine Umsetzung allein mittels Scrum herankommt.

Was bietet also Scrum?

  • Der Product-Owner kann das Backlog und somit das zu implementierende Produkt bestimmen. Er kann die Priorität der einzelnen PBIs bestimmen und somit bestimmt er was, wann implementiert werden kann. Es fehlt ihm aber das technische Verständnis für die technischen Zusammenhänge und Abhängigkeiten, als auch er Gesamtüberblick über den technischen Aufwand.
  • Scrum bietet die Möglichkeit, wenn das Product-Backlog grob feststeht und bereits einige Sprints vom Team durchgeführt wurden eine Grobschätzung aller PBIs zu machen und mit der Team-Velocity eine ungefähre Durchlaufzeit zu berechnen.
  • Das Team kann realistisch schätzen und sein Commitment auf Sprintziele abgeben und dafür eintreten, dass eine gute Qualität bei jedem Sprint geliefert wird.

Was bietet Scrum nicht?

  • Es gibt keinen fixen Projektplan
  • Es gibt keinen Meilensteinplan
  • Es gibt keinen der für die Einhaltung von Meilensteinziele verantwortlich ist, oder jeder ist dafür verantwortlich
  • Es gibt keine fixen Anforderungen zu beginn
  • Man kann keine Aussage bei Start machen wo man nach x Monaten steht. Diese Aussage kann man nur vage treffen nachdem die Velocity feststeht.

3. Fixe Zeitpläne und fertige Software vs. kein Kompromiss hinsichtlich Qualität

Der Kunde, der zugleich oft Product-Owner in Scrum-Projekten ist, ist meist der Domänenexperte. Er hat das Domänen-Knowhow, ist für das Stakeholder-Management verantwortlich und weiß, was seine User wollen. Als Projektverantwortlicher auf Kundenseite tritt er für ein gewisses Budget und einen Zeitplan ein, den er seinem Management vorgelegt hat. Die Software muss also innerhalb eines Gewissen Budgets und eines Zeitplans „fertig“ werden. Bei Scrum gibt es dieses „fertig“ zu Beginn des Projekts aber nicht. Es gibt einzig und alleine eine Produktvision. In vielen Fällen ist es sogar so, dass diese Produktvision gar nicht vom Product-Owner selbst kommt. Vielmehr kommt diese Vision von einen Vorgesetzten des Product-Owners. Hier findet man schon die erste Kommunikationsschnittstelle zwischen dem Visionär und dem Product-Owner, bei der Information verloren gehen kann. Eine „fertige“ Software in Augen des Product-Owners kann für den visionsstiftenden Vorgesetzten noch unvollständig sein. Das Selbst wenn der Product-Owner ein gutes Reporting und Produktmanagement durchführt, so wird das Bild der an Gestalt gewinnenden Software erst nach und nach klarer und deutlicher. Es kann somit schnell passieren, dass das Produkt nach Verstreichen einer gewissen Zeit, oder nach Aufbrauchen eines gewissen Budgets noch nicht dort ist, wo es eigentlich sein sollte. In diesen Situationen sind dann zwei Szenarien möglich:

  1. Der Product-Owner übt Druck auf das Umsetzungsteam aus und das Team beginnt zu „optimieren“ um noch „schnell“ alle gewünschten Features in das Produkt zu bekommen.
  2. Der Product-Owner muss seinen Vorgesetzten Reporten, dass das Projekt doch mehr Budget/Zeit braucht als ursprünglich eingepreist und kalkuliert.

In beiden Fällen bedeutet das ein Risiko für das Projekt und einige negative Auswirkungen auf Projekt, Team und Produkt.

Im ersten Fall weicht das Team von einem wichtigen Grundsatz von Scrum ab, es bricht die Regel: „Kein Kompromiss hinsichtlich der Qualität“ was wiederum eine Verschlechterung der Produktqualität mit sich bringt. Im zweiten Fall muss der Product-Owner und das Projekt zu Kreuze kriechen mitteleinen dass ihre Versprechen nicht eingehalten wurden und einen Gesichtsverlust hinnehmen, was wiederum eine Verschlechterung in das Vertrauen des Projekts und des Teams mit sich bringt und letzten Endes eine Verteuerung des Produkts oder eine Verschlechterung der Wirtschaftlichkeit des Produkts.

4. Variables Eingehen auf Feedback/Bugs vs. Entwicklung in Sprints

Ist ein Projekt noch in der Entwicklung und noch nicht Produktiv im Einsatz, so ist es meist einfach Feedback einzumelden und bei dem nächsten oder übernächsten Sprint einzuplanen. Das funktioniert aber nur so lange, solange es keine produktive Liveumgebung mit echten Usern und echten Fehlern gibt. Viele Projekte befinden sich aber nach einer ersten Ausbaustufe im Produktivbetrieb. In einer idealen Welt betreibt man Staging, hat ein Entwicklungsteam, einen 1st-Level-Support einen 2nd-Level-Support und ein Wartungsteam, Entwicklung und Wartung und Support sind also getrennt. In der Realität müssen aber Unternehmen und Software wirtschaftlich sein, und eine derartige Infrastruktur mit hochqualifizierten gut bezahlten Entwicklern, ist kostspielig, muss wirtschaftlich sein und erst aufgebaut werden. Es kommt also sehr schnell vor, dass das Entwicklungsteam noch an einer zweiten Ausbaustufe arbeitet, aber gleichzeitig wichtige Fehler gemeldet werden die behoben werden müssen. Scrum regelt diese Situationen nicht, ganz im Gegenteil, Scrum verbietet es während eines Sprints das Sprintziel zu verändern und Bugs oder Features in den Sprint hinzuzuziehen. Eine Situation die nicht akzeptabel und realistisch ist. Wenn ein Kunde die Software der ersten Ausbaustufe bei seinen Usern ausgerollt hat und diese nicht arbeiten können kann schnell ein großer Schaden entstehen. Es ist nicht realistisch dann noch zwei bis vier Wochen zu warten, um dann die geänderten Features oder Bugs im nächsten Sprint einzuplanen. Hier muss vom Scrum-Prozess abgewichen werden.

5. Domänenwissen, Produkthaftung und die Rolle des Product-Owners

Der Product-Owner (Kunde) hat oft als einziger das notwendige Domänen-Knowhow und führt das Stakeholder-Management durch, bei dem er auch Informationen, Feedback und Wünsche der Keyuser sammelt und in das Produkt einfließen lässt. Er koordiniert Schnittstellen zu anderen, oft internen Systemen und sorgt für die Implementierung dieser Schnittstellen. Als Auftraggeber arbeitet der Product-Onwer intensiv gemeinsam mit dem Auftragnehmer verkörpert durch das Umsetzungsteam gemeinsam an der Realisierung der Software. Er hat maßgeblichen Einfluss auf die entstehende Qualität der Software und führt nach jedem Sprint-Meeting die Qualitätsabnahme der einzelnen Features durch. Für die technische Umsetzung der Features ist zwar der Auftragnehmer also das Team verantwortlich, sollten hier aber technische Abhängigkeiten zu Schnittstellen sein, ist hier ebenfalls der Product-Owner beteiligt. All dies führt dazu, dass keine klaren Linien gezogen werden können wer wofür eine Produkthaftung übernimmt. Ganz im Gegensatz zum Wasserfallmodell bei der es klar definierte Schnittstellen zwischen Auftraggeber und Auftragnehmer gibt. Es gibt eine von allen Seiten verständliche und klare Beschreibung der Anforderungen in Form eines Lastenhefts. Alles was im Lastenheft gefordert wird muss vom Auftragnehmer umgesetzt werden. Fehlen Funktionalität oder sind sie Fehlerhaft kann der Auftraggeber eine Verbesserung der Anforderungen laut Lastenheft verlangen. Umgekehrt kann aber auch der Auftragnehmer Anforderungen die nicht explizit im Lastenheft enthalten sind weglassen und sie im Nachhinein mittels Change-Requests nachholen lassen. Nach Abnahme der Software durch den Auftraggeber besteht nur mehr eine gewisse Zeit eine Gewährleistung (sofern nicht vertraglich abbedungen), und danach sind alle Support- und Wartungsanfragen extra zwischen Auftraggeber und Auftragnehmer zu vereinbaren oder ansonsten in der Verantwortung des Kunden.

Empfehlungen für ein besseres vorgehen

Um sowohl die Vorteile der zeitlichen und budgetären Planungssicherheiten auf der einen Seite und die Vorteile der agilen Umsetzung mit Scrum auf der anderen Seite zu erhalten, muss der Standard Scrum-Prozess um einige Punkte erweitert werden bzw. einiges an Vorarbeiten geleistet werden. Die folgenden Punkte stellen eine Handlungsempfehlung dar, die eingehalten werden können wenn sowohl Planungssicherheit als auch Agilität wichtig ist.

1. Gemeinsame Vision

Beim Kunden muss der Product-Owner bei seinem Management und bei alle Stakeholder dafür eintreten, dass eine gleiche Vision von der zu entwickelnden Software besteht.

2. Scoping und Backlog initial anlegen

Abgeleitet von der Vision wird eine Vorprojektphase eingeführt. In dieser Scopeing-Phase wird, in der ähnlich wie beim Wasserfallmodell bereits eine grobe Spezifikation der Software erstellt. Es werden Product Backlog Items (=PBIs) mit User-Stories angelegt und diese zum Teil oberflächlich, wo es drauf ankommt detaillierter, erfasst und einer Grobschätzung unterzogen. Es ist nicht zielführend hier in alte Wasserfallmodell-Verhaltensweisen zurückzufallen und ein Lastenheft mit ausgiebiger Dokumentation in Form eines Product-Backlogs zu schreiben. Ziel ist es einen groben Umfang/Umriss des Projektes zu erhalten, in dem alle wichtigen Programmfeatures und Module enthalten sein sollten. Diese Features bilden dann einen Scope und können grob geschätzt werden. Dieser Projektumfang kann dann einen Richtwert geben, wieviel Budget eingeplant werden muss.

3. Grobe Budgetplanung aufgrund des Scopes + Sicherheitspuffer

Der Scope bzw. der geschätzte Gesamtaufwand wird entweder in Story-Points oder gleich in Umsetzungsaufwand in Stunden des Teams erstellt. Wenn das Team noch nicht feststeht, und in Story-Points geschätzt wurde, muss ein Schlüssel für die Umsetzung gefunden werden. Dazu muss der Auftragnehmer einige PBIs begutachten und eine Schätzung abgeben wieviel Umsetzungsaufwand es bedeuten würde. Danach kann der Umrechnungsschlüssel auf alle Story-Points angewendet werden und somit eine grobe Budgetplanung erstellt werden. Da zu dieser frühen Zeit noch keine Velocity bekannt ist, muss das Budget mit einem Sicherheitspuffer ergänzt werden.

4. Detailplanung des ersten Sprints

Im ersten Umsetzungsschritt werden bei Scrum jene PBIs/User-Stories entwickelt die am höchsten priorisiert sind und/oder das größte Risiko darstellen. Der Product-Owner wählt daher die ersten PBIs aus die dieser Definition entsprechen und präsentiert diese in einem ersten Refinementmeeting dem Team. Das Team nimmt die Anforderungen ab und schätzt die Aufwände sodass die Defintion of Ready erfüllt ist. Danach kann das erste Sprintbacklog angelegt werden. Nach der Detailplanung und der Abarbeitung kann eine erste Team-Velocity berechnet werden. Nach 1-3 Sprints sollte sich die Velocity stabilisiert haben und es kann ein Gesamtaufwand der im Backlog befindlichen Backlog-Items berechnet werden.

5. Gesamtaufwand mit Scoping und Meilensteinplanung abgleichen

Sollten die PBIs nicht in Story-Points sondern in Aufwandsstunden geschätzt worden sein müssen sie nun eventuell nochmal mit den Erkenntnissen aus den ersten Sprints nachgebessert werden. Wenn mit Story-Points gearbeitet wurde, so kann mit der Velocity ein Umrechnungsschlüssel auf Stunden und somit auf Budget entwickelt werden und das Gesamtbudget berechnet werden. Mit der Team-Velocity kann ebenfalls ein grober Sprintplan und ein Meilensteinplan aufgestellt werden. Sollte bereits vor den Ersten Sprint eine derartige Planung stattfinden so müssen einerseits Sicherheitspuffer für Budget und Zeitplan einkalkuliert werden, andererseits müssen Velocity oder Schätzungen von Erfahrungen aus anderen Projekten herangezogen werden.

6. Klassisches Projektmanagement und Produktmanagement bei PO ansiedeln

Um im Projekt Vorteile von klassischen Projektmanagement und des Produktmanagements zu nutzen sollte der Product-Owner diese Aufgaben übernehmen. Er ist als Domänenexperte und als Verantwortlicher der für das Produkt und die Wirtschaftlichkeit des Produkts eintritt, derjenige der Das Projekt am einfachsten und effizientesten beeinflussen kann. Dabei sollte darauf geachtet werden, dass positive Effekte die Scrum aufweist erhalten bleiben. Eine Trennung zwischen Produktmanagement und Umsetzung sollte jedenfalls erhalten bleiben, sprich: Der Product-Onwer sollte sich nicht einmischen wie die Software technisch umgesetzt werden soll.

7. Testing, Feedback, Key-User, Test-User

Es sollten gleich von Beginn an mittel Continuous Integration und Staging Testumgebungen eingerichtet werden, um nach jedem Sprint-Review Tests durchführen zu können und Key-Usern und Test-Usern die Möglichkeit zu geben ausgiebig zu testen. Feedback von Usern sollte frühzeitig in den nächsten Sprint eingeplant und ungesetzt werden.

8. Support und Wartung möglichst bald etablieren

Um sich möglichst unabhängig von den Auftragnehmern zu machen aber gleichzeitig eine parallele Weiterentwicklung zu gewährleisten sollte möglichst schnell mit dem unternehmensinternen Kompetenzaufbau in Support und Wartung der Software begonnen werden.

9. Flexibilität bei Bugs in Produktivsystemen bei Sprints

Auf Fehler muss, wenn die Software parallel produktiv bereits betrieben wird, auch während der Sprints eingegangen werden. Es empfiehlt sich hierzu freie Kapazitäten pro Sprint einzuplanen.

10. Gemeinsam statt gegeneinander und Effizienzsteigerung durch aktive Arbeit des Product-Owners

Die gemeinsame Abarbeitung des Projekts zwischen Kunde und Auftragnehmer ist ein Schlüsselerfolgsfaktor von Scrum. Es sollte aktiv von Product-Owner mitgearbeitet werden und vom Product-Onwer genügend Freiräume und Ressourcen neben dem Tagesgeschäft für das Projekt eingeplant werden.

11. Whitebox statt Blackbox

Transparenz und gemeinsames Arbeiten sollten von Scrum übernommen werden. Kunde und Auftragnehmer sollte sich nicht als Kunde und Auftragnehmer sondern als Partner sehen die gemeinsam zu gleichen Teilen für dem Projekterfolg verantwortlich sind.

12. Staging, Defenisve Releasing

Continuous Integration und Staging sind mächtige Konzepte die während des Scrum-Prozesses eingesetzt werden sollen. Die QA-Stage sollte zumindest vor jedem Sprint-Review aktualisiert werden. In die Produktiv-Umgebung sollte defensiv mit Realeasmanagment umgegangen werden um lästige Bugs zu vermeiden.

13. „Fertig“ definieren und Awareness dass es kein „fertig“ gibt

Von Beginn an sollte es eine Definition of Done im Projekt geben. Die aussagt was erfüllt sein muss, damit ein Feature funktioniert und fertig ist. Dabei sollten auch Integration in die Testumgebung enthalten sein. Es kann keine fehlerfreie Software geben, daher sollte der Kunde frühzeitig geschult werden, dass Bugs auftreten können. Kunden die noch nie Softwareprojekte umgesetzt haben und nur Standardsoftware kennen sind es nicht gewohnt Fehlermeldungen von Softwareprodukten zu bekommen.

14. Nicht immer mehr und mehr wünschen

Scrum ist ein selbstoptimierender Prozess, wenn mit einer vorzeitigen Projektscoping-Phase und einem Budget mit Sicherheitspuffer gearbeitet wurde, so ist es wahrscheinlich, dass die initial geschätzte Funktionalität implementiert wird, bevor das Budget aufgebraucht wurde. Scrum verleitet dazu immer mehr Features zu planen und umzusetzen und das Produkt immer noch besser zu machen. In den oben beschriebenen Fall sollte der Product-Owner nicht mehr und mehr Features planen und mit dem Team umsetzen bis das Budget samt Sicherheitspuffer aufgebraucht ist. Sollte Budget über bleiben sollte dieses für etwaige Fehlerbehebungen aufgespart werden. Das Produkt sollte möglichst einfach und simpel gehalten werden.

15. Haftungen Rechte und Pflichten vertraglich gut absichern

Vor Beginn des agilen Projekts sollten vertragliche Rechte und Pflichten der beiden Geschäftspartner genau geregelt werden. Es sollte eine Präambel mit allen wichtigen Details über die Zusammenarbeit gemeinsam geschrieben werden.

Buchempfehlungen:

 

Mehr zum Thema Digitalisierung

https://www.facebook.com/Digitalisierung Täglich zwischen 20 und 100 Beiträge aus über 200 verschiedenen Fachquellen

https://www.facebook.com/DerDigitalisierungsCoach/ Der DigitalisierungsCoach auf Facebook, Infos, Termine und mehr.

Zum Autor:

David Theil aus Linz Oberösterreich ist Digitalisierungs-Coach, Software-Entwickler und als Head of Presales and Delivery für über 30 Softwareentwickler verantwortlich. Beruflich beschäftigt er sich bereits jahrelang mit der Digitalisierung und hat bereits bei vielen Digitalisierungs-Projekten in der Wirtschaft federführend mitgewirkt. Er bewegt sich in Themen wie Digitalisierung, IoT, oder Industrie 4.0 sowohl beratend als auch praktisch mit echten Lösungen.

https://medium.com/@david.theil

https://www.xing.com/profile/David_Theil

https://www.linkedin.com/in/david-theil-1a4190148/

https://www.linkedin.com/groups/8678887

https://twitter.com/DavidTheil

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden /  Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden /  Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden /  Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden /  Ändern )

Verbinde mit %s

Create a website or blog at WordPress.com

Nach oben ↑

%d Bloggern gefällt das: