Teamprove Wissen - Neue Fragen & Antworten in Agiles Projektmanagement

Beantwortet: Bei unseren Retrospektiven will keiner was sagen. Was soll ich tun?

Wed, 11 Feb 2026 09:52:14 +0000

Hallo zusammen (und hallo an mein früheres Ich),

ich antworte mir hier mal selbst, da mittlerweile einige Jahre vergangen sind und sich meine Sichtweise auf dieses Problem komplett gewandelt hat. Es ist viel passiert seit 2019 – wir haben uns verändert, die Arbeitswelt ist remote geworden, und Methoden, die damals funktioniert haben, reichen heute oft nicht mehr aus.

Wenn ich heute auf das Problem "Schweigen in der Retro" schaue, realisiere ich: Das Problem war oft nicht das Team, sondern mein Ansatz. Ich habe versucht, sofort auf die Meta-Ebene zu gehen ("Was lief schlecht?"), ohne dass das Team emotional dort war.

Was ich heute anders mache: Ich nutze kaum noch klassische "Frage-Antwort"-Runden zum Einstieg, sondern Simulationen.

Warum? Weil Schweigen oft Unsicherheit ist. Wenn wir aber gemeinsam ein kurzes Spiel spielen (z. B. 5 Minuten), bei dem wir gemeinsam scheitern oder gemeinsam gewinnen, ist das Eis sofort gebrochen. Die Emotionen sind wach, und man redet über das Spiel statt über sich selbst. Das ist viel sicherer.

Aus dieser Erkenntnis heraus haben wir eine Sammlung an Tools gebaut, die genau diese Brücke schlagen: games.teamprove.de

Wenn heute ein Team schweigt, lasse ich sie z. B. den "Traffic Jam" spielen. Danach redet jeder, weil sie sich über den Stau im Spiel aufregen. Und von da ist der Schritt zur Diskussion über unsere echte Arbeit nur noch winzig.

Vielleicht hilft dieses "Update aus der Zukunft" ja jemandem, der heute über diesen Thread stolpert.

Viele Grüße, Giancarlo

Beantwortet: Welche Spiele / Methoden nutzt ihr für die Retrospektive-Moderation?

Wed, 11 Feb 2026 07:56:46 +0000

Hi Martin,

ich hole den Thread mal aus der Versenkung, weil sich bei mir in den letzten Jahren einiges an der Methodik geändert hat.

Früher habe ich oft klassische Icebreaker genutzt, um die Stimmung zu lockern. Mittlerweile setze ich in Retrospektiven verstärkt auf kurze Simulationen, die das Team direkt auf ein Problem (z. B. Stress durch Multitasking) stoßen.

Wenn das Team zum Beispiel über "zu viel Arbeit" klagt, lasse ich sie als Check-in kurz eine Traffic-Jam-Simulation spielen (dauert 3 Minuten). Dabei sehen sie sofort: Wenn wir die Straße zu 100% füllen, steht der Verkehr. Das ist der perfekte Einstieg, um dann in der Datensammel-Phase (Gather Data) konkret über WIP-Limits zu sprechen.

Wir haben dazu eine Sammlung an kostenlosen Browser-Games gebaut, die genau für solche Retro-Einstiege gedacht sind: games.teamprove.de

Vielleicht ist das ja eine spannende Ergänzung zum Retromat für dich!

Viele Grüße, Giancarlo

Beantwortet: Wie vermittelt ihr Scrum-Konzepte (Flow, WIP, etc.) in Remote-Workshops effektiv? Mir fehlen die "haptischen" Übungen.

Wed, 11 Feb 2026 07:49:07 +0000

Hi!

Das Problem kenne ich nur zu gut. Als wir auf Remote umgestiegen sind, habe ich meine geliebten Papierflieger-Workshops und das Ball-Point-Game auch schmerzlich vermisst. Man kann Verhalten einfach schlecht durch Folien ändern – die Leute müssen den "Schmerz" eines schlechten Prozesses (z. B. zu viel WIP) selbst spüren, damit es "Klick" macht.

Ich bin mittlerweile dazu übergegangen, digitale Mikro-Simulationen zu nutzen, statt Dinge zu erklären.

Schau dir mal games.teamprove.de an (ist kostenlos).

Wir haben die Plattform genau aus diesem Frust heraus gebaut. Dort gibt es z. B. eine "Traffic Jam"-Simulation. Da lässt du dein Team erst mal den Fehler machen, die "Autobahn" komplett vollzustopfen (100% Auslastung = Push-Prinzip). Das Ergebnis ist der totale Stillstand. Danach spielen sie im Pull-Modus mit WIP-Limits, und plötzlich läuft der Verkehr.

Warum das meiner Erfahrung nach besser funktioniert als Erklärungen:

Erleben statt Glauben: Wenn ich einem Manager sage "Multitasking ist schlecht", glaubt er mir vielleicht nicht. Wenn er aber in der Simulation sieht, dass seine Durchlaufzeit explodiert, kann er nicht gegen die Daten argumentieren.
Emotionale Verankerung: In einer Simulation (wie dem Scrum Simulator dort) spüren die Leute den Stress, wenn das Sprint-Ziel wackelt. Das bleibt viel länger hängen als eine Grafik auf einer Folie.
Schnelligkeit: Die Spiele dauern meist nur 3–5 Minuten. Perfekt, um ein Meeting aufzulockern oder ein Thema einzuleiten.

Vielleicht hilft dir das ja für deinen nächsten Workshop weiter!

Viel Erfolg!

Beantwortet: Visialisierung von X User Stories in einem Dokument,damit so etwas wie ein Art Lastenheft entsteht. Wie macht ihr das ?

Mon, 31 Mar 2025 14:09:29 +0000

Hallo Stefan,

sorry, für die späte Antwort, leider ist Deine Anfrage etwas untergegangen.

Ich persönlich stelle Lastenhefte bzw. Pflichtenhefte generell in Frage (außer es führt - aus Gründen - kein Weg dran vorbei). Wenn ihr bereits Userstories habt, habt ihr euch ja schon Gedanken gemacht, was ihr braucht. Wenn diese Stories so formuliert sind, dass Persona bzw. Task, Nutzen und Kontext gut erkennbar sind, dann ist dies vielleicht schon aussagekräftig genug.

Ich würde eher ein agiles und iteratives Vorgehen in Erwägung ziehen. Vielleicht könnte es auch hilfreich sein, dass ihr erstmal ein allgemeines Dokument erstellt, in das ihr eure Idee, Ziel, Gedanken dazu etc. einfließen lasst, so dass ein gemeinsames Verständnis zwischen euch und einem Softwarehersteller, ergänzend mit einem persönlichen Austausch, grundlegend hergestellt werden kann.

Das Vorgehen wird natürlich von verschiedenen Faktoren beeinflusst, wie z.B. der Komplexität, Umfang und Dauer des Projektes. Zusätzlich zu dem allgemeinen Dokument könnte z.B. ein Workflow helfen, bei dem alle Userstories in einem Tool wie Jira oder Trello erfasst werden, diese über Tools wie StoriesOnBoard oder Miro visualisiert und zum Schluss in z.B. MS Word exportiert werden. Die Tools stellen ja verschiedene Exportfunktionen zur Verfügung. Dann könnte das Worddokument weiter zu einem Lastenheft aufgebaut werden, dass dann über die Funktionen von Word wie Versionierungen usw. weitergenutzt werden kann. (Wobei die darin enthaltenen Anforderungen nicht wenig später schon wieder veraltet sein könnten)
Long story short - viele Wege führen nach Rom :-)

Beantwortet: Spielsimulation zur Retrospektive

Sun, 07 May 2023 21:19:12 +0000

Hallo Céline,

ich hätte noch ein paar Fragen vorab:

Wie groß ist das Team?
Arbeitet das Team schon lange zusammen oder eher noch im "Kennenlernmodus"?
Habt ihr schon Retros durchgeführt oder startet ihr ganz neu?
Ist die Durchführung in Präsenz, hybrid oder remote geplant
Ist das Team schon "Spiele erprobt" oder wäre auch ein anderes Verfahren wert in Erwägung zu ziehen?

Freue mich auf Deine Antwort

Beantwortet: Was ist der Unterschied zwischen Scrum und Agile?

Mon, 19 Dec 2022 15:47:32 +0000

Hallo Emil,
vielen Dank für deine spannende Frage. Ich möchte gerne an Wibkes Erläuterungen anknüpfen.

Wie du richtig gesagt hast, sind Scrum und Agile nicht das gleiche. Du könntest dir Agilität als einen Überbegriff vorstellen unter dem verschiedene Rahmenwerke existieren und Scrum ist eines davon, wie eine Sorte. Wie Wibke auch geschrieben hat, gibt es verschiedene weitere Rahmenwerke neben Scrum wie Kanban etc.

Agilität kann man daher auch als eine Philosophie oder Denkweise erklären. Agilität beschreibt eine Kultur, Werte, Kommunikationsformen, Nutzen, Ziele etc., was in dem agilen Manifest festgehalten wurde. Scrum beschreibt wie man dort hinkommt, in dem es Rollen, Wege beschreibt, und somit ein Framework vorgibt.

Ein Beispiel dafür sind die Agilen Grundwerte wie sie in Scrum umgesetzt werden bspw.: “Individuen und Interaktionen haben Vorrang vor Prozessen und Werkzeugen“ wird in Scrum umgesetzt durch konstante Kommunikation bspw. in den Dailies, aber auch anderen Scrum Events.
Der zweite Agile Grundwert “Funktionsfähige (Software)/Produkte haben Vorrang vor umfassender Dokumentation.” wird in Scrum umgesetzt in dem jeden Sprint ein Increment geliefert wird u.s.w.

Scrum ist somit ein Weg, wie man zu Agilität kommen kann. Man kann aber auch einen anderen Weg dazu wählen. Ich hoffe die Erläuterung macht es etwas klarer. Melde dich sehr gerne bei uns, wenn weitere Fragen auftreten.

Beantwortet: Was sind Story Points?

Fri, 02 Dec 2022 07:14:05 +0000

Für mich sind Story Points eine Maßeinheit, wie Meter oder Kilogramm. Was Story Points meiner Ansicht nach besonders macht, ist, dass sie eine Größe angeben, die unabhängig von dem Know-How und Fähigkeiten einer Person sind. Eine Zeiteinheit bspw. ist abhängig von den Fähigkeiten und Know-How einer Person. Beispiel: Ich brauche für eine Jogging Strecke von 5 km z.B. länger, als eine Person, die jeden Tag joggen geht. Wir könnten uns also streiten, wie lange wir für die Strecke brauchen, ohne jemals zu einem zufrieden stellenden Ergebnis zu kommen (und nein, eine Einigung in der Mitte ist nicht zufrieden stellend). Was ich aber mit der Person gemeinsam habe und unabhängig von meinen sportlichen Fähigkeiten steht ist, dass wir beide 5 km joggen. Darauf können wir uns einigen.

Beantwortet: Kann man agiles und klassisches Projektmanagement kombinieren?

Fri, 02 Dec 2022 06:59:27 +0000

Ich denke auch, dass es sinnvoll ist, trotz der Gegebenheiten agil zu arbeiten. Im besten Fall überzeugt man mit den dann erzielten Erfolgen auch die stärksten Kritiker und kann eine Vorbildrolle für das ganze Unternehmen einnehmen.

Beantwortet: Geht Scrum auch ohne Scrum Master?

Tue, 29 Nov 2022 14:29:18 +0000

Hallo,

die Situation habe ich schon oft in Unternehmen gesehen. Es klingt verlockend zu sagen, dass eine "nicht-produktive Rolle" eingespart werden kann, indem die Aufgaben dieser Rolle an andere Menschen verteilt werden. Es gibt dabei zwei Fehler:

Zu denken, dass diese Rolle nicht produktiv ist. Sie produziert viel, aber indirekt. Sie produziert Fokus, weil sie Diskussionen, Gespräche und Verhandlungen begleitet aber nicht involviert ist. Sie produziert Verständnis zwischen verschiedenen Menschen und Rollen die unterschiedliche Ziele verfolgen. Sie produziert Disziplin und sorgt für Ordnung in einer schnellen und volatilen Umgebung.
Zu glauben, dass es ohne weiteres möglich ist die Rolle - oder Teile dieser Rolle - an Menschen zu übertragen die andere, oft inkompatible Rollen ausführen, und meistens schon mit deren Aufgaben überlastet sind.

Das was die Scrum Master Rolle speziell und vorteilhaft macht ist ihre Unabhängigkeit. Scrum Master sind zuständig für die Effektivität des Teams. Kurz, mittel und langfristig. Damit das richtig gut funktioniert, sind Scrum Master auf gleicher Ebene in der Organisation mit Teammitgliedern und Product Owner. Wenn man versucht die Scrum Master Rolle mit anderen Rollen zu kombinieren, dann geht genau diese Unabhängigkeit verloren und damit ist sie schnell wertlos.

Ich kenne viele Organisationen die es versucht haben so eine Formel zu nutzen und ich kenne nur zwei Ergebnisse dieser Entscheidung:

Scrum wird halbherzig gelebt. Scrum Meetings werden nicht gut durchgeführt, die Vorbereitung ist schlecht, sie werden als nicht wertvoll wahrgenommen. Die Organisation hört auf zu Wachsen, sie entwickelt sich nicht weiter. Diese Situation kann über Jahre so bleiben. Es sammeln sich "Verbesserungsschulden" (Dinge/Probleme/Dysfunktionen die angegangen werden müssten, die aber verdeckt bleiben). Wenn dann mal eine größere Krise oder Veränderung kommt, dann bricht das Team in sich zusammen, denn es ist schlichtweg nicht darauf vorbereitet.
Das Team merkt, das Scrum so nicht funktioniert. Der Eindruck der bleibt heißt: "Scrum funktioniert (bei uns) nicht" und es werden andere Ansätze gesucht. Oft wird dann Kanban (ohne WIP) eingesetzt und das fühlt sich besser an, auch wenn damit der Output des Teams bei weitem nicht optimal ist.

Ich hoffe, ich konnte mit meiner Antwort helfen.

Beantwortet: Wozu verwendet ihr Tasks in Jira?

Thu, 27 Oct 2022 08:13:20 +0000

Tasks/Aufgaben habe ich schon in Verwendung gesehen für folgendes:

Beauftragte Arbeiten, die keine Änderungen am Produkt bedeuten, demzufolgende auch eine andere oder keine DoD haben (z.B. Analyse durchführen, Deployment einer Komponente auf eine gewünschte Umgebung, Dokumentation in Confluence überarbeiten)
Reminder für Tätigkeiten im Sprint, die eigentlich kein eigenes Backlog-Item sein müssten, aber damit man alles im Sprint Backlog sieht (z.B. Deployment, manche Tests, die in bestimmten Zeitfenstern auf bestimmten Umgebungen durchgeführt werden müssen)

Beantwortet: Ist Dokumentation beim agilen Arbeiten noch nötig und wenn ja inwieweit?

Fri, 09 Sep 2022 08:25:05 +0000

Im Manifest für Agile Softwareentwicklung steht, dass die Ersteller vom Manifest "diese Werte zu schätzen gelernt" haben und anschließend folgt die genannte Gewichtung, dass "Funktionierende Software" wichtiger sein soll als "umfassende Dokumentation".

Aus meiner Erfahrung in nicht agilen/klassischen Projekten gibt es viele Dinge, die vertraglich geliefert werden müssen und dazu gehört typischerweise auch eine umfassende Dokumentation. Es gibt hier also zumindest vertragliche keine Gewichtung bei klassischen Projekten, da alles geliefert werden muss (Software und Dokumentation).

Aus dieser Erfahrung her mit den Zielen agiler Produktentwicklung (s. 12 Prinzipien) macht es meiner Meinung nach Sinn die Wichtigkeit funktionierender Software deutlich über die der Dokumentation zu stellen, sonst werden gleich viele Prinzipien verletzt / nicht erreicht.

Aus meiner Erfahrung wird das Prinzip "Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, Entwickler und Benutzer sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können." massiv verletzt, falls man auf Dokumentation verzichtet. Denn dann würde die Software immer komplizierter und spätestens wenn dann auch noch alte Hasen das Projekt verlassen wird das Tempo deutlich langsamer ohne Dokumentation.

Wenn ich also ein "gleichmäßiges Tempo" halten will, ein "Augenmerkt auf technische Exzellenz" und gleichzeitig "die Menge nicht getaner Arbeit zu maximieren" versuche, dann komme ich ebenfalls zu den bereits von Giancarlo und dem anonymen Antworter genannten Punkte. Dann muss ich überlegen, welche Dokumentation brauche ich wirklich (nicht vertraglich, aber um als Team(s) mein Tempo halten zu können. Welche Dokumentation brauche ich, um gute Entscheidungen bzgl. technische Exzellenz, gutes Design und gute Architekturen, Anforderungen und Entwürfe treffen zu können. Dokumentation ist, in welcher Art auch immer, meiner Meinung nach unglaublich wichtig und essentiell, aber nicht zum Selbstzweck, sondern als Mittel zum Zweck (mal abgesehen von gesetzlichen Vorgaben).

Daher unterstütze ich voll die Gewichtigung, dass funktionierende Software wichtiger ist, würde aber selbst niemals behaupten, dass Dokumentation unwichtig sei.

Beantwortet: Wie bei Scrum mit Terminabsagen Einzelner für die Scrum Events umgehen?

Fri, 19 Aug 2022 13:31:24 +0000

Ich sehe das ähnlich, wie Markus. Von der anderen Seite betrachtet, würde ich aber sagen, dass nicht unbedingt immer die Frage auf das "Gesetz der zwei Füße" mit JA beantwortet werden kann. Ich erlebe oft, dass das Review mehr einem Status-Meeting gleicht oder die Informationen nicht auf der richtigen Ebene geteilt werden. Daher würde ich eher den Ansatz wählen, die entsprechenden Stakeholder zu fragen, was sie denn bräuchten, um teilzunehmen bzw. damit das Event für sie interessant wird (ganz im agilen Sinne).

Was ich auch häufig feststelle ist, dass nach der Vorstellung der Ergebnisse gefragt wird: "Gibt es Fragen?" Anstatt konkrete Fragen an die Stakeholder zu stellen. Wenn diese nicht wissen, was dem Team wichtig ist, können sie auch kein Feedback geben. Um hierzu ein Beispiel zu machen: Wir haben im Team gelbe und blaue Post-its hergestellt. Diese werden nun präsentiert mit ihren Klebefähigkeiten und ihrer Größe. Im Anschluss wird gefragt, ob es Fragen gibt. Hier werden vmtl. nicht so viel Rückmeldung kommen. Frage ich aber z.b. konkret, ob die Stakeholder mit der Größe etwas in ihrer täglichen Arbeit anfangen können oder ob die Farbe für sie passt, erhalte ich vmtl. mehr Rückmeldung, da diese Fragen konkret und fokussiert sind.

Zusammenfassend: Ich glaube, dass es wichtig ist zu verstehen, warum die entsprechenden Stakeholder nicht teilnehmen (können). Denn nur, wenn ich das Problem verstehe, kann ich darauf reagieren. Ansonsten bewege ich mich mit Annahmen, die ich nicht verifiziert habe.

Beantwortet: Was tun wenn sich das Team wie ein altes Ehepaar verhält?

Mon, 15 Aug 2022 08:41:49 +0000

Lieber Kaspar,

hast du denn deine Hypothese "Du nervst einfach nur noch" schon einmal mit dem Team besprochen? Wie Giancarlo bereits schrieb, bist du in der wunderbaren Lage das ganze Geschehen aus einer anderen Perspektive zu betrachten, die die anderen Teilnehmenden evtl. gar nicht sehen können.

Ich mache gerade eine Mediationsausbildung und erlebe in den Übungsfällen immer wieder einen AHA-Moment, wenn jemand von außen einfach mal beschreibt, was er/sie sieht. Ohne eine Bewertung, einfach nur das, was wahrgenommen wird. Die häufigste Reaktion ist: "So hab ich das noch gar nicht gesehen! Das ist ja spannend."

Deshalb denke ich, könnte es helfen, wenn du deine Wahrnehmung dem Team zur Verfügung stellst. Evtl. ergeben sich bereits daraus wichtige Ankerpunkte.

Beantwortet: Warum dauern Pull Requests so lange?

Tue, 12 Jul 2022 15:17:52 +0000

Von außen klingt es so, als wenn jedes Teammitglied wie ein eigenes Silo / eine eigene Abteilung arbeitet. Jeder hat seine eigenen Tickets und möchte hier gut vorankommen. Eine Unterstützung für andere ist von außen zwar erwünscht, aber in erster Linie wird von den Teammitgliedern erwartet, dass >ihre< Tickets gut vorankommen.

In meiner Beobachtung kommt das sogar häufig vor, dass Tickets nicht wie Features, sondern wie Arbeitspakete geschnitten sind. Auf diese Weise passen sie zwar nicht zum Scrum Gedanken, dafür aber zu JIRA, da JIRA einen ja zu exakt >einem< Bearbeiter eines Tickets zwingt.

Eine Möglichkeit das zu ändern sehe ich darin, dass das Projekt (meist in Persona Product Owner:in und Scrum Master:in) eine gemeinsame Linie vertritt, dass im Daily Scrum nicht jeder seinen persönlichen Status reportet (was nicht der Scrum Gedanke ist), sondern dass gemeinsam geschaut wird, welches Ticket man als nächstes "Fertig"/"Done" bekommt und wer hier unterstützen kann, damit es besonders schnell geht. Wenn dann das Augenmerk auf das Ticket mit offenem PR fällt, dann kann noch im Daily Scrum durch die Developer entschieden werden, wer den PR reviewed.

Eine etwas konkrete Art wäre, dass z.B. die Tickets eine Priorisierung haben - hiermit meine ich nicht die ursprüngliche Priorisierung im Product Backlog durch den Product Owner, sondern eine selbstorganisierte Priorisierung der Developer, in welcher Reihenfolge sie die Tickets abarbeiten wollen. Dann kann man z.B. im Daily Scrum nicht personenweise durchgehen, sondern ticketweise... mit dem Ziel, dass immer geschaut wird, wer alles zum Vorankommen eines Tickets benötigt wird... solange, bis sich alle Tickets zugeordnet haben (natürlich darf man auch an anderen Tickets weiterarbeiten, wenn seine Unterstützung bei den priorisierten Tickets bereits erledigt ist oder ggf. aktuell gar nicht möglich ist).

Beantwortet: Wann nimmt der Product Owner die Stories ab? Vor dem Review oder mittendrin? Muss er sie überhaupt abnehmen?

Wed, 16 Feb 2022 08:05:17 +0000

Das was im Scrum Guide dazu steht finde ich sehr passend: "The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations. The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed." Das heißt erstmal, dass im Scrum Review keine Übergabe der Ergebnisse oder Ähnliches von Developers an dem Product Owner stattfindet. Es ist eher eine Präsentation an die Stakeholder, also Menschen die Ausserhalb des Scrum Teams sind.

Es muss also vor dem Sprint Review schon Instanzen geben wo Developer mit Product Owner über den Stand der Stories reden und wo der Product Owner (als Vertreter der Kunden) Feedback gibt. In der Regel gehört diese Überprüfung der Stories in die Definition of Done. Stories können demnach nur geschlossen werden, wenn es zu dieser Überprüfung durch den Product Owner kam. Ob ich das "Abnahme" nennen würde? Ich weiß nicht, Abnahme klingt sehr Bürokratisch für mich. Das Ziel der Überprüfung durch Product Owner und Developers ist aus meiner Sicht weniger "Compliance" sondern eher eine Maßnahme damit der Kunde das bekommt was er braucht.

Und nun zu diesen ominösen "Instanzen" wie ich sie genannt habe. In einige Teams mit denen ich gearbeitet habe, gab es nach dem Daily immer wieder die Möglichkeit Dinge zu präsentieren wo die Developer Feedback vom Rest des Teams haben wollten. Diese Zeitslots wurden unter Anderem benutzt um Stories die aus Sicht der Developer fertig waren zu inspizieren. Wenn Developer und PO zufrieden waren, und die Stories damit alle Definition of Done Kriterien erfüllt haben, dann wurden diese Stories als Fertig markiert.

Und dann zurück zum Review Meeting: im Review Meeting sollten dann nur Stories gezeigt werden die schon Fertig sind. Sonst sind es ja keine "results". Das zwingt die Scrum Teams dazu sich auf Fertigstellung von Stories zu fokussieren. Darüberhinaus verwirren halbfertige Stories die Stakeholder, da sie oft als Fertig wahrgenommen werden. Danach ist es nicht verständlich warum dann noch an Dingen weitergearbeitet wird die schon längst fertig waren.

Ich hoffe, ich konnte dir mit meinen Ideen weiterhelfen!

Beantwortet: Wie visualisiert ihr Geschafftes in Zeiten von Remote?

Tue, 15 Feb 2022 08:03:04 +0000

Ich schließe mich Thomas Antwort an. Ich glaube, was wichtig ist, ist alle Erfolge im Blick zu haben und nicht nur einzelne Stories, die abgeschlossen wurden. Bei meinem alten Arbeitgeber gab es auch eine Wand - ähnlich der von Thomas beschriebenen "Wall of Fame" - auf welcher Diamanten gesammelt wurden. Das kann der Diamant der Woche, des Monats oder Tages sein. Sie war so platziert, dass man jeden Morgen daran vorbeigelaufen ist und den Fortschritt in Form von Kundenlob, Storyabschluss etc. sehen konnte.

Da wir uns aber derzeit mehr in remote befinden, habe ich damit begonnen solche Sachen mit in die Retro einzubauen. Vor allem, wenn der Sprint z.b. aus technischen Gründen mal nicht so super gelaufen ist, ist das immer ein toller Stimmungsaufheller.

Beantwortet: Sollten Teams strikt nach dem 11. agilen Prinzipien bezüglich Architektur vorgehen auch in skalierter Entwicklung?

Tue, 08 Feb 2022 14:02:28 +0000

Aus meiner Sicht gibt es in Software-Organisationen keinen Platz für "Architekten". Diese existieren und bestehen aus meiner Sicht nur weil wir Menschen das Bedürfnis haben "anders als die anderen zu sein". Deswegen gibt es in Büros oft auch solche mit und ohne Fenster, Parkplätze mit Kennzeichen für VIPs und Büros mit und ohne Tür. Softwareentwicklung funktioniert genauso gut wenn die Verantwortung für die Architektur verteilt ist.

Wenn Organisationen mit der Aufgabe konfrontiert sind "agiler zu werden", dann suchen die Menschen die sie "transformieren" nach Möglichkeiten ihre Vorteile zu behalten. Craig Larman formuliert es so: "Organizations are implicitly optimized to avoid changing the status quo middle- and first-level manager and “specialist” positions & power structures."

Aus meiner Sicht benötigen gute Softwareorganisationen Mitarbeiter (gute, fachkundige, erfahrene Softwareentwickler) die in der Lage sind gute und wachsende Designs zu entwerfen und weiter zu entwickeln. Diese Fähigkeit muss in allen Teams existieren. Es ist eher schädlich die Verantwortung für gute Designs an einer Person (oder einem Gremium) zu delegieren, denn damit wird die Autonomie und Verantwortung der Teams reduziert.

Persönlich glaube ich, dass SAFe sehr oft in Organisationen eingesetzt wird wo es nicht erwünscht ist Machtstrukturen und Spezialisten-Rollen aufzugeben. Die Tatsache, dass SW-Architektur nach SAFe auch die Aufgabe des Architekten bleibt bestätigt meiner Meinung nach diese Annahme.

Ich bevorzuge eher Ideen wie die von LeSS (Large Scale Scrum) und die Ansätze die dort beschrieben werden: "Think ‘gardening’ over ‘architecting’—Create a culture of living, growing design". Diese setzen die Prinzipen des Agilen Manifests richtig um und erreichen damit mittel- und langfristig bessere Ergebnisse, durch eine höhere Autonomie und Verantwortungsbewusstsein aller Beteiligten.

Beantwortet: In welchen Situationen macht Kanban Sinn, in welchen ist Scrum besser?

Mon, 31 May 2021 08:40:13 +0000

Nun Scrum und Kanban schließen sich zunächst einmal nicht gegenseitig aus. Es gibt viele Teams, die Scrum mit Kanban einsetzen.

Es sind wahrscheinlich eher die Rahmenbedingungen, wann eher Scrum oder wann Kanban vorrangig eingesetzt werden soll.

Kanban visualisiert zunächst einmal einen Wertschöpfungsprozess und hat die Idee diesen durch Transparenz zu kontroliieren und verbessern.

Scrum ist ein Regelwerk zur Produktentwicklung mit empirischen Vorgehen, sowie Iterationen von Inspektion und Adaption.

Scrum wird daher eher nur in komplexen Umfeldern eingesetzt.

Ist das Team bereits ein Team oder eher eine Gruppe ? Gibt es einen gewissen Veränderungswillen ? Wenn eher nein, sollte man mit Kanban starten und das Team und die Organisation entwickeln.

Wie ist die Kultur im Unternehmen und im Team ? Gibt es ein starkes Bedürfnis nach Kontrolle ? Dürfen die Teammitglieder selber ihre Aufgaben organisieren oder arbeiten Sie von Außen gegebene Aufgaben ab ? Gibt es dauerhaft fixe Fertigungstermine ?

Weder Scrum noch Kanban sind alleinige Tools fürs Projektmanagement. Bei beiden gilt, dass eine Implementierung eigentlich nur zur Zufriedenheit aller erfolgreich verläuft, wenn auch der Kulturwandel, welche bei Scrum mehr, bei Kanban weniger, gestaltet wird.

Beantwortet: Ist es sinnvoll den Aufwand für Bugfixes zu schätzen?

Sun, 24 Jan 2021 20:24:31 +0000

Wie immer, es kommt auf den Kontext an.

In den teams mit denen ich gearbeitet habe hat man auch Bugfixing Aufgaben geschätzt. Ein einfach zu behebender Bug ist schnell geschätzt, ein Kniffliger oft überhaupt nicht schätzbar. Darum arbeiten wir mit

Blitzanalysen, wenn unser Support einen Bug nicht reproduzieren kann. Dabei investiert der Entwickler maximal 30 Minuten und zeitnah und oft sieht er mit wenigen Blicken wie heftig der Bug ist.
Analysestories: Bugs die man im Refinement nicht schätzen kann weil die Ursache auch für Entwickler unklar ist wird über eine storypointbegrenzte Userstory analysiert. Wenn man den Bug dann auch noch schnell fixen kann, dann wird das natürlich gleich gemacht. Erfordert die Analyse oder der Bugfix mehr Zeit als die vereinbarten (1, 2?) Story Points () dann wird die Story abgebrochen und das Zwischenergebnis mitgeteilt. Die Story Points werden dabei einmalig als Faustregel festgelegt. Bei uns 2.

Beantwortet: Wer schreibt eigentlich die User Stories?

Thu, 21 Jan 2021 17:44:44 +0000

User Stories ist ja nur eine Art, wie man Backlog Items formulieren kann. Insofern sind sie im Scrum Guide definiert. Wie schon von Giancarlo geschrieben wurde, liegt die Verantwortung dass sie geschrieben werden und dass sie richtig priorisiert werden beim Product Owner.

Leider sehr oft sehe ich folgendes Modell im Einsatz:

Stakeholder entscheiden, was mit welcher Priorität (teilweise auch bis wann) umgesetzt werden muss und teilen das nur dem PO (vormals Teamlead) mit. Dieser ist also das Bottleneck bzw. Stille-Post-Prinzip zu den Stakeholdern. Der PO sieht sich in der Funktion des Fachkonzeptionisten und schreibt alle Anforderungen auf (meistens die konkreten Lösungsschritte und nicht das ursächliche Problem). Damit wird die grundlegende Idee der User Story, das konkrete Problem des Anwenders zu verstehen, um dies als Diskussionsgrundlage für potentielle Lösungsmöglichkeiten zu nutzen, bereits verletzt. Das Team wird lediglich als Menge von untergebenen Entwicklern gesehen, welche wie im Wasserfall 1:1 die fertig definierten Lösungen umsetzen sollen.

Meiner Meinung nach kann man das so machen, aber mit agiler Softwareentwicklung oder den Ideen hinter Scrum hat das nichts zu tun.

Oder man macht es, wie Scrum es vorsieht:

Der Product Owner ist der oberste Entscheider über die Produktentwicklung. Er kümmert sich um das Stakeholdermanagement - spielt aber nicht das Stille-Post-Prinzip sondern stellt Kontakte her, sorgt dafür, dass er immer auf dem aktuellen Stand ist bzgl. der Priorität und dem Mehrwert für die verschiedenen Stakeholder, um auf deren Basis selber die Priorisierung zu entscheiden.

Er sorgt anschließend dafür, dass er selber oder jemand aus dem Team die Probleme der Kunden z.B. in Form einer User Story aufschreibt. Anschließend kommt das Team zusammen, dass auch Spezialisten im Bereich Konzeption und Spezialisten im Bereich Umsetzung enthält (sowie Test etc.). Hier entsteht eine kreative Diskussion über verschiedene Möglichkeiten der Lösung des Problems. Bei konkreten Unsicherheiten über die Situation des Kunden wird der direkte Kontakt gesucht, um das Problem genau zu verstehen. Möglicherweise werden dabei aus einer User Story mehrere mit verschiedenen Lösungsoptionen. Dabei halten die Teammitglieder fest, welche Rahmenbedingungen sie sehen (z.B. Lastanforderungen, Design-Leitplanken und Skizzierung der Lösung) und schätzen die User Story(s). In Zusammenarbeit mit dem PO werden dann Kosten und Nutzen (kurz- wie langfristig) der verschiedenen Lösungen diskutiert und die letztendliche Entscheidung liegt beim PO, ob, wie und in welcher Priorisierung die Lösung angegangen wird.

Scrum sieht sich als Framework für die Entwicklung komplexer Produkte und orientiert sich an den 12 Prinzipien für agile Softwareentwicklung. Dabei spielt direkte Kommunikation eine Rolle (nicht PO als man-in-the-middle bzw. Stille-Post-Prinzip). Für komplexe Produktentwicklung nutzt Scrum ein cross-funktionales, um qualitativ hochwertige und alle Perspektiven (UX, Architektur, Design, Testbarkeit, ...) berücksichtigende Lösungen zu entwickeln und gemeinsam umzusetzen. Scrum vertraut darauf ein Team zu haben, was in der Zusammenarbeit bessere Lösungen entwickeln kann, als es jeder einzelne alleine könnte. Aus diesem Grund ist der PO weder der Fachkonzeptionist noch ein Bottleneck in der Zusammenarbeit mit den Stakeholdern.

Natürlich kenne ich diverse Interpretationen und Adaptionen von Scrum, in denen der PO kein Entscheidungsrecht über das Produkt Backlog hat, seine Daseinsbestätigung in der Vermittlung zwischen Entscheidern und Team sieht und dort die Lücke füllt und den Fachkonzeptionisten für das Team darstellt, der sich alleine um die Erstellung der Backlog Items / User Stories kümmert. Dies fördert allerdings weder ein selbstorganisiertes, verantwortliches Arbeiten bzw. Mitdenken im Team, noch die Kreativität für Lösungsfindungen im Team und beruht auf der Annahme, dass es entweder der einzelne PO besser weiß und kann als das Team zusammen oder dass PO und Team zusammen allesamt nichts zu sagen und nur das umzusetzen haben, was der Stakeholder nicht wünscht sondern befiehlt.

Beantwortet: Wie verändert der neue Scrum Guide 2020 meine Arbeit als Scrum Master?

Thu, 21 Jan 2021 14:41:57 +0000

Ich denke auch, dass die neue Version vom Scrum Guide nichts Wesentliches verändert hat und dennoch wollen die Änderungen uns auf Dinge hinweisen, welche in der Vergangenheit oft fehlinterpretiert wurden und deswegen verbessert werden sollen. Auch aus meiner persönlichen Erfahrung kann ich die folgenden Punkte/Veränderungen im Scrum Guide nur unterstreichen:

Es gibt nur noch 1 Team, das Scrum Team. Hiermit soll u.a. verhindert werden, dass z.B. der PO sich oberhalb des Teams, als Teamlead oder Auftraggeber vom Team sieht. Er ist Teil vom Team, genauso für das Ergebnis verantwortlich und speziell ein Forecast im Sprint Planning ist kein(!) Commitment oder Vertrag gegenüber dem PO und wurde vom Scrum Guide überhaupt noch nie als Commitment gesehen. Commiten tut sich das ganze Team auf die bestmögliche Erreichung vom Sprint Goal. Dies kann man nun als Scrum Master nochmal besonders betonen.
Der Scrum Master ist ein Servant Leader und auch ein True Leader. Mit der Neuerung wurde nochmal betont, dass "Servant"/dienend zwar seine Art ist, er dennoch ein echter/"true" Leader ist und sich auch so sehen sollte. Er wird vom neuen Scrum Guide noch viel klarer in die Verantwortung genommen für die "Scrum Teams' Effectiveness". Ein reines Moderieren, Meeting aufsetzen oder Planning Poker Karten verteilen kann niemals dieser Verantwortung gerecht werden.
Das Product Goal ist auch neu. Hiermit kann man als Scrum Master nochmal gut hinterfragen, welches zumindest mittelfristige Ziel angestrebt wird. Hieran kann man auch gut erkennen, ob der PO einen eigenen Plan verfolgt oder gerade einfach das umsetzen lässt, was von verschiedenen Seiten so reingeworfen wird und darüber reden, wie man mit dieser Situation umgehen will.

Das sind für mich so die Hauptpunkte, die man als Scrum Master beachten kann (in der Annahme, dass man sie vorher noch nicht so beachtet hat).

Beantwortet: Wie funktioniert Agilität in Vertriebsteams in der Praxis?

Sat, 10 Oct 2020 11:17:27 +0000

ich kenne ein positives Beispiel in dem die Abteilung: Vertrieb und die Abteilung Marketing ein Produkt Backlog gemeinsam erarbeitet haben und gemeinsam abarbeiten.

Ich stimme Markus Fuchs zu: „versuchen Sie anstatt eines agilen Prozesses lokal im Vertrieb einzuführen den Austausch zu fördern“ um awareness & Wunsch und Notwendigkeit nach Veränderung zu wecken.

Wenn noch nicht geschehen würde ich einige Vertriebsmitarbeiter in das Scrum Event Sprint Review oder Daily Scrum des Softwareteams einladen um vorzuzeigen WIE und DAS es funktioniert. Ein Vorzeigeprojekt zeigen überzeugt oder weckt Interesse.

Das Bewusstsein und anschließend der Wunsch und Notwendigkeit auf Veränderung muss geweckt werden!
Gibt es einzelne Kollegen die Scrum im Vertrieb befürworten und als Vorbild und Leader die ganze Abteilung mitnehmen? Die Eventualität das im Vertrieb alles bestens funktioniert ist ja auch eine Möglichkeit.

In einem Event für den Vertrieb zum Thema.
„Nutzen für das Unternehmen verbessern“ würde ich die Notwendigkeit nach Veränderung prüfen.

Merke: maximaler Nutzen für das Unternehmen, fokussiert auf das wesentliche, timeboxed und Abhängigkeiten mit anderen Abteilungen sind geklärt. Sind wesentliche Merkmale von agiler Arbeit.
Merke, maximaler Nutzen steht im Backlog an oberster Stelle! Somit kann ich langsam ein Backlog erstellen und an Scrum heranführen.

In einem Event indem der Vertrieb eingeladen ist würde ich dann folgende Fragen oder ähnlich nach dem Vorbild OKR stellen.
Was läuft gut im Vertrieb und wie kann ich es nutzbringend ausbauen?
Was läuft gut im gesamten Unternehmen gut und wie kann ich es nutzbringend ausbauen?
Was funktioniert schlecht und wie könnte eine Lösung aussehen?
Welche Verbesserungsmöglichkeiten gibt es?
Wie kann ich den Nutzen für das Unternehmen verbessern?
Vielleicht entsteht ja eine Liste die wir Backlog nennen und können dann das Backlog priorisieren und in 4 Wochen abarbeiten – schon ist Scrum eingeführt.
Diese Liste sind dann auch die besten Argumente für die Veränderung.
Viele Grüße
Martin Messerer

Beantwortet: Sind agile Projekte und Termintreue von Roadmap-Meilensteinen zu vereinbaren?

Tue, 21 Jul 2020 08:44:02 +0000

Ich möchte zusätzlich noch eingehen auf den Wunsch nach mehr Detailtreue. Wir alle sind es gewohnt, dass wir versuchen einen möglichst guten Plan von vorne herein zu definieren, damit die Risiken früh erkannt werden und man überhaupt erst gar nicht in ein Problem läuft. Dieser Wunsch nach früher Sicherheit ist nur zu verständlich, ist nur leider nicht vereinbar mit einem komplexen Sachverhalt, bei dem sich erst auf dem Weg herauskristallisiert, was funktioniert und was nicht.

Hier wird also das eigentliche Problem verursacht. Denn wir denken nur, dass unser Plan bereits so gut ist, dass die meisten Risiken bereits berücksichtigt sind. Auch hier kommt wieder das psychologisch wirksame und schädliche Denken in 'Anforderungen' zum Tragen. Denn unter Komplexität gilt: Jede Lösungsidee, die noch nicht umgesetzt wurde ist und bleibt eine Hypothese!

Hat man sich erst einmal mit diesem Gedanken angefreundet, fällt es leichter eben nicht mehr zu versuchen, alles vorweg zu planen. Und zwar aus ganz logischen Gründen: Was, wenn die Hypothese sich als falsch erweist? Dann wären nämlich alle bisherigen Anstrengungen (in Form von Zeit und Geld) unwiederbringlich verloren. Deshalb drängt sich beim Denkmodell in Form von Hypothesen statt Anforderungen sofort die Frage auf: Wie können wir möglichst schnell heraus finden, ob unsere Hypothese richtig ist?

Man hangelt sich also von einer Hypothese zur nächsten vor, immer in Richtung auf das Ziel und kann dabei schnell gegensteuern, sollten Überraschungen auftreten. Es mag unserem Wunsch nach Sicherheit widersprechen, so zu arbeiten. Defacto bleibt aber festzuhalten, dass diese Herangehensweise die besten Chancen auf Erfolg hat.

Auf der anderen Seite möchte man frühzeitig wissen, ob denn überhaupt das Ziel erreicht werden kann. Das heißt, eine gewisse Planung (in Form von Lösungshypothesen!) ist nicht nur wünschenswert, sondern auch sinnvoll. Woher soll man sonst wissen, ob ein Meilenstein gehalten werden kann? In der Praxis ist dies mit schlanken Herangehensweisen, wie Du das schon angedeutet hast, sehr einfach und ohne große Aufwände möglich. Dazu bieten sich neben den bereits genannten Werkzeugen Magic Estimation und Event Storming, z.B. Burnup-Charts an. Mittels dieser kann ein Überblick gegeben werden können, mit welcher Wahrscheinlichkeit der aktuelle favorisierte Plan (wiederum: in Form von Lösungshypothesen) den Meilenstein einhalten kann. Stellt sich heraus, dass es sehr unwahrscheinlich ist, müssen eben andere Wege gefunden werden, um das Ziel zu erreichen. Dwight D. Eisenhower hat einmal gesagt: "Plans are worthless, but planning is everything." Dem stimme ich zu. Im Agilen wird - wie oft missverständlich behauptet wird - nicht nicht geplant, sondern es wird ständig geplant und Änderungen am Plan sind an der Tagesordnung. Wie agil hier eine Organisation solche Änderungen erarbeiten kann, hat maßgeblichen Einfluss auf die Erfolgschancen, dass die gesteckten Ziele auch erreicht werden. Traditionelle Strukturen, abgeteilte Funtionseinheiten, viele Abhängigkeiten zwischen Abteilungen, Kommunikation über Dokumente anstatt miteinander zu Reden, Entscheidungsbefugnisse nur an zentralen Stellen (= Engpass!) machen diese Notwendigkeit nach schneller Planänderung zu langsam und damit zu teuer und verhindern effektive Agilität. Und erhöhen damit vehement die Risiken, dass ein Ziel nicht erreicht wird.

Beantwortet: Wie damit umgehen, dass die Software stückweise von Scrum-Teams immer aufwendiger zu testen ist?

Wed, 15 Jul 2020 14:19:43 +0000

Ich kenne das Problem. Die Software wird immer umfangreicher und die Seiteneffekte durch Neuentwicklungen werden immer unbeherrschbarer. Es gibt dazu ein Grundprinzip: Testautomatisierung! Mein früherer Arbeitgeber, die andrena objects AG hatte sehr gute Kenntnisse im SW-Engineering. Sie haben den Ausdruck geprägt: "Legacy Software ist jede Software, die nicht automatisiert getestet wird." Oder: "Nur Test- und Deploymentautomatisierung ermöglicht wirksame Agilität." Deshalb hatten sie in SW-Projekten zunächst eine Priorität darauf, dass der bestehende Code erstmal mit automatisierten Tests abgesichert wird.

Microservices sind ein gutes Pattern, um Unabhängigkeit zwischen einzelnen Softwarekomponenten zu erreichen. Das alleine reicht aber nicht. Auch die Microservices müssen automatisiert getestet werden. Ich kenne den Kontext nicht, aus dem die Frage entstanden ist. Auf alle Fälle kann ich empfehlen, genau hinzusehen, wie es mit er bestehenden Testautomatisierung aussieht? Ist die Testpyramide erfolgreich umgesetzt?

Also

automatische Unit-Tests für die Tests direkt im Compiler bzw. der Dev-Umgebung, die nach jedem Checkin ins Code-Repository automatisch ausgeführt werden. (Laufzeit im Bereich von Sekunden bis Minuten)
Unit- und Integrationtesting auf der (den) Testumgebung(en), die bei jedem Deployment getriggert werden. (Laufzeit im Bereich von Minuten bis Stunden, besser Minuten)
Smoketests bevor die neuen Funktionen produktiv gehen?

Tests müssen kontinuierlich durchgeführt werden. Wobei anzumerken ist, dass die Tests im Vorfeld vor der Entwicklung definiert werden sollten (Stichwort TDD), damit während der Entwicklung zu jeder Zeit gegen diese Testkriterien getestet werden kann und nicht erst beim Deployment auf die Testumgebung festgestellt wird, dass die Tests nicht erfolgreich laufen. Denn dann fängt man wieder von vorne an und das kostet unnötig Zeit und Geld. Ein oft beobachtetes Phänomen ist das des Mini-Wasserfalls innerhalb eines Sprints. Es ist und war nie Ziel, am Ende eines Sprints festzustellen, dass die Qualität nicht stimmt. Qualität kann nicht eingetestet werden, sondern muss von vorne herein eingebaut werden! Deshalb gelingt es einem guten Scrum-Team, die Tests bereits sehr früh im Sprint zur Verfügung zu stellen.

Hinsichtlich des Testaufwandes bleibt somit festzuhalten, dass der Aufwand idealerweise nur 1x nötig ist, nämlich zum Erstellen der automatisierten Tests. Anschließend sorgt das automatisierte Testsystem dafür, dass die Kosten für das Testen minimal bleiben.

Ich habe Systeme gesehen, wo bei jedem Deployment auf die Integrationsumgebung an die 7000 Tests ausgeführt werden. Das sollte für eine state-of-the-art Testautomation kein Problem darstellen.

Eine weitere Möglichkeit, Testautomatisierung einfacher zu gestalten, ist die Anwendung geeigneter Containerisierung (Stichwort docker) und adhoc Erstellung von Testumgebungen (Stichwort kubernetes). Damit können ganz gezielt Testkonfigurationen hergestellt werden, um in ihnen besondere Testszenarien zu testen. Z.B. können gezielt Netzwerkverbindungen gekappt werden oder falsche Daten erzeugt werden, damit die Tests prüfen können, wie die Software mit solchen Fehlern zurecht kommt.

Wendet man diese Prinzipien konsequent von Anfang an an, lassen sich Software-Systeme damit auch über Jahre hinweg nachhaltig und mit wenig Wartungsaufwand weiterentwickeln. Wurde diesem wichtigen Punkt der Testautomatisierung zu Beginn zugunsten von schnellerer Featureentwicklung zu wenig Aufmerksamkeit gewidmet, bleibt leider nur zu sagen, dass dies nun aufwändig nachgeholt werden muss.

Eine Anmerkung möchte ich noch mitgeben hinsichtlich der Aussage '... Testaufwand gering zu halten, damit sich ein Scrumteam auf die neuen Bausteine neuer Sprints konzentrieren kann...' : Ein Scrum-Team ist vollverantwortlich dafür zu sorgen, dass der Testaufwand eben NICHT aus dem Ruder läuft. Deshalb gehört beim Nachdenken darüber, wie neue Features entwickelt werden zwangsläufig dazu, darüber nachzudenken, wie die neuen Features entsprechend abgesichert werden können, damit man sich über mögliche Seiteneffekte späterer Entwicklungen keine Gedanken machen muss. Es ist also kein entweder-oder, sondern diese Dinge gehören schlicht zusammen.

Abseits der Testautomatisierung und Microservices gibt es natürlich weitere Möglichkeiten, wie nachhaltige Software entwickelt werden kann. Jedem Entwickler müssen die Clean-Code-Prinzipien nicht nur vertraut sein, sondern er sollte sie auch sicher anwenden können. Wenn Microservices auf der modularen Ebene für Unabhängigkeit sorgen, dann gibt es ähnlich wirksame Prinzipien und Software Design Patterns auch auf der Code-Ebene. Z.B. das Single-Responsibility-Prinzip für Klassen. Nähere Infos hierzu finden sich hier: https://clean-code-developer.de/

Ist hier noch Entwicklungspotential der Mitarbeiter gegeben, ist es Aufgabe des Managements, für diese Entwicklung der persönlichen Fähigkeiten entsprechenden Freiraum zur Verfügung zu stellen. Der Invest zahlt sich schon nach kurzer Zeit aus.

Übrigens: Studien haben gemessen, dass das Verhältnis zwischem einem echten Profi-Programmierer und einem durchschnittlichem Programmierer einen Produktivitätsfaktor von bis zu 300, also 30000% ausmachen kann. Es lohnt sich also, bei der Rekrutierung genau hinzusehen. Lieber etwas mehr für einen Profi-Programmierer ausgeben, der vielleicht 30% teurer sein mag wie ein Durchschnittsprogrammierer. Es lohnt sich in den meisten Fällen.

Beantwortet: Bei wem sollte die Verantwortung für das Schreiben von User Stories liegen?

Tue, 14 Jul 2020 19:29:25 +0000

Ich bin mir nicht sicher, ob die Frage nach der Verantwortlichkeit für das Schreiben von User Stories die richtige Frage ist. Deshalb hole ich zum besseren Verständnis etwas weiter aus:

Zunächst ist einmal klar, dass die Verantwortlichkeit für das Backlog (z.B. als eine sortierte Liste von User Stories) beim Product Owner liegt.

Wenn es um User Stories geht, assoziiere ich damit zuallererst ein Werkzeug, das nützlich dabei ist, ein gemeinsames Problemverständnis zw. Product Owner und Umsetzungsteam zu erreichen. Nicht umsonst heißt es über User Stories: 'Sie sind ein Versprechen auf eine noch zu führende Diskussion'. Diese wichtige Aussage macht für mich den Unterschied. Während im traditionellen Wasserfall Anforderungsdokumente geschrieben werden und dann weitergereicht werden an ein Team, dass diese Anforderungen umsetzen soll, soll mit der Anwendung von User Stories insbesondere die gemeinsame Diskussion über diese Anforderungen unterstützt werden. So betrachtet, ist es letztlich nicht entscheidend, WER die User Story schreibt, sondern DASS die Diskussion stattfindet. Jeder kennt das 'Stille Post' Spiel aus der Kindheit, indem man sich in einer Reihe aufstellt, der Erste dem Zweiten einen Sachverhalt ins Ohr flüstert, der Zweite diesen Sachverhalt weitergibt an den Nächsten und der Letzte in der Reihe dann laut ausspricht, was von der ursprünglichen Botschaft bei ihm noch angekommen ist. Nicht selten wurde dabei viel gelacht, welch Blödsinn übrig geblieben ist. In der Arbeitswelt ist dieser Sachverhalt zu beobachten, wenn versucht wird, alleine über Dokumente zu kommunizieren. Leider ist es hier ernst und falsch verstandene Sachverhalte verursachen gefährliche Kosten einer Fehlentwicklung am ursprünglichen Ziel vorbei. Das ändert sich auch nicht, indem man die Anforderung nun User Story nennt und gleichzeitig das altgewohnte Verhalten beibehält, indem versucht wird in der User Story genau zu beschreiben, was gemeint ist und davon ausgegangen wird, dass ein Team den Inhalt richtig interpretiert. Richtiges Verständnis ohne gemeinsame Diskussion ist eher die Ausnahme als die Regel. Als Reaktion auf dieses Problem erlebe ich, dass nach noch genauerer Beschreibung gerufen wird. Leider hilft das nicht, weil das eigentliche Problem, nämlich dass zu wenig miteinander geredet wird. Und ich ergänze, dass auch zu wenig visualisiert wird, um Gedankenmodelle und unterschiedliche Interpretationen sichtbar zu machen.

Indem Sinne, um die gestellte Frage zu beantworten: Wer sollte verantwortlich für das Schreiben von User Stories sein? Ich würde fast sagen Niemand! Die Frage verleitet zu sehr, dass das Schreiben im Vordergrund stehe und das geht an der Intention von User Stories grundlegend vorbei. Deshalb würde ich eher fragen: Wer ist verantwortlich dafür, dass User Stories diskutiert werden? Und das dürfen alle sein. Wenn es festgelegt sein soll auf ein dedizierte Rolle, dann würde ich sie dem Product Owner zuschreiben. Er muss dafür sorgen, dass das Team das zu lösende Problem richtig verstanden hat.

Als abschließenden Tipp möchte ich noch hinzufügen: Weniger ist mehr! Deshalb ist es hilfreich, um einen werthaltige Diskussion anzustoßen, dass lediglich die Story selbst mit dem bekannten Template "Als [Rolle] möchte ich [Funktionalität], um [Problem zu lösen]" textuell festgehalten wird. Im Refinement werden dann gemeinsam Akzeptanzkritierien entwickelt, mittels derer festgestellt werden kann, dass das Problem gelöst ist. Diese Akzeptanzkritierien werden dann im Anhang der User Story dokumentiert. Das Wichtigste ist also die Reihenfolge, was durch das CCC-Prinzip ausgedrückt wird: Zuerst die User Story (Card), dann die Diskussion (Conversation), dann die gemeinsamen Erkenntnisse, z.B. in Form von Akzeptanzkriterien (Confirmation).

Einen Nachteil von User Stories möchte ich nicht verschweigen. Indem im Template ein Wunsch für eine Funktionalität ausgedrückt wird, verleitet dies sehr schnell den User Story Autor bereits in das Lösungsdenken abzuschweifen. Das ist insbesondere dann tragisch, wenn dadurch das Team bereits vor-ge-biased, also vorbeeinflusst wird, was getan werden soll und lenkt vom eigentlichen Problemverständnis ab, welches unbedingt an erster Stelle stehen sollte. Würde das Team nur das Problem hören, entstehen möglicherweise ganz andere Lösungsideen, die besser, kostengünstiger und zielführender sein können. Durch die Vorbeeinflussung werden diese Ideen unbewusst unterdrückt und dieses wertvolle Potential ist dann leider verloren.

Je nach Situation und Reifegrad des Scrum-Teams bin ich daher statt der Beschreibung von User Stories übergegangen zum sogenannten Problem-Statement, welches z.B. diesem Format folgen kann: "The problem of [statement of problem] affects [users and/or stakeholders] the impact of which is [statement of issues, costs, or other impacts] a successful solution would be [important benefits that would successfully solve the problem]." Damit habe ich sehr gute Erfahrungen gemacht, dass die oben genannte wichtige Diskussion ganz von allein passiert.

Welche Kompetenzen brauchen die Mitarbeiter/ Projektmitglieder fürs Agiles Projektmanagement?

Sat, 28 Mar 2020 21:30:54 +0000

Mich würde es Interessieren, welche Kompetenzen die Mitarbeiter mitbringen müssen fürs Agiles Projektmanagement..

Könnte man einfach die Mitarbeiter aus dem „traditionellen PM“ einfach ins Agile PM mitnehmen? Was ist im Agilen PM anders?

Was kann ein Team tun, damit der / die Kunden die agile Zusammenarbeit spürbar wahrnehmen?

Wed, 11 Mar 2020 10:01:29 +0000

Gerade in frühen Phasen von agilen Teams stellt sich häufig die Frage, wie die positive Wahrnehmung der Kunden für die neue agile Arbeitsweise besonders gestärkt werden kann. Ziel dieser Arbeitsweise ist ja schließlich auch, dass das Ansehen des Teams durch diese Arbeitsweise steigt.

Neben erfolgreichen Sprints sowie regelmäßigen Reviews mit stetigen Ergebnissen, die einen Mehrwert bringen, gibt es nach meiner Erfahrung noch weitere Möglichkeiten. Hierzu interessieren mich Eure Erfahrungen und Elemente, die ihr erfolgreich als Agile Coach im Team gefördert sowie genutzt habt. Welche Elemente haben sich demnach also besonders bewährt, um die Zusammenarbeit mit Kunden durch Agilität des Teams zu fördern?

Gibt es Elemente bei der Ausführung der Rolle des Scrum-Masters, die Euch stören und wenn ja, wie geht Ihr damit um?

Fri, 21 Feb 2020 09:16:45 +0000

Vor kurzem wurde ich gefragt, ob es bis zu fünf Elemente in Scrum sowie gegebenenfalls bei der Rolle des Scrum-Masters gibt, die mich bei meiner täglichen Arbeit stören. Mich interessiert hierzu auch die Meinung der Teamprove Community und vor allem, wie Ihr mit bestehenden störenden, aber notwendigen Scrum-Master Aufgaben bei Eurer täglichen Arbeit umgeht.

Sollte in der Praxis bei User Stories auf Dokumente (z.B. Pflichtenheft) verwiesen werden?

Mon, 10 Feb 2020 09:33:19 +0000

Im Verlaufe des ersten User Story Workshops hat einer der Teilnehmer die oben genannte Frage gestellt. Die Frage kam von einem Mitarbeiter im Produktmanagement, der bisher häufig mit Dokumentationen wie Pflichtenheften etc. gearbeitet hat und nun verstärkt User Stories nutzen möchte. Für den Mitarbeiter ist insbesondere die Empfehlung für die Praxis interessant sowie Eure Erfahrung und ggf. ein konkretes Beispiel. Obgleich ich hierzu auch eine Meinung habe, möchte ich der Teamprove Wissen Community die Möglichkeit bieten hierauf zu antworten.

Dailies in skaliertem Scrum - ein großes vs. mehrere kleine was ist dabei zu beachten? Was ist sinnvoll?

Fri, 07 Feb 2020 09:39:01 +0000

Hallo zusammen,

mich würden eure Gedanken und Meinungen zu folgendem Thema interessieren:
In meinem aktuellen Projekt wurden gerade (vor wenigen Tagen) die Teams neu strukturiert, so dass aus drei Komponententeams drei Featureteams wurden. Wo früher jedes Team immer nur eine Komponente eines größeren Produkts bearbeitet konnte sind die Teams nun so zusammengestellt, dass jedes der neuen Teams nun das gesamte Produkt bearbeiten kann. Die neue Organisation ist stark an LeSS angelehnt und es gibt auch nur einen PO.
Aus den Teams gab es nun den Wunsch, ein gemeinsames Daily zu machen (ca. 20 Personen) um unteranderem den Austausch zwischen den Teams zu fördern.
Das aktuelle Vorgehen ist, dass wir es für eine Woche versuchen, ein großes gemeinsames Daily anstelle der einzelnen Team-Dailies abzuhalten.

Ich selbst muss zugeben, dass ich etwas skeptisch bin, ob es funktionieren kann. Halte die Idee aber für hinreichend spannend, als dass ich ihr gerne eine ehrliche Chance geben möchte. Da ich mir sicher bin, dass wir mit den klassischen drei Daily-Fragen aus dem Scrum Guide das gesteckte Ziel nicht erreichen können würde ich mich freuen, ein paar Anregungen und Ideen zu bekommen, wie man mit dieser Situation umgehen kann. Bzw. was dabei zu beachten ist oder was es vielleicht noch für spannende Ansätze gibt um damit umzugehen.

Wie mache ich aus großen Epics für eine Neu-Entwicklung ein Productbacklog mit Stories, für einen Sprint?

Wed, 22 Jan 2020 13:08:16 +0000

Ich denke man findet viele Informationen dazu, wie ein gutes Productbacklog aufgebaut sein sollte, aber was mache ich, wenn es noch kein Productbacklog gibt, dass es zu pflegen gilt, sondern ein neues Productbacklog erstellt werden muss?

Bei einer Neu-Entwicklung gibt es zu Beginn sehr viele Unbekannte. Um herauszufinden wie ein Produkt aussehen kann, gibt es ebenfalls bereits viele agile Methoden, die helfen sich ein Bild davon zu machen, z.B. Durch Design Thinking oder Design Sprints. Aber wie verarbeite ich die gewonnenen Erkenntnisse so, dass am Ende ein Backlog entsteht? Wie mache ich aus vielen recht großen Epics, kleine Stories, welche ich gut in den Sprint packen kann? Habt ihr hierzu bereits Erfahrungen gemacht oder Methoden?

Was kann ich tun, wenn der Product Owner das Bottleneck ist?

Tue, 26 Nov 2019 14:08:56 +0000

Wenn die Definition of Done eine Abnahme/Test aus User-Sicht durch den Product Owner vorsieht, passiert es schnell, dass der PO das Bottleneck wird und die Stories am Ende des Sprints bei ihm auflaufen. Häufig kann dieser nicht alle Stories rechtzeitig abnehmen. Es kann natürlich auch andere Gründe geben, weshalb der PO das Bottleneck im Sprint ist. Was sind hier eure Erfahrungen und welche Lösungen seht ihr hier, um einen besseren Flow herzustellen?

Wie lassen sich Retrospektiven skalieren?

Tue, 19 Nov 2019 18:02:50 +0000

Vielleicht kennt ihr die Situation: Man startet agil und alles läuft gut – bis das Team wächst und das Produkt von mehreren Scrum-Teams entwickelt wird. Wie funktionieren dann die Retrospektiven? Machen die Scrum-Teams nur unter sich Retrospektiven, dann fehlt das Übergreifende. Oder macht man eine große Retrospektive wo alle zusammenkommen, dann fehlt vielleicht die interne Abstimmung. Wie macht ihr das? Was sind eure Erfahrungen dazu?

Wer trifft Entscheidungen über Software-Architektur und Coding Style in selbstorganisierte Teams?

Wed, 18 Sep 2019 15:48:33 +0000

Oft höre ich von Mitarbeitern in Selbstorganisierte Teams, dass Sie sich jemand wünschen würden der Entscheidungen trifft. Zum Beispiel zu Coding Styleguides oder Software-Architektur. "Es wäre doch schön, wenn jemand endlich Standards definieren würde". "Wir brauchen ein Software-Architekt oder ein Teamleiter/Entwicklungsleiter der diese Entscheidungen trifft".

Ist es so, dass ein selbstorganisiertes Team von guten, erfahrenen Entwicklern die fachlich in der Lage sind gute Architekturen und Design-Entscheidungen zu treffen diese selbst treffen sollten oder ist es effektiver jemand zu haben der die Rolle eines Architekten hat und hauptamtlich diese Entscheidungen trifft? Was ist Eure Erfahrung hierzu?

Ansätze um User Stories auf zuteilen/kleiner zu schneiden

Thu, 29 Aug 2019 19:55:18 +0000

Hallo zusammen,
immer wieder erlebe ich es, dass es Teams und POs schwerfällt die Aufgaben so zu verfassen, dass sie klein genug sind um in einem Sprint umgesetzt zu werden.

Mit welchen Ansätzen/Tools kann ich das schneiden von großen User Stories in kleinere User Stories angehen?

Wie kann ich als Scrum Master mein Team bei der Implementierung von BDD (Beahvior Driven Development) unterstützen?

Fri, 02 Aug 2019 10:59:50 +0000

Bei der Einführung von BDD steht zuerst natürlich die Frage im Raum wie funktioniert das alles? Hier scheint es mir sinnvoll zunächst gemeinsam die Kerninhalte von BDD in einem Workshop und idealerweise mit echten Beispielen aus dem Projekt, zu erarbeiten. Doch für gewöhnlich machen die Feinheiten den Unterschied und es tauchen schnell Probleme mit Formulierung und Aufbau der Szenarien auf. Habt ihr vielleicht schon Erfahrungen mit solchen Problemen bei "Feinheiten" und wie würdet ihr in der Rolle als Scrum Master hier unterstützen? Ich freue mich auf eure Antworten!

Was versteht ihr unter Pregame und Postgame und wie ordnet ihr diese Begrifflichkeiten ein?

Tue, 11 Jun 2019 13:27:46 +0000

Mir sind diese beiden Begrifflichkeiten / Definitionen in Bezug auf einen Sprintzyklus über den Weg gelaufen. Pregame beschreibt die Phase vor und Postgame die Phase nach dem Sprint.

1) Pre-Game (Planning + Architecture )

2) Game (Sprint + Scrum meeting )

3) Post-Game (Demo + closure )

Was gehört in die jeweilige Phase? Was genau findet in diesen beiden Zeiträumen statt? Macht diese Unterteilung in euren Augen Sinn oder sollte man den Sprint als beginnend mit planning und endent mit review betrachten?

Was kann ich tun, um das Bewusstsein für die Wichtigkeit der Scrum Master Rolle zu schärfen?

Thu, 23 May 2019 08:32:32 +0000

Leider erlebt man immer wieder mal, dass gerade auf Führungsebene das Bewusstsein für die Wichtigkeit der Rolle des Scrum Masters sehr gering ist. Während die Rollen der Entwickler und Productowner sehr klar und offensichtlich sind, hat es der Scrum Master leider häufig schwer, seine Daseins-Berechtigung geltend zu machen. Und das, obwohl es im Scrum Guide ausführlich beschrieben wird und er wie jede andere Rolle auch wichtig und nötig ist.

Was können hier konkrete Maßnahmen sein, die helfen das Verständnis dafür zu verbessern?

Macht es Sinn Scrum mit kleinen Teams zu machen?

Tue, 21 May 2019 06:37:13 +0000

Ab welcher Teamgröße funktioniert Scrum? Macht es auch Sinn Scrum mit 2-3 Mitarbeiter zu machen? Im Scrum Guide steht: "Weniger als drei Mitglieder des Entwicklungsteams reduzieren die Interaktion und führen zu geringeren Produktivitätssteigerungen [als bei größeren Teams]. Kleinere Entwicklungsteams können eventuell kein potentiell auslieferbares Produktinkrement liefern, da sie möglicherweise nicht über alle benötigten Fähigkeiten verfügen."

Was soll dann ein kleines Team mit 2 Teammitglieder, ein Scrum Master und ein PO machen? Gibt es so was wie "Scrum für extrem kleine Teams"?

Wie terminiert man am Besten die SCRUM-Events bei zwei oder mehreren Teams?

Fri, 17 May 2019 08:54:08 +0000

Es kommt immer wieder mal vor, dass man nicht nur ein SCRUM-Team hat sondern evtl. mehrere. Wenn es dann noch der Fall ist, dass die Sprints der Teams parallel laufen, kommt man unweigerlich in die Situation, dass es Probleme mit den Terminen gibt.
Die einfachste Möglichkeit, die Situation aufzulösen, wäre es die Sprint nicht mehr parallel zu halten.
Was aber macht man, wenn dies nicht möglich ist? Würdet ihr dann mit jeweils einem Team, aller Termine an einem Tag machen oder würdet ihr die Tage nach Events aufteilen und dann entsprechend mit den Teams terminieren. Bsp. Retrospektive findet Dienstag statt, Planning am Mittwoch.

Was tun, wenn Scrum Teams ihre Sprintziele nie erreichen?

Tue, 14 May 2019 07:26:25 +0000

Ich habe schon einige Teams erlebt die ihre Sprintziele immer wieder verfehlen. Mal aus dem einen Grund, mal aus einem Anderen. Es kommt immer wieder was dazwischen, irgendjemand verschätzt sich, der Eine ist mal krank, usw. Am Ende stehen alle da und nur sehr wenig oder gar nichts ist fertiggeworden. Woran könnte es liegen? Was kann man unternehmen um aus dieser Situation herauszukommen?

Business Value - Wie fange ich an? Lohnt es sich überhaupt?

Thu, 09 May 2019 10:46:52 +0000

Der Business Value soll dem PO bei der Priorisierung der Aufgaben und der Auswertung der Sprintergebnisse helfen. Er möchte nun seine Aufgaben im Backlog mit einem Business Value versehen.
Wie starte ich mit dem Thema an besten? Gibt es einen guten Weg sich dem ganzen anzunähern? Und lohnt sich der Aufwand überhaupt?

Wie kann Mut für Innovationen und anspruchsvolle Sprintziele gefördert werden, wo das Umfeld keine Fehlerkultur kennt?

Wed, 08 May 2019 18:05:02 +0000

Ich persönlich habe u.a. mit Event Storming und User Story Mapping Workshops mit klarem Fokus auf die Stärkung des agilen Mindsets gute Erfahrungen gemacht und hohe Return on Time Invested (ROTI) erzielt. Welche Methoden habt Ihr schon eingesetzt, die gut angekommen sind und wie hoch war ggf. der ROTI?

Wie fördert man (täglich) das agile Mindset bei den Stakeholdern von Scrum Teams?

Wed, 08 May 2019 17:47:59 +0000

Vor Einführung von agilen Methoden, führe ich oft zunächst Workshops zur Förderung des Verständnisses von Agilität durch, um hierfür zu motivieren. Durch den regelmäßigen Einbezug der Stakeholder während des Sprints (z.B. in Abstimmungen mit einem Product Owner zu Anforderungen) kann zudem das gemeinsame voneinander Lernen unterstützt werden und die agile Haltung beider Seiten gefördert werden. Welche Wege seid Ihr schon mit den Stakeholdern zur Förderung der Agilität gegangen?

Wie lange sollte ein Team begleitet werden, um eine Aussage über dessen korrekten Scrum Anwendung treffen zu können?

Wed, 08 May 2019 17:37:30 +0000

Nach meiner Erfahrung reichen für einen ersten Eindruck sowie erste Aussagen zur agilen Haltung des Teams sowie der Anwendung des Prozesses zwei bis drei Tage, wobei diese sich um den Sprintwechsel bewegen sollten, um alle Scrum Meetings beobachten zu können. Um genauere Aussagen über die Team Performance treffen zu können ist es nach meiner Erfahrung empfehlenswert, ein Teams ein bis zwei Sprints zu begleiten und auch den Flurfunk zu begleiten sowie Einzelgespräche mit den Teammitgliedern (Entwickler/ generell Produktentwickler, Product Owner, Scrum Master) durchzuführen.

Wie sind Eure Erfahrungen hinsichtlich des zeitlichen Umfangs bei der Begleitung von Teams?

Welche Methoden haben sich für den Fitnesscheck von agilem Projektmanagement bewährt?

Wed, 08 May 2019 17:24:19 +0000

In Teams nutze ich häufig ein Team Self Assessment, siehe auch: https://www.google.de/amp/s/www.teamprove.de/blog/team-self-assessment-wie-agil-arbeiten-sie-wirklich%3fformat=amp

Darüber hinaus erstelle ich ein Coaching-Dokument mit Beobachtungen zur aktuellen Haltung der Mitarbeit und dem angewandten Prozess.

Wie geht Ihr vor?

Wie passen Fehlerbehebung und Scrum zusammen?

Wed, 08 May 2019 13:56:40 +0000

Teams müssen manchmal an langfristigen Themen arbeiten und parallel dazu müssen sie kurzfristig auf Kundenanfragen oder Probleme reagieren. Wie bringt man das am Besten zusammen? Im Planning gibt man ja ein Commitment ab, da kann man nicht vorhersehen ob ein Kunde drei Tage später größere Probleme haben wird. Es ist auch nicht realistisch den Kunden wochenlang warten zu lassen. Wie geht Ihr damit um?

Wie fängt man am Besten mit Scrum an? Big-bang oder in kleinen Schritten?

Wed, 08 May 2019 07:37:52 +0000

Die Väter von Scrum (Ken Schwaber und Jeff Sutherland) und viele andere Autoren empfehlen Scrum immer all-or-nothing einzuführen. Sie sagen, dass von Tag 1 alle Events, Rollen und Artefakte so sein müssen wie es im Scrum Guide beschrieben ist (zumindest ist das mein Verständnis). Was sind Eure Erfahrungen damit? Gibt es da nur den einen Weg oder macht manchmal auch die Einführung von Scrum in kleinen Schritten Sinn?

Sollte ein Scrum Team immer alle Sprint-Ziele erreichen?

Wed, 08 May 2019 07:12:22 +0000

Am Anfang des Sprints werden Ziele definiert. Alle Teammitglieder arbeiten gemeinsam um die definierten Ziele zu erreichen. Sie stimmen sich täglich ab und fragen sich regelmäßig ob sie die Ziele noch erreichen können, bzw. was getan werden kann, damit sie auf jedem Fall erreicht werden. Es gibt Teams die viel Druck vom Management oder von sich selbst bekommen um die Sprint-Ziele immer zu erreichen. Schafft ein gut funktionierendes Scrum-Team IMMER die Sprint-Ziele?

Ist es gut, wenn in Scrum ein Teammitglied gleichzeitig Scrum Master ist?

Tue, 07 May 2019 14:56:19 +0000

In kleinen Organisationen fällt es manchmal schwer aus einem Teammitglied einen Vollzeit Scrum-Master zu machen oder jemand dafür einzustellen. Deswegen wird es manchmal so praktiziert, dass ein Teammitglied parallel zu den gewohnten Aufgaben noch die Scrum Master Rolle übernimmt. Würdet Ihr das empfehlen? Was sind Eure Erfahrungen damit?