Grundsätzlich bearbeiten wir alle Projekte nach agilen Methoden

Veröffentlicht in: Netzwoche 04/2013

Christian Stocker erklärt im Gespräch, wie sich agiles Entwickeln und Firmenstrukturen gegenseitig beeinflussen. Seiner Meinung nach funktioniert agile Softwareentwicklung mit klassischen Firmenhierarchien kaum.

Herr Stocker, Liip gilt in der Schweiz als eine der Vorkämpferinnen, wenn es um Agilität geht – wie schlägt sich das in Ihrer Produktiv-IT nieder?

Wir haben eigentlich gar keine produktive IT. Wir sind ein Dienstleister, der Projekte mit teilweise sehr unterschiedlichen Anforderungen bearbeitet. Deshalb haben wir einige Server bei Kunden, einige haben wir in der Cloud. Wobei sich das mit der Cloud noch nicht so richtig durchgesetzt hat – die wäre vor allem für die Kunden interessant, die Lastspitzen abfedern müssen. Weil wir aber sehr auf die Schweiz fokussiert sind, müssen unsere Projekte nicht so stark skalieren. Selbst grosse Kunden wie die Migros haben keine Peaks, die plötzlich nach 50 Servern verlangen.

Heisst das, dass Sie für Ihre Kunden hosten?

Wir haben früher einiges selbst gehostet. Das hängt auch damit zusammen, dass wir agil sein und rasch eine bestimmte Software installieren wollten. Oft ging es auch darum, spezielle Anforderungen zu erfüllen oder Projekt-Tools nutzen zu können, die man bei normalen Hostern nicht bekam. Das hat sich unterdessen geändert. Heute ist alles, was unter der Applikationsebene liegt, schon sehr stark komodifiziert. Zudem wollen wir uns auf unser Kerngeschäft konzentrieren und uns nicht mehr bis nachts um drei um Server kümmern. Deshalb lagern wir das Hosting an Schweizer Partner aus.

Gibt es bei Ihnen überhaupt noch so etwas Banales wie einen Datenserver?

Nein, so etwas habe wir überhaupt noch nie besessen. Für unsere Arbeit benötigen wir im Wesentlichen ein Wiki, das heisst Confluence, einen Issue Tracker namens Jira und ein Zeiterfassungstool. Das sind die drei Hauptanwendungen. Das Wiki und den Issue Tracker hosten wir zurzeit noch selbst, werden sie aber demnächst auslagern. Diese Applikationen sind für uns einfach zu aufwendig im Hosting. Aber zurück zur Frage: Wir brauchen gar keinen Fileserver, weil man beim Wiki und beim Issue Tracker Dateien anhängen kann. Wenn es einmal darum geht, eine Datei solo zu transportieren, nutzen die Teams hierfür oft Dropbox. Wir sind auf vier Standorte verteilt und achten darauf, dass man von überallher arbeiten kann. Deshalb war es uns schon immer wichtig, dass alle Tools webbasiert laufen. Wir betreiben auch kein VPN.

Das heisst, die wesentlichen Applikationen laufen in einer privaten Cloud?

Könnte man so sagen, je nachdem wie man Private Cloud definiert.

Gibt es hierfür keine Public-Cloud-Angebote?

Doch, der Hersteller des Wikis bietet so etwas an.

Warum nutzen Sie die nicht?

Einerseits, weil wir lieber Schweizer Hoster haben und einige Kunden ihre Daten gar nicht ins Ausland verschieben dürfen. Andererseits sind Wiki und Issue Tracker in den fünf Jahren, die wir sie jetzt nutzen, stark gewachsen. Bis wir die Public-Cloud-Version wieder so weit konfiguriert hätten, dass sie unseren Wünschen entspricht, wäre es ein hartes Stück Arbeit. Deswegen migrieren wir lieber zu einer Schweizer Firma, bei der wir unsere Wünsche anbringen können.

Wie sieht es mit BYOD aus?

Bei uns gibt es keine Vorgaben bezüglich der Arbeitsgeräte. Es wird mit Linux, iOS und Windows gearbeitet – das Betriebssystem spielt keine Rolle. Alles was die Leute zum Arbeiten brauchen, ist ein Browser – ausser, sie programmieren.

Haben Sie ein Gerätemanagement?

Wir stellen sicher, dass die Festplatten verschlüsselt sind und schlaue Passwörter verwendet werden. Das bietet schon einen guten Grundschutz für unsere Kundendaten. Für Projekte mit höheren Sicherheitsanforderungen werden individuelle Massnahmen getroffen.

Gibt es Anwendungen, die bewusst nicht in die Cloud verschoben wurden?

Für das Source Code Management setzen wir Git ein. Hierfür gäbe es zwar einen guten Hoster in den USA, aber das verträgt sich wieder nicht mit den Vorschriften einiger Kunden. Deshalb hosten wir das für solche Projekte selbst. Auch die Testserver behalten wir bei uns. Sonst fällt mir nicht viel dazu ein.

Gab es schon schlechte Erfahrungen mit der Cloud?

Schlechte Erfahrungen eigentlich nicht. Wir haben uns aber schon über die Preisänderungen der Hoster geärgert.

Wie sind die Verantwortlichkeiten verteilt, wenn es um IT geht?

Wir haben feste Entwicklerteams, die alle Funktionen vom Business Development bis zu Deployment abdecken. Denen lassen wir ziemlich viel Entscheidungsfreiraum bezüglich ihrer Ausrüstung. Wenn so ein Team findet, es möchte bestehende Applikationen durch neue ersetzen, dann darf es das bei sich ausprobieren. Sollte sich dabei zeigen, dass sie eine neue, bessere Lösung gefunden haben, dann werden das die anderen Teams wahrscheinlich auch übernehmen. Dabei wollen wir aber vermeiden, dass wieder mehr selbst gehostet wird. Es sollen also cloudfähige Lösungen sein. Was aber bei uns nicht funktioniert, ist, dass einer kommt und sagt, ich habe eine tolle Lösung und die führen wir jetzt unternehmensweit ein.

Also keine Standardisierung?

Wir haben das früher eine Zeit lang versucht, aber es hat nie so richtig funktioniert. Das hängt wahrscheinlich auch damit zusammen, dass wir rasch gewachsen sind und immer wieder neue Teams mit eigenen Vorstellungen hinzugekommen sind. Wir glauben daran, dass die Mitarbeiter besser entscheiden können, war für sie und ihre Projekte gut ist. Wichtig ist einfach, dass die Teams voneinander lernen und keine Doppelspurigkeiten entstehen.

Gibt es für diesen Erfahrungsaustausch einen formalen Rahmen?

Ja, wir haben hierfür einige Gefässe. Beispielsweise gibt es jede Woche an einem fixen Tag zu einer bestimmten Zeit einen Vortrag zu irgendeinem Thema. Oft sind das interne Referenten, die von ihren Erfahrungen mit neuen Tools erzählen, manchmal auch externe. Diese Vorträge werden über Video zu den anderen Standorten übertragen. Sie sind recht beliebt und seitens der Referenten gut ausgebucht. Zusätzlich haben wir uns an jedem 10. des Monats einen sitzungsfreien Tag verordnet. Dann organisieren wir jeweils einen sogenannten Hackday. Dort kann man etwa ausprobieren, wie man ein neues Tool benutzt. Weil man keine Sitzungen vereinbaren darf, hat niemand eine Ausrede, nicht zu kommen. Das machen wir seit etwa zwei Jahren und es funktioniert recht gut. Schliesslich gibt es bei uns auch noch einen Innovationsprozess, innerhalb dem man Dinge ausprobieren kann, die länger brauchen als einen Hackday. Dazu muss man zu zweit sein und kann sich ein bestimmtes Zeitbudget dafür reservieren. Entschieden wird das vom Innovationsgremium, das aus drei bis vier Mitarbeitern besteht. Wo wir noch nicht ganz zufrieden sind, ist der Know-how-Transfer aus den Projekten in die anderen Teams. Hierzu haben wir gerade kürzlich einen Hackday veranstaltet.

Wie gross ist der Anteil an Projekten bei Liip, die agil bearbeit werden?

Es kommt darauf an, wie man agile Entwicklung definiert. Grundsätzlich bearbeiten wir alle Projekte nach agilen Methoden – den klassischen Wasserfall gibt es bei uns nicht. Manchmal gibt es Kunden, die von agil nichts wissen wollen, dann arbeiten wir einfach nur intern agil. Wir machen dann zwar den Backlog, den der Kunde verlangt, entwickeln aber trotzdem nach agilen Prinzipien. In solchen Fällen funktionieren wir quasi als agile Blackbox. Das kommt aber selten vor. Was es immer häufiger gibt, sind Kunden, die mit einer Idee kommen, und sich um die Entwicklung gar nicht kümmern wollen. Sie möchten einfach in einem halben Jahr ein Resultat sehen, das ihrer Vision entspricht. Dann können wir voll agil entwickeln. Das braucht aber viel Vertrauen.

Wie gehen Sie aber vor, wenn ein Kunde mit einem riesigen Anforderungskatalog kommt?

Dann versuchen wir mit dem Kunden als Erstes, den Business Value seiner verschiedenen Storys zu bestimmen. Wir fragen etwa, ob das Gästebuch, das er gerne haben möchte, wirklich relevant fürs Geschäft ist. So sortieren wir die Anforderungen nach Wichtigkeit. Im Idealfall fängt man beim Entwickeln oben an und fährt fort, bis man zum Punkt kommt, an dem es sich nicht mehr lohnt. Im Verlauf des Projekts kommt der Kunde dann sicher auf die Idee, dass er die eine oder andere Funktion doch etwas anders haben möchte, und schon haben wir den Change Request. Dann diskutieren wir mit ihm, ob wir innerhalb des Kostenrahmens die gewünschten Änderungen bei einer wichtigen Funktion machen, dafür aber eine andere, unwichtige weglassen sollen. So kann man sich eine gewisse Agilität erhalten. Beim Offerieren ist das allerdings immer etwas heikel, aber das geht allen so.

Wie steht es um die Akzeptanz der agilen Entwicklung in der Schweiz?

Auch wir hören bei Offerten immer wieder, man habe mit der agilen Entwicklung schlechte Erfahrungen gemacht und wolle deshalb nichts mehr damit zu tun haben. Das hat aber meist nichts mit der Methode an sich zu tun, sondern damit, dass das Projekt per se verkorkst war. Die Nachfrage ist aber da. Als Dienstleister sucht man noch immer nach Lösungen, wie man das am besten macht. Es ist nicht ganz einfach, weil der Kunde ja ein Versprechen bezüglich Kosten und Termine will. Da kommt es sehr auf die Konstellation an. Bei agilen Projekten braucht es den unbedingten Willen zur Zusammenarbeit über alle beteiligten Instanzen. Vielleicht müssen die Kunden zuerst einfach ein paar gute Erfahrungen gemacht haben, bis sie diesen neuen Methoden vertrauen. Aus meiner Sicht findet aber schon ein Umdenken statt. Wir müssen aber sicher noch stärker im Markt kommunizieren, was mit agilem Arbeiten eigentlich gemeint ist.

Führt die agile Arbeitsweise zwangsläufig zu Firmen wie Liip mit ihren dezentralen und flachen Strukturen? Oder anders herum: Gibt es so etwas wie agiles Management?

In unserem Fall hängen die Strukturen vor allem damit zusammen, dass wir uns von Anfang an möglichst demokratisch organisieren wollten. Wir wollten keinen Patron, der uns sagt, wo es langgeht. Wir sind sehr konsensorientiert, was aber auch nicht immer traumhaft schön ist. Es braucht oft viel Überwindung, als Mitglied der Firmenleitung einem Team zu sagen, «ja, macht mal», auch wenn man nicht davon überzeugt ist. Am Ende wollen wir aber einfach ein Rahmenprogramm vorgeben, und die Leute sollen das Beste daraus machen.

Anders herum: Geht agiles Arbeiten nur in flachen Hierarchien?

Ja, das kann man so sagen. Agile Softwareentwicklung funktioniert wahrscheinlich nicht mit den klassischen Hierarchien. Bei uns gibt es beispielsweise keine Teamleiter. Auch das ist nicht immer einfach, funktioniert aber offensichtlich meist gut. Es kann schon vorkommen, dass das Management einmal eingreifen muss, beispielsweise, wenn sich ein Team wegen internen Zoffs blockiert. Grundsätzlich verlangen wir von allen Mitarbeitern, dass sie Leadership in ihrem Gebiet übernehmen.

Gibt es für die Teamentwicklung irgendwelche Formalismen?

Jedes Team macht regelmässig eine Quartalsretrospektive, die etwa zwei Stunden dauert. Dort wird darüber diskutiert, was gut, was schlecht war. Eigentlich sollten dort auch zwischenmenschliche und strukturelle Dinge besprochen werden. Das bedingt aber auch, dass im Team ein gewisses Grundvertrauen vorhanden ist. Wir haben zudem sogenannte Standort-Scrum-Masters. Die funktionieren auf der Team-Ebene ähnlich wie ein Projekt-Scrum-Masters. Sie sollen dafür sorgen, dass es den Teams gut geht.

Liip hat vor kurzem den Nachhaltigkeitspreis der Zürcher Kantonalbank gewonnen – hilft das?

Wir haben den Preis vor allem für unseren Umgang mit den Mitarbeitern erhalten und nicht dafür, dass wir viel Energie sparen. Hier wurde gewürdigt, dass wir uns für Mitbestimmung und für die Entwicklung unserer Mitarbeiter einsetzen – all die Dinge, über die wir gerade geredet haben. Das hat uns sehr gefreut und wir verstehen es als Bestätigung für das, was wir die letzten Jahre auf dem Gebiet unternommen haben. Für mich hat Nachhaltigkeit schon immer auch die sozialen und die gesellschaftlichen Aspekte beinhaltet. Wichtig ist auch, dass ein Unternehmen an sich nachhaltig wirtschaftet. Uns geht es nicht darum, möglichst schnell möglichst viel Geld zu verdienen. Wir reinvestieren viel, vor allem in die Mitarbeiter, und wie sich zeigt, geht es uns gut dabei. Und ja – der Preis hilft uns, indem unser Modell öffentlich anerkannt wird.