Tag Archives: Agile

Festpreisprojekte und Scrum

Posted on by

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.

Getier unterwegs

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

Posted on by

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.

XPDays 2009 in Karlsruhe

Posted on by

Am Donnerstag beginnen die XPDays 2009 – diesmal wieder in Karlsruhe. Im Vorfeld finden zudem einige Scrum-Schulungen statt.

Für den einen oder anderen bieten die XPDays sicherlich einen guten Überblick über die aktuellen Diskussionen zu agilen Themen wie Scrum und XP. Interessant sind jedoch sicherlich die Vorträge von Wolfgang Kraus (Collaboration – Agile Softwareentwicklung in verteilten Teams) und von Thomas Starz (Erfahrungen mit Scrum in global verteilten Teams).

Schöne Idee ist der Community Day – eine Möglichkeit sich nach den zwei durchgeplanten Tagen nochmals auszutauschen. Insgesamt ist das “Drumherum” zudem deutlich moderner geworden: Neben dem Blog gibt es nun einen Twitter-Account (@xd_de) inkl. Tag (#xdde09) und sogar Poken sollen herumgeistern.

Für mich fehlen jedoch “die Knaller” im Programm und deshalb nehme ich dieses Jahr nicht an der Konferenz teil. Aufgrund akut immer stärker angreifenden “Wishful Thinking”-Rotten bin ich auf Grund akuter Frust-Anfälle auch nicht in der Verfassung dem Community Day beizuwohnen ;-).

Dazu passt eine Karikatur der Hippenstocks Strategen (Süddeutsche), Ausgabe letzten Samstag:

Man sieht einen Manager an seinen Schreibtisch; er telefoniert: “Hallo ich bin Manager. Bitte verbinden Sie mich mit der Realität.”

Diese Karikatur trifft es auch recht gut: “Kopf hoch Kottelmann! 50 Prozent der Wirtschaft sind Psychologie – die Fakten sollten Sie nicht überbewerten!”

So, das reicht für Heute.

Success Stories zu agilen Methoden beim Nearshoring gesucht

Posted on by

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?

Agile Eastern Europe und Agile Nearshoring

Posted on by

Jutta Eckstein berichtet von der Konferenz “Agile & Scrum in Eastern Europe”, einer Veranstaltung die diesen September zum ersten mal in der Ukraine stattfand.

Fokus der Konferenz lag – neben allgemeinen agilen Themen – besonders auf der Nutzung von agilen Prozessen bei  verteilten Projektteams.

Wie Jutta richtig schreibt:

Es war naheliegend, dass der Fokus der Konferenz auf verteilter agiler Entwicklung lag, da der Großteil der Teilnehmer aus Ländern des ehemaligen Ostblocks kamen, die häufig Mitarbeiter und Teams für Offshore- oder Nearshore-Projekte stellen. Agile Entwicklung ist für diese Teams nicht nur ein großes Thema, weil häufig ihre Kunden Agilität als strategische Vorgehensweise erkannt haben, sondern da es auch für die Offshore-Teams wesentlich einfacher ist, Projekte erfolgreich abzuschließen, wenn sie eine agile Vorgehensweise einsetzen.

Quelle

Mittlerweile sind viele der Präsentationen online verfügbar, die eindrucksvoll belegen wie beliebt agile Entwicklungsmethoden mittlerweile bei unseren östlichen Nachbarn sind und wie erfolgreich diese eingesetzt werden. Kombiniert man nun diese Kenntnisse mit einem agilen Sourcing-Ansatz, dann kann Agile Nearshoring beginnen.

Interessante Vorträge im Themenbereich des Agile Nearshoring interessant sind:

Viel Spaß beim lesen ;-)

Die Konferenz scheint einen Besuch wert zu sein. Mit lediglich 190 USD Gebühren bleibt auch noch genügend Spielraum für die Anreise ;-)

UmptyFraz und was sonst so passiert …

Posted on by

Ordnung hilft Fokus zu gewinnen. Dies ist wohl ein Grund, weshalb aus Japan die Nachricht kommt, dass die Belegschaft in schlechten Zeiten bitte morgens etwas früher kommt und selbst aufräumt.

In der heutigen Zeit gibt es neben der “echten” Welt eben auch die virtuelle – und diese muss ach aufgeräumt werden. Aus diesem Grund habe ich vor einiger Zeit meine Festplatte aufgeräumt.

Dabei ist mir aufgefallen wie viel UmptyFraz ich schon mitgemacht habe. Die zwei populärsten Hypes sind sicherlich Model Driven Architecture (MDA) und das ganze Geschrei um die agilen Methoden ;-)

Am Schluss bleien doch immer die gleichen Anforderungen aus der IT-Industrie:

“Wanted: Young, skinny, wirey fellows not over 18. Must be expert riders willing to risk death daily. Orphans preferred. Wage $25 per week.”

- Pony Express advertisement, 1860  (via After the Goldrush von Steve McConnell)

Es gibt ja auch Evangelisten, die Teilzeitarbeit kritisieren. Nein, diesmal verlinke ich nicht.

 

Wie auch immer, zu MDA habe ich einen recht kritischen Foliensatz von mir gefunden, in dem ich auf die Schwächen des Ansatzes hingewiesen habe (“wo ist eigentlich mein Debugger hin?”). Leider ist dieser nie fertig geworden. Auf jeden Fall gefällt mir heute noch eine Folie, die ebenfalls Punkte aus “After the Goldrush: Essays on the Profession of Software Engineering (Best Practices)” enthält:

 image

Hmmm,

  • Can the innovation be misapplied?
  • Must the innovation be applied in its entirety to realize significant benefits?
  • …

KADEV09: Entwicklertag 2009: Agile Nearshoring

Posted on by

Agile Nearshoring

Achim Maier, POET AG
Prof. Dr. Khaled Nagi, Universität Alexandria, POET Egypt LLC

Angekündigt wurde der Vortrag unter dem Titel “Agile Offshoring”, vorgetragen letztendlich als “Agile Nearshoring”. Nearshoring passt auch eher, schließlich zählt Agypten aus Sicht Deutschlands zu den Near-Shore-Destinationen. Überrascht war ich etwas, dass der Saal nicht einmal halb voll war. Für mich sind die Themen “Agile Methoden” und “Sourcing” für die kommenden Jahre von sehr großer Bedeutung (“hot topics”), die Gründe muss ich hier nicht noch einmal erläutern. Wenn man schließlich Agile und Sourcing verbinden möchte, dann bietet Nearshoring – also Agile Nearshoring – interessante Möglichkeiten. Genau um diese Möglichkeiten ging es auch in dem Vortrag.

Nach der obligatorischen Vorstellung des beteiligten Unternehmens (POET) mit seinen drei Standorten in Karlsruhe, Hamburg und Alexandra (Ägypten) wurde kurz die Ausgangssituation erläutert.

Ausgangssituation: Wasserfall

  • Phasen nach Wasserfall
  • Quality Gates, intene Verrechnung, abgegrenzte Verantwortungsbreiche
  • umfangreiche Anforderungen
  • Umsetzung der Anforderungen in Ägypten, keine Feedbackschleifen
  • lediglich 1 Release pro Jahr des Kernproduktes

Seit einger Zeit nutzt nun POET bereits agiles Nearshoring, um die Wettbewerbsfähigkeit zu stärken.

Es folgte eine kurze Erläuterung zu den agilen Methoden:

  • short cycles
  • continuous integration
  • acceptance

Und zum Nearshoring:

  • Zeitzone -> wenig Unterschied (im Vergleich zum Offshoring)
  • Resource planning (Entwicklerkapazität besser skalierbar)
  • lower daily costs (Tagessätze geringer)
  • Internationalization (Internationalisierung quasi nebenbei, da eh durch Nearshoring benötigt)
  • culture (kulturelle Nähe, v.a. im Vergleich zur asiatischen Mentalität)
  • level of domain know-how (ok, das dürfte firmenspezifisch sein)
  • IT Infrastructure
  • stability of team (Fluktuation muss gering gehalten werden, gelingt aber besser als bsp. in Indien)

Auch Herausforderungen - gerade im Managementbereich – wurden nicht ausgespart, u.a. wurde die Wichtigkeit von Kommunikation, vor allem auch direkte Kommunikation (face to face) hervorgehoben. Immer wieder wurde darauf hingewiesen, dass Team-Building bzw. ein “Team-Gefühl” ebenfalls von immenser Bedeutung ist. Team-Feeling: 3 Standorte, 1 Team!

  • software development = people business (deshalb: Management auf der persönlichen Ebene ist wichtig)
  • viele gegenseitige Besuche nötig, um Vertrauen aufzubauen
  • Reisekosten: Besuch Karlsruhe -> Alexandria: 450 EUR Flug + 3,5h Flugzeit + 1000 EUR Hotel & per diem => überschaubare Kosten
  • Aufwand für Spezifikation kann durch enge Interaktion jedoch reduziert werden

Interessant war die Ergänzung der Scrum-Rolle “Product Owner” um einen “Project Owner”. Der Product Owner führt in diesem Modell die Anforderungsanalyse durch, der Project Owner fokussiert sich auf die Prozessmodellierung. In unserem Multi-Project-Scrum haben wir ebenfalls die Rolle des Product Owners und die der Projektleiter – dies ist ein praktikabler Kompromiss, schwächt aber die Entscheidungskompetenz des Product Owners und sollte IMHO soweit als möglich vermieden werden.

Durch das Nearshoring gewinnt die Infrastruktur und der Werkzeugkasten an Bedeutung: Nur mit einem guten Tool-Set ist verteilte Entwicklung mit geringen Reibungsverlusten möglich.

Eingesetzte Methoden und Werkzeuge umfassen:

  • continuous integration & tests
  • Quellcode jederzeit verfügbar
  • Performance Tests: Web Load
  • Jira:
  • – Issue tracking
  • – Sprint-Planning
  • – Estimation Soll/Ist => Transparenz
  • – Aufwandserfassung
  • – Burn down charts werden aus Jira generiert
  • – Reporting aus Jira
  • – alle Kollegen (egal welcher Standort) arbeiten an Issues
  • – Verlinkung Issue <-> SVN
  • Kommunikation: VoIP + Jabba (selbst gehostet) -> schnell und günstig
  • Netviewer (Screen-Sharing / Online-Collaboration)

Die Ergebnisse des Agile-Nearshoring wurden insgesamt als sehr positiv beschrieben. Die Kundenzufriedenheit ist deutlich gestiegen, kein Projekt hat bisher den Budgetrahmen oder die zeitlichen Vorgaben gesprengt:

Customer Satisfaction

  • on time & in budget
  • no major bug fixes required after release
  • 23% weniger Support

Software Quality

  • average bug count 180 -> 25
  • kein “won’t fix” weil so dokumentiert

Team Performance

  • bug fixing & maintenance time 45% -> 34% (target 25%)
  • customer related implementation 9% -> 25%
  • time for implementing roadmap innovative enhancements 38% -> 43%
  • more room for innovation in cooperation with research partners

Gerade der wieder zurückgewonnene Handlungsspielraum läßt raum für neue strategische Optionen erahnen.

In der Zusammenfassung wurde nochmals auf die wichtigsten Punkte hingewiesen:

  • organisatorische Anpassung nötig
  • Offenheit & Flexibilität als Grundlage der Zusammenarbeit
  • Verbesserte Termintreue als Resultat
  • Kunden bekommen bessere Lösung
  • bessere Qualität der Software
  • Reisekosten erhöhen sich definitiv
  • DailyScrum in Egypt
  • Weekly: Steuerung auf PO/PL Ebene -> wöchentlich

Ingesamt war dies ein sehr interessanter Vortrag über ein spannendes Thema, welches in den kommenden Jahren an Bedeutung gewinnen wird.

Karlsruher Entwicklertag 2009 – Es hat sich gelohnt!

Posted on by

Die drei Tage “Karlsruher Entwicklertag 2009” sind vorbei, begonnen hat alles am Montag mit demVKSI Day (vgl. Posting), gefolgt vom Conference Day und dem Agile Day.

Trotz der etwas verwirrenden Benennung “Entwicklertag” für drei Tage haben sich alle drei Tage für mich gelohnt. Jede Menge interessante Menschen getroffen und viele gute Vorträge gehört. Erstaunlicherweise hat es mit den Netbook und dem Surf-Stick meist gut funktioniert und der Akku des 1000he hat wirklich den ganzen Tag durchgehalten. Somit ist auch dieses Experiment gelungen. Überrascht hat mich, dass einigen Teilnehmern ArmerKater.de bereits bekannt war!

Über den VKSI Day habe ich bereits etwas geschrieben, die Notizen zu den anderen beiden Tagen muss ich noch aufbereiten. Es ist doch mehr Text geworden als ich zunächst vermutet hätte und ich werde diesen noch sehr stark reduzieren müssen. Die beiden Berichte sollten in den nächsten Tagen fertig werden (=> zum Live-Reporter tauge ich also nicht).