Wie unterscheiden sich No-Code und Low-Code Projekte von agilen Projekten?

Wie unterscheiden sich No-Code und Low-Code Projekte von agilen Projekten?

No-Code und Low-Code sind aktuell sehr gefragt. Fast täglich liest man nicht mehr nur in Fachzeitschriften über diese Begriffe. Natürlich sind die offensichtlichen Vorteile von No-Code und Low-Code Projekten klar ersichtlich. Man braucht weniger Zeit, weniger Budget und kann dem Fachkräftemangel entgegenwirken. Diese Vorteile ergeben sich jedoch nicht nur aus der Technologie ein. Das Projekt Set-up unterscheidet sich bei No-Code und Low-Code Projekten im Vergleich zu klassischen oder agilen Softwareentwicklungsprojekten.

In diesem Artikel möchte ich auf diese Unterschiede eingehen und zeigen, warum gerade kleine und autarke Entwicklungsteams mit der No-Code und Low-Code Entwicklung viel erfolgreicher sein können.

Wie verändert sich sie Teamzusammensetzung bei No-Code und Low-Code Projekten?

In der agilen Softwareentwicklung werden die verschiedenen Rollen in einem Softwareentwicklungsprojekt häufig nach den Scrum-Rollen unterteilt. Diese werden unterschieden zwischen Softwareentwicklern, Scrum Master und Product Owner. Bei den Softwareentwicklern wird in der Praxis meist nach Einsatzgebiet differenziert. Oftmals wird zwischen Backend und Frontend unterschieden. Aber auch zwischen den Plattformen der Entwicklung von mobilen Apps gibt es eine Unterscheidung zwischen Android und iOS.

Long story short, es gibt sehr viele Rollen, mit einer Spezialisierung auf den entsprechenden Anwendungsbereich. Das kostet natürlich viel Geld. Personen müssen bezahlt und organisiert werden. Wobei die Organisation wiederum einiges an Budget kostet.

Teamzusammensetzung bei No-Code und Low-Code Projekten

Bei der No-Code oder Low-Code Entwicklung gibt es die Unterscheidung zwischen Frontend und Backend meistens nicht. Das liegt vor allem daran, dass die Entwicklung des Interfaces und die Entwicklung von der Businesslogik in den gleichen No-Code oder Low-Code Plattform geschieht. Es ist viel mehr ein fließender Übergang zwischen den Disziplinen. So kommt es sehr häufig vor, dass eine Applikation komplett von einem Entwickler entwickelt wird. Hinzu kommt in der Regel die Qualitätskontrolle durch einen zweiten Entwickler. Dadurch, dass die Entwicklung auch sehr schnell ist, wäre es sogar in vielen Fällen hinderlich die Disziplinen zu trennen.

Teamzusammensetzung bei No-Code und Low-Code Projekten

Viele No-Code und Low-Code Entwickler haben auch unterschiedliche Berufserfahrungen oder Studienabschlüsse. Sie sind daher nicht spezialisiert auf einzelne Disziplinen. Ausnahmen gibt es für sehr spezielle Gebiete wie z.B. die Entwicklung von Plug-Ins oder die Integration von AWS Services.

Die meisten Entwickler beherrschen auch eine Vielzahl von No-Code Plattformen. Daher ist es keine Seltenheit, dass ein Entwickler eine Webapplikation und eine native App mit No-Code entwickeln kann.

Eine weitere Rolle, welche es vor allem bei No-Code Entwicklern mit viel Berufserfahrung nicht gibt, ist der Product Owner. Beispielsweise habe ich selbst jahrelang als Product Owner gearbeitet und kann daher aus losen Anforderungen eine Softwareapplikation bauen. Hierbei kommt es sehr stark darauf an, mit wem man zusammen arbeitet (wie auch in allen anderen Bereichen ;))

Die Rolle des Scrum-Masters habe ich bei keinem einzigen No-Code oder Low-Code Projekt gesehen. Das hat vor allem was mit der deutlichen kleineren Teamzusammensetzung, als auch der kürzeren Projektlaufzeit zu tun.

Weniger Projektmeetings

Ein sehr großer Vorteil für mich persönlich ist, dass ich deutlich weniger Projektmeetings habe, als im Vergleich zur agilen Softwareentwicklung. Das hat viele verschiedene Gründe. Erstens sind die Teams deutlich kleiner. In der Regel nicht mehr als insgesamt 2-4 Personen. Die Notwendigkeit sich in unterschiedlichen Konstellationen abzustimmen ist deutlich geringer.

Ein weiterer Grund ist, dass der Kunde / Projektleiter / Product Owner sehr genau den Projektfortschritt nachvollziehen kann. Das ist meiner Meinung nach ein Vorteil von No-Code und Low-Code, welche viel zu wenig berücksichtigt wird. Es ist überhaupt kein Problem, die entsprechenden Projektmitglieder in die Applikation mit einzubinden. Entweder als Editor oder als Beobachter. Dadurch, dass die Entwicklungsumgebung auch für nicht Softwareentwickler verständlich ist, gibt es viel mehr Transparenz. Es ist überhaupt keine Seltenheit, dass wir nach bereits nach 2-3 Tagen eine erste Version deployen, sodass der Kunde direkt einen Einblick bekommt.

Die Zusammenarbeit untereinander wird daher deutlich agiler, da Ergebnisse und Fortschritte für alle einsehbar sind und direkt Feedback gegeben werden kann (z.B. über E-Mail, Kanban Board, etc.).

Des Weiteren können die Projektmeetings auch effektiver genutzt werden. Durch die deutlich schnellere Entwicklung ist kein Problem direkt Anpassungen zusammen mit den Projektbeteiligten durchzuführen. Es muss also nicht besprochen und dokumentiert werden, wie etwas aussehen soll. Stattdessen wird es direkt implementiert.

Mehr Praxis, weniger Theorie

Wer kennt es nicht, die Planung von Softwareprojekten kann ziemlich lange dauern. Selbst bei der agilen Softwareentwicklung werden Stunden benötigt für Plannings oder Refinement. Die Meilensteinplanung wird in Power-Points überführt. Obwohl man doch weiß, dass komplexe Softwareprojekte sehr schwer zu planen sind.

Bei der Entwicklung mit No-Code oder Low-Code gibt es natürlich auch eine Planung. Allerdings ist diese viel übersichtlicher und weniger granular. Warum? Nun ja, einzelne Aufgaben benötigen teilweise nur wenige Stunden für die Umsetzung. Beispielsweise die Integration von Zahlungsdienstleistern. Solch eine Aufgabe ist für einen geübten No-Code Entwickler eine Sache von wenigen Stunden. Damit kann die Planung in viel größeren Arbeitspaketen erfolgen.

Durch die kleinere Teamzusammensetzung können auch die unliebsamen Abhängigkeiten eliminiert oder zumindest reduziert werden. Ein Feature oder sogar die ganze Applikation wird autark entwickelt. Dadurch entstehen keine Wartezeiten, welche in der Planung berücksichtigt werden müssen.

Viel mehr Zeit kann dabei man für die Umsetzung verwenden, als nur für die Planung.

Kürzere Projektlaufzeiten durch No-Code und Low-Code

Die reduzierte Geschwindigkeit ist wohl einer der größten Vorteile von No-Code und Low-Code. Aber warum sind die Projektlaufzeiten eigentlich so viel geringer? Das liegt zum Teil natürlich an der Technologie. Mit visuellen Editoren lassen sich Oberflächen und Workflows zusammen klicken und müssen nicht zeilenweise programmiert werden.

Ein weiterer Vorteil liegt auch bei der Wiederverwendbarkeit. Einmal gebaute grafische Elemente können innerhalb verschiedener Applikationen erneut verwendet werden. Hierbei bedarf es jedoch eine individuelle Anpassung. Ich würde davon abraten, alle visuelle Elemente nur zu kopieren. Je nach Fall, kann die Anpassung länger dauern, als das Element erneut zu entwickeln.

Viel besser ist dagegen, Plug-Ins für Business Logik oder externe Anbindungen zu entwickeln. Diese werden meist von Natur aus so gebaut, dass sie von verschiedenen Applikationen nutzbar sind.

Eine Kombination der bereits genannten Punkte ist ebenfalls ein Grund für die deutlich kürzeren Projektlaufzeiten. Durch die kleineren Teams, die schlankere Planung, ist mehr Zeit für die eigentlich Entwicklung vorhanden.

Des Weiteren reduziert sich durch die häufigen Deployments das Risiko aneinander vorbeizureden und nicht die gewünschte Funktionalität zu entwickeln. Wie bereits geschrieben sind erste Deployments nach 2-3 Tagen keine Seltenheit.

Ein durchschnittliches Projekt dauert in etwa 2-3 Monate, manchmal sogar kürzer. Durch diese kürzeren Projektlaufzeiten ergeben sich auch viel weniger sogenannte „Durchhänger“. Aus meiner Erfahrung als Teamleiter kann ich nur sagen, dass es völlig normal ist, dass die Motivation nach oft monatelanger Entwicklung nachlässt. Ohne erste Erfolgserlebnisse oder erreichte Meilensteine fällt es manchmal schwer 100 % Leistung zu geben.

Diesen Umstand gibt es fast nie bei No-Code oder Low-Code Projekten. Gerade, wenn sie von erfahrenen Entwicklern durchgeführt werden.