Category Archives: Projektmanagement

SUGK: Zusammenfassung Scrum User Group Karlsruhe – Scrum und Kanban

Posted on by
1

Das letzte Meeting der Scrum User Group Karlsruhe war wieder ein großer Erfolg. Ich habe ein Schnitzel bekommen und das Thema “Scrum und Kanban” lockte ca. 30 Interessenten an, die sich sehr aktiv vor und nach dem Vortrag austauschen konnten.

Scrum und Kanban

Der Vortrag von Lutz Ehrlich war sehr gut vorbereitet und sehr informativ. Da Jeff Sutherland anwesend war, wurde der Vortrag und die dazu passende Diskussion kurzerhand in Englisch gehalten. Nach dem Vortrag und Ende der Diskussion wurde ein Kanban-Spiel ausprobiert, das guten Anklang fand.

sugka-0910-1

sugka-0910-2

Am Tag nach dem Meeting habe ich  mich kurz mit Heiko unterhalten: Es muss unbedingt kommuniziert werden, dass der Vortrag von Lutz nicht die neue Messlatte für Vorträge wird – sonst gehen der SUGKA die Vortragenden aus ;-)

Agile schlägt Wasserfall

Aus der Diskussion um Kanban und wie schlecht planbare Aktivitäten via Kanban und WIP-Limits trotzdem noch beherrschbar bleiben wurde schnell eine Diskussion über Agile vs. Wasserfall. Laut Jeff: “Agile has proven to work much better than waterfall. IF waterfall does work, it costs twice as much as agile.” (kein wörtliches Zitat). Leider habe ich die Links auf die Dokumente vergessen.

Hat hier jemand besser aufgepasst als ich??

DIN-Norm für Scrum und Übersetzung der Scrum-Termini

Wie viele zertifizierten Scrum’ler mitbekommen, scheint es organisatorische Herausforderungen bei der Scrum Alliance zu geben. Ausgehend von dieser Diskussion ist ein “Normungs-Tisch” sehr schnell zur Auffassung gekommen, dass wir unbedingt eine DIN-Norm für Scrum benötigen. Zunächst muss  jedoch ein guter und belastbarer Plan aufgestellt werden, dann ist die Umsetzung sicherlich schnell erledigt ;-). Danke auch an Go Fragile für die vielen hilfreichen Tipps ;-)

Da diese Planung sicherlich Monate, wenn nicht Jahre benötigt wurde als ergänzender Vorschlag diskutiert, ob nicht zumindest mit der Übersetzung der Scrum-Terminini in Landessprachen begonnen werden könnte: Bayrisch, Schwäbisch, Badisch, Platt. Erste Übersetzungsversuche fanden bereits statt, das dazu nötige Bier wurde schnell und problemlos geliefert.

Hat jemand Interesse daran dieses Übersetzungsprojekt mit mir weiter zu treiben?

Verschwendung in der Softwareentwicklung

Posted on by
2

YAGNI! Das “You aren’t gonna need it!” aus dem eXtreme Programming hat schon immer zu vielen Diskussionen geführt.

Gerade in konservativen Unternehmen, die auf solide Softwareentwicklung setzen, werden Minimallösungen sehr kritisch betrachtet. Schnell wird in Wiederverwertbarkeit, Konfigurierbarkeit und sehr solide Lösungen investiert ohne genau das Endstadium zu kennen.

Ich sehe dies zunehmend kritischer.

image

Ich habe nichts gegen Qualität und gute Software. Ich habe allerdings etwas gegen Investitionen, die nie eine Rendite erwirtschaften.

In der Softwareentwicklung wird bei “Verschwendung” gerne auf die Implementierung von Features verwiesen, die (fast) nie benutzt werden. Zu selten werden jedoch auch die inneren Werte der Software kritisch hinterfragt. Häufig wir ausschließlich mit Beispielen argumentiert, in denen überhaupt keine Rücksicht auf die interne Struktur genommen wurde. Diese dienen dann als Begründung für umfangreiche Umbauarbeiten. Die Auswirkungen dieser Änderungen auf die Gesamtkosten wird dann häufig nicht mehr betrachtet.

Es ist doch meist so, dass ein Kunde für Features zahlt, die er beauftragt hat und dann nie nutzt. Für mögliche Verbesserungen an der internen Struktur der Software zahlt er typischerweise nicht, diese erwirtschaften eine Rendite, indem die Wartungskosten sinken. Leider ist dies zu häufig nicht der Fall.

Beispiel: “Wir mussten das konfigurierbar machen (1), da wir sonst bei jeder Änderung an der Darstellung der Seite drei weitere Dateien hätten anpassen (2) müssen!” ist eine typische Begründung von Entwicklern.

Meiner Meinung nach steckt hinter (1) oft der Spaß, etwas “solides” zu bauen. Hier ist der Ingenieur gefragt. “Wofür habe ich denn sonst studiert?”. Zudem kommt oft noch eine Brise Angst hinzu, sich bei einer einfachen Lösung später rechtfertigen zu müssen “(“Warum habt ihr nicht … ?”).

Bei (2) geht es darum etwas am Laufen zu halten. Ein pragmatischer Handwerker zimmert etwas zusammen. Die Aufgabe ist nicht sonderlich spannend und wir wissen alle, dass früher oder später etwas noch einmal angepasst werden muss. Leider ist dies auch oft die Quelle von Fehlern, die lange gesucht werden müssen – Fehler die entstehen, wenn man die “langweilige Handwerksarbeit” nicht sorgfältig durchführt.

Leider führt eben auch (1) oft zu hohen Folgekosten, beispielsweise wenn während einer Entwicklung etwas zu früh verallgemeinert wurde. Später werden weitere Aspekte hinzugefügt und die Annahmen für die Verallgemeinerung ändern sich. Das Konstrukt funktioniert nicht mehr, es muss angepasst und mit Balkonen versehen werden. Plötzlich wird aus einer soliden Ingenieursleistung eine immer weniger wartbare Ansammlung von Sonderfällen.

Code-Duplizierung doch  nicht böse?

Vor diesem Hintergrund sehe ich Code-Duplizierung – gerade bei bestimmten Teilen von Webseiten in Portalprojekten – nicht immer kritisch. Solange es handhabbar bleibt, kann man (sollte man?!) die Entscheidung, was als Verallgemeinerung extrahiert werden soll, hinausschieben. Zu einem späteren Zeitpunkt, wenn sich die Anforderungen in dem betroffenen Teil der Anwendung wirklich nicht mehr im großen Umfang ändern, kann schließlich eine Verallgemeinerung vorgenommen werden.

PM mit Scrum – Video vom #fucamp

Posted on by
Reply

Nach einigen Monaten ist das Video zum Vortrag “PM mit Scrum” online:

image

Zusammen mit Martin Fache habe ich spontan ein Vortrag gebastelt und in einer Session auf dem FuCamp in Furtwangen vorgestellt. Leider ist der Ton nicht sonderlich gelungen – und man merkt, dass ich nicht besonders viel Erfahrungen mit spontanen Vorträgen habe. Insgesamt scheint die Session aber einigen etwas gebracht zu haben, vgl. Kommentare hier.

Update:
Hier das Video in einem schönen Player:

Sourcing: Ergebnisse einer Umfrage bei GULP

Posted on by
Reply

In der IT-Industrie spielen Nearshore-Outsourcing und Offshore-Outsourcing eine zunehmend wichtige Rolle, da durch die günstigeren Gehaltsstrukturen der Lieferantenländer oft das Potential (!!!) für Kostensenkungen gegeben ist.

Es handelt sich jedoch nicht um eine automatische Reduktion der Gesamtkosten, wenn die Lohnkosten bei einem Lieferanten beispielsweise 50% niedriger ausfallen als die internen Kosten und eine Fokussierung auf den Kostenaspekt greift in den meisten Fällen auch zu kurz. Trotzdem ist Nearshoring und Offshoring ein heißes Thema und viele Unternehmen wollen ihre Aktivitäten in diesem Bereich weiter intensivieren.

Mit diesem Themenkomplex hat sich auch eine Umfrage bei GULP beschäftigt, deren Ergebnisse jetzt verfügbar sind.

Einerseits lässt sich eine gewisse Ernüchterung erkennen, so spricht ein SAP-Experte davon, dass aktuell 120 IT-Experten in Bratsilava für Aufgaben eingesetzt werden, die auch 30-40 gut ausgebildete IT-Experte vor Ort erledigen könnten. In solchen Szenarien relativiert sich der Lohnkostenvorteil natürlich sehr schnell und es bleibt eine größere Komplexität – dies es natürlich zu managen gilt.

Andererseits ist Nearshoring/Offshoring Realität und tägliches Geschäft in vielen Unternehmen, so sind 59% der Befragten der Meinung, dass sich der Trend zum Off- und Nearshoring durchgesetzt hat. Bei 56% wird Nearshoring/Offshoring aktiv eingesetzt und 82% stimmen zu, dass der Kostendruck dazu führt, dass dieser Ansatz vermehrt eingesetzt werden wird. Es sind jedoch 62% der Meinung, dass ein Nearshoing-Anbieter nicht das gleiche Leistungsspektrum abdecken kann wie ein lokaler Anbieter, die oft viel Know-how in Bereichen aufbauen, die unternehmens- oder anwendungsspezifisch sind. Anbieter von Nearshoring und Offshoring konzentrieren sich hauptsächlich auf Know-how im Bereich Technologie und Standardthemen.

image

Aus meiner Sicht wird es spannend, wenn es gelingt Nearshoring-Kapazität im Rahmen von agilen Prozessen zu nutzen und mit den existierenden Strukturen zu verbinden.

Im Prinzip und Wirklichkeit

Posted on by
1

Ja, wer kennt diese Situation nicht: Im Prinzip haben wir alles für ein Projekt zusammen und es muss nur noch los gehen. Alle Schätzungen der sogenannten Experten weisen auf ein überschaubares Unterfangen hin. Gut, das Projekt wird gestartet und muss sich der Wirklichkeit stellen.

Was einem IT Projekt dabei so passieren kann, schreibt Siegried Hauer in ihrer Geschichte “Wie weiss ein Unternehmen, was es eigentlich weiss???”. Unterhaltsam … und aus der Realität geschrieben ;-)

Auf ihr lesenswertes Blog “Projektgeschichten” bin ich via einem Artikel von Andreas gestoßen. Ach, immer die gleichen Verdächtigen ;-)

KADEV09: Entwicklertag: Zusammenfassung Agile Day

Posted on by
1

Nach dem VKSI Day und dem Conference Day war der Agile Day der dritte Tag mit interessanten Veranstaltungen.

Anmerkung: Jetzt ist es schon August und es sind immer noch keine Fotos online ;-(

Getting done your non-functional Requirements


Thomas Starz von IBM stellte in seinem Vortrag (Folien) vor, wie sich Scrum, XP und GTD kombinieren lassen.
Das Problem, dass ständig irgendwas dazwischen kommt, kennt wohl jeder. So kommt es schnell dazu, dass obwohl das Team viel arbeitet keine sichtbaren Ergebnisse erzeugt werden.
Kurze Diskussionen gab es um die Definition von “Nicht-funktionalen Anforderungen” (NFA), Thomas bezeichnete abhängige Anforderungen als NFAs:

  • neue Entwicklungsumgebung
  • neue Server
  • Performance
  • Usability

Nicht jeder im Publikum wollte diese Definition teilen.

Nach Meinung von Thomas legt der Product Owner (PO) seinen Fokus auf die Funktionen, dem sollte als Gegenüber ein Architekt auf die NFAs achten.

Für die Planung im Rahmen von Scrum gab es folgende Tipps:

  • Puffer für unvorhergesehene Arbeiten
  • NFA als Story im Backlog
  • PO (Funktion) soll sich intensiv abstimmen mit Architekt (NFA)
  • alles erfassen, was erledigt werden muss -> wirklich ALLES ins Backlog
  • Backlog ist Grundlage für Entscheidung

Hierbei sollte die Erfahrung berücksichtigt werden, dass viele POs zu häufig NFA nicht ausreichend berücksichtigen. Zudem wird man früher oder später wohl immer mit einem Verweis auf das Vorgehen nach Wasserfall bekommen: “Wir hätten nur die Spezifikation (besser) schreiben müssen!”

Scrum bei der BASF IT Services

Irene Kuhn von der BASI IT Services und Fahd Al-Fatish von andrena objects stellten ein Einführungsprojekt von Scrum bei der BASF IT vor.

Folien

Ziel des Projektes war der Relaunch des Internetauftritts (www.basf.com) von BASF.

Für dieses Projekt wurde ein erfahrenes Kernteam von sechs Entwickler um sechs weitere Mitarbeiter aufgestockt. Das Kernteam hatte in dem Bereich bereits viel Erfahrung mit Intra- und Internetauftritten (Portale, CMS, Redaktionssysteme)

Neben dem Relaunch von basf.com war ein weiteres Ziel die Vorgehensweise nach Scrum zu etablieren und Know-how-Träger als Scrum Master auszubilden.

Herausforderungen und Vorbehalte

Wie in Großunternehmen nicht unüblich stoßen Veränderungen schnell auf Vorbehalte. Gerade die Transparenz, die mit Scrum möglich ist, wird nicht immer nur positiv gesehen. Zudem wird bei der Einführung von Scrum auch oft kritisiert, dass die Methode zu viele Meetings mit sich bringt. Angesprochen wurde auch die Herausforderung, die sich daraus ergibt, dass trotzdem noch das klassische Reporting befriedigt werden muss. Weiterer Punkt war die Definition der Rolle des Projektleiters. Im konkreten Fall wurde der PL zum Scrum Master ernannt.

Vorbereitung

Um das Projekt richtig aufzusetzen und das Team auf Scrum vorzubereiten wurde in eine gute Vorbereitung investiert. Zuerst wurde mittels Einzelgespräche und Teambefragung der Ist-Zustand analysiert (Retrospektive). Es wurde geklärt, welche Probleme existieren und wo die Stärken des Teams liegen. Im nächsten Schritt wurde über Ziele gesprochen und diskutiert, was beibehalten werden kann und was sich ändern soll.

Durch diese Vorbereitungsphase war klar, auf was während der Einführungsphase geachtet werden musste.

Einführungsphase

Um das Team zu stärken (Teamfindung) und Vertrauen in Scrum zu schaffen wurden vier Sprints als “Probezeit” angesetzt. In diesen vier Sprints wurden die Mechanismen und Rollen eingeführt sowie ein erstes Product Backlog (PBL) geschrieben. Durch die Abarbeitung des Stories aus dem PBL war es möglich, eine Team-Velocity zu ermitteln.

Planung

Die Vorplanung für die Sprints erfolgte in mehreren Schritten: Zunächst eine Vorausplanung in einer kleinen Gruppe (Anmerkung: IMHO wichtige Methode, nicht bei jedem Estimation muss 90% des Teams anwesend sein!), gefolgt durch das Planungsmeeting mit dem gesamten Team am Folgetag.

Für die Vorausplanung wurde die Sprint-Kapazität abnehmend festgelegt: 1. Sprint 100%, 2. Sprint 80%, 3. Sprint: 75%. Durch die abnehmende Kapazität wurde der Unsicherheit Rechnung getragen.

Das PBL wurde durch ein “Product Owner-Team” bestehend aus PO & Chief Architect & Technical Architect geschrieben. Damit wurden sichergestellt, dass sowohl Funktionen als auch NFAs berücksichtigt werden. Die Schätzung des Aufwands erfolgte in Ideal-Tagen, zur Ermittlung kam die Planning-Poker Methode zum Einsatz.

Herausforderungen und Zusammenfassung

Im Rahmen des Projektes war es nötig eine Brücke von Scrum zum klassisches Reporting zu etablieren. Der klassische Projektleiter war jedoch eher als übergeordneten Stakeholder eingebunden. Hierbei spielt es eine Rolle, dass Projektleiter häufig zu viele Projekte gleichzeitig betreuen, deshalb beschränkte sich das “Management” hauptsächlich auf die Review-Meetings.

Sehr gut funktioniert hat das Team-Building und sehr effektiv war auch, dass der ProductOwner aus dem Team (!!) verantwortlich für das Management des PBLs war.

Auf die Einführung von komplexen Softwarelösungen wurde bewusst verzichtet. Als Tools kamen lediglich Excel und ein Task-Board zu Einsatz.

Durch die Restschätzung des PBL und Abgleich mit der Restschätzung Budget wurde eine sehr  gute Transparenz erreicht.

Fazit: Das Projekt war ein Erfolg und Scrum wird bei BASF IT Services immer häufiger eingesetzt.

Making Scrum stick – Transforming the Enterprise

Christoph Mathis (ScrumCenter) beschäftigte sich in seinem Vortrag (Folien) damit, wie Scrum nachhaltig im Unternehmen verankert werden kann.

Jeder von uns kennt es – unter Druck fallen wir schnell zurück in alte Verhaltensweisen und vergessen das neue. Hierbei spielt es oft auch eine Rolle, dass konservative Kollegen nichts mit den neuen Ansätzen anfangen können und dagegen opponieren. Auch Manager, die zu viel Transparenz fürchten, sorgen oft für einen gewissen Druck, wieder zurück zur alten Vorgehensweise zu wechseln. Ein kritischer Moment ist dann gekommen, wenn der Sponsor von Scrum die Firma verlässt.

Wie lassen sich solche Rückschläge vermeiden?

Christoph schlägt als erfolgsversprechendes Herangehen vor, dass Scrum vollständig praktiziert werden soll und damit letztendlich Scrum in der DNA der Firma verankert wird.

Er bezieht sich auf grundlegene Praktikern und Ideen von Scrum:

  • ask the team
  • inspect & adapt
  • deliver every 30 days
  • treat people as adults

Ergänzt werden sollen diese durch den konsequenten Einsatz von Engineering Praktiken.

Immer wieder soll die Frage gestellt werden, was getan werden muss, damit Scrum maximale Produktivität bringt?

Sein Vorschlag ist der Einsatz eines Verbesserungs-Backlog. Dieses wird in der Diskussion in Gruppen zu 2-3 Teilnehmern erstellt. Zentrale Fragestellung hierbei: Was braucht es, damit unsere Scrum-Praxis wirklich exzellent wird?

Um Scrum in der DNA des Unternehmens verankern zu können, muss die Kultur des Unternehmen berücksichtigt werden. Beispiele für die Kultur in einem Unternehmen sind:

Geschichten (worüber geredet wird)

  • welche Geschichten im Unternehmen (Held, Armleuchter, Erfolge, Misserfolge)
  • welche Geschichten sollen erzählt werden?
  • Was soll nächstes Jahr über das Projekt und das Team erzählt werden?

Symbole

  • wer hat welches Büro und welchen Dienstwagen?
  • wie ist die Kleiderordnung?
  • wer ist “Anzugträger”?

Organisationsstrukturen

  • wie ist die Organisation?
  • formal / informell

Kontrolle

  • wer fördert wen?
  • was bedeutet es Scrum Master zu sein für die Karriere?

Rituale & Routine

  • was für Veranstaltungen werden gemacht?
  • wie tut man Dinge?
  • wie initiiert man einen Vorschlag bei seinem Chef?
  • “das macht man bei uns so!” – nicht rational

Macht (Beeinflussung)

  • wer kann welche Vorgaben machen?
  • Methodenabteilung – hat diese Macht?
  • wer hört auf wen?

Durch sorgfältige Analyse können die einflussreichen Personen identifiziert und überzeugt werden. Nur mit der Unterstützung der Schlüsselpersonen, kann es gelingen Scrum dauerhaft im Unternehmen zu verankern.

Wichtig ist es, dass nach Identifikation des bzw. der Sponsoren Hilfe von außen geholt wird.

Hilfe von außen holen:

  • Hilfe von außen
  • Leuchtfeuer
  • Professionalisierung (Kompetenzzentrum)
  • Fördern
  • Diversifizieren
  • Etablieren
  • Konsolidieren
  • Integrieren

1) Scrum gut machen: Verbesserungs-Backlog
2) Scrum in Unternehmens-DNA einbauen: Transition-Backlog

Insgesamt wurden einige wichtige Hinweise gegeben, wie eine Einführung und Verankerung von Scrum im Unternehmen gelingen kann. Aus den Hinweis, dass es wichtig ist, Hilfe von außen zu holen durfte natürlich nicht verzichtet werden ;-)

Fazit Agile Day

Jetzt hat es doch wirklich mehr als einen Monat gedauert bis ich meine Notizen endlich überarbeitet habe. Nunja, zumindest bin ich mit der Zusammenfassung fertig bevor Fotos erscheinen ;-)

Insgesamt war der Agile Day sehr interessant – nicht nur wegen den Vorträgen! Die sehr spannende Podiumsdiskussion zum Thema “Clash of Cultures – Agilität und hergebrachte Arbeitsmodelle – Beobachtungen aus USA, Europa, Naher Osten und Asien – Unterschiede und Gemeinsamkeiten.” bekomme ich jetzt nicht mehr zusammen, dazu sind meine Notizen einfach zu wirr ;-)

Nun, es scheint ich tauge nicht zum Konferenz-Blogger. Na, wieder einmal etwas gelernt ;-)

Cargo Cult & Scrum & was weiss ich

Posted on by
2

imageVor einem Jahr habe ich schon kurz über kultische Handlungen und verblendete Missionare aus der “agilen Subkultur” ;-) geschrieben und mich kurzerhand zum XPAPM (eXtreme Pragmatic Project Manager) ernannt.

Das Thema kommt jetzt gerade wieder hoch (Sommerloch?), so versteht Boris irgendwie nicht, dass für manche Betrachter Scrum etwas kultisches haben kann.

Ralf Eisend schreibt was nettes über “Cargo Cult” und verweist auf die Glaubenskämpfe im Umfeld von Scrum und anderen agilen Methoden. Naja, fairerweise will ich nicht unterschlage, dass er wohl auf Projektmanagement im Allgemeinen abzielt. Da aber gerade Scrum so hipp ist …

Dabei könnte alles doch so einfach sein: Inspect & Adapt. Anschauen, verstehen, anpassen. Dazu noch “Individuals and interactions over processes and tools” und es sollte passen.

Dabei bitte auch kritische Diskussionen aushalten und zugeben, wenn man etwas nicht weiß. Nicht alles aus den ersten Scrum Büchern kann man direkt in der Unternehmensrealität einsetzen ohne auch Schaden anzurichten.

Uuuuund gaaaanz wichtig: Nicht alles dreht sich gleich im Scrum-Takt wenn man das will. Falls es überhaupt möglich sein sollte eine Organisation entsprechend umzubauen ist dies ein harter Weg. Ein Weg, der nicht für alle Beteiligten Gutes bringt und auch zu Verlierern führt. Hier ist wirklich Augenmaß gefragt!

Scrum ist doch gut …

Ich bin von der grundlegenden Idee und den Werten in Scrum überzeugt. Ich sehe diese allerdings stets im Kontext. Eine Unternehmensrealität kann auch dazu führen, dass bestimmte Dinge (Praktiken) nicht funktionieren können und das Leben von (positiven) Werten zu Problemen führt.

Ist das ein Problem von Scrum? Nein. Das Problem ist, dass teilweise die Realität (der Kontext) ignoriert wird, in dem die Praktiken und Werte Anwendung finden.

Die Herausforderung besteht dann darin, die Rahmenbedingungen langsam anzupassen oder erkennen zu müssen, dass eben nur eine suboptimale Implementierung von Scrum möglich ist.

Viele freiberuflichen Berater kennen diese langen und teilweise sehr frustrierenden Kampf nicht (mehr). Freiberufliche Experten werden eingesetzt, wenn grundsätzliche Entscheidungen bereits getroffen wurden. Meist auf Basis der Erkenntnis, dass es überhaupt ein Problem gibt.

Naja, deshalb haben es die großen Scrum-Evangelisten einfacher. Von denen wird erwartet, dass sie die “große Welle” mitbringen.  Es folgt leider häufig eine Zeit voll Aktionen und Reorganisation von Prozessen. Der freie Berater als Held und Evangelist. “Ich sage euch was ihr machen müsst, damit es euch besser geht!” ist doch häufig das Muster nach dem agiert wird.

Aber auch Berater aus dem Scrum-Umfeld  sind eben nicht davor gefeit auf einem Auge blind zu sein. Dann beginnt lokale Optimierung (“ändere das was Du kannst”), was sofort Widerstand an anderer Stelle hervorrufen kann. Bevor dies aber richtig deutlich wird, ist der Berater schon wieder auf einem anderen Gig…

Ist ja auch gut so. Oder so …

KADEV09: Entwicklertag: Juristisch Aktuelles vom Software Engineering – Projektmanagement-Recht

Posted on by

Von offenen Quellen und Wasserfällen – juristisch Aktuelles vom Software Engineering

RA Prof. Dr. Rupert Vogel

PDF Dokument
Ein sehr interessanter und unterhaltsamer Vortrag über rechtliche Aspekte des Urheberrechts und des IT-Projektmanagement wurde von RA Prof. Dr. Rupert Vogel gehalten. Nicht alles habe ich im Detail verstanden, aber dies ist schließlich auch die Aufgabe eines Juristen ;-)

Teil2: Projektmanagement-Recht

Leistungsbeschreibung

Eine wichtige Fragestellung in der Praxis ist: Wer muss definieren, was die Software tun muss? Grundsätzlich muss dies der Kunde/Auftraggeber tun, es besteht jedoch Beratungspflicht des Auftragnehmers. Hier bei ist das Wissensgefälle zwischen Kunde und Softwarehaus maßgeblich.

Hinsichtlich Qualität der zu erbringenden Leistung gilt, dass (falls nichts anderes vereinbart wurde), eine ist mittlere Art & Qualität (Stand der Technik) zu erbringen ist. Es gibt drei grundlegende Qualitätsstufen:

  • gering: Regeln der Technik
  • mittel: Stand der Technik
  • sehr hoch: Stand von Wissenschaft und Technik

TIPP: Verfahrenstandards konkretisiert undVertragsbedingungen prüfen hinsichtlich geforderter Qualitätsstandards

Beweis und Dokumentation

Es wurde hervorgehoben, dass die Dokumentation eine der Hauptpflichten des Softwareherstellers ist. Ein Softwarehaus hat bis zur Abnahme die Beweislast, dass die gelieferte Software dem vereinbarten Qualitätsstandard entspricht. Falls es zu Verzögerungen kommt, sollte man vor Behinderungsanzeigen nicht zurückschrecken: Hier gilt es eine Aktenlage zu schaffen! Gerade bei kritischen Projekten ist es wichtig, eine Claim-Liste zu führen. Bei Verhandlungen im späteren Projektverlauf kann der Projektleiter dann “seinen Stapel” mitbringen. Viele große Auftragnehmer haben eigene Claim-Manager, deren Hauptaufgabe es ist etwaige Mängel zu finden. Damit soll der Preis gedrückt werden.

TIPP: Stärkerer Position durch Protokollierung von Besprechungen, Redaktion von Verträgen, durchgängige Dokumentation der Softwareerstellung und des Projektverlaufs. Etwaige Beweismittel im Prozess (z.B. Mails) frühzeitig und konsequent sammeln.

Abnahme

Eine Abnahme erfolgt nur bei einer Individualentwicklung, markiert rechtlich den Beginn der Gewährleistung und führt zur Zahlungspflicht des Kunden.Laut BGH liegt eine stillschweigende Abnahme nach 6 Monate produktiver Nutzung vor, jedoch nur wenn keine Mängelrügen erhoben wurden.

TIPP: Teilabnahmen anstreben, die Testmodalitäten frühzeitig klären (Vorschlag: Teil Angebot) und hierbeidie Fehlerklassen definieren.

Gewährleistung und Haftung

Ein Softwarehaus muss im Rahmen der Gewährleistung etwaige Mängel in seiner Sotfwarebeseitigen. Ohne individuelle Regelung gilt eine Gewährleistungsfrist von zwei Jahren nach Abnahme. Ein Softwarehaus muss für Schäden haften, ohne individuelle Regelung ist die Haftung unbeschränkt. Produkthaftung und Haftung für Körperschäden können nicht ausgeschlossen werden.

TIPP: Ein Hersteller/Dienstleister sollte die Frist verkürzen auf ein Jahr (per AGB) bzw. wenn möglich noch kürzer im Rahmen individueller Absprachen regeln. Es ist sinnvoll individuelle Haftungsbeschränkung/Ausschluss  im Rahmen eines Individualvertrags festzulegen. Haftungsbegrenzung in AGBs sind kaum wirksam, deshalb muss dies in individuellen Verträgen geschehen.

SW-Hinterlegung

Idee: Die Hinterlegung von Software soll im Falle der Insolvenz des Auftragnehmers den Schaden für den Auftraggeber begrenzen.Das Probleme für Kunden in der Praxis ist meist, dass sie die Vollständigkeit der Sourcen/Artefake nicht einschätzen können. Zudem ist die Insolvenzfestigkeit nicht geklärt. Probleme für SWH ergeben sich aus der Regelung des Herausgabegrundes und -verfahren.

TIPP: Genaue Regelungen, indivduelle Vertragsgestaltung

Fazit

Insgesamt ein sehr spannendender und lehrreicher Vortrag. Viele der angesprochenen Aspekte werden im Projektalltag häufig nicht ausreichend bedacht.

Wer mit agilen Methoden und den damit verbundenen Wertvorstellungen arbeitet, muss jedoch an der einen oder anderen Stelle schlucken. “So” möchte man nicht arbeiten, wird sich der eine oder andere wohl gedacht haben….