Enable javascript in your browser for better experience. Need to know to enable it? Go here.
Blogs Banner

Der Mensch im Mittelpunkt: Wandel bei der Softwareentwicklung

Manager und Teammitglieder haben oftmals die gleichen Ziele während des Projektverlaufes. Jeder ist daran interessiert etwas zu verändern, sei es in der Technologie, in Prozessen oder gar am Geschäftsmodell. Allen liegen dennoch fundamentale Vorraussetzungen zugrunde, die manchmal auch Veränderungen in der Haltung und im Projektaufbau nach sich ziehen.

Wenn man Manager und Verantwortliche, die sich mit Veränderungsprozessen befassen, befragt woran Veränderungen scheitern, bekommt man verschiedene Antworten.

Die häufigste Antwort ist jedoch – Menschen:
  • Menschen, die nicht mitzogen.
  • Menschen, die etwas nicht verstanden haben.
  • Menschen, die nicht die nötigen Fähigkeiten besaßen.
  • Menschen, die sich nicht an Erwartungen hielten.

Dies bedeutet für uns aber nicht, dass wir uns noch mehr Ideen überlegen wie wir die Gründe für den notwendigen Wandel besser vermitteln können. Stattdessen drehen wir die Sache um: Wir beginnen mit den Menschen und stellen sie in den Mittelpunkt.

Eine erfolgreiche Disziplin, die am Menschen ansetzt, ist die nutzerorientierte Produktentwicklung. Sie folgt folgendem Leitgedanken: Beim Nutzer beginnen, dessen Bedürfnisse erkennen und eine sinnvolle Lösung entwickeln. Findet man ein echtes Bedürfnis und eine gute Lösung, sind Menschen auch bereit, dafür zu bezahlen und der Geschäftserfolg lässt nicht lange auf sich warten.



Veränderungen in der Haltung


Schneller und effizienter sein, rascher auf den Markt reagieren können – das sind häufig die Gründe, die für den Veränderungsbedarf angeführt werden. Die Ziele werden dabei fast immer aus Sicht des Unternehmens festgelegt.

Doch was wäre, wenn wir von den Mitarbeitern, den Teams, den Menschen auf sämtlichen Hierarchiestufen ausgingen und uns fragten: Was brauchen sie, damit sie ihre Aufgaben besser erfüllen können? Was wäre, wenn wir ihre Bedürfnisse ermitteln und Lösungen finden? Was wäre, wenn die gleiche Annahme, die auf die nutzerorientierte Produktentwicklung zutrifft, auch hier gälte, und wir vom Bedarf über sinnvolle Lösungen zum Geschäftserfolg gelangen könnten?

Unserer Erfahrung nach verhält es sich tatsächlich häufig so. Wenn Teams die nötigen Befugnisse und Mittel haben und starre Strukturen sie nicht daran hindern, Spitzenleistungen zu erbringen, liefern sie den besten Beitrag zum Unternehmenserfolg.

Oder wie Peter Drucker es ausdrückt:  

Wie kommt man dorthin?


Wie kann man die Menschen als Nutzer eines Systems in den Mittelpunkt des Wandels stellen? Im Folgenden zeigen wir ein paar Schritte auf.

Am Anfang steht die Recherche: Wie sieht es momentan aus? Sobald man die Bedürfnisse der Mitarbeiter kennt, kann man mit der Lösungsfindung beginnen.

Ausgehend von den Ideen werden einzelne Schritte in einer Roadmap gegliedert. Am Ende folgt die Skalierung. Sobald erste Erfolge zu verzeichnen sind, sollte man überlegen wie man das Konzept auf das gesamte Unternehmen übertragen kann. Dazu eignen sich sogenannte “Workarounds”.

Bei Produktdesignern sind sogenannte „Workarounds“ besonders beliebt. Das heißt, Dinge werden anders eingesetzt als eigentlich vorgesehen. Wenn man darauf achtet, findet man überall „Workarounds“.

Meine erste Erfahrung mit einem Workaround war bei meine Großeltern. Als wir Kinder noch klein waren, schliefen wir immer im oberen Stockwerk, während meine Großeltern im Erdgeschoss blieben. Der Lichtschalter war für uns Kinder zu hoch angebracht. Damit wir nun bei Dunkelheit nicht die Stufen herunter fielen, legte meine Großmutter einen Spazierstock bereit, mit dem wir das Licht anschalten konnten.

Allerdings war das Haus meiner Großeltern voller Workarounds. Und je älter sie wurden, desto mehr Workarounds gab es. Da war ein Nußknacker, mit dem Dosen und Flaschen geöffnet werden konnten, Zangen um ihre Strümpfe hochzuziehen. Sie haben damit ihre Umgebung ihren verändernden Bedürfnissen angepasst.
Und genau das machen Workarounds - mit ihnen adressiert man Bedürfnisse und Lösungen, um Umgebungen anzupassen.

Bei Unternehmen ist dies nicht anders. Wenn man genauer hinschaut, kann man überall „Workarounds“ erkennen: Das interne Netzwerk unter Kollegen, mit dem Dinge inoffiziell erledigt werden. Die individuelle Anpassung des Arbeitsplatzes, damit die Arbeit leichter fällt. Auch kleine Gedächtnisstützen gehören dazu. Diese Behelfslösungen geben Aufschluss darüber, wo im Unternehmen Wertströme behindert werden.

Hat man „Workarounds“ entdeckt, kann man überlegen, welches Problem dahintersteckt. Was möchte der Mitarbeiter oder das Team erreichen? Wieso kommt dafür ein „Workaround“ zum Einsatz? Welcher Vorteil entsteht dadurch? Es gibt mehrere Möglichkeiten, dies in Erfahrung zu bringen. Man kann die Betreffenden danach fragen, man kann beobachten. Oder noch besser: Man arbeitet mit dem Team daran, das Problem zu beschreiben.

Stellen sie sich zum Beispiel vor, sie entwickeln ein System zur Spezifikation von Produkten. Die Zusammensetzung des Teams ist gut. Erfahrene Anwender sind eng eingebunden, sie leisten gute Arbeit und sind von Unterbrechungen abgeschirmt. Und doch gibt es Missverständnisse. Es läuft nicht richtig glatt. Sie können nicht greifen, woran das liegt.

Hier kommt einer Methodik aus der nutzerorientierten Produktentwicklung, dem sogenannten „User Journey Mapping“ zum Tragen. Hierbei folgt man dem User durch den gesamten Prozess und visualisiert all seine Schritte, mit „User Stories“. Eine „User Story“ gibt sinnbildlich das zu Entwickelnde wieder und ist somit jenes Element, dem man entlang der Wertschöpfungskette folgen kann.

Der Wert von User Stories


Setzen sie sich im Team zusammen und markieren ihre Rollen mit Klebezetteln in unterschiedlichen Farben. Dann schreiben sie jeden einzelnen Schritt auf, mit dem sie an einer bestimmten „Story“ beteiligt waren – vom ersten bis zum letzten Kontakt.
Agiles Projektmanagement: Die Story wird festgelegt

Wenn das Ergebnis schließlich als Schaubild an der Wand hängt, erkennen sie Muster. Wer war wann an welcher Story beteiligt? Wer war gar nicht beteiligt? Wo gab es viele und wo gab es wenige Ereignisse? Sie erhalten dadurch ein Gesamtbild der Abläufe und können gemeinsam überlegen, wo sie sich verbessern wollten.

Diese Übung ist besonders wertvoll, weil alle Betroffenen beteiligt sind. Auch wenn man Interviews führt oder sich zunächst auf Einzelpersonen konzentriert, kommt irgendwann der Zeitpunkt, an dem man das entstandene Bild teilen muss, um ein gemeinsames Bild der Situation zu schaffen.

Lösungsfindung durch Experimentieren


Wie kommt man jetzt zur Lösungsfindung? In der Produktentwicklung arbeiten wir iterativ, das heißt, wir nähern uns einer Lösung schrittweise an. Wir probieren etwas aus, zeigen es dem Kunden, holen seine Meinung ein und lernen daraus. Danach geht der Prozess von vorne los.

Bei Unternehmen funktioniert es auf die gleiche Art und Weise. Man überlegt sich ein Experiment, mit dem man glaubt eine Verbesserung erreichen zu können. Man setzt sich einen zeitlichen Rahmen und beobachtet, ob sich innerhalb dieses Zeitfensters etwas verbessert. Selbst wenn ein Experiment nicht erfolgreich ist, lernt man daraus. Hierdurch versteht man das Problem besser und erhöht die Chance mit dem nächsten Experiment richtig zu liegen.

Überall wird derzeit auf DevOps umgestellt. Dieser Wandel berührt viele Bereiche: Starre Abteilungsgrenzen werden aufgebrochen. Menschen arbeiten anders zusammen, als sie es bisher gewohnt waren, Aufgabengebiete und Verantwortungen verschieben sich. In genau so einer Situation findet man bei genauer Betrachtung jede Menge Workarounds.

Egal wie starr die Grenzen, wie streng die „Silos“ innerhalb eines Unternehmens voneinander getrennt sind – schon immer gab es Menschen, die sich irgendwie darüber hinweggesetzt haben. Wer kennt wen, wer kann einem bei seinen Aufgaben behilflich sein? Hier sollte man bei der Lösungsfindung ansetzen. Man sollte diese Menschen mit ihren Workarounds ins Boot holen und mit ihnen die ersten Experimente durchführen. Man bittet die Mitarbeiter so vorzugehen, wie sie es sonst auch tun würden und zeigt die Vorteile eines solchen Handelns auf. Was kann man dabei lernen? Und wie kann dieses Wissen verbreitet werden?

Roadmapping, um Ziele zu verfolgen


Es sieht aus wie ein großer Schritt: einen Blocker im Team zu beseitigen, um dann schlussendlich ein Starteam zu werden. Jede Journey beginnt mit einem ersten Schritte.

In der Produktentwicklung erstellen wir eine Roadmap, um den Bezug zwischen dem was wir heute tun und dem Ziel nicht aus den Augen zu verlieren. Das heißt, nachdem man die derzeitige Situation hinreichend verstanden hat, sollte man formulieren wie die Zukunft idealerweise aussehen könnte. Wir nennen das den Zielzustand. Wie bei einer Produktvision hat man dann ein Ziel, auf das man hinarbeiten kann. So können sich Experimente Schritt für Schritt entwickeln, ohne das Ziel aus den Augen zu verlieren. Es empfiehlt sich auch, Folgemaßnahmen für Experimente festzulegen. Denn die Frage, die es zu beantworten gilt, lautet stets: Was haben wir gelernt, das uns näher an den Zielzustand bringt?

Schauen wir uns noch einmal das Beispiel der DevOps an. DevOps bringen viele Facetten mit, aber wahrscheinlich auch jede Menge Missverständnisse. Eine Roadmap hilft dabei, das Ziel visualisiert vor Augen zu halten. Gleichzeitig werden damit aber auch einzelne Schritte festgelegt und wie man sie umsetzen kann. Um nun dem DevOps Ziel näher zu kommen, können verschiedene Bereiche an einer Wand aufgeführt werden: z.B. Automation: das Entfernen von Prozessbarrieren, engere Zusammenarbeit und der notwendige Code für Infrastruktur. Jetzt können sie mit ihrem Experiment in diesen 3 Richtungen weiterarbeiten und somit sicherstellen, dass sie somit ihrem Ziel näherkommen.

Skalierung des Erfolges auch ins Unternehmen


Wenn man sinnvolle Experimente entwickelt und Erfolge erzielt, kann man sich über das Wertvollste freuen, auf das ein Designer hoffen kann: Persönliche Empfehlung. Erfolgsgeschichten, die sich in einem Bereich des Unternehmens ereignen, verbreiten sich überall. Die Mitarbeiter, die eine neue Lösung zuerst ausprobieren, ziehen schließlich die Mehrheit mit und der Wandel verbreitet sich im gesamten Unternehmen.

Ein Hilfsmittel, mit dem der Funke leichter überspringt, sind Visualisierungen, sogenannte „Information Radiators“. Wenn dem Team mit einem Schaubild vor Augen geführt wird, was gerade geschieht, fällt es leichter, Ideen zu übernehmen oder sich aktiv einzubringen. Darüber hinaus macht ein Schaubild den Wandel sichtbar. Die Menschen werden neugierig und beginnen, Fragen zu stellen. Wenn man ein Unternehmen betritt, in dem wir gerade einen Wandel begleiten, ist es sofort sichtbar, wo dieser Wandel stattfindet. Neugier wird erzeugt und es spricht sich herum. Zusätzlich veranstalten wir sogenannte „Lunch and Learns“. Man lädt alle Interessierten ein und berichtet über die letzten Experimente.

Das Unternehmen ist voller Nutzer


Die beschriebenen Maßnahmen funktionieren auf allen Unternehmensebenen. Alle Personen, die auf dem Organigramm eines Unternehmens namentlich genannt werden, sind in irgendeiner Form Nutzer im Unternehmen. Die Strategie ist ein zentrales Element in jedem Unternehmen. Allerdings wird diese von Menschen erarbeitet. Wer ist im Unternehmen für die strategische Ausrichtung verantwortlich? Es kann zum Beispiel sinnvoll sein, mit dieser Gruppe zu beginnen. Was braucht sie, um eine moderne und durchschlagende Strategie zu entwickeln? Wodurch wird ihre Arbeit erschwert?

Unabhängig davon, ob man im Team, in einer Strategiegruppe oder einer anderen Gruppe beginnt – der Prozess ist immer derselbe: Es gilt, das Problem zu verstehen, das Ziel zu erarbeiten und mit dem Experimentieren zu beginnen. Sobald man eine Nutzergruppe ausgewählt hat, legt man los!

Hinweis: Die in diesem Artikel geäußerten Aussagen und Meinungen sind die der Autor:innen und spiegeln nicht zwingend die Position von Thoughtworks wider.

Bleiben Sie auf dem Laufenden mit Hilfe den neuesten Insights