Erkenntnisse als Newcomer in der agilen Welt

Hätte ich das vor einem Jahr gewusst …
ich würde alles noch einmal genauso machen.

Dies ist mein allererster Blogbeitrag, seit ich die Pforten zur agilen Welt geöffnet habe. Was, erst jetzt?! Ja, erst jetzt.
„Alles zu seiner Zeit.“

Marcel Lehmann, ein Wertwandler seit Juli 2024.

Mein erster Berührungspunkt mit dem Begriff Scrum

Vor ungefähr fünf Jahren sass ich mit meinem Mitbewohner am Küchentisch, und wir beschäftigten uns mit unseren Projekten. Ich schrieb ein Konzept für meine 24. Geschäftsidee, und er lernte für seine Zertifizierung als Scrum Master.

„Hä? Worum geht es da genau?“, fragte ich ihn.

Er erklärte es mir mit seinen Worten, und ich verstand es auf meine Weise. Doch meine Gedanken wanderten schnell wieder zurück zu meiner One-Million-Dollar-Business-Idee.

In den darauffolgenden vier Jahren baute ich mein Business auf, wurde reich und wanderte nach Bali aus – Quatsch. Ganz im Gegenteil.

Es begann eine Zeit, in der ich bestehende Ideale loslassen musste, um meinen inneren Antrieben und Interessen zu folgen. Keine leichten Entscheidungen.
Am Ende fand ich mich in einer Situation wieder, in der ich allein in einer befristeten Wohnung sass, in der einen Hand ein gekündigter Arbeitsvertrag, in der anderen ein Flugticket nach Vietnam.

Der Startschuss

Vier Jahre später stellte ich meinem damaligen Mitbewohner dieselbe Frage noch einmal: „Worum geht es bei Scrum – und was macht ein Scrum Master?“

Er vernetzte mich mit einer Person, die ich sinnbildlich als Pfortenwächter bezeichnen würde. Gemeinsam erkannten wir Chancen für eine Zusammenarbeit – und es passte perfekt zu meinem inneren Antrieb und meinen Interessen.

Von da an ging alles sehr schnell. Ich fand mich in einer völlig neuen Situation wieder: Diesmal mit einem unbefristeten Mietvertrag, zusammen mit Freunden. In der einen Hand ein Arbeitsvertrag, in der anderen ein Mandat als Scrum Master.

Was ich erleben durfte…

Heute, nach zehn Monaten als Scrum Master, bin ich an einem Punkt in meinem Leben angekommen, den ich mir nicht besser vorstellen könnte – er entspricht meinem Ideal.
Und es brauchte alle Etappen meines Lebens. Alles kam zu seiner Zeit. Genau deshalb ist jetzt auch der richtige Zeitpunkt für meinen allerersten Blogbeitrag.

Zu Beginn, war ich irritiert. Während Agilität in manchen Unternehmen längst ein alter Hut ist, ist sie in anderen der neueste Way to go. Für mich als Newcomer konnte das zu Unsicherheiten führen und den Blick auf die Zukunft trüben. Dazu kommen all diese agilen Methoden – Scrum, Kanban, SAFe usw. Alles klingt logisch, aber auch abstrakt.
Grund genug, meine Erfahrungen zu teilen: was ich lernen durfte und weshalb ich mich nicht wieder beim Pfortenwächter verabschiedete und alles den Wasserfall hinuntergehen ging.

Rückblickend durfte ich in meinem Mandat und in der Rolle als Scrum Master viele neue und spannende Situationen erleben.
Dabei ging es vorwiegend um die Begleitung von Teams, was mir sehr entspricht.
Die unterschiedlichen Teamdynamiken in verschiedensten Situationen zu erleben und zu begleiten, war stets herausfordernd und bereichernd.
Die Vielzahl an Retrospektiven schenkte mir die Möglichkeit, die Teams besser kennenzulernen und sie mit den agilen Prinzipien vertraut zu machen.
Ich erkannte schnell: Theorie ist nicht gleich Praxis und es erforderte von mir viel Flexibilität, mich auf neue Situationen einzulassen.

Besonders bei der Konzeption und Durchführung von Workshops auf Führungsebene durfte ich viel über mich und meine Tätigkeit lernen.
An jeder Herausforderung konnte ich ein Stück wachsen und gleichzeitig den Mehrwert im Unternehmen erkennen.
Obwohl ich vieles allein vorangetrieben habe, hatte ich stets motivierende Menschen um mich und ein starkes Team im Rücken.
Die Zusammenarbeit mit Gleichgesinnten sowie das gegenseitige Unterstützen und Herausfordern sind für mich zentrale Aspekte, um mit Freude und Begeisterung bei der Arbeit zu sein.
Genau mit dieser Motivation, Teams in diesen Flow-Zustand zu begleiten, stehe ich heute am Markt und freue mich auf alle neuen Begegnungen und Herausforderungen, um schlussendlich unsere Kunden zu begeistern.

Was ich aus meinen ersten Erfahrungen mitnehme ist, dass Agilität und agile Methoden nichts Neues sind und auch nichts, was plötzlich wieder verschwindet. Mir ist bewusst, dass Viele darüber sprechen, oft mit unterschiedlichen Begriffen, doch ähnliche Kerngedanken verfolgen.

Aus meiner Sicht erklärte es bereits Charles Darwin in seiner Evolutionstheorie:
„Es ist nicht die stärkste Spezies, die überlebt, auch nicht die intelligenteste, sondern diejenige, die sich am besten an Veränderungen anpassen kann.“

Wenn du dich, dein Team und dein Unternehmen nachhaltig weiterentwickeln möchtest, dann investiere in deine Lernbereitschaft, Offenheit für Veränderung und den Mut, neue Wege zu gehen. Agilität beginnt nicht mit Methoden – sie beginnt mit deiner Haltung.
Und vergiss nie: Alles zu seiner Zeit.

Lust auf einen Kaffee? Ja!

Warum eine Test-Spalte auf Boards ein Problem darstellt

Ich bin Sebastian Stautz und Software-Tester mit Passion seit 2008. Seit über 10 Jahren arbeite ich in verschiedenen Scrum-Teams und sehe Probleme in der Verwendung einer Test-Spalte auf Boards.

Diesen Artikel habe ich ursprünglich im April 2024 auf englisch auf meinem Blog veröffentlich.

Häufig sehe ich auf Boards nach dem typischen „Open“, dass die nächste Spalte entweder gleich „Dev“ heißt oder selbst als generisches „In Progress“ / „In Arbeit“ Entwicklern bzw. Entwicklungsaufgaben vorbehalten ist. Diese wird wiederum folgt sehr oft „Test“ / „QA“.
In diesem Artikel lege ich dar, warum ich diese Aufteilung als Problem sehe, wird sie erzwungen kann sie Probleme erzeugen, und was mögliche Alternativen sind.

Eine Test-Spalte auf einem Board funktioniert genau dann, wenn …

… man nur eine Aufgabe gleichzeitig an dem Ticket ausgeführt werden kann. Entwicklung XOR Testen.
Wann ist das wirklich mal so ??? Sehr selten.

Das Tester immer nur nach der Entwicklung anfangen können, basiert auf dem Missverständnis, dass Testen auf die reine Interaktion mit dem Produkt reduziert.
Als ob keine Vorarbeiten möglich wären oder auch Interaktion mit dem Produkt nicht parallel zu Entwicklung statt finden könnte (z.B. auf verschiedenen Zwischenständen).

Eine Command & Controll-Mentalität mag ein anderer Ursprung sein. Für konstruktive Zusammenarbeit und schnelles Feedback ist schon allein diese nicht hilfreich.

Einige Modelle der tatsächlichen Arbeitsverteilung

Dies sind ein paar vereinfachte Modelle dessen, wie ich regelmäßig beobachte, dass Tester und Entwickler an einem Ticket arbeiten. Die Realität ist noch komplexer.

Rhetorische Frage: Wann wechselt hier ein Ticket von der In-Progress- in die Testspalte?

=> eine einzige In-Progress-Spalte ist ausreichend

Testen profitiert von der Vorbereitung

Das Sammeln von Informationen, das Erstellen und Besprechen erster Pläne, das Vorbereiten von Test-Daten und -Werkzeugen und vieles mehr sind Aufgaben beim Testen, die ohne ein tatsächliches Produkt durchgeführt bzw. begonnen werden können. Während oder sogar bevor der Code geschrieben wird.

Was sind gute Gründe, dies zu verschieben, bis die Entwicklung der ersten Version abgeschlossen ist? Abgesehen von Zeitmangel.
Es wäre eine Zeitverschwendung und ist ein Risiko, da es die Feedbackzeit für die Entwickler und Projektverantwortlichen verlängert.

=> eine einzige In-Progress-Spalte ist ausreichend

Testen kann in die Entwicklung integriert werden

Anbei zwei Beispiele aus meinem Alltag in denen ich enge mit Entwicklern zusammen gearbeitet habe und wir gar nicht klar sagen könnten in welcher Spalte gerade ein Ticket wäre

  1. Pair-Testing mit Entwicklern auf deren PC. Sie zeigten mir die Anwendung und ich beriet sie was sie ausprobieren sollen. Die Kollegen haben während dieser Sitzung Codeänderungen gemacht und ggf. die Anwendung neu gebaut um sie sofort wieder testen zu können.
  2. Ich kann das Produkt selbst lokal bauen und deployen. Vor diesem Hintergrund geben mir Entwickler in kurzen Abständen Code-Änderungen (git push & pull), die ich wiederum innerhalb von Minuten getestet habe. Oft während wir dabei telefonierten.

=> eine einzige In-Progress-Spalte ist ausreichend

Testen kann parallel zur Entwicklung durchgeführt werden

Es kommt häufig vor, dass ich mit dem Produkt interagiere, während die Entwickler parallel dazu noch an grundlegenden Szenarien programmieren:

Sie fangen an, Fehler zu beheben, während ich weiter teste.
Ich beginne mit dem Testen von noch nicht vollständig entwickelten Funktionen, bei denen wir uns darauf einigen, dass ich nur bestimmte Stellen betrachten soll. Frühes Feedback. Ich teste, während die Entwickler programmieren.

=> eine einzige In-Progress-Spalte ist ausreichend

Was ist mit Tickets?

All das oben Gesagte gilt unabhängig davon, wie die Arbeit organisiert ist.

Bug-Tickets – Testen ist hier zuerst (und auch zuletzt)

Bei Bug-Tickets geht es im Allgemeinen darum, dass jemand ein Problem gefunden und dies gemeldet hat. Typischerweise ein Tester. Aber nur das Symptom zu beschreiben ist für Entwickler selten ausreichend.

Ein Tester muss das genau Szenario herausfinden, dann (versuchen) die Entwickler das Problem zu beheben. Und schließlich muss der Fix getestet werden (und vielleicht noch ein paar Runden, weil es neue Probleme gibt).
Würde dieses Ticket in einer Testspalte beginnen und dann zurück in die In-Entwicklung-Spalte wechseln? …

Testen kommt hier zuerst.

=> eine einzige In-Progress-Spalte ist ausreichend

Fehlermeldungen von extern

Oft fehlt es externen Fehlerberichten an Informationen und sie beschreiben das Problem sehr schlecht, was es schwer macht, es zu reproduzieren und zu wissen, was behoben werden muss.

Tester handeln hier oft vor der Entwicklung in dem sie den Fehleranalysieren und versuchen zu reproduzieren.

=> eine einzige In-Progress-Spalte ist ausreichend

Ein einziges Ticket für mehrere Personen

Irgendwie haben Sie nur ein einziges Ticket, aber mehrere Personen arbeiten parallel daran. Sie verwenden keine Sub-Tasks.
Diese Personen können sowohl mehrere Entwickler als auch Tester sein. In welche Spalte würden Sie ein solches Ticket einordnen, vor wenn beide Disziplinen daran arbeiten?
In Jira z.B. kann ein Ticket nur 1 Bearbeiter haben

=> eine einzige In-Progress-Spalte ist ausreichend

Ein Ticket mit Sub-Tasks als Instanzen

Z.B. in Scrum werden oft Stories mit Sub-Tasks verwendet.

Entweder man hat dedizierte Sub-Tasks für Entwicklung und Testing:
=> eine einzige In-Progress-Spalte ist ausreichend

Und/oder mehrere Personen arbeiten an den Teilaufgaben:
=> eine einzige In-Progress-Spalte ist ausreichend, siehe Absatz zuvor.

Zusammenfassung

Testen und Entwickeln sind Aufgaben, die grundsätzlich parallel durchgeführt werden können. Nur weil noch kein Code geschrieben ist, heißt es nicht, dass Tester nichts zu tun haben.

Außerdem bilden beide eine Rückkopplungsschleife:
Das Testen informiert (mindestens) die Entwicklung und die Entwicklung gibt dem Testen etwas, mit dem es interagieren kann.
Im schnellsten Fall kann diese Schleife in wenigen Minuten mehrmals durchlaufen werden.
Feedback bringt man besser früher als später ein. Wenn Entwickler bereits den Kontext gewechselt haben, dauert es für diese länger wieder ins Thema zu kommen.

Jedes Ticket in einem Issue Tracker ist ein (vereinfachtes) Modell einer komplexeren Realität.

Vor allem die Möglichkeit, nur einen Mitarbeiter zuzuweisen, ist oft weit von der Realität der Teamarbeit entfernt.

Alternativen

Hier sind einige Ideen, was man stattdessen tun könnte.

  • Personenorientiert:
    • Eine Liste alle Personen, die an dem Ticket arbeiten.
      • Für jede Person kann man einen Status pflegen ob sie noch daran arbeitet oder schon fertig ist. Z.B. als Wort oder Symbol.
  • Aufgabenorientiert:
    • Eine Liste von Aufgaben mit Namen wer an welcher arbeitet. Hier gilt das Gleiche für den Status.
    • Subtasks anstatt einer Liste. Die Felder Bearbeiter und Status gibt es hier meistens.
  • Welche Aufgaben man fürs Testen haben kann:
    • X vorbereiten, Y erforschen, Z überprüfen/besprechen. Für so viele Unterthemen wie nötig.
    • Wenn man Session-Based Test Management verwenden, kann man für jede Sitzung einen Subtask erstellen.
    • Daten vorbereiten? Ein Werkzeug entwickeln oder verbessern? Die Grundlagen des neuen Features lernen? Was auch immer => ein neuer Subtask

Kontaktdaten

Die Reise der kontinuierlichen Verbesserung: Agile/Scrum und der Deming Cycle

Stelle dir eine aufregende Reise vor, bei der du deine Organisation transformieren kannst und kontinuierliche Verbesserung erreichen könntest. Auf dieser Reise begegnest du zwei wertvollen Begleitern: Agile/Scrum und den Deming Cycle. Gemeinsam bilden sie ein kraftvolles Duo, das dir hilft, Hindernisse zu überwinden und den Weg zu kontinuierlichem Erfolg zu ebnen. Tauchen wir ein in diese fesselnde Geschichte und entdecken Sie, wie sich Ihre Organisation in eine Quelle der Exzellenz verwandelt.

Die Begegnung mit Agile/Scrum – Der Wendepunkt

Eines Tages stolperst du über das Konzept von Agile/Scrum, einem aufregenden Ansatz für agile Produktentwicklung. Es ist wie eine erfrischende Brise, die Veränderung und Flexibilität in die Luft bringt. Du erkennst, dass dies der Wendepunkt ist, an dem sich deine Organisation in eine neue Ära der Zusammenarbeit, des schnellen Feedbacks und der kontinuierlichen Lieferung bewegt. Agile/Scrum wird dein Wegbereiter für eine effektivere und effizientere Arbeitsweise.

Der Deming Cycle – Die Karte zur kontinuierlichen Verbesserung

Auf deiner Reise triffst du einen weisen Reiseführer namens Dr. Deming, der dir den Deming Cycle vorstellt. Mit einem Lächeln erklärt er dir, dass der Deming Cycle der Kompass ist, der dich auf dem Pfad der kontinuierlichen Verbesserung führt. Er besteht aus vier Schritten: Plan, Do, Check und Act. Du erkennst, dass diese Schritte deine Richtlinien sind, um Prozesse zu planen, umzusetzen, zu überprüfen und auf der Grundlage der Ergebnisse zu handeln.

Gemeinsam auf dem Weg zur Veränderung

Mit Agile/Scrum und dem Deming Cycle als deine treuen Begleiter gehst du weiter auf deiner Reise der kontinuierlichen Verbesserung. Agile/Scrum bringt die Flexibilität und den iterativen Ansatz, der es dir ermöglicht, schnell auf Veränderungen zu reagieren und wertvolles Feedback zu erhalten. Der Deming Cycle bietet dir eine klare Struktur, um Ziele zu setzen, Prozesse zu optimieren und kontinuierlich Verbesserungen vorzunehmen.

Die Transformation vollenden

Während deiner Reise erlebst du unglaubliche Veränderungen. Du siehst, wie deine Organisation agiler wird, wie Teams enger zusammenarbeiten und wie kontinuierliche Verbesserung zu einer grundlegenden Denkweise wird. Die Reise mag manchmal herausfordernd sein, aber mit Agile/Scrum und dem Deming Cycle an deiner Seite hast du die Werkzeuge und den Mut, Hindernisse zu überwinden und deine Organisation zu transformieren.

Fazit: Die Reise der kontinuierlichen Verbesserung mit Agile/Scrum und dem Deming Cycle ist wie ein spannendes Abenteuer. Es ist eine Geschichte von Transformation, Zusammenarbeit und ständigem Streben nach Exzellenz.