Guidewire Case Study beim Scrumbreakfast #7

Professor Stuart Read vom IMD Lausanne hat am Scrumbreakfast #7 eine Case Study von Guidewire vorgestellt. Anders als erwartet hielt Stuart keine herkömmliche Präsentation, sondern gestaltet den Scrumbreakfast als Diskussion bzw. Workshop.

Guidewire ist ein Unternehmen, was mit Scrum aufgebaut wurde, von der ersten Stunde an. Nicht nur, dass es Sprint Team gibt, um Software zu entwickeln, nein - Guidewire ist eine komplett agil aufgebaute Organisationsstruktur. Die Firma reorganisiert sich jeden Monat. Teams wurden neu zusammengestellt, Funktionen und Rollen neu verteilt und interessanter weise zogen sogar die Teams mit ihrem gesamten Desktop um.

Beim Scrumbreakfast #7 traff Stuart auf eine Gruppe von Scrum Anwendern (und solche, die im Begriff sind, Scrum einzusetzen) und wollte von den praktischen Erfahrungen lernen.

Stuart begann den Workshop mit der Frage, welche Personen für agile Teams eingestellt werden sollten: keine Indiviualisten, Teamplayer, Early Adaptors und Output-orientierte Personen. Darüber hinaus wurde darauf eingegangen, wie man den Recruiting Prozess gestalten könne: das Team entscheidet. Der gesamte Entscheidungs- und Organisationsprozess bei Guidewire kommt von der Basis - Bottom-up.

Dann stellte Stuart die Frage, ob man als Kunde eine Software von einem Unternehmen kaufen würde, wenn sich dessen Organisation ständig ändert. Hat man da Verrtauen? Vertrauen, das ist wohl das Kernelelement. Regelmässig liefern, was man versprochen hat - der Schlüssel zum Erfolg.

Guidewire hat in der Zwischenzeit mehr als 350 Mitarbeiter und soll an der Börse notiert werden. Erstmalig in der Erfolgsgeschichte des Unternehmens gab es nun ein Problem - fehlende Hierachie. Es gab keinen CTO, keinen CEO, keinen CFO etc. Wie führt man ein Unternehmen an die Börse, wenn es keine definierten Strukturen hat?

"Wer ist der CTO von Guidwire?"

"Ja, welchen meinen Sie, den von diesem Monat oder den vom vorherigen?"

Stuart fragte uns Teilnehmer, wie wir das Unternehmen beraten würden? Ein paar Minuten später lieferte er die Anworten:

• Die Entwickler-Teams werden in Pods von 3 bis 6 Personen organisiert.
• Jeder Pod hat einen Pod Leader, quasi einen Team Captain.
• Wird ein Team zu gross, gibt es einen Split.
  
• Jedes Team arbeitet an einem spezifischen Teil des Produkts.
• Jeder im Team ist in der Lage, an allen spezifischen Elementen des Teil-Produkts zu arbeiten.
• Die physische Umgebung wurde an dem Team angepasst, um die Kommunikation zu erhöhen - alle sitzen beieinander.
  
• Reviews von Pods werden vom Head des Produktteils durchgeführt, nicht vom Pod Leader.
• Pod Leader werden nach Kompetenz ausgewählt - er kann jeden Job, den ein anderes Teammitglied erledigen kann, auch selbst erledigen.

Guidewire, ein agil organisiertes Unternehmen, dass erfolgreich ist. Die Menschen, die dort arbeiten, würden wohl nie in einem stark hierarchisch organisierten Unternehmen arbeiten und umgekehrt auch nicht. Stuart erzählte, dass man einen CTO von der IBM bei Guidewire eingestellt habe, der das Unternehmen nach kurzer Zeit wieder verliess ...

Mein Resümee

Das Scrumbreakfest #7, organisiert von Peter, war ein interessanter Anlass, insbesondere, weil ich viele organisatorische Prinzipien und Ansätze die diskutiert wurden, bei meinem akutellen Arbeitgeber namics wiederfand. Und dabei ist mir eines klar: nach namics würde es definitiv schwer ein vergleichbares Arbeitsumfeld zu finden ...