Spotify macht es schon so

„Ab heute arbeiten wir in einer agilen Organisation wie Spotify. Hierzu habe ich folgende Matrix-Organisation vorbereitet“.  Hast Du auch solch einen Satz schon einmal gehört oder ist Deine Firma agilisiert worden, ohne dass Du wusstest warum?

Das sich die Produkt- Softwareentwicklung nach agilen Vorgehen wie z.B. SCRUM oder Kanban orientiert, ist (oder sollte für die Meisten) bislang ein alter Hut sein. Nur warum? Da mich das Thema agile Software- bzw. Produktentwicklung seit ca. 2010 nicht mehr los lässt, ist hierzu ein Artikel fast unumgänglich und liegt mir schon länger am Herzen.

In diesem Artikel geht es nicht um die Scrum Basics oder agile Software-Produktentwicklung an sich,  sondern um das nächste Level. Jetzt agilisieren wir das ganze Unternehmen. Doch nun der Reihe nach.

Wer schlecht kopiert, hat schon verloren

Angesteckt von anderen Unternehmen oder anderen Bereichen im selben Unternehmen die bereits agilisiert haben, will man das nun auch. Doch wie fangen wir das an? Ich glaube, die ungeschickteste Variante ist, einfach ein vermeintliches Erfolgsrezept zu kopieren. Das Motto: „Das hat bei z.B. Spotify funktioniert, dass klappt bei uns auch“, halte ich für den falschen Ansatz (Spotify dient hier nur als Beispiel-Referenz. Mir liegt es fern die Spotify-Vorgehensmethode schlecht zu reden. Ganz im Gegenteil).

Wie transformieren wir uns aber nun? Ich glaube, dass die Frage selbst schon der falsche Ansatz ist. Am Beispiel von Simon  Sinek’s Golden Circle, soll man immer mit dem  „Why“ starten und nicht mit dem „How“ oder „What“. Ziel ist es als erstes das Problem zu erkennen und nicht eine Umsetzung von etwas zu starten, ohne zu wissen was das eigentliche Problem/Ursache ist. Das gilt im übrigen aus meiner Sicht sowohl für eine Re-Organisation bzw. agile Transformation, als auch für die Produktentwicklung an sich. Was bringt mir eine Lösung, wenn ich kein Problem dazu habe? Was soll ich beispielsweise mit einem Spitzer anfangen, wenn ich keine stumpfen Bleistifte habe 😉

Wieso, weshalb, warum? Wer nicht fragt bleibt…

Zurück zum Thema… Sollte nicht ein gewisser Änderungsbedarf bereits vorhanden sein, würde ich vermuten, dass die agile Transformation von Beginn an zum Scheitern verurteilt ist. Folgende Fragen sollte man sich vorab stellen:

  • Wie komme ich zu der Annahme, dass eine agile Transformation erfolgen sollte?
  • Welche nüchternen/unvoreingenommenen Probleme bzw. welchen Optimierungsbedarf habe ich?
  • Habe ich mein Team/Abteilung etc. bereits interviewt, welche Probleme sie alle sehen bzw. wahrnehmen?
  • Haben die diversen Organisationseinheiten selbst erkannt, dass sie  Optimierungsbedarf haben?
  • Was sagen die Lessons Learned Erkenntnisse der vergangenen Produkt- und Softwareentwicklungsprojekte?
  • Welche übergreifenden Probleme und Chancen berichten die Mitarbeiter selbst?
  • Gibt es überhaupt einen Bedarf für Veränderungen?

Nur weil man im Internet das Spotify Modell gefunden hat, von Bereichen gehört hat die sich in Richtung agile transformiert haben oder man einschlägige Literatur gelesen die agile Entwicklung empfehlen, löst man noch kein Problem. Die Frage nach dem „Warum“ ist nach wie vor offen.

Wir setzen auf agil aus Überzeugung

Anhand dem einfachen Zyklus „Build >> Measure >> Learn“ aus u.A. dem Buch „Lean Startup“ von Eric Ries  sollten ein paar Iterationen der bisherigen Produktentwicklung betrachtet worden sein, bevor man eine Transformation irgendwohin anvisiert. D.h. bevor man etwas verbessert, muss man erstmal den Status-Quo kennen und einen Bedarf für Verändeurngen erkannt haben.

Warum sollte ich eine Säge schärfen, wenn sie jetzt noch hervorragend sägt?

Im Gegensatz zu einem mittelständischen oder großen Unternehmen, setzen Start-Ups, je nach Unternehmensziel, möglicherweise direkt auf agile Prinzipien. Dies kommt ggf. daher, dass die Gründer bereits Erfahrungen aus anderen Unternehmen mitbringen, und bereits wissen, wie man es nicht machen sollte.

Die richtigen Gründe für eine Agilisierung

Aber was genau sind die Erkenntnisse der vergangenen Projekte? Aus meiner Sicht sind folgende Erkenntnisse/Aussagen, mögliche Impulse für eine weitere Analyse auf dem Weg zu einer agilen Transformation:

  • Die letzten Projekte wurden zum größten Teil mit starker Verzögerung, erst einige Monate später als geplant fertiggestellt. Die resultierende Software/das Produkt wurde somit verspätet gelauncht
  • Die Produkte hatten eine unzureichende Qualität. Selbst nach einer langen Qualitätssicherungsphase, waren noch zu viele Bugs in der Software
  • Nur ein kleiner Teil der Projektmitarbeiter arbeitet mit Herzblut an dem Produkt. Diese haben das Gefühl, kontinuierlich das ganze Team begeistern zu müssen.
  • Es denken nicht Alle Ende-zu-Ende. D.h. nicht Jeder hat komplexe Strukturen im Kopf und kann die Probleme erkenne, die auf das Projekt zukommen. Wohingegen Andere mit einer „Dienst nach Vorschrift Attitude“ zwar persönlich recht ausgeglichen sind, aber möglicherweise nicht all ihre Talente/Fähigkeiten einbringen
  • Das Endprodukt entspricht nicht dem, was der Kunde verlangt bzw. erwarten würde. Evtl. wurde direkt das „What“ implementiert ohne sich mit dem „Why“ zu beschäftigen

Die Liste könnte ich noch um einige Punkte ergänzen. Aber ich hoffe die Logik der Aufzählung und die Sichtweise ist deutlich geworden.

Viele Töne machen die Musik

Um den hier aufgelisteten Punkten Abhilfe zu schaffen, würde es möglicherweise genügen, nur das jeweilige Projekt der Produkt- bzw. Softwareentwicklung zu transformieren. Einige bis alle der o.g. Feststellungen könnten somit auch positiv optimiert werden. Z.B. halte ich es für sehr wahrscheinlich, dass das Team mit Herzblut an einem Produkt arbeitet, wenn alle relevanten Personen auch tatsächlich persönlich zusammen interagieren. Im besten Fall arbeiten alle notwendigen Personen z.B. der Product Owner, ScrumMaster, Entwickler, Software-Tester, Designer etc. in einem Raum zusammen. Nur so können aus meiner Sicht Effizienzen entstehen. Absprachen werden optimiert, Erkenntnisse sofort geteilt und Probleme mehr oder weniger sofort gelöst werden. Es entsteht eine echte interdisziplinäre Zusammenarbeit. Der Product Owner fängt an sich für die Probleme bei der Softwareentwicklung zu interessieren, der Designer bekommt direkt Feedback wie aufwändig die Umsetzung seiner Visualisierungen sind und der Software-Tester kann schon vor dem eigentlichen Test seine Testfälle schreiben, da er weiß was nach/in dem Sprint zu testen ist.

Aus Erfahrungen ist mir durchaus bewusst, dass ein Großraumbüro nicht für Jedermann geeignet ist. Der Arbeitsraum sollte daher durchaus kreativ und mit genügend Raum für Besprchungen eingerichtet werden. Auch sollten Räume zur Verfügung stehen, in die man sich zurückziehen kann, sollte man beispielsweise Ruhe zur Konzentration benötigen.

Agil braucht kein Organigramm, sondern kulturellen Nährboden

Mit einem agilen Vorgehen hat eine klassische tayloristische Vorgehensweise, bei welchem klare Arbeitsschritte nacheinander prozessiert werden, nichts zu tun. Dieses Vorgehen, bei dem jeder nur seinen Arbeitsschritt ausführt und seine Ergebnisse an einen anderen übergibt ist überholt.

Ein Team sollte eine gemeinsame Vision haben. Solch eine Vision sollte auch einer agilen Transformation unterliegen. Wenn man als Team eine gemeinsame Vision hat und alle darauf „eingeschworen“ sind, sind auch alle gemeinsam für das Endergebnis verantwortlich. Wem Aussagen, wie die folgenden auffallen, ist meiner Meinung nach, noch nicht ganz in dem agilen Mindset angekommen:

  • „Ich habe nur die Anforderungen geschrieben, für die Qualitätssicherung bin ich nicht zuständig“.
  • „Ich mache nur funktionale Software-Test. Ob auch ein Endkunde die Software versteht, ist nicht meine Verantwortung.“
  • „Ich werte nur das Kundenfeedback aus. Ob die Kundenwünsche auch umgesetzt werden, kann ich nicht beeinflussen.“

Kleiner Nachsatz

Klar, kann man nicht alleine alles machen. Jeder bringt seine Stärken und Talente mit und um effizient arbeiten zu können, sollten die Arbeitspakete auch aufgeteilt werden. Aber jeder sollte hinter dem Gesamtergebnis stehen, die gemeinsam Vision vertreten und einfach „Bock“ haben, das geilste Produkte zu entwickeln. Ich will damit sagen, dass man nach der Erledigung seines Arbeitspakets (Puzzleteils) nicht den Hammer fallen lässt, sondern schauen muss, wie sich sein Output und das Gesamtergebnis (Puzzle) integriert.

Ich hoffe, ich konnte mit diesem Artikel ein paar Anregungen geben. Das ich seit einigen Jahren ein Verfechter der agilen Entwicklung bin, sollte rübergekommen sein. Nur wollte ich Euch sensibilisieren, dass nur ein agiles Team oder Organisation keine Probleme löst. Ohne zu wissen warum man etwas macht, kann man auch nicht messen, ob am Ende das Ziel erreicht wurde. Und was ggf. noch viel relevanter ist, ohne sein Team oder Organisationseinheit zu fragen, was Eure Probleme sind, kann das Team nicht mit Herzblut und Engagement eine Transformation vollziehen.