Apr
01
2010

Gamasutra zeigt es: auch der Cabal process macht Software-Entwicklung agil

Ich habe gerade auf dem Spiele-Blog Gamasutra einen sehr offenen Erfahrungsbericht von Valve gelesen, der die Vorteile einer Team-orientierten Entwicklung mehr als deutlich macht. Aufmerksam wurde ich auf diesen Artikel durch Theo Priestley, der meint, dass man von dem beschriebenen Cabal process auch etwas für die Durchführung von Projekten zur Verbesserung von Geschäftsprozessen (BPM/GPM) lernen könne.Valve hatte das übliche Problem: das neue  Software-Produkt, hier das Spiel Half-Life, war zum ausgemachten Zeitpunkt bei Weitem nicht fertig. Neben Szenen, die noch völlig fehlten, waren die Level zu unterschiedlich, viele Sequenzen für den Anwender nicht spannend genug, eher nervend. Ganz nach dem Motto “viele Köche verderben den Brei”, besonders wenn Jeder macht, was er will.

Also hatte man sich noch ein weiteres Jahr Zeit genommen und sich den Cabal process ausgedacht. So weit ich recherchieren konnte, ist dieser Prozess Valve-individuell, hat aber viele Ähnlichkeiten mit agilen Methoden. Leider konnte ich auch nicht erkennen, warum er Prozess Cabal genannt wurde. Ob damit die Kabale gemeint war, einer Absprache von mehreren Personen zu einer Intrige? Gegen die Konkurrenz? Egal, was zählt ist das Ergebnis: Ein super Spiel, weil die Mitarbeiter noch nie so gut aufeinander abgestimmt waren wie jetzt, von den umgesetzten Ideen überzeugt und über Alles informiert.

Was war also passiert? Walve hat Teams 8 zu 6 bis 8 Personen (die Cabale) quer durch die Skills zusammen gebracht, die 4 Tage die Woche, 6 Stunden am Tag über einige Monate Ideen diskutiert, niedergeschrieben, Protoypen entwickelt haben und ihre Ergebnisse zyklisch testen ließen. Nach einem Monaten stand ein Framework von 200 Seiten, mit genügenden Details für das große Bild, aber grob genug für weitere Detailideen.

Eine bedeutende Erkenntnis war, dass nicht alle Mitarbeiten aufgrund ihrer persönlichen Sturktur in den Cabal-Teams mitarbeiten konnten. Aber sobald die Typen zueinander passten, wurden reichlich Ideen entwickelt. Manchmal zwar erst nach zähem Leerlauf, aber deutlich mehr als in der Zeit vorher. Das Wichtigste: jeder hatte eine andere Vorstellung davon, wie das Spiel an bestimmten Stellen aussehen sollte. Aber da Jeder seine Idee einbringen konnte, die Strukturen flach und damit Konfliktpotentiale geringer (es gab Keinen, gegen den man revoltieren konnte), sind schnell die notwendigen Kompromisse erzielt worden. Und da die Ergebnisse an alle kommuniziert wurden, konnten die Teilergebnisse der Einen auch entsprechend von Anderen wieder verwendet werden.

Ken schreibt:” In order for highly hierarchical organizations to be effective, they require one person who understands everyone else’s work at least as well as the individuals doing the work, and other people who are willing to be subordinates yet are still good enough to actually implement the design. Given the complexity of most top game titles, this just isn’t practical — if you were good enough to do the job, why would you want to be a flunky (DE=Lakai)? On the other hand, completely unstructured organizations suffer from lack of information and control — if everyone just does their own thing, the odds that it’ll all fit together in the end are somewhere around zero.” Die Botschaft hier ist: Das Team, zusammengesetzt aus Mitgliedern von unterschiedlichem Skill, hat die Kraft in sich, ein tolles Produkt zu entwickeln. Das ist auch eine der Ziele der SCRUM Methodik (siehe auch den Post von Stefan Zorn: SAPERION benutzt Scrum als Hilfsmittel beim Entwickeln von ECM-Produkten im Rahmen agiler Softwareentwicklung): Die Teams organisieren sich selbst, schätzen gemeinsam die Aufwände ab, strukturieren ihre Arbeit und helfen unter einander bei Problemen. Immer die Priorisierung der Stories im Blick, und durch Retrospektiven am Ende jedes Sprints gewillt, beim nächsten Mal noch besser zu werden, d.h. mehr Story Points dem Product Owner und damit der Firma abliefern zu können.

Die Motivation der Team-Mitglieder steigt durch den erfahrenen Selbstwert im agilen Prozess: “Ich bin nicht der Lakai, der Vorgegebenes abarbeitet, sondern kann mich mit meinen Erfahrungen einbringen und bin damit wichtiger Bestandteil des Gesamtentwicklungsprozesses.”

Um auf  Theo Priestley zurückzukommen: ja, ich kann mir gut vorstellen, dass auch in Teams, die sich die Optimierung ihrer Geschäftsprozesse zur Aufgabe gemacht haben, solche agilen Methoden sehr gut funktionieren sollten (siehe dazu auch meinen Post agiles BPM? Passen Geschäftsprozessmanagement und SCRUM-basierte, agile Entwicklung zusammen?). In der nächsten Woche werden wir, Jakob Freund, Martin Wieschollek und ein neuer Mitstreiter die nächsten Ergebnisse dazu liefern.

Nachtrag vom 08.04.2010

Theo Priestley hat sich nochmals zum Thema social BPM gemeldet, nachdem er mit dem Geschäftsführer Gabe Newell von Valve zu den Erfahrungen mit dam Cabal process direkt gesprochen hat.  Mit der Erfahrung, dass die flache Organisationsstruktur die Mitarbeiter stark motivieren konnte, hat Gabe vermutet, dass Hierarchien dort helfen, wo sehr repetative Prozesse organisiert werden müssen, während dort, wo viel Kreativität gefordert ist, die flachen Organisationen vorteilhafter sind. D.h. die Verantwortung wird dort auf viele Köpfe verteilt und auch von diesen genommen. Siehe dazu auch den Post Auf Ihr Wissen ist wohl auch weiterhin NICHT zu verzichten: Business Experten, Designer, Software-Architekten, Ärzte, …

Post to Twitter Post to Delicious Post to Digg Post to Facebook Post to MySpace

Download PDF
Written by Dr. Martin Bartonitz in: deutsch,general,language | Tags: , , , ,

No Comments »

RSS feed for comments on this post. TrackBack URL

Leave a comment


six + = 14

Theme: TheBuckmaker.com Web Templates | Bankwechsel Umschuldung, Iplexx IT Solutions