Die Zahlen wirken ernüchternd: Nach einer Studie des Project Management Instituts aus dem Jahr 2017 reißt nahezu jedes zweite Softwareprojekt die Deadline. Jedes dritte Projekt verfehlt das Ziel. Die Gründe dafür erscheinen häufig ebenso verheerend wie vorhersehbar, wie der nachfolgende Blick auf zehn prominente Energiefresser in der Produktentwicklung zeigt.
Viele Softwareprojekte starten bereits mit großem Zeitdruck, weil sie nicht vom Projektziel und dem tatsächlichen Bedarf her gedacht werden, sondern primär durch Wünsche und Befindlichkeiten geprägt sind. So möchte beispielsweise der Marketingchef den Launch der neuen App mit dem Beginn einer wichtigen Messe verbinden oder die Geschäftsführung im Rahmen eines Prestigeprojektes sehr schnell mit einer neuen Softwarelösung aufwarten. Die möglichen Folgen: Zeitdruck von Anfang an und eine überhastete Planung, die sich meist nicht an den Bedürfnissen der späteren Anwender*innen, sondern an den Wünschen einzelner Stakeholder orientiert.
Eine überhastete Planung hat häufig auch eine unrealistische Timeline zur Folge, die fast zwangsläufig zum Reißen der Deadline führt. Zugleich können fehlende Zeitpuffer das Projekt gefährden. Zeitplanungen sollten daher immer auch unvorhergesehene Ereignisse, wie Veränderungen im Unternehmen oder auf dem Markt sowie Zeitfenster für ausführliche Tests und das Beheben von Fehlern, berücksichtigen.
Noch immer werden viele Softwarelösungen entwickelt, ohne die späteren Anwender*innen ausreichend zu beteiligen. Dies wird jedoch schnell zu einem Hemmschuh für das gesamte Projekt: Werden Anforderungen und Wünsche der Anwender*innen nicht von Anfang an gehört und berücksichtigt, bringt dies später einen hohen Korrekturaufwand mit sich. Im Extremfall wird die Software sogar vollständig abgelehnt, das Projekt ist gescheitert.
Ein frühzeitiger Einbezug der späteren User kann den Change-Management-Aufwand vor der Produkteinführung dagegen erheblich senken.
Ein ähnliches Problem, wie die fehlende Menschzentrierung, stellt auch das Silodenken in vielen Unternehmen dar. Einzelne Abteilungen stoßen Softwareprojekte an, ohne andere Abteilungen von Anfang an in die Planung einzubinden und Projektziele gemeinsam abzustimmen. Ein mitunter fataler Fehler, denn neue Softwarelösungen betreffen in Unternehmen meist mehr Menschen und Prozesse, als dies anfangs vermutet wird. Erscheinen die Software und die damit verbundenen Prozesse den betroffenen Mitarbeitenden jedoch nicht als alltagstauglich, kann dies zu Vermeidungsstrategien führen: Anstatt sich mit der neuen Software zu beschäftigen, greifen die Mitarbeitenden auf frühere Systeme zurück oder entwickeln eigene (ggf. auch analoge) Lösungsmöglichkeiten, um ihre Arbeitsprozesse zu gestalten. Das Projekt ist gescheitert oder kann nur mit immensen Nachjustierungen gerettet werden.
Fehlende Absprachen unter den Verantwortlichen, aber auch unter den einzelnen Mitgliedern einer Arbeitsgruppe können zu folgenreichen Missverständnissen und Fehlern führen, die das ganze Projekt gefährden können. Einen guten Ausweg zeigt hierbei der agile Ansatz: So fungieren Product Owner und Scrum Master als Vermittler für eine gute Kommunikation zwischen Stakeholdern und dem Entwicklungsteam. Zugleich bieten das Daily Stand-up und die Retrospektiven am Ende jedes Sprints auch innerhalb des Teams eine gute Möglichkeit, Probleme zu erkennen, Missverständnisse zu vermeiden und gemeinschaftlich aus Fehlern zu lernen.
Für gewöhnlich hat in einem Entwicklungsteam jedes einzelne Teammitglied besondere Steckenpferde, also Themenbereiche, mit denen es sich besonders gerne und intensiv beschäftigt. Es erscheint daher nur konsequent, Teammitglieder primär mit den Entwicklungsaufgaben zu betrauen, die ihren Interessen und Talenten am besten entsprechen. Allerdings sollte dabei darauf geachtet werden, dass sich Teammitglieder nicht in Nebenschauplätzen verzetteln, nur ihre eigenen Aufgaben im Blick haben oder sich in einem übertriebenen Perfektionismus verlieren.
Die Vorteile der agilen Softwareentwicklung zeigen sich auch in der Arbeit in sog. Timeboxen. Dies bedeutet, dass Entwicklungsprojekte nicht primär durch die zu erledigenden Aufgaben strukturiert werden, sondern durch die zur Verfügung stehende Zeit.
Konkret werden Aufgaben dazu in kleine „Aufgabenportionen“ zerlegt, die innerhalb festgelegter Zeitfenster, meist innerhalb eines Sprints, erledigt werden können. So kann vermieden werden, dass das ganze Team ausgebremst wird, weil es große unerledigte Aufgabenpakete vor sich herschiebt, deren Implementierung mit der Zeit immer mehr Ressourcen bindet. Da durch die Arbeit mit Timeboxen Aufgaben besser parallel erledigt werden können, werden zudem auch direkte Abhängigkeiten aufgelöst.
Nichts kann Arbeitsgruppen oder auch ganze Unternehmen so stark ausbremsen wie fehlende Entscheidungen. Werden strategische Festlegungen nicht getroffen, weil sich Führungskräfte nicht einigen können oder sich vor der Verantwortung fürchten, gegebenenfalls auch eine Fehlentscheidung zu treffen, führt dies zur Handlungsunfähigkeit der davon betroffenen Mitarbeitenden. Das Projekt verzögert sich oder scheitert ganz, weil strategische Grundsatzentscheidungen oder Korrekturen ausbleiben.
Es mag reizvoll klingen, neue Softwareprojekte direkt zu starten und sich erst später um eine entsprechende Automatisierung zu kümmern. Werden Automatisierungsstrategien jedoch nicht von Beginn an bedacht, erhöht dies den Aufwand und somit auch die Gefahr von Verzögerungen, die eine spätere Implementierung entsprechender Prozesse mit sich bringt.
Die Empfehlung ist daher eindeutig: Automatisierung von Anfang an, wie auch unser Blogbeitrag „Echte Handarbeit ist gut, automatisierte Handarbeit ist besser“ zeigt.
Analog zu verspäteten Automatisierungsprozessen werden auch Testabläufe in vielen Entwicklungsprojekten zu spät bedacht. Dadurch werden Probleme mit der Software verspätet erkannt, sodass sich der Korrekturaufwand entsprechend erhöht. Grundsätzlich gilt daher: Je später Testroutinen als Frühwarnsysteme für Fehler installiert werden, umso größer wird die Gefahr von Problemen, Verzögerungen oder sogar dem Totalausfall der Software und der beteiligten Systeme.
Die Liste der dargestellten Energiefresser in der Softwareentwicklung mag lang und mächtig erscheinen. Alle Energiefresser verbindet dabei jedoch eine positive Eigenschaft: ihre Vermeidbarkeit. Werden Softwareprojekte von Anfang an mit kühlem Kopf, einem systemischen Blick und offenen Ohren für die Bedürfnisse der betroffenen Menschen geplant, können gefährliche Energiefresser fast immer vermieden werden.
Die einen zaubern an der Tastatur, die anderen auf dem Parkett – tatsächlich verbindet Tänzer*innen und Entwicklungsteams mehr, als man zunächst vermuten könnte. Welche Inspirationen das Tanzen für erfolgreiche Retrospektiven bietet, zeigt Christoph als versierter Tänzer in seinem Blogbeitrag.
WeiterlesenDie Sieben ist die Zahl der Vollkommenheit. Die sieben Merkmale, die sich Sven für den Weg in eine echte agile Arbeitskultur überlegt hat, bescheren Unternehmen dennoch keine „vollkommene Agilität“. Sie können aber in jedem Fall in die richtige Richtung weisen.
Weiterlesen