ArmerKater.de - Agiles Projektmanagement, Agile Nearshoring, Scrum » Scrum

Java Forum Stuttgart 2010 – Retro

Felix — Fri, 02 Jul 2010 05:15:26 +0000

Das Java Forum Stuttgart 2010 war auch dieses Mal eine sehr interessante Veranstaltung. Nicht nur wegen den Vorträgen sondern vor allem auch wegen den vielen Diskussionen dazwischen. Mittlerweile sind es jedoch so viele Teilnehmer (~1200), dass man sich nicht mehr automatisch über den Weg läuft.

Herzlichen bedanken möchte ich mich bei den Teilnehmern der BOF-Session “SCRUM – Himmel oder Hölle (aus Entwicklersicht)?”! Die Diskussionen waren spannend und ich glaube, dass jeder Teilnehmer neue Ideen und Eindrücke mitgenommen hat.

BTW, ein Bild unserer BOF-Session hat es auf die “Titelseite” geschafft ;-)

Agile Offshore – Can you hear me now?

Felix — Fri, 25 Jun 2010 12:15:26 +0000

“Can you hear me now"?” ist ein sehr gutes Webinar von Mark Rickmeier/ThoughtWorks, in dem die Schwierigkeiten von Projekten diskutiert werden, in denen Projektmitarbeiter weltweit verteilt sind und bei denen agile Methoden der Softwareentwicklung eingesetzt werden:

http://securerespond.com/thoughtworks/offshorewebinar/

Ansehen lohnt sich auf jeden Fall!

Zunächst geht er auf die grundlegenden Herausforderungen bei verteilten Projekten ein: Kommunikation, Beziehungen, Vertrauen. Um diese Herausforderungen meistern zu können, müssen entsprechende organisatorische Maßnahmen ergriffen werden. Ich möchte hier jedoch einen kommentierten Auszug aus der Liste der empfohlenen Tools geben, die helfen verteilte Projekte erfolgreich durchführen zu können.

Communication Tools

Instant Messaging (IM)

IM Tools dienen zum schnellen (synchronen) Austausch von Informationen. Man sieht, wann jemand verfügbar ist und schnelle – oft informelle – Chats sind möglich. Sehr gut geeignet auch als Fallback bei Telefonkonferenzen. Ausgesprochene Empfehlung: Camp Fire.

Anmerkung: Ich persönlich nutze gerne Google Talk, da hier keine Installation nötig ist, weil ein einfaches Web-Interface existiert. Zudem ist ein GMail-Account weit verbreitet.

Screen-Sharing

Werkzeuge für Screen-Sharing werden vor allem bei Projektmeetings eingesetzt, um die gleichen Dokumente zu sehen, darüber zu diskutieren und direkt gemeinsamt Änderungen daran vorzunehmen. Desweitere interessant für Reviews und beim Pairing über die Distanz. Ausgesprochene Empfehlung: YuuGuu.

Anmerkung: Wir machen seit Jahren sehr gute Erfahrungen mit dem Werkzeug eines Karlsruher Herstellers: “Netviewer”. So gut wie gibt es Probleme mit Netwerkrestriktionen (Firewall).

Voice over IP / VOIP

Wichtigstes Tool bei internationalen Projekten, da es sehr einfach die (nahezu) kostenlose Kommunikation zwischen den Projektbeteiligten erlaubt. Ausgesprochene Empfehlung: Skype

Anmerkung: Teilweise wird Skype bewusst ersetzt durch eine Lösung, in dem die VoIP nur über unternehmensinterne Infrastruktur geleitet wird und offene Protokolle zum Einsatz kommen.

Wiki & Collaboration

Informationen festhalten und austauschen. Ausgesprochene Empfehlung: MediaWiki & Confluence

Anmerkung: Sehr gute Erfahrungen habe ich mit Confluence gemacht. Vor allem wenn Jira als Werkzeug für Issue-Tracking, bieten sich sehr interessante Integrationsmöglichkeiten. Ein Dash-Board für ein Projekt oder eine Team-Seite ist damit schnell erstellt – inkl. dynamischer Daten (Issues, Stories) aus Jira.

Issue/Task Tracking

Um Aufgaben, Fehler und Risiken verwalten und allen Teammitgliedern zugänglich zu machen wird ein Issue/Task Tracker benötigt. Ausgesprochene Empfehlung: Mingel, Jira, BaseCamp.

Anmerkung: Ich habe sehr gute Erfahrungen mit Jira gemacht. Hierbei spielt gerade die Nutzung von zusätzlichen Issue-Attributen und Filtern eine wichtige Rolle, um z.B. Team-Backlogs zu erstellen, die sich aus mehreren Projekten zusammensetzen (Multi-Projekt-Multi-Team). Hilft, v.a. wenn die Ergebnisse dann in Excel exportiert und ausgewertet/aufbereitet werden. Greenhopper (Jira Plugin für Scrum) scheint aktuell noch auf einzelne Jira-Projekte beschränkt zu sein.

Zusammenfassung

Meiner Meinung nach sind die genannten Werkzeuge sehr wichtig, um verteilten Projekten sinnvoll koordinieren/durchführen zu können. Zusätzlich muss auch die gesamte Entwicklungsumgebung so aufgestellt sein, dass verteiltes Arbeiten möglich ist: Continuous Integration, Testabdeckungen, Standardisierung, direkt verfügbares Repository, Werkzeuge zur AUswertung von Code-Qualität – aber dies ist Inhalt eines eigenen Artikels.

Aufwand, nicht Komplexität

Felix — Fri, 25 Jun 2010 05:35:59 +0000

Wohltuend. Jahrelang an “Lehrbuch” CSMs aufgerieben. Immer wieder die gleichen Diskussionen. Nein liebe CSMs, es geht beim Schätzergebnis (Story Points) nicht um Komplexität. Diese spielt natürlich eine wichtige Rolle – aber es geht im Ergebnis immer um Aufwand und Kosten.

(Oft habe ich mich gefragt, wer den CSMs diesen Unsinn erzählt hat… )

Wahnsinn, wie innovativ ich schon vor Jahren war ;-) – damals mit einem Kollegen (Wolfgang for president!) ein Excel-Spielzeug ähnlich wie es Jeff Sutherland jetzt promotet erstellt und dann Aussagen wie “It’s Effort, Not Complexity” von Mike Cohn.

Wirklich befriedigend, diese Bestätigung zu bekommen. Schade nur, dass wir gerade zurechtgestutzt werden, nachdem wir die Probleme transparent gemacht haben. Ist die Gegenreaktion der Linie, vgl. auch “Die dunkle Seite von Scrum”.

Termine: Scrum in und um Karlsruhe

Felix — Wed, 26 May 2010 04:23:32 +0000

In den nächsten Tagen gibt es in und um Karlsruhe zwei Termin für alle, die an Scrum interessiert sind. Ende Juni gibt es den Entwicklertag und Anfang Juli in Stuttgart das Java-Forum. Bei diesem Angebot sollte für jeden etwas etwas dabei sein.

2. Juni 2010: Treffen der Scrum User Group Karlsruhe

2.06.2010, 20-23 Uhr

Ort: Großer Kurfürst, Sophienstraße 80, 76135 Karlsruhe

Thema dieses Mal: Agile Simulation.

Wir werden eine kleine Simulation (der ein oder andere würde auch Spiel sagen) durchführen, die sehr schön einige Agile Grundprinzipien erfahrbar macht.

Mehr Informationen und Anmeldungen via XING Event.

7. Juni 2010: 5. Deutschsprachiges Scrum Meeting

Bei SAP in Walldorf findet am 7.6. das 5. deutschsprachige Scrum Meeting statt.

10 – 17h Open Space

Ort: bei der SAP AG, Walldorf

Die Teilnahme ist frei, das Event wird von SAP gesponsert.

Mehr Infos dazu findet ihr hier.

Anscheinend gehen die Plätze aus, deshalb wurde eine Warteliste erstellt – auf der jedoch bisher nur ein Eintrag zu finden ist.

SLM: Professional Scrum Development – Interview mit Ken Schwaber

Felix — Sat, 24 Apr 2010 10:55:40 +0000

Video in dem Ken Schwaber (einer der Erfinder von Scrum) und Sam Guckenheimer (Produktmanager bei Microsoft für Visual Studio) den "Professional Scrum Developer (PSD)" diskutieren.

Quelle: Channel9 MSDN

Ken erläutert die Motivation hinter PSD, Sam vermarktet die Werkzeugkette von Microsoft. Wenn man sich nicht dadurch stören lässt, dann sehr sehenswert.

Im Juni wird Ken Schwaber übrigends in Karlsruhe sein: Er hält die Keynote für den Agile Day beim diesjährigen Entwicklertag.

Treffen der Scrum User Group Karlsruhe 7. April

Felix — Tue, 06 Apr 2010 19:28:23 +0000

Morgen (Mittwoch, 7. April) trifft sich die Scrum User Group Karlsruhe wieder einmal im Restaurant Großer Kurfürst (Sophienstraße 80, 76135 Karlsruhe). Wie immer beginnt der “offizielle Teil” um ca. 20:00 Uhr, erste Teilnehmer dürften ab ca. 19:30 Uhr fleißig Schnitzel bestellen und über Scrum reden.

Der Termin – obwohl schon länger bekannt – ist wohl etwas in Vergessenheit geraten, erst Heute wurde der entsprechende Xing-Termin angelegt wo man sich auch schön registrieren kann. Wer will kann aber auch einfach vorbeischauen.

Das Thema diesmal: “Scrum in unseren Unternehmen”.

Die dunkle Seite von Scrum

Felix — Sat, 20 Mar 2010 10:57:18 +0000

Ich glaube, dass Scrum als moderner iterativ-inkrementeller Softwareentwicklungsansatz der auf Werten beruht ein großes Potential für langfristige Produktivitätssteigerungen besitzt.

Aber “reines” Scrum funktioniert nicht überall. Und “reines” Scrum hat – wie andere “reine Lehren” auch – viele “dunkle” Seiten.

Selbst Evangelisten wie Ken Schwaber gehen auf Probleme bei Einführung von Scrum in Unternehmen ein. Einige der Punkte aus “The Enterprise and Scrum” von Ken möchte ich aus einer eher skeptischen Perspektive kommentieren.

Aus Part I, “Adopting Scrum”:

Staff turnover will occur

Ja, manche Personen möchten nicht mehr Verantwortung und mehr Freiheit. Manche Angestellten arbeiten, um Geld zu verdienen – nicht weil es sich um ihre Berufung handelt. Zugrunde liegt ein Vertragsverhältnis und ein Vertrauensverhältnis. Die Organisation möchte dies nun einseitig ändern. Widerstand wird die Folge sein, Kosten entstehen, Veränderung verlangsamt sich.

Conflict will occur

Veränderungen führen zu Konflikten. Sind alle darauf vorbereitet mit Konflikten richtig umzugehen? Hat die Organisation Antworten auf die Fragen die in den Gesprächen gestellt werden? Hat die Organisation die Kraft die Konflikte zu lösen? Meine Erfahrungen hier sind ernüchternd. Mir ist keine ältere Organisation bekannt, die gut mit Konflikten umgehen kann. Unternehmenspolitik spielt hierbei eine wichtige Rolle. Möchte man dies überwinden, so kostet dies Geld und Zeit. Oft müssen auch Personen im mittleren und höheren Management ausgetauscht werden.

Product management’s job will change and will be harder

Klar, Scrum verschiebt die wirklich komplexen Entscheidungen dorthin, wo sie hingehören: Zum Management. Die wichtigsten Fragen sind: WAS will ich tun – und vor allem was will ich NICHT tun?

Dafür, dass diese Fragestellungen von zentraler Bedeutung sind, wird die Rolle des PO meiner Meinung nach zu wenig beachtet. Der gestiegenen Verantwortung steht im Allgemeinen leider keine gestiegene Entlohnung gegenüber. Im Grunde ein Verlustgeschäft für die betroffenen Manager – zumindest wenn man nur die finanziellen Aspekte betrachtet und eine mögliche gestiegene Motivation durch schnellere Ergebnisse vernachlässigt.

Meiner Erfahrung nach ist es aber auch häufig so, dass aus verwaltenden Produktmanager einfach verwaltende ProductOwner gemacht werden. Zu häufig ist der PO eben nicht er “Gold Owner” und damit geht viel Einflussmöglichkeit dieser Rolle verloren.

Engineering is accountable for quality

Eine Frage, die ich mir immer wieder stelle: Woher wissen die Techniker, was Qualität ist? Qualität muss im Kontext betrachtet werden. Eine Entwicklung für eine Messepräsentation muss nicht unbedingt wartbar oder performant sein. Für eine Software, die der Grundstein für ein Produkt ist, ist dies jedoch sehr wichtig. Zu oft erlebe ich in der Praxis, dass hier immer mit einem Maß gemessen wird. Technik ist nicht Business, Business soll aber die Richtung (“was”) vorgeben. Wenn Technik dann nur eine Art von Qualität liefern kann, dann ist dies zu teuer und es wird kein Geschäftswert generiert.

Compensation policies need to change

Damit wird Scrum zur Restrukturierungsmaßnahme im großen Stil. Viel Spaß mit dem Widerstand, auf den man treffen wird. Betriebsrat? Gewerkschaft? Sind die Manager wirklich so gut, diese Veränderungen an die Belegschaft zu verkaufen?

Jobs will change

Für Deutschland eine spannende Sache. Veränderung der Stellenbeschreibung bei Festangestellten. Vielleicht wollen diese ihre alte Position behalten und klagen dagegen? Nicht jeder ist mit den Veränderungen einverstanden. Mit Widerstand ist zu rechnen – wiederum muss mit Kosten und Verzögerungen gerechnet werden.

Management’s primary responsibility will shift from command to servant leadership

Das Management wird reduziert auf die Beseitigung von Hindernissen. Hier wird stets davon ausgegangen, dass Selbstorganisation funktioniert. Ich bezweifle dies. Leider sprechen meine Erfahrungen dagegen. Die meisten Teams, die ich kenne, denken zu technisch und zu sicherheitsorientiert. Zu langsam und damit unbezahlbar. Der Grund? Meist Überforderung in Form von Multi-Projekt-Abarbeitung und dauernde Veränderung des Fokus. Ja, ein Management-Problem. Ihr könnt aber sicher sein, dass das Management dies gerne lösen würde – aber nicht kann. Superheld Produktmanager (PO) scheitert an der Realität. Wer hätte das erwartet?

Trotz Selbstorganisation wird im Allgemeinen auch nur der Manager an die Wand gestellt. Single wrinkable neck eben.

Management turnover will occur

Für viele Manager ist der Deal mies: Mehr Verantwortung, mehr Stress und Druck. Weniger Einflussmöglichkeiten. Immer noch im Schussfeld, wenn es Probleme gibt – während die Entwicklung ziemlich geschützt ist. Naja, da kann man verstehen, dass der eine oder andere Manager eine Position vorzieht, in denen er mehr bewegen kann.

Fazit

Aus meiner Sicht sieht das Fazit so aus:

Mit Scrum werden die Defizite einer Organisation deutlich. Jede Organisation hat Defizite und Probleme. Was tun? Ken warnt davor, Scrum anzupassen – da dann die Probleme nicht beseitigt werden. Verständlich – aber auch realistisch? Vielleicht. Wenn man in der Lage ist die Kosten einer Einführung von Scrum (as from the book) zu bezahlen. Falls dies nicht der Fall ist, muss mit Kompromissen gearbeitet werden.

Sorry, wollte euch nicht den Tag vermiesen ;-)

Prophet im eigenen Lande …

Felix — Sun, 31 Jan 2010 09:09:45 +0000

Es gibt doch das Sprichwort, dass der Prophet im eigen Land nicht viel gilt. Irgendwie fühle ich mich so, nachdem ich die Excel-Tabelle von Jeff Sutherland gesehen habe.

Ein ähnliches Planungswerkzeug habe ich zusammen mit ein paar anderen POs vor fast zwei Jahren bei unseren Teams eingeführt und im Allgemeinen sehr gute Erfahrungen damit gemacht. Unser Werkzeug war nicht ganz so detailliert, hat aber stets seine Aufgaben erfüllt.

Leider konnte es sich auf Grund erheblichen Widerstands von “Traditionalisten” (und einiger externer Berater) nicht durchsetzen. Naja, vielleicht lernen sie nun von Jeff, dass Excel nicht böse sein muss, und dass eine genauere Betrachtungsweise der Teamzusammensetzung in der Vergangenheit ein relevanter Parameter für die zukünftige Velocity sein kann.

Urlaub? Warum soll ich Urlaub berücksichtigen – wir mitteln einfach über das ganze Jahr!

Wunderbar, wenn es fixe externe Termine gibt und man frühzeitig wissen muss, ob diese eingehalten werden können.

Alle weiteren Kommentare verkneife ich mir jetzt.

New book from Kniberg: Kanban and Scrum – making the most of both

Felix — Wed, 20 Jan 2010 21:01:03 +0000

Falls ihr es (wie ich) übersehen habt, dann für alle der “late majority” der Hinweis, dass Henrik Kniberg zusammen mit Mattias Skarin ein neues Buch veröffentlich hat.

Nach seinem fantastischen “Scrum and XP from the Trenches” und seiner Scrum Checklist (vgl. auch ArmerKater) sicherlich ein lesenswertes Buch. Mal sehen, wann ich dazu komme.

Bei InfoQ gibt es Informationen zum Buch und ein Link zum PDF Download.

PS: Freue mich natürlich über Kommentare zum Buch, falls ihr es schon gelesen habt!

Scrum Mind Map noch vor How to say no

Felix — Fri, 15 Jan 2010 19:15:37 +0000

Gerade gesehen: Meine Mind Map mit einem Überblick zu Scrum ist jetzt #1 bei den “Recent Popular Maps”. Meine Mind Map fürs Projektmanagement von Kleinstprojekten rangiert auf Platz #6.

Mind Map: Scrum

Felix — Wed, 30 Dec 2009 07:25:23 +0000

Mind Maps nutze ich schon relativ lange. In letzter Zeit setze ich diese Technik und die erzeugten Mind Maps immer stärker ein.

Für sehr kleine Projekte kann eine aktuell gehaltene Mind Map sogar einen Großteil der Projektdokumentation ersetzen. Sozusagen die WBS in die Mind Map gießen und den Status plakativ festhalten. Ist natürlich weder die echte Projektmanagement-Lehre (WBS und Fortschritt nicht vermischen), noch echtes Mindmapping. Funktioniert allerdings überraschend gut.

Mit Werkzeugen wie XMind kann man zudem direkt eine Tabelle hinzufügen (bzw. einen Ast als Tabelle visualisieren) und damit die wichtigsten Termine im Auge behalten.

Gestern habe ich mir nach längerer Nutzung der kostenlosen Standard-Version die Pro-Lizenz für XMind gegönnt (Aktionspreis etc.) und ein bisschen herumgespielt und eine einfache Mind Map zum Thema Scrum erzeugt.

Wie immer freue ich mich natürlich über Kommentare!

UPDATE: Simon Baker hat ein wirklich beeindruckende Mind Map zu Scrum erstellt.

Scrum User Group Karlsruhe: Die Leiden des Scrum Product Owner

Felix — Tue, 15 Dec 2009 08:02:00 +0000

Das letzte Treffen der Scrum User Group Karlsruhe in 2009 beschäftigte sich mit der Rolle des Scrum Product Owners. Genauer: “Herausforderungen für unseren Product Owner”.

Zunächst wurde darüber diskutiert, wie/ob der Product Owner (PO) zum Scrum Team gehört. Relativ schnell wurde die allgemein akzeptierte Formel “Scrum Team = (Dev) Team + SM + PO” übernommen.

Auf die Frage, wer bereits als Product Owner arbeiten konnte, gab es nur wenige Meldungen. Die Verteilung dürfte ähnlich wie bei den Zertifizierungen sein: Viele ScrumMaster, wenige ProductOwner.

Danach wurden typische Herausforderungen für den Product Owner gesammelt:

Die Punkte wurden auf Karten geschrieben und dann inhaltlich gruppiert. Die größte Gruppe stellten dabei die organisatorischen Herausforderungen bzw. Rahmenbedingungen da:

Am meisten kritisiert: Der Product Owner hat keine echten Entscheidungsbefugnisse (ProductOwner != Gold Owner).
Teilweise sind POs nur Verwalter eines Team-Backlogs, d.h. die Rolle des POs wird ad absurdum geführt. Sehr beliebt v.a. bei Multi-Projekt-Umgebungen.
POs müssen die Arbeitsweise des Scrum Teams bzw. das Projekt nach außen vertreten. Hierbei spielen oft fixe Termine für Releases, Budgets (EUR, PT) und Standards (Norm xyz) eine wichtige Rolle. Die äußeren Zwänge in Einklang mit der Sichtweise innerhalb des Scrum-Prozesses zu bringen bleibt oft alleine die Aufgabe des PO.
POs bekommen in ganzer Schärfe den Wettbewerb zu spüren, ohne den Druck weitergeben zu können. Letztendlich sind Product Owner die Schnittstelle zur Welt außerhalb des Scrum-Teams.
…

Diese größte Gruppe wurde klassifiziert als “Pech, das ist der Job des Product Owners” ;-)

Augenmerk wurde dann auf Herausforderungen gelegt, die direkt beeinflusst werden können. Dazu gehören:

Überforderung des Product Owners durch die vielfältigen Aufgaben. Der Product Owner sollte bei größeren Projekten nicht alleine agieren, sondern es soll eine Hierarchie von Product Ownern geben (PO of PO)
Product Owner sollte ein gutes technisches Verständnis haben
Product Owner sollte nicht zu viel technisches Verständnis haben (Oh! Ein Widerspruch)
Der Product Owner soll direkt mit dem Kunden interagieren, aber im besten Fall auch immer für das Team erreichbar sein. Problematisch, wenn der Kunde relativ weit entfernt ist.
… sowie noch eine große Anzahl weiterer Themen (hat die jemand mitgeschrieben?)

Letztendlich wurde allen Beteiligten schnell klar, welche Anforderungen die Rolle des Product Owners stellt und das die Arbeit als PO voll widersprüchlicher Zielsetzungen sein kann (Team coachen ja/nein, einmischen bei technischen Fragestellungen ja/nein, Rahmenbedingungen verändern wollen ja/nein, Team hinterfragen ja/nein, …).

Meiner Meinung nach verbirgt sich jedoch hinter vielen Wiedersprüchen auch eine Verantwortung, welche zum großen Teil vom Team übernommen werden müsste. Das Team darf nicht eindimensional auf der technisch besten Lösung beharren, sondern muss die Rahmenbedingungen – auch die wirtschaftlichen – verstehen und ist deshalb in der Pflicht Alternativen anzubieten und auf mögliche Auswirkungen hinzuweisen. Leider sind die meisten Entwickler-Teams hier sehr zurückhalten und ziehen sich auf eine vereinfachte Sichtweise zurück.

Gerade bei Teams, in denen die Schlüsselrolle des POs geschwächt ist, fehlt den Team-Mitgliedern der Ansprechpartner für schnelle Entscheidungen und sie ziehen sich zunehmend in die Passivität oder Feuerwehraktionen zurück. Genau so darf Scrum natürlich nicht laufen, dürfte aber zu der verbreitesten Form der Scrum Implementierung zählen ;-(

Festpreisprojekte und Scrum

Felix — Fri, 11 Dec 2009 06:24:16 +0000

Auf der Mailingliste scrumdevelopment wurde vor einigen Tagen die spannende Frage diskutiert ob/wie Scrum zu Projekten mit Festpreis-Verträgen passt. Eine Frage, die immer wieder diskutiert wird, wie schon ein anderer Thread aus dem Jahr 2006 zeigt.

Im Rahmen der aktuellen Diskussion wurde immer wieder das Festpreis-Modell als sehr problematisch bezeichnet, allerding sind in vielen Bereichen Festpreis-Projekte Standard und dieses wird sich trotz der vielfältigen Nachteile dieser Vertragsform wohl auch in absehbarer Zeit nicht ändern.

Da auch in meinem Umfeld Festpreis-Projekte dominieren, hier ein paar Gedanken zu dem Thema.

Festpreis-Projekte – nicht nur der Preis ist fix

In einem Festpreis-Projekt sind alle wesentlichen Parameter vorgegeben:

Das Angebot definiert den Preis, es gibt keine variablen Anteile
Die Spezifikation definiert dem Umfang, die Features – in Scrum-Speak den “Scope”
Die Termine sind in den meisten Fällen ebenfalls genau fixiert, Strafzahlungen bei Terminverfehlungen sollen häufig die Termintreue verbessern
Hinsichtlich Qualität wird meist mit Verweise auf “entspricht dem aktuellen Stand der Technik” etc. gearbeitet; Formulierungen die für Juristen Munition genug abgeben

Auf den ersten Blick vermittelt ein Festpreis-Vertrag damit den Eindruck einer sicheren Grundlage für das Projekt. Der Teufel steckt – wie immer – im Detail.

Typische Herausforderungen bei Festpreis-Projekten

Beispiele für typische Herausforderungen beim Einsatz von Festpreisprojekten sind:

Meist wird der Preis stark durch den Wettbewerb beeinflusst. Schätzungen der Entwicklungsabteilungen werden nach unten korrigiert, Risiken nicht ausreichend eingepreist. Der Vertrieb wird oft am Umsatz der abgeschlossenen Verträge gemessen und weniger daran, ob die versprochenen Leistungen auch geliefert werden können.
Anforderungen und Spezifikation sind in der Regel weder ausreichend genau noch fehlerfrei. Selbst wenn dies der Fall wäre, dann würde eine Spezifikation die noch vor der ersten echten Projektphase geschrieben wurde, nie die wirklichen Wünsche des Kunden abdecken. Zudem ändern sich diese stetig.
Im Allgemeinen hat man bei Ausschreibungen für Festpreis-Projekte nur beschränkt die Möglichkeit eng mit den (potentiellen) Auftraggebern zusammen zu arbeiten. Der Aufwand ist zudem eine erhebliche Investition, die sich nur auszahlt (?), wenn das Angebot attraktiv genug ist, um den Zuschlag für das Projekt zu erhalten. Attraktivität definiert sich hierbei oft über die ausgewiesenen Kosten.
Termine werden meist ebenfalls durch Wunschdenken herbeigeführt. Mögliche Risiken werden hierbei ebenfalls ignoriert.
Qualitätskriterien sind nicht vereinbart, alle beteiligten Parteien haben eine unterschiedliche Auffassung, was genau unter Qualität zu verstehen ist.

Roy Morien schreibt in seinem Beitrag einen entscheidenden Satz, der wohl irgendwann in jedem Festpreis-Projekt von Auftraggeber gesagt wird:

‘Oh, but surely you understood that {some feature or process} is part of what we asked for’.

In vielen Fällen war hierbei wohl selbst dem Auftraggeber zum Zeitpunkt der Beauftragung nicht klar, dass die Funktion oder der Prozess zum Leistungsumfang gehört. Sonst hätte er dies nach Erhalt der Spezifikation anmerken müssen. Der Auftraggeber kann sich im Allgemeinen nicht von seinen Mitwirkungspflichten entbinden.

Vorgehensweise bei Angebotslegung und Abwicklung

Im Allgemeinen wird bei Festpreis-Projekten auf zwei Arten auf die Herausforderungen reagiert:

Bei kleineren Punkten wird ein im Festpreis vorgesehene “Puffer” genutzt, um unnötige Reibungsverluste durch Verhandlungen von Änderungswünschen zu vermeiden. Eine Methode die nur bedingt zu empfehlen ist, da im Allgemeinen der Puffer in anderen Positionen verstreckt wird und damit das Vertrauen beschädigt werden kann.
Im Allgemeinen muss bereits kurz nach Projektbeginn über Änderungswünsche diskutiert werden. Änderungswünsche haben meist Auswirkungen auf Projektbudget und Termine. Teilweise gelingt es aber auch Funktionen zu tauschen, d.h. den Scope des Projektes anzupassen.

Erfolgsfaktoren

Entscheidend bei Festpreis-Projekten sind oft Punkte wie

Offenheit und Vertrautheit: Kommunizieren Auftragnehmer und Auftraggeber offen miteinander und besteht grundsätzlich Vertrauen zwischen beiden Parteien?
Rahmenvertrag und Einkauf: Ist der Rahmenvertrag fair oder wird eine der beiden Parteien stark benachteiligt? Wann/wie muss bei Konzernen die Abteilung für Einkauf / Projektabwicklung involviert werden. Welche Vorgaben und Prozesse bestehen?
Nachvollziehbarkeit: Sind die Änderungswünsche für beide Parteien nachvollziehbar? Sind die Kosten nachvollziehbar?
Änderungswesen: Wurde über den Umgang mit Änderungswünschen schon bei den Vertragsverhandlungen gesprochen?
Flexibilität: Hält der Auftraggeber einen Teil des Projektbudgets zurück, um Änderungswünsche schnell finanzieren zu können? Ist er flexibel genug, um Anforderungen tauschen zu können?
Kapazität: Hat der Auftragnehmer die Kapazität und die Fähigkeiten, um Änderungswünsche zeitnah umsetzen zu können?

Vielfältige Meinungen aus der Agilen Community

Das Thema Festpreis-Projekte hat schon immer vielfältige Reaktionen ausgelöst. Besonders heftig wird in der Agile Community diskutiert.

Scott Ambler beispielsweise bezeichnet Festpreis-Projekte als grundsätzlich unethisch:

Fixed price work is unethical. As wannabe professionals we need to stand up to the bureaucratic treadmill.

Peter Stevens hat zum Thema Festpreis-Projekte und Scrum auf dem Italien Agile Day eine Key Note gehalten. Eine kurze Zusammenfassung über verschiedene Vertragsformen – inkl. Festpreis - kann man hier nachlesen.

Simon Baker hat vor längerer Zeit schon über Festpreisprojekte etwas geschrieben:

To say how much something will cost, you need to know in great detail exactly what needs to be built so that your estimates for the work can be accurate. But you can’t define everything you want, in detail and up front, and get it exactly right so there will be no changes in the future. And no estimate is ever accurate (it wouldn’t be an estimate if it was). […] Don’t base the contract with your vendor on conformance to a detailed requirements specification. If you do, you’re saying all your good ideas happen at the start of a project and you’re effectively betting all your money on a hole-in-one

Woraufhin einer seiner Leser seine Erfahrungen mit einem Festpreisprojekt schildert:

[…] fixed price contract where the client and contractor fought endlessly over what was included in the price I endorse everything said above. Unless you are exceptionally lucky your fixed price contract will be toxic to the client supplier relationship.

Paul Klipp erläutert in seinem Artikel, warum Festpreis-Projekte letztendlich auch schlecht für den Kunden sind: Why Fixed Bids Are Bad for Clients (Scrum Alliance).

Einen Überblick über verschiedene Vertragsformen in agilen Organisationen gibt ein älterer Artikel hier auf Armerkater.de.

Fazit

Mein Fazit zu Festpreis-Projekte ist, das es sich um eine in der Industrie immer noch sehr beliebte Vertragsform handelt, die mit vielen Herausforderungen verbunden ist. Gründe hierfür sind die scheinbare Sicherheit für den Auftraggeber.

Auch bei Festpreis-Projekten kann man (relativ) gut und flexibel auf Änderungen reagieren – wenn Auftraggeber und Auftragnehmer dieses Thema offen angehen und an einer Win-Win-Situation interessiert sind.

Gibt es jedoch kein Grundvertrauen, so kann jedoch schnell eine Lose-Lose-Situation entstehen:

Der Auftraggeber wird im besten Fall bekommen, was er spezifiziert hat – nicht was er wirklich braucht. Ein zunächst preisgünstig erscheinender Anbieter kann sich im Rahmen von Änderungswünschen als vergleichsweise teuer herausstellen.

Für Anbieter stellen Festpreis-Projekte stets eine große Herausforderung da, vor allem wenn im Angebot keine große Marge zu erwarten ist bzw. kein großer Sicherheitspuffer eingepreist werden kann. Im Grunde müssen Festpreis-Projekte deshalb immer teurer verkauft werden, als Projekte die nach Aufwand abgerechnet werden. Hier spielen Risikorückstellungen, Verhandlungsmasse, Puffer und zusätzliche Verhandlungs- und Analysekosten eine Rolle.

Termine: Scrum User Group Karlsruhe, IT-Projektmanagement Stuttgart

Felix — Wed, 25 Nov 2009 09:23:20 +0000

Die XPDays finden jetzt in Karlsruhe statt, demnächst gibt es weitere interessante Termine in Karlsruhe bzw. Stuttgart:

02.12.2009: Scrum User Group Karlsruhe – Product Owner Herausforderungen

02.12.2009, ab 20:00 Uhr, Großer Kurfürst, Sophienstrasse 80, 76135, Karlsruhe, Deutschland

Agenda:

n.n. moderiert das Thema “Herausforderungen für unseren Product Owner”
Freie Gespräche zu jedem Thema das gerade aktuell ist
Themensammlung für folgende Treffen aktualisieren

Anmeldung via Termin bei Xing:
https://www.xing.com/events/scrum-user-group-karlsruhe-product-owner-herausforderungen-432772

04.12.2009: Regionale Fachgruppe IT-Projektmanagement in Stuttgart – PM & Stress

04.12.2009, 18 Uhr in Raum K5 (EG), Kienestr. 35, S-Mitte

PM & Stress – mit Stress besser umgehen, Spielregeln & Teamvertrag, Gesundheitsbewusste Teamführung

Es geht diesmal um das Thema Gesundheit und Stress im Umfeld von Projekten und Projektmanagement.
Damit ist eine der Fragestellungen: “Wie gehe ich als Projektleiter (gut) mit dem Stress um?”, eine andere, “Wie berücksichtige ich als PL die Gesundheit meiner Projektmitarbeiter?” und “Worauf ist dabei überhaupt zu achten?”.

Details zur Anmeldung befinden sich auf der Webseite: http://www.stz-itpm.de/de/detail.php?nr=1329&rubric=Fachgruppe_ITPM.

Success Stories zu agilen Methoden beim Nearshoring gesucht

Felix — Thu, 19 Nov 2009 20:41:26 +0000

Agile als Mega-Trend

Agile Methode wie Scrum sind ein Mega-Trend und mittlerweile in der IT-Industrie weit verbreitet. Sie führen in vielen Fällen zu erstaunlich guten Ergebnissen: Mittels Fokussierung und den anderen Werten in Scrum können Verbesserungen in der Produktivität und Qualität erreicht werden, wie man sie früher nicht für möglich gehalten hat.

Wo früher basierend auf einem Wasserfall-Modell eine Vielzahl von schnell veralteten Dokumenten erzeugt wurden, werden heute Werte geschaffen und damit sowohl Auftraggeber als auch Auftragsnehmer gestärkt.

Ursprung in fokussierter Umgebung

Agile Methoden haben ihren Ursprung jedoch in einem überschaubaren Umfeld, in dem ein fokussiertes Team mit einem Auftraggeber direkt zusammen arbeitet. Dies ist natürlich in größeren Unternehmen so nicht mehr der Fall, Scrum und die anderen agilen Methoden wurden neu interpretiert, um auch in wesentlich größeren Settings gute Ergebnisse liefern zu können.

Scaling Agile

Dem Ausspruch “all large scale development is distributed development” (vermutlich Dean Leffingwell?) kann ich nur zustimmen – und dieser Herausforderung stellen sich bereits viele größeren Projekte, in denen verteilten Entwickler-Teams Lösungen erarbeiten und sich dabei durch erweiterte Scrum-Implementierungen koordinieren (lassen).

Kurz: Agile goes distributed … oder Agile goes Global.

Kommunikation ist wichtig

Letztendlich basieren agile Methoden jedoch stets auf einer sehr engen und direkten Kommunikation aller Beteiligten. Zu viele Zeitzonen sind hierbei hinderlich, weshalb eine beliebige Verteilung von Team-Mitgliedern über den Erdball stets zu großen Herausforderungen führen wird.

Sourcing von Entwicklungsleistungen

Was jedoch sicherlich in den nächsten beiden Jahren an Bedeutung gewinnen wird ist der Einsatz von agilen Zulieferern auf dem benachbarten Ausland. Heute noch meist von bestimmten Arten der Festpreis-Projekte bestimmt, wird sich sowohl der Käufer- als auch Anbietermarkt sicherlich in Zukunft immer mehr an agilen Verträgen orientieren. Zu oft haben sich Festpreis-Projekte als “Lose-Lose” herausgestellt, heute bieten moderne Vertragsformen ganz andere Möglichkeiten.

Die räumliche Nähe – für Deutschland beispielsweise das östliche Europa oder auch Ägypten – bietet einerseits die typischen Vorteile von Offshoring: Geringere Lohnkosten, Verfügbarkeit von Expertenwissen, bessere Möglichkeiten zu skalieren, bestimmte Arten der Flexibilität – ohne die großen Zeitunterschiede wie beispielsweise China aufzuweisen. Bei Problemen im Projektverlauf ist es auch leicht möglich, als Auftragsgeber schnell das Team zu besuchen und intensive Gespräche mit dem Anbieter zu führen.

Anbieter ohne Erfahrung in agilen Methoden?

Allerdings ist auch anzumerken, dass heute noch erstaunlich wenige Anbieter von Entwicklungsleistungen mit nachweisbaren Erfahungen und Erfolgen beim Einsatz von agilen Methoden und Praktiken gibt. Die wenigsten Anbieter nutzen ihre Erfahrungen intensiv im Vertrieb und im Marketing. Agile wird teilweise noch als “können wir auch” und nicht als Kernkompetenz verstanden.

(Success) Stories gesucht!

Darum mein Aufruf: Wer hat bereits positive Erfahrungen sammeln können? Wer kennt Anbieter, die hier aktiv sind? Genau so spannend sind jedoch auch Berichte zu gescheiterten Versuchen! Vielleicht mag der eine oder andere Anbieter auch etwas dazu sagen?