. .

Kurz nachdem ich meinen neuen Job als Management Consultant bei bor!sgloger angetreten hatte, gratulierte mir ein ehemaliger Kollege mit den Worten: „Have fun making software teams productive!“

Geht es bei Scrum wirklich um Software-Entwicklung? Kann es das richtige Ziel sein, ein einzelnes Entwicklungs-Team produktiv zu machen? Dreht sich die Einführung eines agilen Mindsets in einem Unternehmen tatsächlich um technische Praktiken und Management-Frameworks?

Nein! Das alles greift viel zu kurz.

Immer wieder höre ich von Managern den Wunsch: „Wir müssen effizienter werden.“ Dahinter steckt oft der klassische Ansatz der lokalen Optimierung. Wenn nur jeder Bereich, jede Abteilung, jedes Team und jeder Mitarbeiter maximal ausgelastet sei, dann würden unsere Projekte auch schneller fertig.

Immer wieder höre ich von Managern die Aussage: „Die Entwicklung muss eine bessere Qualität liefern. Das Anforderungsmanagement muss bei uns vorgelagert sein. Der Betrieb ist sowieso voll ausgelastet, da die Software nie richtig funktioniert.“ Auch hier wird die Software-Entwicklung als zentraler Schuldiger gesehen, durch den die Probleme in der restlichen Organisation verursacht würden.

Was geschieht nun im Regelfall nach einer erfolgreichen Einführung von Scrum und agilen Entwicklungsmethoden? Die beteiligten Manager erkennen nach kürzester Zeit, dass die Probleme in der restlichen Organisation nicht verschwinden, obwohl die Entwicklung funktionierende Software schneller und in besserer Qualität liefert.

Scrum hat die Macht, die wahren Probleme einer Organisation sehr schnell offenzulegen! Und diese Offenlegung geschieht eben auch an den Schnittstellen der Entwicklungsteams in andere Bereiche. Damit erkennen wir die Kommunikationsschwierigkeiten zwischen allen Beteiligten am Produktentstehungsprozess. Produktmanager haben vielleicht noch nie mit Administratoren gesprochen, Verkäufer noch nie mit Testern, Entwickler noch nie wirklich mit dem Support. Aber all diese Mitarbeiter mit ihren unterschiedlichen Verantwortungen müssen gemeinsam daran arbeiten, den „Wow!“-Effekt für Kunden und Anwender zu erzeugen!

Durch die reine Optimierung unserer Entwicklungsmannschaft werden wir es nicht schaffen, den Anwender signifikant zu begeistern. Nur durch das Zusammenspiel aller Beteiligten können wir ein Produkt, eine Dienstleistung erzeugen, die der Anwender wirklich haben möchte.

Was müssen wir also tun, um ein erfolgreiches Scrum-Unternehmen zu transformieren?

Eigentlich ganz einfach: die Scrum-Teams müssen cross-funktional mit Beteiligten aus allen Unternehmensbereichen besetzt werden, die zur Erschaffung des Produktes benötigt werden!

So einfach dies klingt, so schwierig ist die Umsetzung der dafür notwendigen Grundlage: Veränderung der Unternehmensstruktur und vor allem der Unternehmenskultur. Das bedeutet, das agile Mindset, also die agilen Werte und Prinzipien, im Unternehmen auf allen Ebenen zu etablieren. Dies ist die eigentliche Herausforderung, mit der wir es zu tun haben. Und ich freue mich jeden Tag darüber, wenn ich sehe, wie Mitarbeiter und Manager sich von ihren traditionellen Vorstellungen Stück für Stück trennen, weil sie erkannt und erfahren haben, dass es andere, vielleicht erfolgreichere Wege gibt, mit Menschen gemeinsam ein funktionierendes Produkt zu bauen.

Wenn ich meinen alten Kollegen das nächste Mal treffe, werde ich ihm also antworten: „I have fun changing product development organizations. And sometimes that even may have something to do with making software teams productive.“

Avatar of Marc Bless
Kapitulation vor dem Status quo käme für Marc Bless nie in Frage. Wenn die alten Methoden nicht mehr helfen, sucht er kurzerhand nach neuen, denn seit er Anfang der 2000er „Slack“ von Tom DeMarco gelesen hat, hat sich die erste Regel des schlechten Managements in seinem Denken eingebrannt: „Wenn etwas nicht funktioniert, tun Sie das Gleiche immer wieder.“ Wie das in der Praxis aussieht, hat Marc in den Sackgassen und Teufelskreisen traditioneller Softwareentwicklungs-Projekte oft genug erlebt und arbeitet daher seit 2005 aus voller Überzeugung mit agilen Methoden. Nach einer 15-jährigen Karriere als Projekt- und Teamleiter hat er seine Berufung darin gefunden, Individuen, Teams und Organisationen als Coach dabei zu helfen, sich selbst und damit das Arbeitsumfeld aus eigener Kraft zu verbessern.
  • http://yascrum.blogspot.com/ Sebastian Radics

    Interessanter Post, danke dafür!
    Wie sieht denn dann so ein cross funktional besetztes Team genau aus? Ich hatte das bisher immer cross funktional im Sinne der Technik verstanden – z.B. im Java-Umfeld also ein Teammitglied, dass sich mit Tests auskennt, Java Entwickler mit unterschiedlichen Schwerpunkten, Architekt. Im Artikel klingt es so, als würden im Team auch Fachexperten mit dabei sein? Dabei würde es mich dann interessieren, wie ein Sprint-Tag dann aussieht – denn ich kann mir den Beitrag über den kompletten Sprint hinweg so nicht vorstellen.

    • Marc Bless

      Um die Wertschöpfungskette so weit wie möglich zu agilisieren, stoßen Organisationen oft schon an ihre Grenzen, wenn es darum geht, alle technischen Bereiche einzubeziehen. Das typische Beispiel ist der Betrieb, der sich erst nach der Entwicklung darum kümmern kann, das Produkt auch tatsächlich produktiv zu schalten.

      Noch weiter weg sind im Regelfall Fachexperten wie z.B. Übersetzer, Redakteure oder Marketing-Profis, die sich bereits während des Sprints im Team darum kümmern können, dass pünktlich beim Live-Deployment am Sprint-Ende auch die Social Media Marketingmaßnahmen starten.

      Die Frage nach dem Beitrag über den kompletten Sprint hinweg entspricht letztlich der Frage nach der Auslastung eines Mitarbeiters. Und diese ist zweitrangig im Vergleich zu dem Ziel, am Sprint-Ende ein fertiges Produkt zu liefern. Findet ein Teammitglied während des Sprints tatsächlich nicht genügend Arbeit im Team und langweilt sich, kann es möglicherweise auch in weiteren Teams “Teilzeitmitglied” sein.

      Noch einmal explizit: unser Ziel ist niemals, jeden Mitarbeiter immer auszulasten! Aber das ist vielleicht ein Thema für einen weiteren Blog-Beitrag.

      • http://yascrum.blogspot.com/ Sebastian Radics

        Danke für die Antwort. Mit ging es dabei nicht um die Auslastung des Mitarbeiters, sondern um die Integration im Team.

        Bzgl. der Integration mit Ops, da stimme ich Dir zu.

        Wenn es um Fachexperten geht, dann kann ich mir das im Team aus Teamentwicklungssicht im Moment schlecht vorstellen, da aus meiner Sicht der Beitrag dann doch eher punktuell ist. Wie kann dann konkret die Integration aussehen (Durchlaufen der Teamphasen und gemeinsames Wachsen in Richtung High-Performance-Team)? Siehst Du dann den Fachexperten für ein paar Tage im Sprint zusammen vor Ort mit dem Team und dann arbeitet er wieder in der Fachabteilung (und wandert damit zwischen den Welten?)

        Werden die Teams dann für jedes neu kommende Thema neu zusammengestellt?

        Kannst Du evtl. ein Beispiel für eine Teamzusammenstellung geben?

      • http://twitter.com/borisgloger Boris Gloger

        Hi Sebastian,

        kennst du das Video von ABC über die Arbeit von IDEO – findest du hier:http://www.youtube.com/watch?v=M66ZU2PCIcM.

        Es ging in Scrum immer darum ALLE Beteiligten der Product-Entwicklung zusammen zu würfeln. Vielleicht liesst du dazu auch nochmal den Artikel – The New New Product Development Game von Nonaka. Wichtig – klar sind das dann keine 5 Personen Teams mehr, sondern ganze Bereiche von bis zu 200 Personen. Aber die Prinzipien gelten dann auch.

        Für eine erste Annäherung kann das bedeuten, dass man die Fachbereiche und die Spezialisten tageweise dazu holt, oder man beteiligt sie intensiv beim Sprint Planning.

        Stell dir doch einfach einen kleinen Start Up von ca 25 Personen vor. Da sollte doch auch alles aufeinander eingespielt sein. So ähnlich ist auch ein wirkliches Product Development Scrum-Team.

        Viel Spass beim Lesen und schauen des Videos. — Boris

      • http://yascrum.blogspot.com/ Sebastian Radics

        Hi Boris,
        danke für das geniale Video – das hat es echt klasse gezeigt, was cross-funktionale Teams bedeutet und bewirkt. New Product Development Game – lese ich gerade.

        Sebastian

    • http://twitter.com/svnwnk Sven Winkler

      Hi Sebastian,

      es gibt verschiedene Möglichkeiten Know-How cross-funktional in dein Team hineinzubekommen. Eine Möglichkeit ist, dass aus Service und Betrieb dein Team so lange unterstützen, bis sie autonom ausliefern und installieren können, also befähigen.
      Das gleiche geht mit Fachexperten, die man anfangs zu Sprint Planning und Review einlädt und mit denen dann über die Zeit immer engere Kontakte entstehen und zu einer besseren Zusammenarbeit führen, was übrigens Ziel einer Organisation ist.

      Es geht allerdings auch anders. Ein Kunde von uns hatte, beim nachsinnen über die Vergangenheit, fallen lassen: “damals saßen die Leute aus den Fachbereichen noch direkt neben uns und haben uns die Funktion direkt in die Finger diktiert” – und das meinte er im positiven Sinne: Teamarbeit und direkter Austausch – von Angesicht zu Angesicht und ohne Dokumente, Verträge dazwischen. So wachsen auch gute Produktentwickler heran. Immer nah an der Domän. Zum Start Entwickler, die Produkt-Know-How haben, später dann (und das ist mein Ziel) Produktentwickler, die Entwicklungs-Know-How haben. Das letztere rockt mehr :-) und genau das kriegt man hin, wenn verschiedene Disziplinen zusammenarbeiten. Heutzutage nennt man das Teams, aufgestellt und getrennt durch disziplinarische Gerüste.

      Viele Grüße, Sven :-)

      • http://yascrum.blogspot.com/ Sebastian Radics

        Hi Sven,
        danke für die super Erklärung! Das schärft für mich zusammen mit dem Video von Boris das Bild. Es ist nicht nur die technische Diversifizierung im Team sondern gerade das Zusammenwachsen von Produktwissen und Technik – mit dem Ziel ein Team zu schaffen, was möglichst weit durch eigene Kraft ein Produkt entwickeln kann (natürlich in enger Abstimmung mit den Markbedürfnissen)? Oder?

      • http://twitter.com/svnwnk Sven Winkler

        Jep, du bringst es auf den Punkt :-)
        Die Ausrichtung ist der Markt, denn dafür wird ja gearbeitet. Wichtig ist hier noch die internen von den externen Märkten zu trennen. Also wann machen wir etwas mit Geschäftswert und Strahlkraft und ab wann entwickeln wir für interne Bedürfnisse, die keinen Geschäftswert erzeugen.