Anzeige
Anzeige
Artikel
Artikel merken

Agiles Projektmanagement: Scrum, Kanban und Scrumbuts im Einsatz

Agile Projektmanagement-Methoden wie Scrum und Kanban versprechen effiziente Abläufe, motivierte Mitarbeiter und zufriedene Kunden. Doch kann ihr fehlerhafter Einsatz auch das genaue Gegenteil bewirken. Ein Praxisbericht, der Einblicke in Erfolgsmethoden sowie Risiken bei der Umsetzung gewährt.

8 Min. Lesezeit
Anzeige
Anzeige

[metabox keyword=“projektmanagement“]Scrum und Kanban sind mittlerweile populäre agile Methoden, die auch in der Agenturwelt immer mehr Verbreitung finden. Der Grund: Sie helfen IT-Aufträge schneller, sicherer und damit auch erfolgreicher abzuwickeln, als dies mit herkömmlichem Projektmanagement möglich ist. Hinter dem Wort „agil“ verbindet sich dabei die Idee, ein Projekt oder Produkt Schritt für Schritt mit einem sich selbst organisierenden, interdisziplinären Team in Zyklen (Sprints) zu entwickeln. Der Sinn ist, einen Auftrag durch Priorisierung schlank zu halten, Kundenwünsche rasch umzusetzen und auch in späten Projektphasen noch flexibel auf Veränderungen eingehen zu können.

Vision Driven Development

Anzeige
Anzeige

Im klassischen Projektmanagement-Ansatz legt eine Planungs- und Spezifikationsphase – das sogenannte „Big Design Up-Front“ – vorab den Umfang der gesamten zu entwickelnden Lösung fest. Oft stellt der Projektleiter im Laufe der Umsetzung dann fest, dass Zeit und Budget nicht ausreichen, um alles zu bewerkstelligen. Oder er erkennt, dass das Projektteam an den Bedürfnissen des Kunden oder Marktes vorbei gearbeitet hat. Die Folgen dieses „Plan Driven Development“: Stress, Unzufriedenheit und mangelnde Wirtschaftlichkeit.

Agile Methoden stellen das traditionelle Projektmanagement auf den Kopf.

Agile Methoden stellen das traditionelle Projektmanagement auf den Kopf.

Der agile Ansatz definiert hingegen zu Beginn Zeit und Budget als Konstanten – und schaut dann gemeinsam mit dem Kunden, welche Anforderungen sich innerhalb dieses Rahmens umsetzen lassen. Man spricht hier auch von „Vision Driven Development“. Die Vorteile dieser Vorgehensweise liegen auf der Hand: Der Kunde kann von Projektbeginn an mitbestimmen und die einzelnen Aufgaben von Iteration zu Iteration priorisieren (Scope-Management). Detailspezifikationen folgen nur dann, wenn sie tatsächlich auch nötig sind. Außerdem kann das Team Lerneffekte aus vorangegangenen Iterationen direkt für die nächsten Schritte nutzen. Regelmäßige Auslieferungen neuer Versionen, hohe Transparenz und ein klarer Projektfortschritt, bei dem der Umfang und die Qualität der Lösung mit jeder Iteration wachsen, helfen sowohl dem Entwickler-Team als auch dem Kunden – nicht zuletzt, weil regelmäßige Retrospektiven zu einer besseren Stimmung im Team führen.

Anzeige
Anzeige

Du möchtest Scrum besser kennenlernen und verstehen? Unsere Videokurse zeigen dir, wie es geht!

Anzeige
Anzeige

Wie funktioniert Scrum?

Jedes Scrum-Projekt beginnt damit, dass der so genannte Product Owner das Product Backlog herstellt, also eine priorisierte Aufgabenliste für das Team. Kommt der Product Owner nicht direkt vom Kunden, kann dieser auch einen Proxy Product Owner mit dieser Aufgabe betrauen, den der Auftragnehmer stellt. Alle Aufgaben bestehen aus Sprints (Iterationen), fest definierten Zeiträumen von zwei Wochen. Während der Planungsphase – dem Sprint „Planning“ – greift sich das Team die Aufgaben aus dem Product Backlog heraus, die es in der vorgegebenen Zeit realistischerweise umsetzen kann. Gemeinsam entscheidet es, wie es dabei vorgeht (Team Commitment).

Während der Product Owner für den Erfolg des Projekts und den Return on Investment verantwortlich ist, sorgt der Scrum Master dafür, dass alle den Prozess verstehen und einhalten. Außerdem stellt er sicher, dass das Team ungestört arbeiten kann. Das Ergebnis jedes Sprints ist ein Projekt-Inkrement (etwa ein funktionierendes Kunden-Login), dessen Qualität den Review-Prozess bestanden hat und das sich somit an den Kunden ausliefern lässt. Die anschließende Retrospektive überprüft den abgeschlossenen Sprint in Bezug auf die Qualität des Scrum-Prozesses: Wie geht es dem Team? Und funktionieren die Werkzeuge? Zu Beginn des nächsten Sprints wählt das Team die nächsten Aufgaben aus dem Product Backlog, die der Project Owner als besonders relevant definiert hat – und der nächste Sprint beginnt.

Anzeige
Anzeige

Wie lässt sich Kanban anwenden?

Viele Agenturen nutzen Scrum und Kanban für jeweils unterschiedliche Projekte und Teams. Im Gegensatz zu Scrum handelt es sich bei Kanban um eine Methode,, die einen kontinuierlichen Arbeitsfluss (Flow) sicherstellen soll. Dazu visualisiert man alle Aufgaben und Abläufe (also auch die Probleme, die diese behindern) und macht sie somit erkennbar. Dies geschieht mithilfe eines Boards, das in Zeilen und Spalten (Lanes) aufgeteilt ist. An diesem Board wandern alle Aufgaben in Form von Tickets über die einzelnen Spalten. Jede Spalte repräsentiert einen Arbeitsschritt. Somit können Projektbeteiligte jederzeit sehen, welche Aufgabe sich in welchem Status befindet.

Daneben gibt es ein Limit für die Menge parallel laufender Aufgaben. Das heißt, dass in der Spalte „Entwicklung“ zum Beispiel nur vier Tickets auf einmal hängen dürfen. Ziel ist, dass jeder Mitarbeiter möglichst nur an einer Aufgabe arbeitet und nicht an mehreren parallel. Dahinter steht der Flow-Gedanke: Die Tickets sollen möglichst gleichmäßig und ohne lange Wartezeiten oder Blockaden über das Board fließen. Was den Flow behindert, wird betrachtet und gegebenenfalls behoben. Auf diese Art lassen sich Probleme im Prozess sichtbar machen und nach und nach lösen. Im Gegensatz zu Scrum visualisiert Kanban also lediglich den aktuellen Prozess, ändert diesen aber nicht signifikant.

Der Scrum-Prozess: Rund zwei Wochen dauert ein typischer Sprint.

Der Scrum-Prozess: Rund zwei Wochen dauert ein typischer Sprint.

Typische ScrumButs

Die Agentur AOE media begann bereits 2007, die ersten Projekte mit Hilfe agiler Methoden umzusetzen und machte dabei erste praktische Erfahrungen mit Plannings, Reviews und Retrospektiven – und erzielte direkt Erfolge. Die Retrospektiven zeigten schnell, dass sich Scrum stetig verbessern lässt. An dieser Stelle ist jedoch Vorsicht geboten: Wer Scrum einführt, für den ist die Versuchung oftmals groß, direkt eigene Modifikationen an Scrum vorzunehmen (ScrumButs ) und wichtige Elemente wegzurationalisieren. Doch oft zeigt sich, dass man die für den Erfolg existenzielle Bedeutung dieser Elemente nur noch nicht verstanden hat. Typische Beispiele für so einen ScrumBut sind:

Anzeige
Anzeige

Wir nutzen Scrum, aber wir…

  • verzichten auf den Scrum Master, da das Team zu klein ist.
  • brauchen das aufwändige Schätzen des Aufwands einzelner Aufgaben nicht.
  • verlängern die Sprints, bis wir das Ziel erreichen.
  • kommen ohne die Retrospektiven aus.

Ein absolutes Muss in Scrum sind regelmäßige, feste Zeitabschnitte (Timeboxes). Schafft man die Arbeit innerhalb der festgelegten Iteration nicht, sollte das Team keinesfalls den Zeitraum verlängern. Vielmehr sollte man sich überlegen, wie man das Projekt in kleinere Inkremente aufteilen kann. Das Motto lautet hierbei: „How to slice the Elephant?“ Ein weiteres Risiko ist, dass sich ein Scrum Master wie ein Projektmanager verhält und sich als Teamleitung versteht. Bei Scrum hat jedoch das Team die Autorität. Darüber hinaus muss der Kunde für die agile Entwicklung bereit sein – also nicht mehr im Plan Driven Developement leben und denken, sondern die Rolle des Product Owners wirklich erfüllen können. Ist das nicht der Fall, lässt sich sein Projekt nur sehr schwer mit Hilfe von Scrum verwirklichen. All dies führt dazu, dass Organisationen (auf Kunden- wie auf Dienstleister-Seite) bei schlechten Scrum-Interpretationen schnell dazu neigen, die Methode als ungeeignet über Bord zu werfen und für den Misserfolg eines Projekts verantwortlich zu machen. Man sollte Scrum daher unbedingt sauber implementieren. Später lassen sich durchaus sinnvolle, zum Unternehmen passende Modifizierungen machen. Diese sollten nicht so radikal wie bei einem ScrumBut sein, doch lässt sich etwa die Rolle des Scrum Master anpassen. AOE media hat zum Beispiel seinen eigenen Weg gefunden und sieht Scrum heute als Framework, das sich an verschiedene Projekte und Situationen anpassen lässt.

Wann Scrum, wann Kanban?

Auch Kanban hat AOE media eingeführt: Hier gibt es mehrere Boards mit sehr unterschiedlichen Designs und mehreren Lanes. Zu Beginn hatten die Teams noch wenig Erfahrung, wann welche Methode einzusetzen ist: Scrum und Kanban wurden deshalb parallel verwendet. So konnte man sehr gut vergleichen, welche Methode für welches Projekt und welches Team besser geeignet ist. Kanban führt vor allem zu deutlichen Verbesserungen bei projektübergreifenden Teams, bei kontinuierlichen, schlecht planbaren Aufgaben und bei kleineren Projekten, die sich nicht in Iterationen aufteilen lassen. Für große, komplexe Aufträge und vor allem langfristige Projekte eignet sich Scrum besser.

Anzeige
Anzeige
Bunte Post-Its helfen, die aktuellen Projektsituation zu visualisieren.

Bunte Post-Its helfen, die aktuellen Projektsituation zu visualisieren.

Eigenmotivation und Transparenz

Bei AOE media entdeckten die Unternehmensleitung und die Entwickler gleichermaßen die agile Entwicklung für sich. Pioniere aus verschiedenen Unternehmensbereichen erarbeiteten sich damals gemeinsam die Einführung der agilen Ansätze, die stark auf Eigenmotivation und Selbstbestimmung setzen und damit sehr gut zur flachen Hierarchie und den gelebten Werten der Agentur passen. Im Zuge der agilen Entwicklung machte sich das Management auch mehr und mehr Gedanken um intrinsische Faktoren wie die Mitbestimmung, Verantwortung oder die Motivation, die aus der Person oder einer Aufgabe entspringt.

Dass Mitarbeiter ihre Aufgaben – wie in Scrum oder Kanban – innerhalb eines Rahmens selbst wählen können, trägt ganz erheblich zu einer hohen Arbeitszufriedenheit und hervorragenden Ergebnissen bei. Besonders Scrum ermöglicht zudem ein hohes Maß an Transparenz. Einerseits im Team, andererseits aber auch dem Kunden gegenüber: Release-Pläne sind durch die regelmäßigen Aktualisierungen am Ende jeder Iteration nicht länger ein frommer Wunsch, sondern Realität. Dies zieht sich hin bis zur Vertragsgestaltung: AOE media bietet Kunden zum Beispiel einen eigens entwickelten agilen Festpreisvertrag.

Meetings und Open Fridays

Meetings sind in Scrum keine Berichte „von unten“ an einen Projektleiter „da oben“. Sie dienen vielmehr der Information des gesamten Teams. Jeder kann im täglichen Meeting (Daily) sagen, was er gemacht hat, was er als nächstes angeht und auch, was ihn eventuell aufgehalten hat. Hier kommt unter anderem der Scrum Master zum Einsatz. Er sorgt dafür, dass der Fokus während des Meetings nicht verloren geht – etwa weil auf einmal über die defekte Kaffeemaschine gesprochen wird. AOE media hat zudem spezielle Formen der Retrospektive eingeführt. Dazu gehört zum Beispiel der Open Friday, der quartalsweise nach verschiedenen Methoden abläuft, etwa als Open Space. So besprachen die Mitarbeiter beim letzten Open Friday beispielsweise, welche Möglichkeiten AOE media hinsichtlich Feedback, Offenheit und Transparenz bietet oder wie sich die Arbeit im Support-Team attraktiver gestalten lässt. Daraus bildeten sich regelmäßig stattfindende Arbeitsgruppen.

Anzeige
Anzeige

Fazit

Wer Scrum einführen will, für den reicht es nicht, Bücher zu lesen: Zwar sind die Grundlagen von Scrum oder Kanban einfach zu verstehen. Die disziplinierte Umsetzung ist jedoch nicht ganz so leicht einzuhalten. Doch nur sie führt letztlich in die „Freiheit“ und aus der klassischen Projektmanagement-Tretmühle. Es lohnt sich, die (klassischen) Projektmanager, das Team und die Kunden zu schulen. Auch ein Scrum-Coach kann sich als wertvoll erweisen. Scrum ist dabei wesentlich mehr als ein neues Instrument der Software- oder Produktentwicklung: Scrum führt einen Paradigmenwechsel ein, der vom gesamten Team und auch den Kunden ein Umdenken verlangt. Die Voraussetzung, um agile Entwicklung zur Maxime der Unternehmenskultur zu machen, sind der Mut zu kontinuierlicher Veränderung, das Lernen aus Fehlern und der Wille zur Verbesserung der Prozesse. Das Wesentliche: Alle Mitarbeiter, nicht bloß das Management, müssen beteiligt sein. Nur dann wird agile Entwicklung im Unternehmen auch wirklich gelebt.

Mehr zu diesem Thema
Fast fertig!

Bitte klicke auf den Link in der Bestätigungsmail, um deine Anmeldung abzuschließen.

Du willst noch weitere Infos zum Newsletter? Jetzt mehr erfahren

Anzeige
Anzeige
9 Kommentare
Bitte beachte unsere Community-Richtlinien

Wir freuen uns über kontroverse Diskussionen, die gerne auch mal hitzig geführt werden dürfen. Beleidigende, grob anstößige, rassistische und strafrechtlich relevante Äußerungen und Beiträge tolerieren wir nicht. Bitte achte darauf, dass du keine Texte veröffentlichst, für die du keine ausdrückliche Erlaubnis des Urhebers hast. Ebenfalls nicht erlaubt ist der Missbrauch der Webangebote unter t3n.de als Werbeplattform. Die Nennung von Produktnamen, Herstellern, Dienstleistern und Websites ist nur dann zulässig, wenn damit nicht vorrangig der Zweck der Werbung verfolgt wird. Wir behalten uns vor, Beiträge, die diese Regeln verletzen, zu löschen und Accounts zeitweilig oder auf Dauer zu sperren.

Trotz all dieser notwendigen Regeln: Diskutiere kontrovers, sage anderen deine Meinung, trage mit weiterführenden Informationen zum Wissensaustausch bei, aber bleibe dabei fair und respektiere die Meinung anderer. Wir wünschen Dir viel Spaß mit den Webangeboten von t3n und freuen uns auf spannende Beiträge.

Dein t3n-Team

Frank

Danke für den übersichtlichen Vergleich der Methoden. Ein Kritikpunkt an Scrum aus dem Bereich ERP-Software ist, dass durch die Fokussierung auf einzelne kleinere Programmierungen, der Blick für die Qualität der Gesamtfunktionalität leidet. Bin gespannt, wie das andere Leser einschätzen.

Antworten
Matthias

„Oft stellt der Projektleiter im Laufe der Umsetzung dann fest, dass Zeit und Budget nicht ausreichen, um alles zu bewerkstelligen.“

Das ist schlicht und pauschal falsch. Ebendas ist eher der Fall in agilen Projekten. Warum? Der Kunde möchte unbedingt ein zumindest abgegrenztes Festpreisangebot haben. Das verträgt sich grundsätzlich natürlich eher weniger mit einem agilen Ansatz. Soweit sich beide Seiten auf einen Rahmen des Umfangs einigen und trotzdem agil vorgehen, kann entsprechend dieses Aufwands auch die gewünschte Funktionalität geändert werden. Hat man sich dann aber im Gesamtprojekt nicht gut überlegt, was man wirklich benötigt und was vielleicht doch später genügt, dann wird ein agiles Projekt in aller Regel viel eher zur Kostenfalle für den Kunden als ein Projekt mit einer Spezifikation oder einer iterativen Spezifikation.

„Die Folgen dieses „Plan Driven Development“: Stress, Unzufriedenheit und mangelnde Wirtschaftlichkeit.“

Auch hier wieder sehr subjektive Betrachtung des Sachverhalts, der aus meiner Sicht schlicht falsch ist. Stress folgt eher in agilen Projekten für die Entwicklung, weil diese harte und zeitnahe Ziele hat und immer wieder Änderungen unterworfen ist. Diese sind spannend, natürlich, aber diese können auch komplette Architekturen niederreißen.

Für schnelle Ergebnisse oder Produktentwicklungen sind agile Methoden geeignet, auch wenn man den Rahmen absteckt und sich vorher im Klaren ist, was die Kernfunktion bzw. -ziel des Projekts ist. Pauschal aber so zu werten, ist mehr als fraglich und finde ich aus meiner Sicht schlecht. Daher muss ich auch sagen, dass ich von dem Artikel sehr enttäuscht bin, da man die „ich liebe agile Methoden“ Brille hier sehr deutlich herausliest und diese Welt ist nunmal nicht rosarot. Der Mittelweg ist meist der Goldene, nicht die Wiese rechts und links davon …

PS: wie mein Vorredner sagte, Qualität was die Architektur angeht, ist in diesen sehr agilen Vorgehen auch meiner Meinung nach nicht gegeben bzw. einfach sehr wage, da einfach viel zu schnell durch Funktionsänderungen zu zerstören.

PPS: zu den SCRUMBUTS … wenn man agil entwickelt, dann richtig, wenn man dies so abändert wie hier dargestellt, ist das kein SCRUM und auch keine SCRUM Abwandlung, dann ist das nur ein Buzzword für Marketing Zwecke. Vor allem der Punkt keine Retrospektivmeetings zu machen, nicht ordentlich zu schätzen, Zeitlinien zu verlängern, klar, wenn es nicht anders geht, sollte man einen Ausweg finden, aber hier wird das ja zur Regel verklärt. Sry entweder das geht in einem Projekt oder nicht. Es gibt genügend Alternativen, die nicht starr darauf aus sind, alles komplett vorher tot zu definieren und trotzdem genug Agilität im Projekt zu haben, dass der Kunde noch einen Entscheidungsspielraum hat. Wobei auch die Darstellung oben, der Scope ist fix, das ist richtig, aber eigentlich meint Scope im Englischen nicht den detaillierten Umfang einer Aufgabe, sondern die Rahmenbedingungen und hier wird einfach falsch dargestellt, dass man es unbedingt mit einer totdefinierten Aufgabenstellung herumplagen muss. Es wird auch nicht darauf eingegangen, was die Nachteile sind „Detailspezifikationen folgen nur dann, wenn sie tatsächlich auch nötig sind“, das kann extrem nach hinten losgehen, weil sich oft die Erwartungshaltungen von den Parteien unterscheiden, hier liegt der Teufel eben schon im Detail.

Antworten
Laph

Ugh! Das Thema KanBan ist doch reichlich verkürzt dargestellt, was den Eindruck erweckt, KanBan wäre quasi statisch, weil es „lediglich den aktuellen Prozess darstellt“.

Aber KanBan ist das genaue Gegenteil davon. Lt. der Theorie soll man mit dem Prozess zwar dort starten, wo man ist – diesen dann aber stetig anpassen, wenn es Bedarf dafür gibt.

Und der Kerngedanke von KanBan, die Reduktion paralleler (und daher die Wertschöpfung behindernder) Arbeit durch die Einführung von WiP (Work-in-Progress) Limits kommt auch nur am Rande vor.
Nicht umsonst heißt die primäre Website für KanBan http://www.limitedwipsociety.org

KanBan ist flexibler als Scrum – weniger Regeln, keine Timeboxes – und daher IMHO besonders gut für Agenturen geeignet.

Antworten
probeabo

Bei einer Webagentur sehe ich im Moment die Probleme eher in der starken Integration des Kunden, wie es z.B. Scrum verlangt. Viele Kunden sind gar nicht bereit oder in der Lage, Anforderungen zu spezifizieren oder mehr zu tun als unbedingt nötig, sie wollen einfach ein fertiges Konzept / Produkt und fertig.

Antworten
AndreasAt99

Mehr über Kanban und speziell „Personal Kanban“, also Kanban zur Task-Planung für Privatpersonen, findet man da:

http://99-developer-tools.com/personal-kanban-kanbanpad/

Lesen! wenn Du an Kanban interessiert bist.

Antworten
boris_es

Blöde Frage. Scrum wird ja insbesondere in der Entwicklung eingesetzt. Hier ist das Prinzip einfach: jedes Teammitglied kann fast jede Aufgabe aus dem Backlog umsetzen. Wie funktioniert es aber mit interdisziplinären Teams (z.B. Entwickler, Designer, Konzeptioner, Texter) bei komplexen Projekten?

Insbesondere wenn Aufgabenteile einander bedingen: erst Text – dann Design – dann Entwicklung …

Antworten
YUHIRO.DE

Danke für den Beitrag. Besonders das mit dem „How to slice the Elephant“ ist interessant.

Spannend währe natürlich auch die Frage zu beantworten, wie der – Kosten – und der Zeitrahmen – fix – sein können, wenn sich die Anforderungen ständig aendern. Gerade diese beiden Komponenten, sind im Agilen Ansatz schwer unter einen Hut zu bringen.

Dort war ja gerade der klassische Ansatz stark, diese beiden Dinge fix zu halten.

Zudem finde ich jedoch auch den, im Beitrag erwähnten Weg, Scrum an die Anforderungen anzupassen interessant. Einige raten zwar alles so anzuwenden, wie es in Scrum empfohlen ist, aber wie bereits erwähnt, ist in kleineren Projekten sicherlich auch eine abgespeckte Version davon sinnvoll.

Hier auch ein paar weitere Informationen zu Agile: https://www.yuhiro.de/was-ist-agiles-projektmanagement/

Danke für den Beitrag und auch für das Teilen des ScrumButs Ansatzes.

Antworten
Thomas Nasinaki

Ich beschäftige mich erst seit kurzem mit den Themen rund um agile Methoden, agiles Projektmanagement. Spannend find ich an diesem Artikel insbesondere die Fehler, die man nicht machen sollte. Ich könnte mir vorstellen, dass viele Firmen aus verschiedenen Gründen, diese kleinen Aspekte weglassen wollen, ohne sich über die möglichen Auswirkungen Gedanken zu machen. Spannende Artikel rund um das Thema des Agiles Projektleiters habe ich auch unter marcthiel.de/agile-projektmanager gefunden. Ich stimme dem Autor des oben aufgeführten Artikels auch besonders zu, bei der Aussage, dass man Scrum und die anderen Methoden in der Praxis ausprobieren muss und stets die eigenen Fehlern reflektieren muss und dementsprechend das Verhalten anpassen muss.

Antworten
Eike

Ein guter Artikel um mal die gesammelte Übersicht über agile Methoden zu erhalten. Aus eigener Erfahrung kenne ich die Schmerzen der Einführung von Scrum im Agenturfeld nur zu gut. „Scrum-but“ trifft es genau. Aber man sollte sich auch überlegen, dass es oft weder möglich noch gut ist Scrum nach Lehrbuch einzusetzen. Aus meiner Erfahrung muss jedes Unternehmen und Projektteam selbst herausfinden, wie strikt man sich an gewisse Vorgehensmodelle orientiert.

Antworten

Melde dich mit deinem t3n Account an oder fülle die unteren Felder aus.

Bitte schalte deinen Adblocker für t3n.de aus!
Hallo und herzlich willkommen bei t3n!

Bitte schalte deinen Adblocker für t3n.de aus, um diesen Artikel zu lesen.

Wir sind ein unabhängiger Publisher mit einem Team von mehr als 75 fantastischen Menschen, aber ohne riesigen Konzern im Rücken. Banner und ähnliche Werbemittel sind für unsere Finanzierung sehr wichtig.

Schon jetzt und im Namen der gesamten t3n-Crew: vielen Dank für deine Unterstützung! 🙌

Deine t3n-Crew

Anleitung zur Deaktivierung
Artikel merken

Bitte melde dich an, um diesen Artikel in deiner persönlichen Merkliste auf t3n zu speichern.

Jetzt registrieren und merken

Du hast schon einen t3n-Account? Hier anmelden

oder
Auf Mastodon teilen

Gib die URL deiner Mastodon-Instanz ein, um den Artikel zu teilen.

Anzeige
Anzeige