Wenn man aus einer Arbeitsumgebung mit klassischen Strukturen, Hierarchien und einer klassischen Arbeitsweise kommt, mag vieles, was bei uns in der Qudosoft passiert, erst mal komisch erscheinen. Aus der Ferne betrachtet wirken wir möglicherweise wie ein chaotischer Haufen “junger Wilder”, die tun und lassen können, was sie wollen und viel mehr mit sich selbst und ihrem Traumarbeitsplatz beschäftigt sind, als damit wirklich zu arbeiten.

In diesem Blogpost möchte ich mit einigen gängigen Missverständnissen rund um das agile Arbeiten aufräumen.

Was agiles Arbeiten ist

Agilität zeigt vor allem Möglichkeiten auf, wie man einem riesigen Problem entgegenwirken kann, das vor allem zu Zeiten der Entstehung des “Agilen Manifests” (2001) in der Softwareentwicklung herrschte und das bis heute noch immer vielen Unternehmen (nicht nur in der IT-Branche) Sorgen bereitet. Ich möchte es hier kurz beispielhaft skizzieren:

Ein Unternehmen stellt fest, dass es ein neues Produkt benötigt und startet ein Projekt zur Entwicklung und Einführung dieses Produkts nach dem sogenannten Wasserfallmodell: Die “Planungsabteilung” setzt sich zusammen und arbeitet über Wochen hinweg ein 70 Seiten dickes Lastenheft mit Spezifikationen aus, in dem genau beschrieben steht, wie der Dienstleister das Produkt umzusetzen hat. Dieses Heft wird dem Vertrieb des Dienstleisters übergeben, welcher die Anforderungen sichtet und ein Angebot (Zeit und Geld) macht. Nach einigem Hin und Her haben sich die beiden Parteien geeinigt und das Projekt wird gestartet. Die Anforderungen werden dem Entwicklungsteam übergeben, welches mit der Umsetzung beginnt.

Folgende Probleme treten mit einiger Wahrscheinlichkeit auf:

• Das Entwicklungsteam missversteht Anforderungen
• Nicht alles, was in dem Dokument steht, ist korrekt, aktuell, oder vollständig
• Nach Monaten meldet sich der Dienstleister stolz beim Kunden und verkündet, dass das Produkt nun fertig ist
• Der Kunde ist schockiert über das, was entstanden ist und versucht nun alles zu tun, um die Schuld dem Dienstleister zuzuschieben
• Der Dienstleister versucht nun alles zu tun, um um die Schuld dem Kunden zuzuschieben
• Es wird ungemütlich und nach einigen Gesprächen zur Schadensbegrenzung wird am Produkt noch etwas nachgearbeitet, sodass der Kunde mit dem Gelieferten halbwegs leben kann
• Bis zur ersten Benutzung des Produkts sind viele Monate vergangen, es wurde sehr viel Geld ausgegeben und alle Beteiligten sind am Schluss unzufrieden
• Wenn das Produkt in Benutzung kommt, fallen noch 70 Fehler in der Software auf, die nur mühselig behoben werden können (es gibt übrigens IMMER Fehler in JEDER Software! Wer etwas anderes behauptet, lügt. Je früher man sie erkennt, desto einfacher kann man sie beheben.)
• Inszwischen hat sich der Markt leicht gewandelt, im Unternehmen gibt es jetzt außerdem einen anderen Fokus, das Produkt ist in seinem Kontext nicht mehr passend und zeitgemäß

Nun könnte man sagen, dass die Entwickler doof sind und die Planer unsauber gearbeitet haben und man könnte mit noch längeren Planungsphasen und noch intensiveren Verhandlungen dagegen ankämpfen. Aber würde sich dadurch wirklich etwas ändern?

Die Alternative

Aus solchen schmerzhaften Erfahrungen heraus fand sich eine Gruppe Softwareentwickler zusammen, um gemeinsam einen Vorschlag zu entwickeln, wie dieses strukturelle Problem gelöst werden kann. Ich möchte hier nur kurz die Kernpunkte aus meiner Sicht aufzeigen, um diesen Blogpost nicht noch mehr in die Länge zu ziehen.

• Kunde und Dienstleister sollten ihre Zeit nicht in Vertragsverhandlungen stecken, sondern einfach direkt zusammenarbeiten
• Anstatt eisern einem Plan zu folgen, sollten alle Beteiligten lieber akzeptieren, dass die Situation und die Umwelt sich permanent im Wandel befinden und auf sich ändernde Anforderungen reagieren
• Es ist wichtiger, auf die Menschen einzugehen, die an einem Projekt beteiligt sind und diese bei Bedarf in Kontakt zu bringen als sich an festgelegte Prozesse zu halten oder bspw. an Richtlinien, wer mit wem über welche Wege kommunizieren darf
• Es ist besser eine Software in Betrieb zu haben als sich in Dokumenten und Dokumentationen zu verlieren

Neben diesen vier Kernwerten des “Agilen Manifests” gibt es auch noch die 12 Prinzipien der agilen Softwareentwicklung, die man hier nachlesen kann.

Was agiles Arbeiten NICHT ist

Der/die geneigte Leser/in hat in dem Abschnitt oben eventuell bemerkt, dass kein Wort über Arbeitszeiten oder Kickertische gefallen ist. Wichtig beim Verständnis des agilen Arbeitens ist, dass man es nicht mit Dingen wie flachen Hierarchien, Selbstorganisation der Firma und flexiblen Arbeitszeiten verwechselt.

Das heißt aber auch nicht, dass es das nicht ist. Denn die agile Arbeitsweise ist eng verknüpft mit einem Menschenbild und einem Verständnis von Arbeit, das die Bedürfnisse der beteiligten Individuen anerkennt anstatt diese lediglich als gesichtslose Erbringer von Arbeitsleistung zu sehen. Es geht beispielsweise darum, dass unterschiedliche Menschen einen unterschiedlichen Arbeitsrhythmus haben. So ist ein Kollege jeden Tag pünktlich um 8 Uhr an seinem Schreibtisch, während ein anderer des Öfteren erst um halb 11 da ist, dafür aber auch mal gerne bis spät abends im Büro ist. Den Anspruch, möglichst gute Arbeit abzuliefern und dafür ihr bestes zu geben, haben beide.

Und wie ist das mit dem Chaos? Keine Hierarchie heißt keine Verantwortung? Ich persönlich würde eher das Gegenteil behaupten. Die Tatsache, dass es in der Qudosoft abgesehen von unserem Geschäftsführer keine Hierarchien gibt, hat auf uns den Effekt, dass wir viel stärker in alle Entscheidungen einbezogen sind und uns wirklich aktiv darum kümmern müssen, dass Dinge vorangehen. Wir müssen Entscheidungen treffen, auch wenn es meist viel einfacher wäre, das an eine übergeordnete Stelle oder Person abzuschieben. Je schwerwiegender und schwieriger solch eine Entscheidung ist, desto mehr wünscht man sich, dass man diese Verantwortung jemand anderem überlassen kann.

Geht dann wirklich mal etwas in die Hose, müssen wir auch die Konsequenzen tragen. Wir können uns dann auch nicht herausreden mit „mein doofer Vorgesetzter hat mal wieder eine Fehlentscheidung getroffen, obwohl ich es selbst viel besser gewusst hätte“. Um in solchen unangenehmen Situationen nicht demotiviert oder übervorsichtig zu werden, ist es außerdem wichtig, Rückhalt von unserem Chef zu bekommen. Dieser ist nämlich fest der Überzeugung, dass jeder Mensch Fehler macht und das völlig in Ordnung ist. Solange man dann auch die Verantwortung übernimmt und sich darum kümmert, die Probleme aus der Welt zu schaffen und/oder dafür zu sorgen, dass so etwas möglichst nicht wieder vorkommt. Das Wichtige ist, daraus zu lernen. In solchen Fällen können wir uns außerdem auch zu 100% auf den Rückhalt und die Unterstützung unserer Kolleginnen und Kollegen zählen. Das ist ein wirklich schönes Gefühl.

Fazit

Ich hoffe, ich konnte in diesem Beitrag mit einigen Vorurteilen aufräumen. Ja, so etwas wie “die dürfen zusammen im Hof grillen und Bier trinken” und “die schießen mit Gummipfeilen aufeinander und haben nen Kicker” verbreitet sich als Information sicherlich eher auf dem Flur als “die haben nach ihrem 2-Wochen-Sprint wieder ein Inkrement ihres Softwareprodukts ausgeliefert, das zwei neue Features und drei Fehlerbehebungen beinhaltet”.  Wir sind wirklich ernsthaft daran interessiert, unseren Job gut zu machen und tolle Produkte zu entwickeln.

Und um das noch einmal zu betonen: Ein Unternehmen kann agil sein und trotzdem starke Hierarchien und feste Arbeitszeiten haben. Agilität ist auch bei Weitem nicht die Wunderwaffe, die man irgendwo draufwirft und dann sind alle plötzlich glücklich, machen alles richtig und alle Projekte gelingen. Es ist auch leider sehr einfach, Dingen den Stempel “agil” zu geben und in Wirklichkeit nur wenige Teilaspekte und Methoden zu benutzen, im Kern aber dem klassischen Wasserfallmodell zu folgen.

Agiles Arbeiten ist vor allem Einstellungssache und erfordert ein Umdenken in den Köpfen aller Beteiligten. Es bedarf großer Transparenz und Vertrauen zwischen den Mitarbeitern, ganz besonders aber auch von Vorgesetzten den Mitarbeitern gegenüber. Und eine regelmäßige, offene Kommunikation zwischen allen Beteiligten an einem Projekt ist absolut essenziell. Ich persönlich finde es jedenfalls großartig, muss mich aber auch immer wieder bewusst damit auseinandersetzen und hinterfragen, was ich wie tue. Das ist anstrengend. Aber es zahlt sich meiner Meinung nach aus.