„Sorry, aber Agile verbessert Ihre Produkte nicht”
Wir haben bereits den Blog-Beitrag von Jeff Sutherland gepostet, in dem er auf einen Post von Adam Pisoni reagiert, in dem er behauptet, dass Agile Ihre Produkte in Wirklichkeit nicht verbessere. Hier ist nun eben dieser Beitrag von Adam Pisoni, dem Mitbegründer und früherem technischen Direktor von Yammer und Gründer von Responsive.org.
Wenn Sie nicht regelmäßig die Arbeiten von Steve Denning lesen, empfehle ich Ihnen, das zu tun. Er ist einer der besten Autoren, wenn es um die Zukunft der Arbeit geht. In einem Artikel, den er für Forbes geschrieben hat, sagt er, dass die agile Produktentwicklung zum Mainstream geworden sei, wirft aber auch die Frage auf, ob es mittlerweile ebenso eine vergängliche Modeerscheinung geworden ist wie so viele andere Management-Theorien. Sein Fazit ist, dass Agile nicht wirklich eine Modeerscheinung ist, denn
„Agile und Scrum gehen direkt aktuelle Unternehmensfragen an, denen die Initiativen des 20. Jahrhunderts ausgewichen sind. In Agile und Scrum bekommen die Kunden durch den Product Owner eine Stimme und Kompetenzen werden über Autorität gestellt.”
Obwohl ich grundsätzlich mit vielen Dingen in seinem Artikel einverstanden bin, muss ich seinem Fazit widersprechen. Agile hat tatsächlich einen guten Schritt in die richtige Richtung gemacht, jedoch geht mir das nicht weit genug. Bevor es Agile gab, kam es viel zu häufig vor, dass Teams extrem viel Zeit und Ressourcen benötigten, um etwas zu bauen, nur um zum Zeitpunkt der Fertigstellung herauszufinden, dass der Kunde das gar nicht haben wollte.
Agile sollte es vor allem ermöglichen, erfolgreiche Produkte in einer Welt bauen zu können, die sich zu schnell verändert, um vorhersagen zu können, was die Leute wollen und wie man das am besten für sie baut.
Obwohl Agile einer ganzen Generation von Softwareentwicklern beigebracht hat, wie wichtig das Experimentieren und das Feedback der Kunden sind, hat Agile es nicht geschafft, das alte zentralisierte Command-and-Control System im Management zu ändern, was einen großen Teil des Problems darstellt. Auch mit Agile brauchen Entwickler, die zu wenig Einfluss haben und zu wenig Kontext haben, viel zu lange, um Produkte zu entwickeln, die die Kunden eigentlich gar nicht haben wollen. Das hat unzufriedene Kunden, unmotivierte Entwickler und frustrierte Manager zur Folge.
Nur zur Information, von 1995 bis 2014 war ich immer – bis auf eine kurze Unterbrechung nach dem Platzen der ersten Dotcom-Blase – entweder ein Vollzeit-Softwareentwickler oder Teamleiter von Entwicklungsteams. Im Jahr 1997 leitete ich ein Team, das die Wasserfall-Methode nutzte (Vorgänger von Agile). Bei Wasserfall erledigte man alle Design- und Planungsarbeiten vorab und ging davon aus, die Arbeit dann noch aufteilen und fertigstellen zu können.
In 2004 arbeitete ich für ein Unternehmen, dass stark auf Analyse und A/B-Tests vertraute und sogar wöchentliche Releases hatte – mit all dem war man dort seiner Zeit voraus. Ich erinnere mich daran, wie die Leute das erste mal von Scrum sprachen, und ich erinnere mich daran, dass ich eine klare Vorstellung von dem Problem hatte, das ich zu lösen versuchte: schlechtes Management.
Fairerweise muss ich sagen, dass ich das Agile Manifest und seine Prinzipien erneut gelesen habe und jedem einzelnen Punkt zustimme. Sie sind heute noch genauso gut und zutreffend, wie sie es im Jahr 2001 waren, als sie geschrieben wurden. In Agile sollte man etwas iterativ bauen und währenddessen stetig dazulernen, anstatt einen großen Plan zu verfolgen. Außerdem sollte der Kunde im gesamten Prozess ein enger Vertrauter sein, damit man während der gesamten Entwicklungsphase von ihm lernen kann. Da es das Ziel sein sollte, permanent neue Informationen aufzusaugen, sollte man auch davon ausgehen, regelmäßig die Richtung zu ändern.
Bevor es Agile gab, erstellte das Management einen Plan, der genau dokumentierte (vorhersagte), was gebaut werden sollte, wie es gebaut werden sollte und wie lange das dauern würde – wobei Letzteres der wohl wichtigste Teil war. Wie wir wissen, waren diese Pläne kaum vorhersehbar und konnten nur selten eingehalten werden. Das Ergebnis waren unrealistische Erwartungen und Fristen.
Zu allem Übel war es aufgrund der zeitlichen Verzögerung zwischen Fertigstellung des Plans und dem Ausliefern des Produkts sehr wahrscheinlich, dass das Management ohne jegliches Verständnis für die Kosten seine Meinung zum Produkt noch einmal ändern würde. Das verärgerte natürlich viele Entwickler, deren Job es war, den „Plan” auszuführen. Das bedeutete, dass sich die Situation mit unrealistischen Deadlines nur noch verschlimmerte und viele Teams dazu zwang, durch noch mehr Planung spätere Änderungen so gering wie möglich zu halten. Ironischerweise bekamen die Entwicklungsteams durch den Mangel an Transparenz im Entwicklungsprozess mehr Autonomie zu entscheiden, in welcher Reihenfolge sie die Arbeiten erledigen würden, wie sie sie bauen würden, wer das tun würde usw. Natürlich ist die Folge dieser Art von Autonomie und des Mangels and Transparenz oft Misstrauen zwischen Management und Entwicklungsteam. Am Ende war niemand glücklich.
Und dann kam SCRUM. Damit sollte die Transparenz im Prozess erhöht und die Effizienz in der Entwicklung verbessert werden. Wöchentlich konnten Manager entscheiden, welche Stories (bzw. Features) sie als nächstes haben wollten und die Entwickler konnten dann einschätzen, wie viel Zeit und Ressourcen sie dafür benötigen würden. Das Team konnte dann die Gesamtkosten aller priorisierten Stories ermitteln und herausfinden, wie viel dieser Arbeit sie sich für nächsten Sprint vornehmen können.
Scrum hat die Transparenz drastisch erhöht und es den Managern schwerer gemacht, mehr zu fordern, als überhaupt geschafft werden kann. Es wurde auch das Bedürfnis berücksichtigt, Pläne iterativ zu aktualisieren. Durch die erhöhte Transparenz bei Scrum haben die Entwickler jedoch noch weniger Autonomie als zuvor. Die Befugnisse der Entwickler wurden darauf reduziert, festzulegen, wie lange man wohl für etwas brauchen wird, und die nächste Story aus einer Liste auszusuchen, die größtenteils vom Management vorgegeben wird.
Ein Entwickler, der an einer Story arbeitet, hat unter Umständen gar keine Vorstellung von den Zusammenhängen und warum diese Story so wichtig ist oder was überhaupt die Initiative dahinter ist.
Auch wenn Scrum es geschafft hat, impulsive Manager zu zügeln, lief es im Endeffekt doch darauf hinaus, dass mehr Kontrolle über Entwickler und deren Arbeit ausgeübt werden sollte.
Immer noch trifft das Management Entscheidungen, priorisiert die Features und gibt vor, wer in welchem Team an was arbeitet. Mit seinem Fokus auf die Aufwandseinschätzung vorgegebener Arbeiten und wenig Kontext, blickt Scrum auf die Jahrhundertwende zurück, wo Frederick Taylor Fabrikarbeitern detaillierte Anweisungen erteilt hat.
Im Taylorismus geht man davon aus, dass Manager diejenigen sind, die über die Expertise und den Kontext verfügen, um vorgeben zu können, an was gearbeitet werden sollte. Daher war es deren Aufgabe, den Mitarbeitern detaillierte Pläne vorzugeben, damit diese so wenig eigene Entscheidungen wie möglich treffen mussten.
Ziemlich am Ende der Agilen Prinzipien taucht ein recht deplatzierter Grundsatz auf, der von Scrum ignoriert wird:
Die besten Architekturen, Anforderungen und Designs stammen von selbstorganisierten Teams.
Theoretisch ist es möglich, Scrum für die Nachverfolgung von Arbeit in selbstorganisierten Teams einzusetzen, jedoch ist das nicht vorgesehen und geschieht nur äußerst selten. Die meisten Bücher über Scrum gehen das aus der Perspektive des Top-Down-Managements an und nicht durch Selbstorganisation.
Agile war ein wichtiger Schritt, um zu erkennen, wie wichtig das Testen und das iterative Arbeiten auf der Basis von Kundenfeedback sind. Zum Großteil ist es aber auf gesteigerte Effizienz und Kontrolle vs. Empowerment beziehungsweise selbstorganisierte Teams ausgerichtet. Einer der Autoren des Agilen Manifests, Andy Hunt, sieht das auch so.
Natürlich kann man behaupten, dass Agile nicht das Problem ist, sondern Methoden wie Scrum. Dieser feine Unterschied geht aber verloren, da Scrum und Agile schon fast zu Synonymen geworden sind. Als Agile bekannter wurde, wurde es leider durch traditionelle Command-and-Control Modelle zweckentfremdet, woraus Methoden wie Scrum entstanden.
Was ist die Alternative? Schauen Sie sich doch mal die Entwicklungsmethoden von Spotify oder die Strukturen von Yammer an. Anstatt einzelnen Personen Arbeit aufzuhalsen, geben Sie Teams mehr Autonomie, um entscheiden zu können, was sie bauen wollen und wie. Diese Teams bestehen außerdem aus Personen aus den unterschiedlichsten Disziplinen, um sicherzustellen, dass sie alles Notwendige erledigen können, ohne auf die Erlaubnis oder Unterstützung Anderer warten zu müssen.
Egal ob Sie zur Zeit in Ihrer Organisation mit Scrum arbeiten oder nicht – wenn Sie das Gefühl haben, zu langsam voranzukommen und nicht das zu bauen, was Ihre Kunden haben wollen, gibt es verschiedene Möglichkeiten, mit neuen Modellen zu experimentieren, ohne gleich alles auf einmal ändern zu müssen.
Wählen Sie ein Projekt und stellen Sie ein kleines, engagiertes Team mit Leuten zusammen, die alle nötigen Fähigkeiten haben, auch wenn diese Leute unterschiedliche Manager haben. Stellen Sie Ihnen das Problem vor und geben Sie Ihnen die Möglichkeit, es so zu lösen, wie sie es für richtig halten.
Idealerweise ist dieses Projekt kurz genug, um schnell feststellen zu können, ob das Experiment funktioniert. Wenn Sie dem Team nur ungern diese Eigenverantwortung überlassen, haben Sie entweder die falschen Leuten ausgewählt, oder das Problem liegt vielleicht bei Ihnen selbst. Es ein „Experiment” zu nennen, kann Ihnen dabei helfen, Ihre Idee zu verkaufen. Sehr wahrscheinlich werden Sie herausfinden, dass kleine, engagierte und funktionsübergreifende Expertenteams extrem viel in sehr kurzer Zeit schaffen können.
Die nächste Herausforderung ist, herauszufinden, wie man das auf einen größeren Umfang übertragen kann, falls es funktionieren sollte. Dafür benötigt man normalerweise neue Lösungen, was zu neuen Problemen führt, wofür man wieder neue Lösungen braucht. Es ist nicht einfach, aber es lohnt sich.
Sie werden merken, dass es funktioniert, wenn Ihr Team den Kunden schneller mehr neue Ideen vorstellen kann als zuvor. Das ist das Ziel.
Autonomie erfordert Vertrauen und das wiederum erfordert gemeinsamen Kontext. Das ist der Grund, warum diese neueren Modelle von der vollständigen Transparenz abhängig sind, wenn jeder auf dem Laufenden gehalten werden soll. Bei Yammer haben wir kurzlebige Projektteams, so dass die Leute mehr Möglichkeiten erhalten, tatsächlich zu arbeiten und von den unterschiedlichsten anderen Leuten zu lernen – aber das ist nur eine Möglichkeit, wie man das angehen kann.
Es reicht nicht aus, wenn das Management nur das Sprachrohr der Kunden ist. Entwickler und Designer müssen selbst die Bedürfnisse und Ziele der Leute verstehen und verinnerlichen, für die sie etwas bauen.
Agile war ein wichtiger Schritt weg von den Organisationen und Methoden des Industriezeitalters. Wenn Sie jedoch eine Organisation für das 21. Jahrhundert erschaffen wollen, werden Sie über Agile hinaus auf neuere Modelle schauen müssen, die Autorität verteilen, selbstorganisiert sind und Ihre Kunden, Partner und Mitarbeiter wirklich dazu einladen „Owner” des Prozesses zu werden.
Dieser Text stammt aus dem [Blog von First Round]8https://firstround.com/review/im-sorry-but-agile-wont-fix-your-products/ "Agile Produkte") und wurde von uns ins Deutsche übersetzt.
Für Scrum Master bieten wir folgende Trainings und kostenlosen Fortbildungsmöglichkeiten: