Agile Projekte nach Scrum Methodik mit Festpreisbindung

Lesedauer: ca. 7 Minuten

Wann ist eine agile Festpreisbindung sinnvoll?

Schon lange ist bekannt, dass konventionelle Sourcing-Ansätze den agilen Projektlieferungen durch komplexe und lange Verhandlungen im Wege stehen. Die langfristigen Vertragsvereinbarungen müssen trotz einer potentiellen Unzufriedenheit des Auftraggebers mit den Leistungen eines Service Providers fortgeführt werden. Die agilen Projektmethoden und -Rahmenwerke machen es schwer, konventionelle Service Level Agreements anzuwenden.
Welcher Weg aber führt um dieses Dilemma herum?

Ist es möglich, agile Projektverträge zu Festpreiskonditionen zu vereinbaren und somit ein Projekt nach agilen Rahmenwerken, zum Beispiel Scrum in Sprints zu liefern, die Planung und Abrechnung aber nach einem klassischen Festpreismodell abzuwickeln?

Mit Scrum lassen sich Projekte managen und organisieren lassen. Diese Methode ist nicht nur dafür geeignet die Entwicklung Ihrer Unternehmensprozesse voranzutreiben, sondern kann auch zu einer Optimierung der Selbstorganisation in Ihrem Unternehmen schaffen. Scrum ist besonders für seine engen Kommunikationsstrukturen bekannt, die den Überblick und die Projektorganisation im Team übersichtlich und strukturiert managed. Neben einer statischen Projektorganisation werden bei Scrum jedoch nur die Ziele im Vorfeld definiert. So kann sich der Projektablauf individuell und flexibel in vorab definierten Zeitintervallen, so genannte Sprints (meist 1-2 Wochen) gestaltet werden. Somit bietet Scrum die Möglichkeit, den Teams, die crossfunctional beziehungsweise interdisziplinär zusammengesetzt sind,  die Freiheit den Weg dorthin selbst zu gestalten.
Bei der agilen Projektmethodik nach Scrum gibt es verschiedene Rollen, die Ihre Mitarbeiter in den Teams annehmen können:
Die drei zentralen Rollen sind der Product Owner, der Scrum Master und das Entwicklungsteam. Jeder einzelne davon bekommt eine eigene Management-Funktion mit spezifischen Verantwortlichkeiten und Aufgaben zugewiesen. Nur wenn diese perfekt miteinander harmonieren, können Projekte erfolgreich verlaufen.

Das funktioniert! Allerdings müssen Sie sich darüber im Klaren sein, dass dies erst ab einer bestimmten Größenordnung von Projekten überhaupt sinnvoll und zur Zufriedenheit aller Vertragsparteien realistisch ist.

Ein agiler Projektvertrag zu Festpreiskonditionen bedeutet, dass das Projekt nach agilen Rahmenwerken, wie Scrum, in Sprints geliefert wird, die Planung und Abrechnung aber nach einem klassischen Festpreismodell erfolgt. Das Risiko nachträglicher Änderungen wird durch die Aufteilung des Projektes in Sprints gering gehalten. Voraussetzungen dafür sind die Einhaltung und Durchführung der Sprint Plannings, Sprint Reviews sowie festgelegte Sprint-Längen.

Vorab müssen der Scope sowie die Abnahmekriterien so genau wie möglich definiert werden, da es sich ja um eine Festpreisbindung handeln soll. In der agilen Welt wird erfolgt dies im Product Backlog, den User Stories und den Epics. Der Product Backlog enthält alle Anforderungen an das Produkt, wie beispielsweise die Kundenwünsche und -anforderungen. Die User Stories beschreiben diese Anforderungen und umfasst meist nicht mehr als ein bis zwei Sätze, während die Erics im Kontrast dazu alle wichtigen Details umfassen.
Die Lieferung der Leistungen erfolgt dann im Rahmen zeitlich fest definierter Sprints. Für Werkverträge sicherlich ungewöhnlich ist hier die Beschreibung der Leistungen in User Stories.

Sprint Methodik von Innovations ON Blogartikel
Produkt Backlog
Sprint Methodik von Innovations ON Blogartikel
Sprint Planning

Innovations ON GmbH Trainings für AWS Zertifizierungen und Weiterbildungen

Die Festpreisvereinbarung

Ein wesentlicher Unterschied zum klassischen Werkvertrag mit Festpreisbindung ist hier, dass die Festpreisvereinbarung sich immer auf einen Sprint bezieht: Die Bezahlung erfolgt, wenn die so genannte. Definition of Done (DoD) für die im Sprint Backlog aufgenommenen Tasks erfüllt und das Ergebnis von Product Owner abgenommen wird. Der Preis errechnet sich dabei über die Story Points und den Wert pro Story Point. Der Wert pro Story Point kann nach Durchlauf mehrerer Sprints angepasst werden.

Der Product Owner verpflichtet sich, den Product Backlog mit ausreichend Inhalt zu füllen, so dass das Team ausgelastet werden kann.

Der Sprint Backlog liegt in der Verantwortung des Entwicklungsteams. Dieses hat die Hoheit über die Items im Sprint Backlog. Nur das Development Team kann Änderungen des Sprint Backlog nach Absprache mit dem Product Owner durchführen.

Eine erfolgsbasierte Vergütung, bei der der Auftraggeber nur im Erfolgsfall (DoD für die Tasks des Sprint Backlogs wurde erreicht) die Vergütung freigibt, ist eine denkbare weitere Möglichkeit eines agilen Festpreisvertrages. Dies setzt allerdings eine sehr genaue Abschätzung der Aufwände (Story Points) und sehr genaue, von beiden Vertragsseiten gemeinsam abgestimmte, Abnahmekriterien (DoD) voraus. Die Erfahrung zeigt, dass dies eher schwer realisierbar ist. Vor allem gehen die Vorteile der Agilität durch zeitlich aufwändige Abstimmungen über Produktlieferungen (User Stories, Increment), Aufwandsabschätzungen (Story Points) und den Abnahmekriterien verloren - denn letztendlich muss das finanzielle Risiko vertretbar sein. Denkbar und sinnvoller sind hier Performance-bezogene Vergütungen (vorzeitige Zielerreichung, prozentuale Zielerreichung bezogen auf die Anzahl der User Stories des Sprints, etc).

Das agile Festpreisprojekt strebt eine zum Projektstart vollständige, wenn auch noch nicht detaillierte Beschreibung des Vertragsgegenstandes an. Die beiden Vertragspartner (Auftraggeber, Auftragnehmer) treffen gemeinsam Annahmen bezüglich des Geschäftswertes, des Umsetzungsrisikos, dem Aufwand und den Kosten. Auf Grundlage dieser Annahmen wird ein indikativer Festpreisrahmen vereinbart, der noch nicht bindend ist. Mitunter einer der wesentlichen Vorteile ist die Risikoteilung - beide Vertragsparteien tragen den Mehraufwand für ungeplante Änderungen mit. Es kann auch die Möglichkeit eines Vertragsausstiegs für beide Parteien (Ausstiegspunkte) vereinbart werden.

In einer Testphase (mehrere Sprints; Checkpoint-Phase) beginnt die erste Umsetzung. Am Ende dieser Phase wird aus der so genannten Velocity der durchschnittliche und tatsächliche Aufwand ermittelt und mit den vor Projektbeginn getroffenen Annahmen abgeglichen - die Vertragsbedingungen werden zu diesem Zeitpunkt festgelegt (Festlegung der Sprint-Festpreis-Baseline).

Ermittlung des Sprint-Festpreises

Für die Ermittlung des Festpreises werden folgende Kriterien zugrunde gelegt:

  • Die Beschreibung des Vertragsgegenstandes erfolgt auf einer groben Ebene (Projektziele, Themen, Anforderungen und User Stories/Epics)
  • Ein erfahrener Product Owner des Auftraggebers hat den Product Backlog in Absprache mit dem Scrum-Team initial erstellt.
  • Ein für das Projekt repräsentativer Epic oder mehrere User Stories werden ausgewählt (Referenz-User-Stories).
  • Mindestens zwei (2), aber maximal fünf (5) Sprints werden für die Ermittlung festgelegt.
  • In der Sprintplanung bestimmen die Vertragspartner anhand der Referenz-User-Stories mit Hilfe von Story Points die Komplexität für den Sprint (Planning Poker). Planning Poker (auch als Scrum Poker bezeichnet) ist eine spielerische Team-Building-Aktivität zur Erreichung von Konsens in Bezug auf die Aufwandsschätzung innerhalb einer Gruppe von agilen Projekten. Zusätzlich wird eine Annahme bezüglich des Risikos bei der
  • Implementierung sowie des Business-Values geschätzt. Daraus resultiert ein indikativer Festpreisrahmen, der noch nicht vertraglich bindend ist und erst in einem späteren Schritt (nämlich am Ende der Checkpoint-Phase) festgelegt wird.
  • Die Erfahrung zeigt, dass zwischen 5 und maximal 15 User Stories pro Sprint bewältigt werden können (Sprintlänge[7]: 2 Wochen). Dies bedeutet, dass die User Stories sehr gut vorbereitet werden müssen.
  • Die Sprint-Länge für die Test-Durchläufe sollte in der Checkpoint-Phase jeweils zwei (2) Wochen betragen. Dies deckt auch den zeitlichen Bedarf für das Sprint Planning, den Sprint Review sowie die Sprint Retrospektive ab.
  • Der Aufwand für die Checkpoint-Phase wird nach Aufwand in Rechnung gestellt.
  • Das Development Team wird aus unterschiedlichen Rollen der Innovations ON zusammengesetzt (die Rollen haben unterschiedliche Tagessätze[8]).
  • Es wird eine Checkpoint-Phase (Testphase) festgelegt und mit der Umsetzung begonnen.

Hieraus werden empirische Erkenntnisse bezüglich der sog. Sprint Velocity gewonnen. Die Velocity ist der Durchschnitt über die Summen aller vom Team erledigten Story Points pro Sprint. Im Grunde zeigt die aktuelle Velocity die aktuelle Geschwindigkeit in der Umsetzung innerhalb eines Sprints an. Es gibt also eine aktuelle Velocity und eine durchschnittliche Velocity pro Sprint.Wir empfehlen eine Länge von mindestens zwei (2) und maximal fünf (5) Sprints mit einer Dauer der Sprints von zwei (2) Wochen (time-boxed). Es wird der arithmetische Mittelwert der Velocity der Sprints gebildet. Zusätzlich wird das arithmetische Mittel für die Kosten (Summe Tagessatz pro Rolle und Personentag) festgestellt.

Dadurch werden die Kosten pro Story Point für erfolgreich gelieferte Product Increments errechnet und mit zuvor getroffenen Annahmen überprüft und ggf. angepasst. Diese stellt die Baseline des Sprint-Festpreises dar. Abschließend wird der Festpreisrahmen vertraglich bindend festgelegt. Ebenso wird die Verteilung der Risiken vereinbart (In welchem Umfang werden entstandene Kosten bei Überschreitung des Maximalpreisrahmens an den Auftraggeber verrechnet? Erfolgt eine Incentivierung bei Unterschreitung der erwarteten Velocity?)

Nach jeweils vier (4) Sprints werden erneut die Velocity und der mittlere Aufwand (basierend auf den Innovations ON-internen Tagessätzen) kalkuliert. Die Abweichung zur Baseline wird bestimmt und ggf. eine Preisanpassung durchgeführt. Eine sinnvolle Erweiterung des Vertrages stellt die 60-40-20-Regelung dar, durch die eine gewisse Flexibilität in Form eines Kapazitätenpuffers hinzugefügt wird. Diese Regelung teilt den Backlog und den Projektumfang in eine 60%, 40% und 20% Prioritätenliste auf. Die Kategorie 60% bedeutet “Muss”, 40% bedeutet “Möchte” und 20% bedeutet “Stretch Goal”.

Die Elemente der Kategorie 60% sind auf alle Fälle zu liefern. Die Elemente der Kategorie 40% sind ebenfalls zu liefen, allerdings mit einem gewissen Verhandlungsspielraum (Tausch gegen andere im Rahmen des Change-Managements).

Die Summe der Elemente dieser beiden Kategorien stellen den “in-scope backlog” dar. Bei den Elementen der Kategorie 20% handelt es sich um Elemente, die dann bearbeitet werden, wenn der “in-scope backlog” frühzeitig fertiggestellt wurde.

Innovations ON Blogartikel SCRUM
Die Sprintlänge(n)

In der Regel und nach dem Scrum-Framework ist erst nach Durchlauf einiger Sprints feststellbar, welches eine optimale Sprintlänge ist. Als Grundlage kann man wählen: Je mehr Probleme es im Ablauf der Prozesse gibt, desto sinnvoller ist ein kürzerer Sprint-Zyklus. Insbesondere zu Beginn eines neuen Projektes (oder auch der Zusammenstellung eines neuen Scrum-Teams) beträgt die optimale Sprintlänge eine (1) Woche. Grundsätzlich kann die Länge der Sprints in der Sprint Retrospektive korrigiert werden.

Je genauer die User Stories definiert werden können, desto länger kann der Sprint ausfallen.

 

Das Scrum-Team

Letztendlich ist die Erfahrung des Scrum-Teams ausschlaggebend für die Festlegung der Sprintlänge - diese darf unter keinen Umständen von den Stakeholdern vorgegeben werden. Je erfahrener ein Scrum-Team ist, desto länger kann der Sprint sein.

Wichtiger Bestandteil zur Steuerung des Projektes ist die Benennung und Besetzung der projektverantwortlichen Rollen: Projektmanager und Product Owner sowie der Scrum Master. Aus diesen Rollen bildet sich der Lenkungskreis, der dafür Sorge trägt, dass der kontinuierliche Spezifikationsprozess funktioniert und die jeweils an den höchsten priorisierten Anforderungen als User Stories festgelegt werden. Das Scrum-Team besteht immer aus einem (Teilzeit)-Scrum Master, einem Product Owner und zwischen drei (3) und neun (9) Developern.

Eine wesentliche Voraussetzung für die erfolgreiche Lieferung der Produkte aus dem Product Backlog ist ein erfahrenes Scrum-Team. Wir gehen dabei von einer Erfahrung in der agilen Projektarbeit von mindestens zwei (2) Jahre für alle Projektmitglieder aus.

Der Scrum Master ist mitunter verantwortlich im Rahmen der Sprint Retrospektive die Notwendigkeit für Schulungsmaßnahmen (Scrum Framework) festzustellen und entsprechende Maßnahmen zu treffen. Letztendlich ist das Development Team eigenständig verantwortlich für die Mitteilung notwendiger Maßnahmen im Rahmen der Sprint Retrospektive.

 

Das Projektende

Bei agilen Festpreisprojekten gilt das Projekt als beendet, wenn der Auftraggeber den erwarteten Nutzen durch die bereits erfolgten Lieferungen als erfüllt abnimmt. Eine Verweigerung der Abnahme trotz Erreichen der zuvor gemeinsam definierten DoD (Definition of Done) sollte ausgeschlossen werden.

Offene Aufgaben aus dem Backlog den beendeten Sprints werden wieder in den Product Backlog übertragen. Im anschließenden Sprint Review wird erneut geprüft, für welche User Stories Aufgaben in den Sprint Backlog übertragen werden. Der Product Owner entscheidet über die Priorisierung der User Stories/Epics, aber auch darüber, ob User Stories dem Product Backlog neu hinzugefügt oder herausgenommen werden.

 

Eine vorzeitige Beendigung eines Sprints

Sollte ein (oder auch mehrere) bereits geplante(r) Sprint(s) vor deren Start abgesagt werden, so fällt in der Regel eine Pauschale (z.B. 20%) für den geplanten bzw. ausgefallenen Umsatz an (Cancellation Fee). Dabei muss eine vertragliche Vorlaufzeit für den Change Request festgelegt werden (z.B. 4 Wochen).

 

Änderung/Neuaufstellung des Entwicklungsteams

Muss das Entwicklungsteam aufgrund neuer oder geänderter Anforderungen im Product Backlog neu aufgestellt oder angepasst werden (neue, ungeplante Anforderung wie z.B. Spezialwissen), so muss auch dies mit einer entsprechenden Vorlaufzeit bedacht werden. Tritt durch eine schlechte Planung des Backlog oder zu spät aufgesetzte Change Requests eine Minderauslastungen des Entwicklungsteams ein, so sollte dies dem Vertragspartner in Rechnung gestellt werden.

Certified Migration for the entry in AWS
Certified Cloud Migration for your ideal entry into the world of AWS
Cloud computing is now one of the set terms within the IT industry. The public cloud platforms of le […]

Checklist Cloud Migration
Checklist: Cloud migration – with these 7 expert tips, the leap to the cloud will succeed
How do I get my data and applications into the cloud? This is one of the most frequently asked quest […]

Mistakes Cloud Migration
“Mistakes to avoid in your cloud migration!” Interview with Tom Simon
Tom: We accompany our customers from the various stages of their cloud migration: from the initial c […]

Strategies Cloud Migration
Seven strategies you should know for your cloud migration
Many companies are currently discussing the migration of individual applications or an entire IT env […]

women-in-tech-jelena-frontend-developer-titelbild
Frage eine Frontend Entwicklerin – Women in Tech
In unserer PCG-übergreifenden Interviewreihe stellen wir spannende Cloud Jobs und die Personen dahin […]

202301_Cloud Migration_Schrift_1
Migration zu AWS: der große Guide
Wer über die Migration in die Cloud nachdenkt, kommt nicht umhin, sich einmal näher mit Amazon Web S […]

202209-Energie-sparen-Cloud
3 Gründe, warum die Public Cloud Ihre Energiekosten senken kann
In der Herausforderung, Kosten für Strom einzusparen, kann die Umstellung der eigenen IT Infrastrukt […]

Blogartikel Header Ressourcen
5 IT-Trends 2022 – Wie die Public Cloud aktuelle Herausforderungen im IT-Bereich löst
Ein Blick auf die IT-Trends 2022 zeigt: Mit der Migration in die Public Cloud können Unternehmen vie […]

20220317_Blogartikel_PublicCloud1x1_CloudJourney_Header
Wie sieht Ihre Public Cloud Journey aus?
Die Cloud Journey beschreibt Ihren individuellen Prozess in und durch die Public Cloud. Dabei gibt e […]

Optimierung mit Text
4 Handgriffe für die Kosten- und Performance-Optimierung Ihrer Cloud Umgebung
Die eigene Cloud Journey beginnt bei vielen Unternehmen mit der initialen Bewertung der potenziellen […]

Public Cloud 1x1 zum Thema Cloud Kosten
Was sind die typischen Cloud Kosten?
Faktisch zahlen Sie bei der Nutzung einer Public Cloud der großen Hyperscaler nur für drei Dinge: di […]

AWS Well Architected Framework mit Säule für Nachhaltigkeit
Die sechste Säule des AWS Well Architected Framework: Nachhaltigkeit
Das AWS Well Architected Framework hilft Kunden seit 2015 dabei, ihre bestehende AWS Cloud Umgebung […]

Fehler einer Cloud Migration
“Fehler, die Sie bei Ihrer Cloud Migration vermeiden sollten!” Interview mit Tom Simon
Tom: Wir begleiten unsere Kunden ab den verschiedensten Stadien bei ihrer Cloud Migration: von der e […]

Public Cloud 1x1 mit Dagmar Ziegler zum Thema Managed Service Provider
Managed Service Provider in der Cloud
Ein Managed Service Provider betreibt Ihre Cloud Umgebung. Das bedeutet, er leistet alle Dienstleist […]

Checkliste Cloud Migration: mit diesen Tipps gelingt die Migration in die Cloud
Checkliste: Cloud Migration – mit diesen 7 Experten-Tipps gelingt der Sprung in die Cloud
Wie kommen meine Daten und Anwendungen in die Cloud? Das ist heute eine der meist gestellten Fragen, […]

Innovations ON Public Cloud 1x1 AWS Well Architected Framework
AWS Well Architected Framework – kurz & knapp erklärt
Ein bekanntes Merkmal der Public Cloud von Amazon Web Services (AWS) sind die zahlreichen Möglichkei […]

Treiber für Managed Services
Gute Gründe & Treiber für den Betrieb Ihrer Cloud Umgebung mit Managed Services
Der erste Schritt in die Public Cloud ist geschafft und die eigene Cloud Umgebung entwickelt sich fo […]

Public Cloud 1x1 von Innovations ON erklärt Managed Services
Einführung in Managed Services
“Managed Services” – ein Begriff, den man mittlerweile auf fast jeder Website eines IT-Dienstleister […]

Einführung in Managed Services
Ein schneller Einstieg in Managed Services
Eine eigene Cloud-Umgebung zu betreiben, benötigt einiges an Ressourcen: neben der Hard- und Softwar […]

Cloud Migrations Strategien einfach erklärt von Innovations ON
Sieben Strategien, die Sie für Ihre Cloud Migration kennen sollten
Eine Migration von einzelnen Applikationen oder einer gesamten IT-Umgebung in die Public Cloud der f […]

PublicCloud1x1_AWSServices
Was sind AWS Services?
Amazon Web Services (AWS) ist mit mehr als 200 Services, die umfangreiche Funktionen bieten und in g […]

1_vom Rechenzentrum in die Cloud
Vom Rechenzentrum in die Public Cloud: Hier sind Ihre (Microsoft) Workloads ideal aufgehoben
Für den Betrieb Ihrer Microsoft Workloads stehen Ihnen eine Reihe an Möglichkeiten zur Verfügung: vo […]

PublicCloud1x1_EDVDienstleister
Vom EDV Dienstleister zum Public Cloud Partner
Wir alle kennen ihn und haben mit Sicherheit schon das eine oder andere für unsere IT-Umgebung mit i […]

2_Cloud Kosten Interview
Cloud Kosten auf den Zahn fühlen: Interview mit Simon Baumgärtner
Was ist bei der Evaluation einer möglichen Cloud-Strategie wichtiger als die dazugehörige Kostenbetr […]

PublicCloud1x1_PublicCloud
Was ist die Public Cloud?
Die Public Cloud hat sich in den letzten Jahren neben dem traditionellen Rechenzentrum und weiteren […]

3_Microsoft Workloads Public Cloud
Microsoft Workloads in der Public Cloud
Der Begriff Workload hat verschiedene Definitionen. So kann er in der direkten Übersetzung als „Arbe […]

PublicCloud1x1_AWSPartner
AWS Partner – wieso weshalb warum
Amazon Web Services (AWS) bietet seine virtuellen Public Cloud Ressourcen wie Speicherplatz, Infrast […]

4_Kostenoptimierung
Kostenoptimierung in der Cloud – Unternehmen zahlen oft zu viel
Ein Wechsel der IT-Infrastruktur in die Cloud wird oftmals mit Kosteneinsparungen verbunden. Eine ak […]

PublicCloud1x1_Hyperscaler
Die Hyperscaler im Public Cloud Umfeld
Unter „Hyperscaler“ im Public Cloud Bereich versteht man die internationalen Cloud-Anbieter wie Amaz […]

5_Anzahl AWS Accounts
Die richtige Anzahl an AWS Accounts für Ihre Cloud Umgebung
In diesem Beitrag tauchen wir tiefer in das Konzept der AWS-Plattform ein und sehen uns einige Best […]

6_Migration Einstieg AWS
Zertifizierte Cloud Migration für Ihren idealen Einstieg in die Welt von AWS
Cloud Computing ist mittlerweile einer der gesetzten Begriffe innerhalb der IT-Branche. Die Public C […]

Microsoft Workloads auf AWS und Gründe die für eine Migration sprechen
Microsoft Workloads auf AWS? Diese Vorteile überzeugen
Die Cloud Plattform von Amazon Web Services (AWS) ist im Vergleich zu ihren direkten Mitbewerbern wi […]

8_Dienstleister VS Systemhaus
Cloud Partner: Dienstleister oder Systemhaus?
Wer ist der passende Cloud Partner für Ihren Weg in die AWS Cloud? Spezialisierter Cloud Dienstleist […]

9_Kalkulation CloudKosten
Cloud Kosten richtig kalkulieren
Der Schritt in die Cloud ist eng mit der Frage nach den anfallenden Kosten einer Cloud Migration ver […]

10_ScrumAgiles Vorgehen
Agiles Vorgehen nach Scrum
Vielleicht haben Sie bereits von Scrum gehört und fragen sich, was genau es damit auf sich hat und […]

CloudMigration
Cloud Migration – Ihr erster Schritt in die Cloud Welt
Viele IT-ler sträuben sich, wenn sie den Begriff „Umzug in die Cloud“ hören, denn wie jeder weiß, is […]

Cloudvorbereitung
Bereiten Sie Ihr Team ideal auf die Cloud vor!
Die Cloud bietet vielen Unternehmen Vorteile, die sie mit eigenen lokalen Rechenzentren, Colocation […]

Cloud meets Alb-Donau
Rückblick: Cloud meets Alb-Donau 3.0
Süddeutschland und insbesondere die Region Alb-Donau haben eine starke, innovative und international […]

Scrum Agile Projekte
Agile Projekte nach Scrum Methodik mit Festpreisbindung
Schon lange ist bekannt, dass konventionelle Sourcing-Ansätze den agilen Projektlieferungen durch ko […]

ihre wahl Cloud Dienstleister
Die Wahl Ihres passenden Cloud Dienstleisters
Unternehmen, die erste Anwendungsmöglichkeiten der Cloud geprüft haben oder sie sogar schon einsetze […]

Treten Sie direkt mit dem Autor in Kontakt

Für Fragen stehe ich Ihnen jederzeit zur Verfügung!

Lutz Buchholz, Projektmanager Innovations ON GmbH
Lutz Buchholz
Cloud Engagement Manager
Anfrage senden