3

Prozesse stinken!

Standards können in der Softwareentwicklung nützlich sein. Eine „sauber durchdefinierte“ Ansammlung von Best Practices (neuerdings auch als „Good Practices“ bekannt) ist im Grunde eine feine Sache. Solche Standards bilden aber auch ein mächtiges Werkzeug, das in den Händen eines Unerfahrenen katastrophale Wirkung entfalten kann. Wenn solche Leute Hand anlegen, dann platzt den Entwicklern schnell der Kragen! Dann wird ab sofort alles agil. Oder nicht?

Wo immer man hinschaut, Automotive SPICE, CMMI und Co. scheinen fast einhellig gehasst zu werden. Experten hingegen, die mit diesen Standards Geld verdienen, pflegen diesen Umstand als bloße Widerspenstigkeit oder Mangel an Erfahrung abzutun.

Was ist nun das Problem? Ich wiederhole mich, aber es muss sein: Wir Berater sind SELBST SCHULD. Denn viele von uns haben zu lange die Realität der Standardeinführung in den unendlichen Weiten der Software-Welt ignoriert.

So in etwa sieht der hypothetische Ablauf einer Prozessverbesserung aus:

  1. Ein Verbesserungsbedarf wird festgestellt, z. B. möchte das Team professioneller werden, um seine Marktposition auszubauen.
  2. Ein renommierter Prozessberater, als Experte z. B. auf dem Gebiet Automotive SPICE verdientermaßen bekannt, wird angeheuert, um dem Team zu helfen.
  3. Es wird gemeinsam eine neue, standardkonforme Prozesslandschaft entwickelt, in der sich jeder in einer sinnvollen Rolle wiederfindet und wohldefinierte Qualitätsziele effizient erreicht werden können.
  4. Der Berater beendet seinen Einsatz und hinterlässt einen zufriedenen Kunden.
  5. Weiter siehe Schritt 1.

Die praktische Erfahrung mit Prozessverbesserungen erwies sich oft genug als eine andere. So der häufige Ablauf:

  1. Die Endkunden (z. B. Automobilhersteller) einigen sich auf einen neuen Satz von Regeln („Standards“) und zwingen diesen ihren Zulieferern auf.
  2. Verzweifelte Projektorganisationen heuern einen Berater an.
  3. Der Berater verkauft dem Kunden ein Beratungsprojekt und schickt, statt selbst hinzugehen, junge „High Potentials“ ins Projekt. Dem Kunden versichert er, dass er die Arbeit seiner unerfahrenen Jünglinge selbstverständlich überwache, damit alles so gut werde, „als hätte er das selbst gemacht“.
  4. Die für das Projekt abgestellten Berater haben den neuen Standard auswendig gelernt und legen ihn buchstabengetreu aus.
  5. Weitere Akteure, z. B. QA-Mitarbeiter, andere externe Mitarbeiter oder sonstige Profilierungswillige, lernen den Standard auch auswendig und legen ihn ebenfalls orthodox aus.
  6. Da Standards meist analytisch (und nicht systemisch) aufgebaut sind, führt das so geführte Prozessverbesserungsprojekt im gesamten Entwicklungsbereich zu einem exponentiellen Kostenanstieg, während das Team, statt sich um die Bedürfnisse des Kunden zu kümmern, erbitterte Grundsatzdiskussionen über eine „Practice XY.47.11“ führt.
  7. Das wird dem Sponsor des Prozessverbesserungsprojekts zu viel. Die Junior-Berater werden heimgeschickt.
  8. Nun werden entweder (a) alle oder zumindest viele der vorgenommenen Anpassungen rückgängig gemacht und die Organisation „hyperagil“; oder (b) Möchtegern-Experten übernehmen die Führung und lähmen die gesamte Organisation, indem sie den Standard als Totschlagargument im Kampf der Egos missbrauchen.

Das STINKT!!! Verwundert es vor diesem Hintergrund, dass „alle“ heutzutage „agil“ sein wollen?

Wie konnte es dazu kommen?

Dafür gibt es Gründe. Keine guten Gründe, davon aber recht viele.

Zum Beispiel:

Das Geschäftsmodell der Beratungshäuser. Wie (hoffentlich) jeder weiß, ist die auf Neudeutsch gern als „Leverage“ bezeichnete Hebelwirkung das A und O eines jeden Geschäftsmanns. Chefs von Beratungsunternehmen sind Geschäftsleute, und Leverage bildet ihre Existenzberechtigung. Diese Hebelwirkung entfaltet sich im Beratungsgeschäft über die Anzahl der eingesetzten, festangestellten Berater. Da diese zwecks Maximierung der Gewinnspanne günstig sein müssen, sind sie oftmals nicht so hoch qualifiziert, wie ihre Chefs dies vorgeben. Sie sind vielleicht erfahren im Consulting-Business, aber oft weniger erfahren in der Materie, in der sie beraten. Fachliche Erfahrung ist Mangelware.

Nochmals und immer wieder:  Mangel an erfahrenen Beratern. Es ist ein extrem gefährlicher Irrglaube eines Anfängers, dass das Auswendiglernen aller Details eines Standards genügen würde, um wirksam beraten zu können. Das reicht eben vorn und hinten nicht aus. Standards sind toll, wenn sie ein Experte als Checkliste nutzt, aber sie ersetzen die eigene Erfahrung in keiner Weise. Wenn man nicht jahrelang (noch besser: jahrzehntelang) selbst marktfähige Systeme entwickelt hat, wie soll man dann wirklich in der Lage sein, als Berater Wichtiges von Unwichtigem zu trennen? Es mag sehr seltene Talente geben, die dies von Natur aus vermögen, aber diese Sonderfälle können wir in unserer Betrachtung als statistisch irrelevant vernachlässigen. Und so – anstatt eigene Erfahrungen, gestützt durch Standards als Spickzettel, praxisgerecht umzusetzen – wird vielmehr das auswendig Gelernte wörtlich postuliert und dogmatisch umgesetzt. „Der Standard sieht das so vor.“ Wenn dieses Killerargument häufig ins Spiel kommt, sollte jeder Kunde hellhörig werden, denn es gibt in diesem Fall Grund zur Annahme, dass das Ergebnis der Beratung der betrieblichen Realität nicht gerecht wird.

Anfälligkeit für Modebegriffe. Was verkauft ein Berater? Sinnige, aber schwer greifbare Eigenschaften wie „Erfahrung“, „Expertise“ und „Know-how“ vermarkten sich schlecht. Es muss schon ein magischer Begriff herhalten, wie „CMMI“, „Scrum“ oder „Reengineering“. Die PR-Industrie dient jedem Teufel, so auch diesem. Wer nun kritiklos auf Modebegriffe à la „Wasserfall“, „V-Model“, „Design Thinking“, „Agility“, „ITIL“, „Cloud Computing“ etc. hereinfällt, der hat sein Scheitern verdient. Diese Begriffe sind teils hohl, teils stehen sie für einen überaus komplexen Sachverhalt, und wenn sie im Gespräch genutzt werden, dann denkt sich oft jeder etwas Anderes dabei. Das kann nur zu desaströsen Missverständnissen führen.

Unerfahrenheit der Kunden in der Beraterauswahl. Den richtigen Berater muss man finden können. „Richtig“ meint eine passende Mischung aus Erfahrung und persönlicher „Chemie“, die einfach stimmen muss. Wer sich von coolen Logos, glänzenden Visitenkarten und Marken blenden lässt, der ist wahrscheinlich schnell geneigt, ein mäßiges Preis-Leistungs-Verhältnis zu akzeptieren. Wenn man selbst nicht über jahrelange Projekterfahrung in seinem Fach verfügt, dann sollte man vielleicht erst einmal einen Berater für die Beratersuche anheuern. Vielleicht wird das im Endeffekt der wichtigste Berater im Projekt gewesen sein. Wem diese „Meta-Beratung“ zu extrem erscheint, dem helfen vielleicht eigene, erfahrene Mitarbeiter bei der Suche nach der richtigen Expertise.

Angst vor der Abhängigkeit von Lieferanten. Ein Großkunde, zum Beispiel ein Automobilhersteller, hat notorisch Angst, von seinen Lieferanten abhängig zu werden. Diese Sorge ist historisch gesehen nicht unbegründet. Bevor der umstrittene VW-Manager Ignazio Lopez die Zuliefererlandschaft umpflügte, litt die europäische Automobilindustrie unter explodierenden Kosten und massiven Qualitätsproblemen. Doch das Gegenteil ist auch nicht unbedingt vorteilhaft: Zulieferer mit Hunderten von Standards zu knechten, bis sie kaum atmen können, zerstört das Vertrauen und öffnet die Hintertür für die unerwünschte Beraterinvasion, die zwangsläufig die aus dem Berater-Geschäftsmodell resultierenden Probleme akut werden lässt.

Die Folgen dieser Umstände sind so dramatisch, dass wir wirklich darüber nachdenken sollten, ob wir mit den Standards richtig umgehen. Standards infrage zu stellen darf kein Tabu mehr sein. Standards können Projekte umbringen. Die Mehrkosten einer Standardeinführung (und nachfolgender Pflege) werden von Endkunden nicht übernommen. Diese leisten sich eine völlige Ignoranz der Tatsache, dass immer mehr Standards immer mehr Kosten verursachen. Zugleich wird gemunkelt, dass Endkunden selbst den Anforderungen ihrer eigenen Standards nicht genügen. Da könnte was dran sein.

Alles Quatsch?

Die Standards selbst seien gut, nur würden sie häufig falsch verstanden und umgesetzt, lautet der typische Einwand des prozesstreuen Beraterlagers.

Es ist schier überwältigend, wie viel Schindluder mit einer Rückübertragung eines analytischen Prozessmodells in die Synthese einer Prozessdefinition getrieben werden kann. Da werden beispielsweise Referenzprozessmodelle wie Automotive SPICE komplett eins zu eins in der Praxis umgesetzt. Dabei werden alle ENG-Prozesse (zehn Stück) zuzüglich der SUP- und sonstiger MAN-etc.-Prozesse als separate Entitäten ins Leben gerufen. So erhält die betroffene Organisation auf einmal eine hohe, zweistellige Zahl von Prozessen und Prozessverantwortlichen, die sich mit größtenteils redundanten Themen beschäftigen und so zu Reibungen und Ineffizienzen beitragen. Alles unheimlich standardkonform – und kaum zielführend.

Analytische Prozessmodelle sind von Natur aus redundant, und die Erfahrung über die einzelnen Prozessbereiche hinweg muss in hohem Maße gegeben sein. Nur so kann ein Berater helfen, diese Redundanz in den Griff zu bekommen und konsistente, redundanzfreie Projektmanagementsysteme aufzubauen.

Nicht nur Automotive SPICE, sondern auch ITIL, CMMI, ISO 9001, Functional Safety 26262 etc. sind in ähnlicher Weise problematisch.

Liebe Freunde: Standards können Eure Organisation UMBRINGEN.

Wir sind nun agil, alles wird gut.

Was nun? Alle Prozesse sind schlecht? Nichts wie weg damit?

Vorsicht, Falle! Die Unzufriedenheit mit Prozessstandards weckte bereits unverhoffte Begehrlichkeiten. Bereits vor über zehn Jahren haben clevere amerikanische Berater den Braten gerochen und eine Abwendung von den „bürokratischen Prozessen“ proklamiert. Da half es nicht zu betonen, dass Standards gut seien und lediglich falsch umgesetzt würden. Die Glaubwürdigkeit der traditionellen Prozessberater war leider bereits selbstverschuldet ruiniert. Auf einmal mussten daher alle „agil“ werden.

Doch was bedeutet „agil“? Das Gegenteil des englischen Begriffs „agile“ ist „clumsy“ (dt. „plump“) oder „awkward“ (dt. „scheußlich“). Dies hört sich eher nach dem Versuch, abweichende Ideen abzuwerten, als nach einem konstruktiven Lösungsvorschlag an. Populäre Agilitätsansätze bestärken diesen Eindruck. Nehmen wir z. B. Scrum. Für viele heißt „agil“ heute Scrum. „Scrum“ bedeutet zu Deutsch „Gedränge“. Ich kann mir nicht vorstellen, dass dies eine sinnvolle Zielvorstellung für einen erfolgreichen Manager verkörpern kann.

Die Scrum-Kritik lässt sich leicht weiter vertiefen. Im Scrum wurde nämlich die Rolle des Projektmanagers abgeschafft. Doch gerade diese Funktion war schon immer für erfolgreiche Projektarbeit wichtig. Sie gerät allerdings in Matrixorganisationen unglücklicherweise oft unter die Räder, weil sie nun einmal produktorientiert und nicht linientreu ist. Diese unselige Tendenz darf sich keinesfalls fortsetzen. Aus meiner Sicht muss die Rolle des Projektmanagers unbedingt gekräftigt werden. Dafür gibt es zu viele gute Gründe, um sie hier alle aufzulisten. Nun ist also in Scrum der Projektmanager weg; und was machen unsere agilen Freunde? Sie führen die Rolle des „Scrum Masters“ ein, eine typische Beraterrolle, die kaum intern besetzt werden kann. Scrum wurde offensichtlich zu dem Zweck entwickelt, als gut geölte Vertriebsmaschine für die Beschaffung von Berateraufträgen zu fungieren. Toll!

Die praktische Umsetzung der Agilität ist daher häufig selbst „clumsy“ und „awkward“. Denn auch im agilen Projekt muss ein Berater mindestens genauso viel fachliche Erfahrung mitbringen wie in einem sinnvollen Prozessverbesserungsprojekt. Ist das nicht der Fall, dann werden unter dem Vorwand der „Agilität“ Chaos, Aktionismus, schlechte Organisation und willkürlich bewegliche Ziele verkauft.

Das geht so nicht, meine Lieben.

Extreme Ansichten können erfrischend wirken, auf Dauer lenken sie nur vom Ziel ab.

Das können wir – die Softwareexperten – mit Sicherheit besser.

Erstens brauchen wir „schlanke“ Projektorganisationen und nicht bloße „Prozesskonformität“ oder willkürlich simplifizierte „Agilität“.

Zweitens geht es darum, als Projektmanager seine Erfahrung weiterzugeben. Es lässt sich nicht überzeugend leugnen, dass eigene Projekterfahrung nicht durch Lernfleiß zu ersetzen ist.

Drittens, ob man nun unter der agilen oder sonstiger Überschrift arbeitet, ändert nichts an der eigentlichen Aufgabe, ein ordentliches Projektmanagementsystem aufzusetzen.

Viertens sind die Entwicklungsabläufe mundgerecht zu gestalten, und das ist nur möglich, wenn man realistisch berät und die Projektorganisation fallspezifisch aufbaut. Projektmanagementsysteme von der Stange sind nämlich ähnlich unsinnig wie eine Zahnfüllung aus dem Versandkatalog.

Fünftens: Nein, Prozesse stinken nicht. Agilität stinkt auch nicht. Realitätsfremde Umsetzung, Mangel an Offenheit und blinde Trendgläubigkeit dagegen schon.

Und nu?

Alles Unsinn? Nein, aber einfach auf Teufel komm raus „agil“ zu sein stellt auch keine Lösung dar. Denkverbote in irgendeiner Art (Aufteilung in „gute“ und „böse“ Ideen) ebenso wenig. Eine sklavische, buchstabengetreue Umsetzung von Buch X oder Standard Y ist keine Lösung. Nichts zu tun aber auch nicht.

Und worin liegt denn nun die Lösung? Die Lösungsfindung beginnt bei der Erkenntnis, dass ein Entwicklungsprozess seinem Umfeld gerecht werden muss. Dieses Projektumfeld wird bestimmt von Schlüsselfaktoren wie verfügbaren Ressourcen, der Phase im Produkt-Lebenszyklus und damit verbundenen Marktanforderungen. Auf der anderen Seite ist es wichtig, den Prozess möglichst schlank zu halten, damit er nicht zu viel „Fett“ ansetzt. Ein guter Entwicklungsprozess muss gewissermaßen die richtige „DNA“ aufweisen, damit die daraus resultierende Kreatur – also das Projekt – überlebensfähig ist.

Weitere Details folgen demnächst auf diesen Seiten.

_____________________________________________________________

Über den Autor

Roman MildnerRoman Mildner, zertifizierter Projektmanager (PMP) und Mitglied im United Mentors Network (UMN), ist seit 1992 in der IT und seit 1998 als unabhängiger Berater und Projektmanager tätig. Zu seinen Beratungsschwerpunkten gehören IT-Strategieberatung, Projektmanagment und Prozessberatung. Weitere Details finden sich auf seiner UMN-Seite. (S. auch Google)

Kommentare (3)

Trackback URL | Kommentar RSS Feed

  1. Dimitri sagt:

    Vielen Dank für diesen Artikel.
    Leider ist “Scrum als Wunderwaffe” immer noch verbreitet und ein Ende ist nicht in Sicht.
    Und selbst wenn ein Unternehmen nach einem gescheiterten Scrum-Versuch zu den alten guten Abläufen zurückkehrt, gibt es meistens nicht mal eine offene Erklärung dafür von der Geschäftsleitung den Mitarbeitern gegenüber. Wieso auch, bei der Scrum-Einführung gabs doch auch keine.
    In der Firma, in der ich bis vor kurzem noch gearbeitet habe, war genau das passiert, was Sie schreiben:
    “…Die Scrum-Kritik lässt sich leicht weiter vertiefen. Im Scrum wurde nämlich die Rolle des Projektmanagers abgeschafft. Doch gerade diese Funktion war schon immer für erfolgreiche Projektarbeit wichtig…
    …muss ein Berater mindestens genauso viel fachliche Erfahrung mitbringen wie in einem sinnvollen Prozessverbesserungsprojekt. Ist das nicht der Fall, dann werden unter dem Vorwand der „Agilität“ Chaos, Aktionismus, schlechte Organisation und willkürlich bewegliche Ziele verkauft…”
    Genau das habe ich jahrelang (!) versucht, meinem Chef klar zu machen. Leider erfolglos.

  2. Ich kann Ihren Frust gut nachvollziehen. Vielleicht hat Ihr Chef einfach Angst, sein Gesicht, oder gar die Kontrolle über das Team zu verlieren. Das ist mit Abstand die größte Befürchtung eines Managers. Dieser Angst kann er mit verschiedenen Mitteln begegnen. Aussitzen ist jedoch aus meiner Sicht eine der ungünstigeren Alternativen. In solchen Fällen verliert man vor allem engagierte Mitarbeiter an die Konkurrenz.

    “Agile Entwicklung” ist ein Beraterprodukt, und es wird wie jedes andere Produkt beworben und vermarktet. Dass die Werbung häufig mehr verspricht als das Produkt leisten kann, ist ja nicht ungewöhnlich. Nebenbei: hat denn ein erfahrener Berater Ihr Projekt begleitet?

    • Dimitri sagt:

      Wenn wir bei einem Berater von einem (technischen und organisatorischen) Projekleiter sprechen: nein, es wurde bei keinem mir bekannten Projekte ein Projektleiter eingesetzt. Man kann es kaum glauben, doch war das leider die bittere Wahrheit.

      Ein Projekt lief fast immer so: der Vertrieb hat etwas sehr abstrakt und knapp Definiertes und von dem eigentlichen Entwickler-Team nicht Verwertbares verkauft. Sowas ist zwar nicht schön, wäre aber zu verschmerzen, wenn im 2. Schritt das passieren würde, was in so einem Fall passieren soll: dass jemand das Projekt technisch und organisatorisch leitend übernimmt, mit allem was dazu gehört: ein technisches Konzept erstellen, Schnittstellen definieren, Rollen bei den Entwickler verteilen, sicherstellen das die Entwicklung richtig läuft, Tests organisieren, und so weiter.

      Nur wurde dieser 2. Schritt in keinem Projekt gemacht. Stattdessen wurde der vom Kunden unterschriebene Vertrag den Entwicklern geworfen und es wurde gesagt: “Also Leute, los, entwickelt es mal schnell”. Das sowas nicht funktionieren kann, sollte eigentlich jeder verstehen… eigentlich. Nun ja, was die Folgen waren, können Sie schon ahnen: Projektverzüge ohne Ende, Chaos, Unzufriedenheit bei allen Beteiligten, ständiges Umdelegieren von Aufgaben… Als es im Projekt richtig krachte, wurde der (ohnehin mit Aufgaben zugepflasterte) IT-Leiter der Firma als technischer Krisenmanager eingesetzt und sorgte irgendwann mit viel Mühe dafür, dass das Projekt nur irgendwie abgeschlossen werden konnte, egal wie…

      Der Geschäftsführer hat auch kein Geheimnis daraus gemacht, dass er keine explizite Projektleitung in seiner Firma haben möchte. Einen Grund dafür konnte er allerdings nie nennen.

Kommentar hinterlassen

Loggen Sie sich ein, wenn Sie ein registrierter Benutzer sind.




*