„Unsere höchste Priorität ist es, Kunden durch eine frühe und kontinuierliche Auslieferung wertvoller Software zufriedenzustellen.“

Nicht umsonst steht diese Aussage als erster Leitsatz im Agilen Manifest. Er beschreibt das Ziel, das agile Teams weltweit jeden Tag mit unterschiedlichem Erfolg verfolgen. Forrester Research zufolge verzeichnet der Low-Code-Markt ein Wachstum von fast 40% – denn er soll Unternehmen dabei unterstützen, dieses oft schwierige Ziel durch ein schnelleres Erstellen, Testen und Bereitstellen von Software zu erreichen.

Darüber hinaus hat eine kürzlich durchgeführte Studie über den Stand der Applikationsentwicklung ergeben, dass Unternehmen, die Low-Code eingeführt haben, eine 8% höhere organisatorische Agilität aufweisen als Unternehmen ohne Low-Code.

Eine ausgereifte agile Kultur hilft Unternehmen, die Vorteile von Low-Code-Entwicklungsplattformen zu maximieren, da die schnelle Entscheidungsfindung von Agile mit einer hohen Entwicklungsgeschwindigkeit kombiniert werden. Dennoch übersehen viele agile Teams, dass an ihren bestehenden agilen Praktiken bestimmte Anpassungen erforderlich sind, um die Leistung mit einer Low-Code-Plattform zu maximieren.

Die größten Herausforderungen bei der Einführung von Low-Code in Ihrem agilen Team

Ob Sie in einem Unternehmen arbeiten, das Low-Code in Erwägung zieht, bereits Teil eines Low-Code-Entwicklungsteams sind oder in einem leistungsstarken agilen Team arbeiten, das sich für Low-Code interessiert: Es empfiehlt sich, drei Aspekte der Low-Code-Entwicklung genauer zu betrachten und zu überlegen, wie Sie den agilen Ansatz Ihres Unternehmens entsprechend anpassen können.

1. Low-Code-Entwicklung ist wirklich schneller

Selbst leistungsstarke und erfahrene agile Teams sind selten auf die gesteigerte Entwicklungsgeschwindigkeit vorbereitet, wenn sie zum ersten Mal mit Low-Code arbeiten. Agile Teams, die noch auf dem Weg zur agilen Reife sind, empfinden die Anpassung an das hohe Tempo von Low-Code als noch schwieriger.

Teams haben aufgrund der erhöhten Entwicklungsgeschwindigkeit oft Schwierigkeiten, einen ausreichenden Backlog mit entwicklungsfähigen User Stories zu führen. Dies kann zu Problemen wie diesen führen:

  • Entwicklung von User Stories mit geringem Wert, weil keine anderen fertig sind.
  • Start von Sprints ohne genügend feste Stories.
  • Im Extremfall haben Entwickler schlichtweg nichts zu tun.

Die Pflege eines gesunden Backlogs kann für alle Teams eine Herausforderung darstellen. Doch die Geschwindigkeit von Low-Code kann diese Aufgabe noch erschweren.

2. Geschwindigkeit mit Qualität

Während Geschwindigkeit eine wichtige Metrik für den Wert von Low-Code ist, ist Geschwindigkeit mit Qualität das ultimative Ziel. Neben der Erstellung und Pflege eines Backlogs mit User Storys kann es für Teams, für die Low-Code noch neu ist, schwierig sein, mit ihrem bisherigen agilen Ansatz gleich zu Beginn des Prozesses die erforderliche Qualität zu erreichen.

Wenn Qualitätsansprüche nicht von Anfang an in den Prozess integriert sind, fällt es den Testteams oft schwer, mit neuen Entwicklungen Schritt zu halten und vor allem den Zyklus der Fehlerbehebung zu bewältigen. Das führt dazu, dass am Ende eines jeden Sprints weniger User Stories die „Definition of Done“ erfüllen.

3. Stakeholder bewegen sich mit unterschiedlichen Geschwindigkeiten

Eine weitere häufige Herausforderung für Low-Code-Teams, die in großen Organisationen oder Projekten mit vielen Integrationspunkten arbeiten, ist der erhebliche Unterschied der Entwicklungsgeschwindigkeit von koabhängigen Teams. Teams, die mit Low-Code Enterprise-Applikationen erstellen und dabei Abhängigkeiten von internen und externen Teams haben, die ihrerseits mit Wasserfallmodellen oder Prozessen mit geringem agilem Reifegrad arbeiten, sind oft in ihrer Arbeit behindert oder blockiert.

Selbst Wasserfall-Teams, die an die Zusammenarbeit mit agilen Teams gewöhnt sind, sind oft nicht auf die Anforderungen vorbereitet, die sich aus der Kollaboration mit einem noch produktiveren Low-Code-Team ergeben. Dies kann zu verpassten Terminen, teuren API-Mocks und erhöhten technischen Schulden führen.

Maximieren der Leistung von Low-Code: Tipps und Tricks

Agile Teams, für die die Low-Code-Entwicklung noch neu ist, versuchen oft, das Tempo zu halten, indem sie geringfügige Änderungen an ihrem Prozess vornehmen oder – häufiger noch – einfach länger arbeiten. Letzteres führt jedoch kaum zu Verbesserungen und meist zu einer schlechteren Arbeitsmoral im Team.

Anstatt mehr Stunden in das Problem zu investieren, sollten agile Teams nach Möglichkeiten suchen, ihre agilen Prozesse in fünf wichtigen Bereichen anzupassen und zu verbessern, um die erreichte Qualität mit der Geschwindigkeit zu kombinieren, die sich aus der Entwicklung mit Low-Code-Plattformen ergibt.

Fokus auf den Backlog

Wenn Sie keinen guten Product Owner haben, sollten Sie sich sofort einen suchen. Denn diese Rolle ist von enormer Bedeutung für Ihren Erfolg.

Wir sagen es immer wieder, und es stimmt: Insbesondere bei der Entwicklung mit Low-Code beginnt der Erfolg mit einem kompetenten Product Owner, der engagiert, einflussreich und reaktionsschnell ist. Wenn Sie z. B. daran gewöhnt sind, den Backlog einmal pro Woche oder einmal pro Sprint zu überarbeiten, gilt es nun, die Frequenz zu erhöhen. Für einen gut gepflegten Backlog von Stories und die „Definition of Ready“ braucht es tägliche Aufmerksamkeit und einen schnellen Entscheidungsprozess über die Priorität, den Inhalt und die Akzeptanzkriterien Ihrer User Stories.

Die Anforderungen an Ihre Stakeholder außerhalb der IT werden ebenfalls steigen. Sie werden mehr Funktionen zur Überprüfung und Freigabe bereitstellen, und dies schneller als bei einem Projekt ohne Low-Code. Die Stakeholder, auf die Sie sich bei der Bereitstellung von Anforderungen, Dokumentation und Feedback für die Erstellung und die Pflege des Backlogs verlassen, müssen nun schneller reagieren als bisher.

Da es meistens genau die Stakeholder sind, die die Applikation angefordert haben, dürften sie sich über diesen Umstand freuen. Zugleich sollten sie aber verstehen, dass sie mehr Verantwortung tragen und Informationen und Feedback umgehend weitergeben müssen. Wahrscheinlich ist es nötig, mehr Schulungen, Rollendefinitionen und eine häufigere Zusammenarbeit mit den Stakeholdern einzuplanen.

Alle Teammitglieder (nicht nur diejenigen, die User Stories erstellen) sollten wissen, wie User Stories in einem einheitlichen Format und mit klaren Akzeptanzkriterien geschrieben werden. Während der Entwicklung müssen die Teammitglieder User Stories oft verstehen, interpretieren und spontan konstruktive Verbesserungsvorschläge machen. Im Zusammenhang mit Low-Code kann hilfreich sein, User Stories kurz zu halten, da dies die Entwicklung vereinfacht, den Durchsatz erhöht und die Tests entsprechend den schnelleren Entwicklungszyklen verkürzt. Wenn Sie lange Stories schreiben oder keine Akzeptanzkriterien verwenden, sollten Sie dies ändern oder um Hilfe bitten.

Verbessern Sie die Zusammenarbeit

Viele Low-Code-Plattformen machen es technischen und nicht-technischen Teammitgliedern und Stakeholdern leicht, in Echtzeit zusammenzuarbeiten und den Entwicklungszyklus zu verkürzen.

Bei der Erstellung neuer Funktionen können Entwickler und Business-Analysten von Beginn des Entwicklungszyklus an zusammenarbeiten, insbesondere bei komplexen User Stories. Einige Low-Code-Plattformen enthalten z. B. eine Workflow-Visualisierung, mit der der Entwickler die Geschäftslogik und die Daten im Code visuell in einer nichttechnischen Sprache darstellen kann. Daraufhin gibt der Analyst Feedback, der Entwickler nimmt Änderungen vor, und die Änderungen können in Echtzeit getestet werden. So lassen sich Fehler, fehlende Anforderungen und kostspielige Feedback-Zyklen deutlich reduzieren.

Bei der Feinabstimmung von Stories während eines Sprints erfordern traditionelle Entwicklungsplattformen asynchrone Feedbackschleifen, bei denen der Benutzer die Story erstellt, der Entwickler den Code schreibt, testet und bereitstellt, und der Benutzer die Seite überprüft. Mit Low-Code können Benutzer und Entwickler einen Bildschirm regelmäßig gemeinsam überprüfen und Änderungen besprechen. Anschließend kann der Entwickler die Änderung umsetzen und den Code veröffentlichen, den der Benutzer und der Entwickler wieder gemeinsam prüfen können – in Echtzeit. Dies erfordert eine Änderung des aktuellen Prozesses. Doch die Verringerung der Zykluszeit und unnötiger Arbeit ist erheblich. Eine Investition in die Anpassung Ihres Prozesses zahlt sich also aus.

Entwickler und QA-Tester, die zusammenarbeiten, können die Zykluszeit für Fehlerbehebungen verkürzen. Wie in dem bereits erwähnten Beispiel lassen leistungsstarke Teams Entwickler und QA-Teammitglieder häufig in Echtzeit zusammenarbeiten, um Fehler zu beheben, anstatt den zeitaufwändigen Prozess der Identifizierung, Dokumentation, Einstufung, Priorisierung, Behebung und erneuten Prüfung von Fehlern zu durchlaufen.

Eliminieren (oder verringern) Sie Abhängigkeiten frühzeitig

Produkte sind heute fast immer in irgendeiner Form von Integrationspunkten, Daten, Sicherheitsanforderungen oder anderen Dingen abhängig. Wenn Ihr Team mit Low-Code arbeitet und das andere Team nicht, müssen Sie Ihren Ansatz ändern, um entsprechende Abhängigkeiten deutlich früher als bisher zu erkennen und abzuschwächen. Es gibt kein Patentrezept, um dieses Problem zu lösen, aber einige Optionen:

  • Achten Sie mehr darauf, mögliche Abhängigkeiten zu identifizieren.
  • Markieren Sie selbst risikoarme Abhängigkeiten und verfolgen Sie sie täglich.
  • Verhandeln Sie kürzere SLAs mit dem abhängigen Team.
  • Entfernen Sie die Abhängigkeit, indem Sie Ihr Produkt in Low-Code erstellen.

Sie sollten es vermeiden, immer wieder Workarounds wie API-Mocks zu erstellen, die aufgrund von Änderungen an bestehenden Funktionen, höheren technischen Schulden und doppelten Tests die Geschwindigkeit verringern. Wichtig ist, dass Sie erkennen: Strategien, die früher funktioniert haben, sind bei der Entwicklung mit Low-Code wahrscheinlich weniger effektiv.

Steigern Sie die Effizienz von Zeremonien

Während Sie mit Agile reifen, sollten Sie nach Möglichkeiten suchen, agile Zeremonien zu verschlanken, ohne dass dabei ihr Wert oder ihre Absicht verloren geht. Ein Low-Code-Entwicklungsprojekt ist die perfekte Gelegenheit, um mit diesen Änderungen zu experimentieren und sie umzusetzen.

Wenn Sie mit der Entwicklung mit Low-Code beginnen, schreiben Sie vielleicht weiterhin zu detaillierte User Stories und erstellen mehr unterstützende Dokumentation als nötig. Dieser Ansatz kann die Überarbeitung des Backlogs und die Sprint-Planung in die Länge ziehen, da das Team eine große Menge an Informationen zu prüfen und verarbeiten hat.

Diesen Ansatz fortzusetzen und zugleich mit der Entwicklungsgeschwindigkeit mitzuhalten, wird sich als schwierig erweisen. Konzentrieren Sie sich auf kurze, prägnante User Stories, damit Ihre Teams das Backlog-Refinement und die Sprint-Planung beschleunigen (oder den Durchsatz an Stories erhöhen) können. Nutzen Sie auch die intensive Zusammenarbeit, die mit Low-Code während der Entwicklung möglich ist, um die Stories weiter zu verfeinern.

Darüber hinaus lassen sich überflüssige Zyklen mit weiteren Techniken reduzieren. Wenn Sie z. B. Ihre Kriterien der „Definition of Ready“ in das User-Story-Formular Ihres agilen Projektmanagement-Tools integrieren, können Sie fehlende Kriterien bereits beim Refinement entdecken.

Da Stories mit Low-Code schnell entwickelt sind, sollten die Teams die für Estimations benötigte Zeit unter die Lupe nehmen und nach Möglichkeit reduzieren. Ein höherer Zeitaufwand für Schätzungen führt nicht immer zu besseren Ergebnissen und geht zu Lasten der Entwicklung und Bereitstellung von Software. Wenn Sie es nicht bereits tun, sollten Sie für Ihre Schätzungen relative Größen verwenden, wie z. B. T-Shirt-Größen oder Techniken wie Planning Poker. Hier wird nicht mit Stunden geplant, sondern mittels einer Fibonacci-Folge.

Schließlich können ausgereifte agile Teams, die Low-Code verwenden, eine Verkürzung der Sprint-Dauer in Erwägung ziehen, um Anwendern wertvolle Software schneller zu liefern als es mit traditionellen Plattformen möglich ist. Ihre Projektzeremonien können Sie individuell gestalten. Wenn Sie z. B. von zweiwöchigen zu einwöchigen Sprints übergehen, kann es sinnvoll sein, weiterhin nur alle zwei Wochen Retrospektiven abzuhalten.

Wie bei allem im Bereich Agile sollten Sie experimentieren und schauen, was funktioniert.

Effektive Retrospektiven

Wenn Sie den Schritt zur Low-Code-Entwicklung wagen, müssen Sie bereit sein, Ihr Tempo der kontinuierlichen Verbesserungen zu beschleunigen. Wenn Sie nicht regelmäßig Bereiche identifizieren, die sich optimieren lassen, und neue Ansätze umsetzen, schränken Sie die Geschwindigkeit und den Wert von Low-Code ein. Seien Sie in Bezug auf die Effektivität Ihrer Retrospektiven ehrlich. Wenn sie nicht funktionieren, sollten Sie etwas unternehmen. Sprechen Sie mit jemandem aus Ihrem Netzwerk oder suchen Sie online nach einem neuen Spiel oder einer neuen Übung. Vielleicht können Sie auch einen Außenstehenden für die Moderation hinzuzuziehen, das Meeting an einen anderen Ort verlegen oder das Team auf andere Weise aus seiner Komfortzone locken.

Wie fangen Sie an?

Ganz gleich, ob Sie sich bereits mit Agile und Low-Code auskennen oder gerade erst anfangen – es wird spannend! Denn Sie werden Ihre Arbeit und Ihren aktuellen agilen Ansatz anpassen müssen, um mit dem beschleunigten Entwicklungstempo Schritt zu halten.

Beginnen Sie damit, Ihren Backlog genau unter die Lupe zu nehmen und zu schauen, wie sie ihn verwalten. Sie brauchen einen starken Product Owner, gute Beziehungen zu den Stakeholdern und eine Kultur, die schnelle Entscheidungen unterstützt. Fördern und fordern Sie die Zusammenarbeit zwischen allen Beteiligten, insbesondere Ihrem Projektteam. Antizipieren, identifizieren und lösen Sie aktiv potenzielle Abhängigkeiten, insbesondere mit Teams, die auf traditionellen Entwicklungsplattformen arbeiten. Und nicht zuletzt: Fordern Sie Ihr Team heraus, die Effizienz und Effektivität agiler Zeremonien zu steigern, um mit Low-Code die maximale Leistung zu erzielen.

Agile und Low-Code sind wie füreinander geschaffen und eröffnen eine Vielzahl von Chancen und Möglichkeiten, die Entwicklung von Produkten zu verändern. Wenn Sie gleich loslegen möchten, können Sie OutSystems einfach ausprobieren. Wir wünschen Ihnen viel Spaß!