Follow my new blog

Montag, 4. November 2013

Keine Veränderung ohne echten Stakeholder

Das größte Problem von Unternehmen heute scheint mir ein Mangel an Stakeholdern. An echten Stakeholdern. Denn ohne echte Stakeholder bleiben Veränderungen stecken.

Für mich ist ein Stakeholder zunächst einmal jemand, der etwas haben will. So sieht Wikipedia das auch - nur viel ausführlicher.

Sie werden jetzt denken, “Daran mangelt es doch aber gar nicht. Alle möglichen Leute und Gruppen wollen ständig etwas haben.” Da haben sie natürlich recht. Deshalb braucht es aus meiner Sicht auch noch etwas mehr, um Stakeholder zu sein. Ohne Zusatz ist Stakeholder nämlich nichts anderes als ein Management-Ausdruck für “Dreijähriger”.

Und wahrlich, an Dreijährigen, die sich lauthals etwas wünschen und dann erwarten, dass das auch ASAP von einem Weihnachtsmann geliefert wird, weil sie sich sonst trotzig auf den Boden werfen oder mit dem großen Bruder drohen, mangelt es in Organisationen nicht.

Ein echter Stakeholder ist aber anders. Der will nicht nur haben, der sitzt nicht einfach auf einem Königsthron. Nein, der setzt sich dafür ein, indem er immer wieder Zug auf den Lieferanten und andere Stakeholder ausübt.

Ein echter Stakeholder versteht zweierlei:

  1. Er ist nicht allein mit seinen Wünschen an den Lieferanten. Bei allem Interesse, sie erfüllt zu bekommen, ist er deshalb um Balance und Ausgleich im Feld der Zugspannungskräfte der vielen Stakeholder bemüht.
  2. Wünsche werden nicht einfach erfüllt, nur weil man sie äußert. Es braucht vielmehr kontinuierliche Präsenz beim Lieferanten, um immer wieder deutlich zu machen, “was wichtig ist”.

Für mich ist ein prototypischer echter Stakeholder der Bauherr eines Familienhäuschens. Der hat einen Wunsch geäußert und Lieferanten beauftragt (Bauunternehmer, Handwerker). Aber der lehnt sich danach nicht zurück. Ich kenne keinen Bauherren, der nach Auftragserteilung auf eine ausgedehnte Reise gegangen wäre, um im Anschluss ein schlüsselfertiges Haus zu beziehen. Vielmehr ist der Bauherr ständig auf der Baustelle. Mal mit Zuckerbrot, mal mit Peitsche. Jeden Tag erscheint er und macht den Ausführenden klar, was er will. Insbesondere weist er auf Mängel hin.

In der Softwareentwicklung sehe ich ein solches Verhalten jedoch eher nicht. Dort gibt es eine Menge Stakeholder - aber keine echten. Es tut mir leid, sagen zu müssen, aber meist sehe ich nur einen Kindergarten. Eine Menge Leute laufen aufgeregt umeinander und wünschen sich Berge an Veränderungen… nur keiner hat Zeit, an diesen Veränderungen zu ziehen. Regelmäßig “verreisen” sie nach Auftragserteilung.

Stakeholder ziehen nicht, sondern sie drücken. Sie drücken Teams Aufgaben rein und erwarten, dass die wie von Zauberhand einfach richtig erledigt werden.

So funktioniert es aber nicht. Wie jeder Häuslebauer weiß. Ein Grund, der auf der Hand liegt, sind Mängel in der Wunschformulierung. Ein anderer sind die vielfältigen Kräfte, die auf Lieferanten einwirken. Die werden ja nicht nur von einem Stakeholder gepresst, sondern von vielen. Da entscheiden sie dann immer wieder neu, wie sie am besten ihren Arsch retten.

Dazu kommt, dass oft die Fähigkeiten zur Wunscherfüllung nicht so ausgeprägt sind, wie ein Stakeholder es sich das wünscht. Und schließlich fragen sich Lieferanten sehr schnell “Wozu der ganze Mist? Wozu soviel Stress?”, wenn der Stakeholder nicht zieht. Das ist dann die Sinnfrage.

Und wie sieht der ominöse Zug aus? Wodurch unterscheidet es sich vom Druck?

  1. Erstes Merkmal von Zug ist die wiederkehrende Frage, wie und wo ein Merkmal der beauftragten Lieferung überprüft werden kann. Selbstverständlich nimmt der echte Stakeholder dann die Überprüfung selbst vor. Das ist ein Kennzeichnen jedes nicht-industriellen Herstellungsprozesses, würde ich sagen. Was aus einer Fabrik kommt, wurde dort bereits überprüft; darauf verlasse ich mich als Konsument. Was aber nicht aus einer Fabrik kommt - ein Haus oder eine Software - kann und muss ich als Auftraggeber selbst überprüfen. Ein Stakeholder ist also Abnehmer. Das meine ich genau so: Der Stakeholder überprüft. Er lässt sich nichts präsentieren, sondern begeht und nutzt selbst (oder beauftragt dazu eine vom Lieferanten unabhängige Instanz) [1].
  2. Zweites Merkmal von Zug ist die Präsenz des Stakeholders. Er begibt sich immer wieder zum Lieferanten bzw. Herstellungsort. Er ist vor Ort, um Fragen zum Fortgang zu stellen oder durch seine Anwesenheit es leichter zu machen, gefragt zu werden. Eine “Politik der offenen Tür” ist zuwenig. “Ihr könnt jederzeit kommen, um zu fragen.” ist ein wichtiges Angebot. Weniger darf nicht sein. Nur reicht es eben nicht. Immer wieder gibt es nämlich Barrieren, die verhindern, es in genügendem Maße zu nutzen.
  3. Schließlich halte ich es für wichtig, dass ein Stakeholder mithilft. Natürlich soll er sich seinen Wunsch nicht selbst erfüllen. Aber er soll helfen, Hindernisse für den Lieferanten aus dem Weg zu räumen [2]. Das ist nicht nur produktiv mit Blick auf die Wunscherfüllung, sondern auch motivationsstiftend beim Lieferanten. Der sieht sich dann als Partner und nicht nur als austauschbarer Leibeigener.
  4. Dass ein Stakeholder auch eine gewisse Macht braucht, muss ich nicht weiter betonen, oder? Ein echter Stakeholder kann selbst über Ressourcen entscheiden, um seinen Wunsch erfüllt zu bekommen. Er muss niemanden fragen.

Die Formulierung eines Wunsches durch einen Stakeholder ist für mich weniger wichtig als die Abnahme. Natürlich muss ein Wunsch erst formuliert werden, bevor ein Lieferant sich aufmachen kann, ihn zu erfüllen. Doch gerade in der Softwareentwicklung ist diese Formulierung notorisch mangelhaft. Sie ist kaum mehr als ein frommer Wunsch. Umso mehr, je weiter der Liefertermin in der Zukunft liegt.

Deshalb ist die Gewichtung von Beauftragung/Planung und Abnahme z.B. in verbreiteter Scrum-Praxis aus meiner Sicht falsch. Es wird zu viel Gewicht auf das Sprint Planning gelegt und zu wenig auf den Sprint Review (oder allgemeiner: auf die Abnahme).

Stakeholder gibt es viele. Aber echte Stakeholder… die sind rar.

Mindestens deshalb hapert es auch allerorten bei der Erfüllung von Wünschen. Das können Softwarefunktionen sein, das können Qualitäten von Software sein, das kann die Wandelbarkeit von Software sein, das kann die Einführung eines Tools sein, das kann die Einführung eines Prozesses sein, das kann die Umstellung auf Papierlosigkeit sein usw. usf.

Die Regel ist, dass gewünscht wird - und dann glaubt man, dass die Erfüllung schon eintreten wird. Manchmal werden markige Sprüche im Gang aufgehängt (“Qualität ist nicht verhandelbar!”), doch wer daran zieht, bleibt im Dunkeln. Und ob überhaupt die Fähigkeiten existieren, die Wünsche zu erfüllen, ist auch nicht klar.

Befehle, Maximen, Regelwerke, Incentives, Strafen… es gibt viele Wege, Druck auszuüben. Die werden alle angewandt. Und man wundert sich, dass die gewünschten Effekte nur schwer erreicht werden.

Dabei ginge es viel leichter, glaube ich. Zug statt Druck lautet die Zauberformel. Die braucht allerdings etwas, das viele wohl nur schwer aufbringen können oder wollen: persönliches Engagement.

Denn um an Ergebnissen zu ziehen, muss man ja da sein. Man muss durch Präsenz und Nachfragen und Erklären immer wieder deutlich machen, dass man die Ergebisse wirklich, wirklich will.

Insofern suche ich bei der Problemanalyse in Teams und Organisation zuerst nach echten Stakeholdern. Solange es die nicht gibt, liegt ein Wurzelproblem vor.

Und umgekehrt muss für jedes Veränderungsziel ein echter Stakeholder benannt sein. Wo das schwer fällt, ist schon wieder ein Wurzelproblem aufgedeckt [3].

Echte Stakeholder sind für mich also absolut zentral. Damit getan ist es allerdings nicht. Denn es ist eine Sache, überhaupt erst einmal Zug herzustellen. Doch wie reagiert ein Lieferant darauf? Wie kann er darauf reagieren? Beispiel Clean Code Development. Wer dafür einen echten Stakeholder einsetzt, ist schon einen Schritt weiter als andere. Die Entwickler müssen nur auch in der Lage sein, Clean Code zu produzieren. Der Wille allein genügt hier leider nicht. Woher kommt aber das Wissen, die Fähigkeit?

Einem echten Stakeholder ist deshalb oft zumindest in der Anfangsphase ein Lehrer beizuordnen. Der sorgt dafür, dass Lieferanten in die Lage versetzt werden, dem Zug des Stakeholders zu entsprechen. Mal kann der Lehrer im Hause sitzen, mal findet er sich in einem Seminar, mal braucht es einen Coach über längere Zeit.

Veränderung braucht insofern nicht nur Zug, sondern auch Befähigung. Wir müssen aufhören, daran zu glauben, dass Veränderungen einfach so “auf Befehl” erreicht werden. Umso weniger, je “weicher” sie sind, d.h. je mehr sie mit Gewohnheiten, Glaubenssätzen, Kultur zu tun haben. Ebenso, wo Wünsche unscharf sind oder Risiken hoch. Dann braucht es auch Zug im obigen Sinne und Lernschleifen.

Endnoten

[1] Insofern sind für mich die meisten Scrum Sprint Reviews eine Farce. Da präsentieren Entwickler und der Stakeholder ProductOwner lässt sich entertainen. Das ist für mich kein Zug.

[2] Die Konkrete Hilfestellung kann ein Stakeholder natürlich delegieren. Aber sofern Hindernisse außerhalb des Lieferanten liegen, ist es genauso die Verantwortung des Stakeholders, an ihrer Beseitigung zu arbeiten wie die des Lieferanten. Es geht ja um ein Gesamtergebnis; Stakeholder und Lieferant sind in Bezug darauf ein Team. Wunschkonzert und Ponyhof sind woanders.

[3] Das ist übrigens ein sehr häufiges Wurzelproblem. Denn heute sind ja alle schon mit ihrem Tagesgeschäft voll ausgelastet. Wie soll man denn da noch die zusätzliche Rolle eines echten Stakeholders einnehmen können?

Wenn Veränderungen es schwer haben in Organisationen, dann ist das also kein Wunder. Man stellt sich jeden Tag wieder selbst ein Bein, indem man versucht, Menschen voll auszulasten mit dem Tagesgeschäft. Das mag heute effizient sein - aber auf längere Sicht ist es kontraproduktiv, weil damit Kapazität für notwendige Veränderungen fehlt.

16 Kommentare:

Hannes Preishuber hat gesagt…

auch wenn eher philosophischer Natur ist.
Meiner Ansicht nach verwechselst Du die Rollen. Wovon Du sprichst ist der Auftraggeber, der fachlich als auch sachlich entscheiden kann. Abnahmen durchführt, Zwischenziele überwacht. klassisches Projektmanagement. Stakeholder sind irgendwie alle, Das Bauamt, der Nachbar...

Ralf Westphal - One Man Think Tank hat gesagt…

Ne, ich meine Stakeholder. Denn wenn Bauamt oder Nachbar keine Stakeholder sind, dann weiß ich auch nicht. Die haben nämlich ein Interesse an Merkmalen eines Bauobjektes.

Der Nachbar will vielleicht kein grellbuntes Haus neben seinem. Das Bauamt will vielleicht keines, das zu dicht an der Straßenecke steht und die Sicht versperrt.

Wie diese Stakeholder dann dafür sorgen, dass ihr Wille geschehe (bzw. auch berücksichtigt wird neben anderen), das ist eine zweite Sache.

Der Nachbar überträgt seine Willensdurchsetzung weitgehend dem Bauamt. Das Bauamt überträgt sie Gesetzen - prüft aber am Ende selbst nochmal (zumindest Baupläne).

Wenn der Nachbar seinen Wille nicht bekommt, dann wird er unangenehm: grüßt nicht oder sticht Reifen auf.

Der Auftraggeber/Bauherr ist natürlich auch Stakeholder. Ein Besonderer, weil er allein zahlt. Aber neben den anderen eben nur einer von vielen.

Der zieht am Bauausführenden, der zieht auch an Behörden. Behörden ziehen auch am Bauausführenden.

Mike Bild hat gesagt…

Vorab - alles richtig, alles gut. Diese waren Worte taten Not. Leider hab ich es gerade etwas eilig, deshalb in kurzen Worten.

Da ich selbst mehr und mehr im Bereich Produktentwicklung tätig bin und auch gern mal Meinungen als Gegengewicht äußere, werde ich hier nun auch mal für den Stakeholder-Adressaten in die Bresche springen.

Ganz ehrlich, hier werden Stakeholder als Organisationsmaschienen und Entwickler als kleine Kinder beschrieben. Für mich ist im Entwicklungsprozess auch der Entwickler ein Stakeholder. Hier kann er mit technischen Möglichkeiten und Ideen glänzen. Doch häufig wird diese Rolle nicht wahrgenommen. Im Gegenteil. Entwickler ziehen sich zurück, rümpfen die Nase bei neuen Ideen und Kundenwünschen die möglicherweise nur unzureichend beschrieben werden können. Warum nicht Zettel und Stift nehmen und Anforderungen so mit den Beteiligten formulieren das sie passen?

Zweiter Punkt der mich immer wieder zum nachdenken und auch zum Unverständnis anregt. Das ständige "Software-Rad neu entwickle". Ich muss erstmal nen EMail-Service bauen. Weil es kein MailChimp gibt? Ich muss erstmal nen cooles und ausgefeiltes Datenmodell machen? Weil es keine Dokumenten-basierte oder Event-basierten Ansätze gibt? Wir müssen erstmal ein paar Server und einen performanten Datenspeicher mit einer richtig schicken Datenbank und Apache-Web-Server Farm inkl. coolio Load-Balancer aufsetzen, statt erstmal NodeJS mit JavaScript zu verwenden.

Alles nur Beispiele die mir immer wieder belegen, dass in Entwicklerkreisen zu einem sehr großen Teil die ökonomischen, wirtschaftlichen und marketing technischen Aspekte vernachlässigt und sogar als störend empfunden werden. Schon wieder ne Änderung, Pivot, Design, learning by doing ... och nee ... ist das Motto.

Fertige oder Teilfertige Lösungen sinnvoll mit eigenen Entwicklungen zu kombinieren und der proaktive Blick über den Tellerrand ist selten in Entwicklerkreisen anzutreffen. Auch hier arbeiten Entwickler als eine Art Product Owner. Sie können wichtigen Input geben und sogar das Business-Model komplett umgestalten.

Das geschieht meiner nach zu wenig und hier wird viel potential verschenkt.

Mike Bild hat gesagt…

... so ist es. Ich meine es gibt so viele Ideen die es mehr oder minder Wert sind umgesetzt zu werden. Ja stimmt, leider fehlt es dem einen oder anderen Stakeholder technische und geschäftliche Entwicklungsprozesse im Detail zu verstehen, zu organisieren und zu steuern. Genau hier ist unter Beteiligten und Stakeholdern Team-Work angesagt. Zwischen meckern, debattieren und zurücklehnen aufgrund von fachlichen oder organisatorischen Mängeln sehe ich eher selbst machen. Wer "push"-mäßig Anweisung bekommt, zieht mit Fragen ala "Was wäre z.B. wenn das und das oder das?". Keine Antwort == keine gedachte Umsetzung - fertig aus die Maus. Da hilft auch kein weiteres Gelaber. Gibt es jedoch Vorschläge oder Fragen kann ich doch als vertrauensvoller Softwareentwickler aufklären und Ideen zur Lösung einbringen. Schon ist etwas mehr geklärt.

Die Frage ist natürlich Wie vertrauensvoll ist der Softwareentwickler? Macht er seine Sache gut? Ist er in Breite mit Technologien vertraut? Ist er engagiert, aufgeschlossen, lernbereit, flexibel? Arbeitet er gern mit Menschen zusammen? Versteht er sich als Teil der Unternehmung mit dem Anspruch eines guten Gesamtergebnisses? Technologische Perfektion ist sicher ein wichtiges Merkmal, aber das sieht eben auch nicht jeder so! Hier stoßen manchmal Welten aufeinander. Startup Super Fast Business Hipster auf X Jahre Enterprise ABC Senior Developer und Architekt mit jeder Menge Fowler, Evans und Uncle Bob im Gepäck.

Cheers, Mike

Ralf Westphal - One Man Think Tank hat gesagt…

Stakeholder ist, wer eine Verantwortung hat, dass alle Säulen, auf denen Software ruht, stabil sind. Das sind Funktionalität, Qualität und Investitionssicherheit.

Ultimativ ist das ausschließlich der Kunde, also der, der die Kohle gibt. Der jedoch kann seine Verantwortung übertragen. Er setzt z.B. einen ProductOwner ein, der an Funktionalität und Qualität ziehen muss.

Aber wen setzt er ein für den reibungslosen Betrieb? Wen setzt er ein für die Investitionssicherheit?

Und wenn hier schon so eine Lanze gebrochen wird für Entwickler: Wofür sind sie denn Stakeholder in Bezug auf das Softwareprodukt, das sie selbst herstellen?

Ne, tut mir leid, das scheint mir ein Widerspruch. Ich glaube nicht, dass man gleichzeitig Stakeholder und Hersteller derselben Sache sein kann. Ganz fundamental geht das nicht. Denn: Da lügt man sich entweder in die Tasche oder verfällt auf l´art pour l´art.

Der Begriff Stakeholder macht ja auch nur Sinn, wenn irgendwer etwas anderes ist. Das ist der Hersteller. Ein Stakeholder ist einer, der an einem Hersteller zieht.

Das hat nix mit besser/schlechter, oben/unten zu tun. Es sind einfach grundverschiedene Aufgaben. Wie Koch und Kellner. Keiner ist besser. Der Koch kann noch so gut sein, wenn der Kellner grottig ist. Und umgekehrt.

Natürlich dürfen Entwickler Stakeholder sein. Nur in Bezug auf was?

Mike Bild hat gesagt…

auf die Gefahr hin, dass ich was im agilen Syntaxirrsinn zu Stakeholdern gerade was nicht kapiere...

"Stakeholder ist, wer eine Verantwortung hat, dass alle Säulen, auf denen Software ruht, stabil sind. Das sind Funktionalität, Qualität und Investitionssicherheit."

Genau das machen Entwickler die Verantwortung übernehmen wollen auch. Funktion umsetzen, Qualität sichern und für Investitionssicherheit sorgen, indem sie Technologie entscheiden und Umsetzung im Minutentakt entscheiden.

Natürlich sind Entwickler eben auch vorrangig Dienstleister. Im Namen des Kunden oder Vorgesetzten handelnd.

"Wofür sind sie denn Stakeholder in Bezug auf das Softwareprodukt, das sie selbst herstellen?"

Sprichst Du hier Qualitätssicherung und Risikomanagement an?

"Der Begriff Stakeholder macht ja auch nur Sinn, wenn irgendwer etwas anderes ist. Das ist der Hersteller. Ein Stakeholder ist einer, der an einem Hersteller zieht."

Mal den Begriff "Stakeholder" beiseite. Wichtig für mich ist, dass wenn andere wie bsw. der Product Owner nicht das macht wofür er eingesetzt ist gibt es verschiedene Mittel um verantwortungsvoll im Sinne der Gesamtentwicklung zu handeln. Von Hilfestellung bis hin zur Kündigung.

"Natürlich dürfen Entwickler Stakeholder sein. Nur in Bezug auf was?"

Bsw. im Bezug zum Gesamtziel eines effizient hergestellten Produktes.

PS: Auch diese zum Teil ansteckende Meckerei über unzureichend besetze Teams und angeblich gebundene Entwicklerhände ist für mich wieder ein Beispiel für eine dringend nötige Änderung von Softwareentwicklungsprozess, Organisation, Strategie, Methode, Handwerk und Werkzeuge.

Ralf Westphal - One Man Think Tank hat gesagt…

Ich sage nichts dagegen, dass Entwickler sich verantwortlich fühlen, die Wünsche von Stakeholdern gewissenhaft umzusetzen. Das erwartet jeder Stakeholder von jedem Dienstleister.

Doch das ändert nichts daran, dass ein Dienstleister eben kein Stakeholder ist. Bei aller Gewissenhaftigkeit bestimmt der Entwickler nicht darüber, ob seine Mühe Erfolg hat. Den Erfolg bestimmt ausschließtlich (!) der Stakeholder - das ist der mit der Kohle.

Ein Entwickler hat keine Kohle, sondern bekommt welche. Vielleicht verstehst du das besser :-)

Wir müssen weg von einer naiven wie von einer romantischen Vorstellung.

Naiv: Der Stakeholder denkt, "Ich formuliere meinen Auftrag, übertrage an einen Dienstleister und dann kommt raus, was ich will. Bis dahin kann ich in Urlaub fahren."

Romantisch: Der Entwickler denkt, "Ich arbeite gewissenhaft, denke sogar weiter als der Stakeholder. So kommt am Ende das Bessere raus."

Beides Quatsch. So übertrieben formuliert sowieso. Aber auch in der realen Ausprägung. Und die höre ich bei dir heraus.

Die romantische Vorstellung hat als Voraussetzung die naive.

Deshalb plädiere ich dafür, die naive endlich zu entlarven und es richtig zu machen. Echte Stakeholder müssen her. Alles andere ergibt sich von selbst. Und nur, was sich dann ergibt, ist auch nötig und sinnvoll.

Denn ohne echten (!) Stakeholder-Zug kann niemand wissen, ob irgendetwas beim Dienstleister wirklich nötig ist oder doch nur Verschwendung (und sei es der gut gemeinten Art).

Mike Bild hat gesagt…

Natürlich müssen "echte" Stakeholder her. Doch das plädoye - Sollen die anderen es mal besser machen - klingt für mich nach meckern und zurücklehnen. Nach dem Motto - wenn jemand sich PO schimpft, soll er es auch sein.

Das klingt für mich nicht nachhaltig und bringt letzten Endes auch niemanden weiter. Vielleicht ist es naiv oder romantisch, vielleicht ist aber auch Realität das letzten Endes auch der Stakeholder oder Product Owner nicht über den Erfolg bestimmt, sondern der Endkunde. Das kann der Nutzer meines Kunden, der Kollege aus der Buchhaltung aber auch der Aktionär von Microsoft sein.

Ich höre ebenfalls, dass Kohle die einzige wahre und echte Motivation sei. Natürlich ist Geld, zumindest im Business, die stärkste Motivation. Ja der Kern der Sache. Und genau deshalb ist nicht das schimpfen über den PO / Stakeholder fehl am Platze, sondern wie ich meine Eigeninitiative. Dabei sollte natürlich nicht am gewünschten Ziel vorbei entstehen. Übermotivation kann ebenfalls gefährlich sein.

Wie genau Motivation zum Erschaffen, vorantreiben, ziehen an Resultaten entsteht, und das kann meinetwegen sehr gern ausschließlich über viel Geld entstehen ;-), ist für mich entscheidene Grund alle ins Boot zu holen. Entwickler, PO und Stakeholder müssen an sich ziehen.

Ich wollte hier eine Lanze für den PO / Stakeholder brechen. Den ständiges "ziehen" ohne das berühmte "im Team an einem Strang ziehen" ist auch hier bereits das Kind in den Brunnen gefallen. Da ist nichts naives oder romantisches dran, sondern eine absolut nötige Veränderung von Softwareentwicklungsprozessen in Richtig kleine flexible Entwicklungsteams von wenigen Personen mit einer gemeinsamen Aufgabe. Nach dem Motto mit gefangen mit gehangen.

So bekommen Mitglieder eines Teams, neben einer guten Bezahlung ;-), die Motivation an sich gegenseitig zu ziehen und die Chance aus dem kleinem Rädchen dasein zu einem effizienten Entwicklungsteam zu werden.

Ralf Westphal - One Man Think Tank hat gesagt…

Mike, ich glaube, du siehst das alles noch ein bisschen enger, als ich es gemeint habe.

Es geht nicht um Softwareentwicklung im Speziellen. Ich habe eine ganz grundsätzliche Aussage versucht in Bezug auf jede (!) Art von Veränderung in Organisationen. Mehr Pair Programming, mehr Tests, mehr Clean Code, mehr Agilität... das ist alles nichts anderes als weniger Tippfehler in Angeboten, höflichere Behandlung von Anrufern am Tel, schnellere Reaktion auf Beschwerden oder weniger Abfall bei der Produktion.

Wenn dir in einem Unternehmen irgendetwas (!) auffällt, was sich verändern soll, dann muss ein Stakeholder her. Und zwar ein echter.

Was das ist, habe ich beschrieben.

Du fokussierst nun auf Softwareentwicklung. Kann man machen. Dann sage ich: Da ist der "normale" Stakeholder der Kunde. Und solange er nur "normal" ist, stellt sich eben als Ergebnis ein, was sich heute so einstellt. Dolle ist das nicht, oder?

Wenn es besser werden soll, dann muss sich als allererstes genau dieser Stakeholder verändern. Dann muss er "echt" werden im beschrieben Sinn.

Was sich jeder Stakeholder wünscht, das ist natürlich ein Dienstleister, der seine Wünsche verinnerlicht hat. Das ist ja die Aufgabe von Eltern und Gesellschaft bei Kindern. Die sorgen dafür, dass Regeln und Werte von außen in Köpfe und Herzen der wachsenden Menschen kommen. Das nennt man dann z.B. Gewissen. Oder intrinsische Motivation.

Das funktioniert für ne Menge Dinge recht gut. Nur zu doof, dass Software immer noch so aussieht, wie sie aussieht. Nicht schön. Und dass Unternehmen immer noch unter unschönen Zuständen stöhnen. Wie kann denn das alles sein? Muss da vielleicht noch mehr Gewissen und intrinsische Motivation her?

Ja, kann sein. Aber woher sollen die kommen? Vom Poster an der Wand? Kaum. Das (!) ist mein Punkt.

Wenn einer sich über Zustände beklagt, dann reicht es nicht, ein Poster mit markigen Sprüchen zu neuen Zuständen aufzuhängen. Nein, es muss ein echter Stakeholder her. Einer der zieht. (Und dazu muss dann auch noch Hilfe zur Befähigung gegeben werden.)

Um Geld geht es mir bei der ganzen Geschichte gar nicht.

Es lässt sich aber auch nicht ausschließen, weil am Ende immer irgendeiner fragt: Wer bezahlt das? Und dann kommt man darauf, dass es Veränderungen nicht wirklich gibt, ohne das Geld einzubinden. Man kann es auch Management Buy-In nennen.

Doch das reicht nicht. Nur weil ein Manager nickt, wird eben nichts besser. Es ist nur eine Hürde aus dem Weg geräumt. Eine offensichtliche. Danach braucht es immer noch den echten (!) Stakeholder.

"Im Team an einem Strang ziehen" ist übrigend gar nicht mein Thema hier.

Mike Bild hat gesagt…

Klar ist ein Poster nicht genug. Klar fokussiere ich auf Softwareentwicklung. Klar müssen Stakeholder wie PO und Manager mehr machen als unklare Wünsche äußern. Natürlich ist mehr als Gelaber rund um Agilität, TDD, Clean-Code nötig.Mein Punkt ist, Entwickler sind vor allem Dienstleister. Hier heißt es auf den Stakeholder als Kunden zugehen. Sollte dieser seine Rolle unzureichend wahrnehmen, kann ich als Entwickler Hilfestellungen geben. Natürlich ist ein Veränderungsprozess in Organisationnen und Innovation einfacher, wenn Manager abnicken und Stakeholder die von Dir beschriebene Rolle wahrnehmen. Und am Ende nutzt das alles nichts, wenn die Basis nicht mitzieht. Auf was ich aufmerksam machen wollte ist, dass eben *alle* "mitmachen" ihre Rollen zu überdenken und diese aktiv wahrnehmen. Der Zweck ist, dass Software eben nicht mehr so ineffizeint entsteht wie sie heute zum Teil entsteht.
Im übrigen kenne ich ebenfalls genügend Projekte in Unternehmen (vor allem Startups) in denen die von Dir beschriebene Stakeholder-Rolle sehr wohl wahrgenommen wird. Und genau dort ist es auch nicht besser. Da wird rumgedruckst, kleine und große Probleme verschwiegen, selten eine Verzögerung kommuniziert, Technologie vorgeschoben, über Veränderung gemeckert, mit Leidenschaft an Infrastruktur und Frameworks gebastelt, statt die häufig recht klaren primären Ziele anzugehen, Stakeholder-Bedürfnisse zu verstehen bzw. aktiv mit zu organisieren und umzusetzen.

Wie oft sehe ich das Vorgehen: Macht Ihr mal funktionale Anforderungen, wir fangen schon mal mit der Technik an. OMG(!)

Da hilft kein - ich sage mal was ein "echter" Stakeholder ist. Macht es so und alles wird besser. Haha - ich sehe es - da wird im Gesamtbild auch nichts besser!

Wenn Entwickler nicht endlich ebenfalls beginnen ihre eigene Rolle zu überdenken und entsprechend zu besetzen wird auch nichts besser.

Ralf Westphal - One Man Think Tank hat gesagt…

I beg to differ: Genau in der Situation, die du beschreibst, hilft ein echter Stakeholder. Denn die Situation ist so, weil er fehlt.

Sag mir, was nicht so ist, wie es sein soll, und ich sag dir, welcher Stakeholder fehlt. Ich nehme ein Beispiel von dir: "Verzögerungen werden nicht kommuniziert".

Die Situation, die Organisation soll anders werden, oder? Es sollen weniger Verzögerungen auftreten oder wenn, dann sollen die besser kommuniziert werden.

Wenn das wirklich, wirklich so sein soll, dann muss ein Stakeholder her, der genau daran (!) zieht. Denn ganz offensichtlich hat die bisherige Organisation mit ihren Mitgliedern eben bei diesem Merkmal keine genügend gute Wahrnehmung und/oder Fähigkeit.

Wie der Stakeholder heißt, der in Bezug auf Verzögerungen eine SOLL-Vorstellung hat, ist mir egal. Nenn ihn Projektmanager oder PO oder Putzi. Egal. Solange er jedenfalls nicht eingesetzt ist und deutlich macht, dass und wie es anders sein soll, wird nichts besser. Er muss den Wert "Verzögerungsfreiheit" im wahrsten Sinn verkörpern.

Nicht mit Postern "Immer pünktlich!", nicht mir markigen Sprüchen, nicht mit Drohungen, sondern angemessen, deutlich, mit Wertschätzung und Verständnis, Zug und dem Willen zu helfen, Hindernisse aus dem Weg zu räumen.

Das bedeutet nicht, dass er Dienstleister ihrer Verantwortung enthebt. Die sollen natürlich in die Lage versetzt werden, "ohne Kontrolle" pünktlich zu liefern. Nur tun sie das eben nicht. Also müssen sie befähig werden. Und sie müssen spüren (!), dass das wirklich wichtig ist, ein Wert ist. Denn sie verhalten sich ökonomisch, wenn sie verzögert liefern - nur nicht im Sinne von irgendwem anderes, sondern in Bezug auf für sie wichtige Werte.

Veränderung braucht einen Stakeholder und ggf. einen Lehrer. Gern darf dann über die Zeit der Zug geringer werden, wenn "der rechte Weg" von Dienstleistern verinnerlicht worden ist. Aber solange das nicht der Fall ist... solange muss ein Stakeholder her, ein echter, um die Verhältnisse zu ändern.

Es ist ja nett, dass du dir da mehr von Entwicklern selbst wünschst. Tue ich auch. Ist aber eben, wie die Praxis zeigt, unrealistisch. Es passiert nicht einfach. Was schließen wir daraus? Klagen und Wünschen hilft nicht, sondern nur anpacken. Das bedeutet: Stakeholder einsetzen, die an gewünschten Veränderungen ziehen, ziehen, ziehen. Nur so kann sich das Wertesystem, in dem sich jeder einzelne ökonomisch verhält, verändern.

Florian hat gesagt…

Hallo Ralf,

ich bin mir unsicher, ob es tatsächlich ausreicht nur einen echten Stakeholder zu haben, der die Eigenschaften aufweist, die du skizzierst, um einen Veränderungsprozess zu starten und diesen auch zielgerichtet in Gang zu halten.
Die Erfahrungen, die ich im Bereich der Arbeits- und Organisationspsychologie mache und gemacht habe zeigen viel eher, dass ein Stakeholder alleine nicht ausreicht um eine wirkliche und dauerhafte Veränderung zu erreichen. Du sprichst so etwas wie Gewissen oder intrinsische Motivation an. Die Grundlagen dafür werden durch Eltern, Gesellschaft oder einfach die Kultur gelegt. Auch in Organisationen gibt es entsprechende Kulturen. Das bloße Ziehen eines Stakeholders an anderen innerhalb einer Organisation wird vielleicht kurzfristig etwas ändern, aber nicht dauerhaft tragbar sein. Kulturen lassen sich nur schwer ändern. Wieso sollte ein Betroffener die Motivation haben etwas zu zu ändern, nur weil ein Stakeholder Zug ausübt? Du sagst zurecht, dass Strafen, etc. (Zuckerbrot und Peitsche) nicht die gewünschten Ergebnisse erzielen. Im besten Fall ist doch angestrebt, dass die Organisation aus freien Stücken die Änderung übernimmt und aus eigener Motivation lebt. Selbstbestimmung ist ein wichtiger Punkt.
Dies zu erreichen ist ein Prozess, der vielen, meinem Gefühl nach zu lange dauert. Geht es um Selbstbestimmung kommen auch die Punkte von Stefan und Mike zum tragen, die Aktivitäten bei den Betroffenen sehen und ich denke, dass sie damit auch Recht haben.

Zusammenfassend denke ich, dass eine Mischung der Positionen von Ralf, Stefan und Mike die Problematik ganz gut abbilden kann.

Viele Grüße.

Mike Bild hat gesagt…

Gut(!) wenn Du meinst "die für die Aufgabe richtigen Stakeholder einsetzten". Da bin ich ganz bei Dir. Kommt im Artikel für mich nicht ganz so deutlich rüber.

Ciao, Mike

Mike Bild hat gesagt…

... vielleicht ist in diesem Zusammenhang der Begriff Stakeholder etwas falsch besetzt.

Mentor trifft das gewünschte IMHO etwas besser.

Ciao, Mike

Ralf Westphal - One Man Think Tank hat gesagt…

@Florian: Ein echter Stakeholder allein reicht sicher nicht. Aber ohne echten Stakeholder gehts eben nicht mal wirklich los.

Ein echter Stakeholder ist der, der denen, die sich verändern sollen, deutlich macht, warum sie das tun sollen. Er gibt der Veränderung Sinn. Das meine ich genau so. Denn Sinn bedeutet für mich, dass einer das Gefühl hat, gebraucht zu werden.

Ich bin für alle intrinsische Motivation, die man kriegen kann. Nur woher soll die kommen? Aus Einsicht? Schön wärs.

Nein, verändern tun sich Menschen zumindest leichter wenn nicht sogar vor allem... für andere Menschen. (Oder eine Überzeugung. Fragt sich nur, woher die kommt. Meist auch von anderen Menschen bzw. für andere Menschen.)

Am Anfang einer Veränderung muss also ganz deutlich sichtbar ein Mensch stehen, für den es sich lohnt bzw. an dem man sozusagen nicht vorbeikommt. Einer, der immer wieder ins Auge blickt und sagt "Für mich! Ich brauche das."

Das bezieht sich auf die nächste Funktionalität, auf die nächste Qualität, auf TDD, CI, Code Reviews usw. usf.

Wenn über die Zeit, der Zug von außen nach innen wandert, dann ist das ne schöne Entwicklung. Verlassen würde ich mich darauf aber nicht.

Vor allem funktioniert das für manche Veränderung auch nicht. Der echte Stakeholder PO kann nicht internalisiert werden. Höchstens kann die Sensibilität von Entwicklern in dessen Richtung steigen.

Sabri hat gesagt…

Der Artikel war so fabelhaft, dass ich mir mindestens eine Therapiesitzung sparen kann. Der Chaoskeim hat einen Namen: Stakeholder.
Ausdrücklich und mit vollster Verehrung: DANKE!