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.

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.


Sag uns was du denkst