KADEV09: Entwicklertag 2009: Agile Nearshoring

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.