Yammer: Traditionelle Struktur von Entwicklungsunternehmen ist tot
Kris Gale, Vice President of Engineering bei Yammer, behauptet, kleine Teams seien der Schlüssel zur schnellen Produktentwicklung in größeren Unternehmen. Er erforscht die Feinheiten des Aufbaus von Organisationen in der Produktentwicklung und erklärt, wie das bewusste Treffen von Entscheidungen während einer Wachstumsphase sicherstellen kann, dass die Dinge nicht verloren gehen, die ein Start-up einzigartig und besonders machen. Letzten Endes ist es die Aufgabe eines technischen Direktors, zu überlegen, wie die Softwareentwicklung organisiert und optimiert werden kann.
Kleinere Teams liefern schneller
Anfänglich verfolgte das Yammer-Team einen recht einfachen Ansatz. Man konzentrierte sich hauptsächlich auf das Produkt an sich und machte sich keine großen Gedanken um die Personalbesetzung während der Vergrößerung der Organisation. Als das Unternehmen immer weiter wuchs, bemerkten sie jedoch, dass die marginale Steigerung der Produktivität bei jedem neuen Entwickler aufgrund eines größeren Aufwands immer geringer wurde.
Gleichzeitig wurde dem Rest der Welt klar, dass Yammer dabei war, etwas Großes zu erschaffen. Überall versuchten Start-ups, das Produkt zu kopieren, und sogar große Unternehmen brachten Konkurrenzprodukte auf den Markt. Bei Yammer war man sich bewusst, dass es nur ein einziges marktbeherrschendes Unternehmen geben konnte und dass das ein anderes sein würde, sollten sie nicht agil genug sein. Moderne Webapplikationen müssen agil und anpassungsfähig sein.
Um schneller etwas ausliefern zu können, übernahm man bei Yammer den Ansatz, mit kleinen Teams zu arbeiten. Aber das bedeutet mehr, als nur ein Unternehmen in kleine Teams aufzuteilen. Wenn diese Teams in irgendeiner Weise bei der Implementierung von Code eingeschränkt sind, sind sie nutzlos. Sie müssen die Freiheit haben, Dinge auch außerhalb der Organisation erledigen zu können.
Spezialisierung in kleinen Teams
Ganz am Anfang wurden neue Features bei Yammer je nach Spezialisierung unter den drei Entwicklern aufgeteilt. Dabei ging es nicht besonders streng zu. Wenn es also viel Arbeit mit Rails gab, konnte Gale ein wenig aushelfen, auch wenn Rails nicht seine Stärke war. Das Ziel sollte es sein, ähnliche Gruppen zu erschaffen, die klein und spezialisiert sind, aber keine reinen Silos darstellen, denn unterschiedliche Probleme erfordern unterschiedliche Kompetenzen (und unterschiedliche Erfahrungen).
Serielle Prozesse & große Technologieunternehmen
Dieser Ansatz funktionierte wirklich gut mit drei Entwicklern. Als das Yammer-Team aber größer wurde, bewegte man sich zu einem eher traditionellen Modell für Organisationen in der Softwareentwicklung, in dem es eine Aufteilung nach fachlichen Fähigkeiten gab. Es gab also ein Back-end-Team, ein Front-end-Team, ein Mobile-Team usw. Am Ende des Jahres 2010 arbeiteten nicht mehr nur drei Entwickler an den Features, sondern ungefähr 30. Aber waren sie auch zehn mal schneller? Nein.
Laut dem Amdahlschen Gesetz über die parallele Ausführung von Programmen wird der Geschwindigkeitszuwachs eines Programms bei der Nutzung multipler Prozessoren vor allem durch den sequentiellen Anteil des Problems beschränkt [da sich dessen Ausführungszeit nicht durch Parallelisierung verringern lässt]. Bspl.: Wenn Sie ein Programm haben, von dem Sie nur die Hälfte parallelisieren können, könnten Sie die Geschwindigkeit auch mit 100 Prozessoren nur verdoppeln. Auch mit weiteren 100 Prozessoren würde sich daran nicht viel ändern. Die Zeit für den seriellen Teil des Gesamtaufwandes bleibt also immer gleich.
Leute gehen fälschlicherweise davon aus, dass bei der Softwareentwicklung Code anhand von Spezifikationen geschrieben wird – das stimmt aber nicht. Die technischen Entscheidungen sind auch sehr wichtig – und niemand kann ein Entwicklungsunternehmen bauen, wenn er das glaubt.
Bei einer typischen mittelgroßen bis großen Softwareentwicklungsorganisation hat man vielleicht ein Front-end-Team, ein Back-end-Team und eventuell ein Middleware-Team. Diese Teams haben ihre eigene Codebasis und einen eigenen Manager, der einem Vorgesetzten Bericht erstattet. Es geht darum, dass die Organisation und die Architektur des Codes zueinander passen sollten.
Bevor Führungskräfte Arbeit aufteilen und delegieren können, müssen sie erst entscheiden, was genau gebaut werden soll. Dann kommen solche Fragen auf: „Woran wird das Back-end-Team arbeiten?” und „Wie lässt sich das mit dem Front-end-Team verbinden?”
Wenn die Arbeiten allerdings, wie gerade beschrieben, von den oberen Führungsetagen eingeteilt und delegiert werden, läuft es falsch. Denken Sie mal drüber nach. Wenn nämlich derjenige, der den Code implementieren soll, ein Problem bei den Spezifikationen findet, muss er oder sie einen Verbesserungsvorschlag nach ganz oben in die Managementebene einreichen, der dann wieder nach unten zurückgereicht werden muss. Dieser Prozess bremst ein Produkt aus und bringt es letzten Endes zum Stillstand. Außerdem sehen die Entwickler in anderen Teilen der Organisation dies als Störung an, da sie nicht eng mit dem Entwickler zusammenarbeiten, der die Änderung vorgeschlagen hat. Sie verstehen einfach nicht den Grund für die Änderung.
Das wollte man bei Yammer nicht.
Das Management sollte keine Entwicklungsentscheidung treffen
Man sollte immer Leute einstellen, die besser und klüger sind als man selbst. Wenn man diesen Rat befolgt, sollte man dann nicht eben diesen Leuten Entscheidungen zutrauen, die man sonst selbst hätte treffen müssen? Im Endeffekt ist es die Aufgabe des technischen Leiters, eine Organisation aufzubauen und zu fördern. Sie müssen sich vermutlich schneller als gedacht nicht mehr nur auf das Schreiben des Codes konzentrieren, sondern Ihren Fokus auf die Organisation an sich legen.
Ich denke nicht, dass Sie ein Produkt bauen sollten. Ich denke, Sie sollten eine Organisation bauen, die ein Produkt baut.
Seien Sie äußerst vorsichtig damit, Managern bei Entwicklungsentscheidungen zu vertrauen. Tatsächlich sollten Sie all diese Entscheidungen nach unten an die Leute weitergeben, die sie auch umsetzen müssen. Es ist ein eindeutiges Warnsignal, wenn Manager die einzigen sind, die für mehr als 30 – 40 Leute Entscheidungen treffen.
Wie sollte man nun Features bauen?
Wenn bei Yammer ein Feature gebaut wird, soll immer eine der drei Hauptmetriken verbessert werden:
- Viralität
- Engagement
- Monetarisierung
Grundsätzlich möchte man bei Yammer Features bauen, die Kunden anziehen, halten und von ihnen gekauft werden. Auch wenn Ihre wichtigsten Kennzahlen anders aussehen, sollten auch Sie definitiv anfangen, einige Hauptziele in der gesamten Organisation zu kommunizieren. Andernfalls können Sie nicht alle Mitarbeiter Ihres Unternehmens befähigen, gute Entscheidungen zu treffen.
In traditionellen Organisationen schreiben Projektmanager die Spezifikationen nach ihren Ideen. Bei Yammer ist das anders. Statt eine starre Spezifikation darüber zu schreiben, was gebaut werden soll, wird eine Spezifikation als Ausgangspunkt für ein funktionsübergreifendes Team gesehen, welches die Spezifikation dann ausarbeiten kann. Wenn die Spezifikation schon zu lang ist bzw. zu viel vorgeschrieben wird, sollten Sie vorsichtig sein. Die betroffenen Entwickler sollten die Entscheidungen für ein Feature verstehen können, damit sie den Code auf die effizienteste und effektivste Weise implementieren können.
Die „Zwei-und-Zehn”-Regel
Die wichtigste Faustregel bei Yammer lautet: Zwei bis zehn Leute, zwei bis zehn Wochen. Es gibt also eigentlich keine Projekte, die größer oder komplizierter sind. Es gibt ein nicht lineares Verhältnis zwischen der Komplexität eines Projekts und der abschließenden Integrationsphase am Ende. Bei allem, was länger als zehn Wochen dauert, wird die Dauer der abschließenden Phase unverhältnismäßig.
Wenn man sich an diese Regel hält, zwingt es einen außerdem dazu, häufiger zu releasen, Annahmen zu testen und sich nicht zu sehr mit Fehlern zu beschäftigen. Es ist ähnlich wie beim Lean Startup und wenn Sie es ausprobieren möchten, müssen Sie es in Ihrem Unternehmen kodifizieren.
Sie müssen einen Sinn für Dringlichkeit entwickeln. Sehr lange Projekte sind oft Schuld daran, wenn Entwickler das eigentliche Ziel aus den Augen verlieren. Es ist wie beim Wandern. Wenn Sie losgehen, sind Sie noch voller Energie, freuen sich auf die Wanderung und kommen ziemlich schnell voran. Mit der Zeit wird Ihr Körper aber müde und Sie können nicht mehr erkennen, wo Sie angefangen haben oder wohin Sie gehen. Wenn Sie an diesem Punkt angekommen sind, brauchen Sie einen starken Willen, um sich selbst zum Weitermachen zu motivieren. Unglücklicherweise haben viele Organisationen ihre Entwickler bei den meisten ihrer Aufgaben genau in diese mittlere Phase gesteckt.
Gegen Ende der Wanderung können Sie jedoch wieder Ihr Ziel erkennen und die Motivation kehrt zurück. Mit jedem Schritt kommt das Ziel ein wenig näher. Es ist wichtig, dass sich Ihre Entwickler in dieser Phase befinden, wo sie ihren Fortschritt messen und visualisieren können. Nur so kann man Dringlichkeit und Arbeitsmoral aufrecht erhalten.
Code Ownership
Vorsicht bei Code Ownership – wenn Leute ihre eigene Codebasis haben, kann das viele falsche Anreize schaffen, die man vermeiden sollte. Bei Yammer ist die Organisation in Fachbereiche unterteilt. Entwickler sind schließlich wirklich klug und motiviert und wenn sie sich am Unternehmenziel orientieren können, können sie erstaunliche Dinge leisten (und das sogar völlig selbstständig).
Festlegen, wie ein arbeitendes Team aussieht
Bevor ein Produktteam für ein Feature erstellt wird, schaut man sich die Spezifikation genau an. Genauer gesagt versuchen man, den Aufwand für das Feature einzuschätzen.
Nehmen wir Produkt X. Es ist ein imaginäres Feature, das die Viralität steigert, indem es es einem möglich macht, Freunde während des Anmeldevorgangs einzuladen. Bei diesem Beispiel liegt der Schwerpunkt auf dem Front-End, was bedeutet, dass man eventuell zwei Leute für das User Interface braucht. Und da man wahrscheinlich auch etwas im Anmeldevorgang ändern muss, braucht man sicherlich auch jemanden aus dem Rails-Team, um den Code dafür zu schreiben.
Sobald das Produktteam sich auf eine Priorität für das Projekt geeinigt hat, muss man nur noch darauf warten, dass die Entwickler zur Verfügung stehen (in diesem Fall zwei für das Front-End und einer für Rails). Bei Yammer gibt es ein großes Whiteboard mit Raster, das „Big Board” genannt wird. Auf der einen Seite werden die Projekte aufgelistet, auf der anderen alle Entwickler, die an Features arbeiten. Natürlich kann ein Entwickler zur gleichen Zeit immer nur an einem Projekt arbeiten. Das Big Board schafft außerdem eine gute Transparenz der Prioritäten. Alles, was während der Entwicklung erledigt wird, wird dort erwähnt und so kann der Geschäftsführer jederzeit einen Blick darauf werfen und feststellen: „Daran arbeiten die Entwickler also gerade.”
Wenn Sie es schaffen, den Fokus für ein einziges Projekt zu sichern, wird Ihr Unternehmen schon wesentlich schneller werden. Es ist erstaunlich, dass das niemand in seiner Organisation zur Bedingung macht – dabei weiß im Grunde jeder, wie teuer ein Kontextwechsel ist. Mit einem absoluten Fokus baut man eine Sache, liefert sie aus und kann sich dann etwas anderem widmen.
Aber wer kümmert sich dann um Bugs?
Wenn alle an Features arbeiten, wer kümmert sich dann um Bugs? Bei Yammer gibt es einfach mehrere funktionsübergreifende Teams. Man nimmt ein paar Leute aus dem Rails-Team, dem Front-end-Team und dem Mobile-Team etc. und sagt ihnen: „Euer Job ist es, die Bugs zu beheben und unsere Liste abzuarbeiten.” Das ist nur eine vorübergehende Angelegenheit (wie alle projekt-orientierten Gruppen) und die Leute wechseln sich damit ab. Diese Organisationsstruktur macht es möglich, sich um den Support zu kümmern, ohne die Entwicklung der Features zu beeinträchtigen.
Außerdem entsteht so keine zweite Klasse von Entwicklern. Hier werden nicht einfach nur ein paar Junior-Entwickler abgestellt, um Bugs zu fixen; Senior-Entwickler werden ebenso einbezogen. Und das ist gewollt, denn wenn Bugs behoben werden sollen, will man sie nicht überdecken, sondern die Ursache beheben. Erfahreneren Leuten sollte es erlaubt sein, gegebenenfalls den Code zu refaktorieren.Dieses System führt außerdem zu einer Feedback-Schleife zwischen denjenigen, die die Features bauen, und denen, die die Bugs beheben. Wenn man die Häufigkeit und Art der Bugs kennt, sind das wichtige Informationen für Entscheidungen, die die Produktentwicklung vorantreiben können.
Dieser Text stammt aus dem Blog von First Round und wurde von uns ins Deutsche übersetzt.
Lerne zu Arbeiten, wie die funktionsübergreifenden Teams bei Yammer!
Bist du Entwickler und möchtest mehr über deine Rolle im Scrum Team und deinen Aufgaben erfahren, dann schau dir unsere Deep Dives und Vertiefungskurse zum Certified Scrum Developer an!
Für Scrum Master bieten wir folgende Trainings und kostenlosen Fortbildungsmöglichkeiten:
Wenn du tiefer in die Materie des Agile Leaderships einsteigen willst, empfehlen wir dir unsere Führungskräfte-Zertifizierung zum Agile Leader.