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.

03.02.2010, 18:30-20:30 Uhr, Schlosshotel Karlsruhe, Bahnhofplatz 2 , 76137, Karlsruhe, Germany

• Dr. Nagi (POET Egypt) wird einen Vortrag halten zu: “Nearshore-Entwicklung und -Services mit agilen Methoden”
• Dr. Mevius & Herr Stephan (FZI, Mitglied im Team ZIKS (http://www.ziks.de/)):
  “Projekterfahrungen mit internationalen, kollaborativen Softwareprojekten”
• Ashant Chalasani, Vertreter des Indo-German Software Competence Network (http://indescon.org): “Kooperation zwischen indischen und deutschen Firmen in der IT-Branche: Nicht nur ein Einwegmodell!”

Interessenten können sich via XING registrieren:

• https://www.xing.com/events/roundtable-fzi-forschungszentrum-informatik-karlsruhe-near-offshore-452312

Here we go:

29.01.2010, 18:00-20:00 Uhr: Indescon X-Table Dinner in Karlsruhe

Restaurant Punjab, Amalienstraße 46, 76133, Karlsruhe

Treffen der indisch-deutschen IT-Community. Ziel ist es, dass Kontakte zwischen regionalen Softwareeunternehmen, Indescon-Mitgliedern und indischen IT-Experten geknüpft werden.

Termin bei Xing: https://www.xing.com/events/indescon-table-dinner-karlsruhe-439618

03.02.2010, 20:00–22:00 Uhr: Scrum User Group Karlsruhe

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

Thema diesmal: “Konflikte im agile Umfeld und wie geht ihr damit um?”

Termin bei Xing: https://www.xing.com/events/scrum-user-group-karlsruhe-453234

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?

Nette Erklärung:

Shore 1.0:  onshore -> USA, offshore -> Indien, nearshore -> Kanada

Alles klar, oder? ;-)

Dann folgt eine Erklärung von “Nearshore 2.0″ und warum Mexiko eine bessere Wahl als Indien ist.

Hier das Video:

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.