Agiles Arbeiten auf dem Drupal 8 Code-Sprint im Jahr 2017 bei comm-press

Quer einsteigen . Meine Scrum-Hospitanz bei comm-press

von Kathrin Wilkes
am

Auf dem 11. Bar Camp im November 2017 in Hamburg weckt der kurze Pitch „Bei uns wird es ohne mich erst schön.“ von Ralf Hendel, dem Geschäftsführer der Online-Agentur comm-press, augenblicklich meine Neugierde.

Und auch sein provokanter Einstieg in den Impulsvortrag „Ich bin Chef, habe Führerscheinklasse 3 und kann weniger als meine Angestellten.“ erfüllt die geweckten Erwartungen. Denn was folgt, ist ein kurzweiliger und hochinteressanter Einblick in die Unternehmung eine Online Agentur, die hauptsächlich Content Management Systeme entwickelt, konsequent nach agilen Prinzipien zu führen. Ich fühle mich angesprochen von Ralf Hendels Offenheit und seiner Fähigkeit zur humorvollen Selbstreflexion. Ehrlich gesagt, bin ich begeistert davon, wie er seine eigene Rolle so konstruktiv in Frage stellt. (Nachzulesen hier)

Als Ralf Hendel in seinem Vortrag davon spricht, dass es seit Anfang 2015 bei comm-press einen festangestellten Scrum Master gibt, der die zwei festen Scrum Teams unterstützt, spreche ich ihn nach dem Vortrag an. Gibt es die Möglichkeit, eine Hospitanz in der Firma zu machen, um Scrum und die agile Softwareentwicklung in Reinkultur aus nächster Nähe kennen zu lernen?

Ralf Hendel: Bei uns wird's ohne mich erst schön

Ein Legal Alien im Scrum Team

Ich bin seit 18 Jahren freie Drehbuchautorin und Dramaturgin. Mein Wunsch eine Scrum-Hospitanz zu machen, ist aber nicht der Suche nach einem neuen Stoff geschuldet oder stellt gar einen Selbstversuch dar. Nein, ich möchte mich beruflich neuorganisieren, da die langen, finanziellen Durststrecken des künstlerischen Daseins sich immer schwerer mit meinem Sicherheitsbedürfnis in meiner Rolle als Mutter zweier Kinder vereinbaren lassen.

Ich bin auf der Suche nach einer neuen beruflichen Heimat als Scrum Master. Und baue darauf, dass mein viele Jahre zurückliegendes Informatikstudium, und mein Interesse an Technik und IT-Themen mir beim Quereinstieg, oder soll man lieber sagen, beim Wiedereintritt in die IT-Atmosphäre, helfen.

Ralf Hendel ist meiner Idee einer Scrum Hospitanz gegenüber aufgeschlossen und ich bin aufgeregt und neugierig, herauszufinden, ob ich mit meiner beruflichen Wahl richtig liege.

Meeting the Scrum Master

Eine Woche nach dem Hamburger Barcamp kommt das erste Treffen mit dem comm-press Geschäftsführer und dem Scrum Master Carsten Rhein zustande. Beim Kennenlernen werden mir kurz die wichtigsten Events vorgestellt, die die Arbeitsabläufe beider Scrum Teams „Team Indigo“ und „Team Royal“ strukturieren. Jedes Team begibt sich in wöchentliche, aber zeitlich versetzte Sprints. Während Team Royal von Montag bis Freitag sprintet, sprintet Team Indigo von Mittwoch bis Dienstag.

Die feststehenden Events für jedes Team sind das Planning, Review und Backlog Refinement und am Ende des Sprints die Retrospektive. Jeden zweiten Mittwoch jedoch kommen beide Teams jedoch zu einer großen Retrospektive zusammen. Diese dient, so erklärt mir Carsten, dem Austausch zwischen den Teams, die in einer festen Konstellation arbeiten, ohne Fluktuation zwischen den beiden Teams. Darin werden die Prinzipien der Agilität und der Selbstorganisation mit Kernfragen wie „Was war los? Was wollen wir nächstes Mal anders machen?“ belebt, umgesetzt und verbessert.

Kathrin Wilkes, Scrum Assistenz bei comm-press
Kathrin Wilkes

Ausnahmen bestätigen die Regel

Eine Woche nach dem Treffen, beginnt am 4. Dezember 2017 meine zweiwöchige Scrum-Hospitanz und zwar gleich mit einer Ausnahme von der Regel. Ein personeller Engpass führt dazu, dass genau an diesem Datum nun doch ein Entwickler aus dem Team Royal für einige Zeit ins Team Indigo wechselt.

Bevor ich an meinem ersten „Daily“ teilnehme, sehe ich Carsten über die Schulter, wie er die Etappen des vorangegangenen Tages, die fertiggestellten Tickets als Story Points erfasst. Mit diesen Daten, erklärt er, behält er den Überblick über die Velocity der beiden Teams. Meine Frage, ob er diese Informationen zurück in das Team trägt, verneint er. Anfänglich, erzählt er, habe er es versucht, doch für das Team waren die Informationen über die tägliche Performance in Zahlen, auf ihrem Weg in die Selbstorganisation, weniger aufschluss- und einflussreich, als für den Scrum Master selbst.

Im Daily bin ich überrascht, als ich sehe, dass die Teams kein physisches, sondern ein virtuelles Scrum Board teilen. Da bei comm-press einer der Product Owner in Berlin lebt und einige der Teammitglieder auch remote arbeiten, hat sich für Carsten das digitale Scrum Board des Projektmanagement Tool JIRA als ideal erwiesen. Darüberhinaus teilen die Mitglieder beider Teams einen gemeinsamen Google Kalender, in dem alle ihre Termine verwalten. Die Kommunikation untereinander als auch mit den Kunden findet auf den unterschiedlichen Slack-Kanälen von comm-press statt.

Meinen allerersten Einblick, wie ein selbstorganisiertes Team arbeitet, erhalte ich im Planning des Teams Royal, wo das Team seinen nächsten Wochen-Sprint vorbereitet.

Gemeinsam mit dem PO wird das Backlog sortiert. Neue Tickets werden in den Sprint genommen, noch offenen Tickets geschätzt. Die Tickets, die nach der ersten Diskussionsrunde im neuen Sprint landen, addieren sich zu einer hohen Zahl an Storypoints.

Scrum Master Carsten moderiert den Prozess und fragt das Team: „Was nehmen wir wieder raus?“ Nach einer weiteren Entscheidungsrunde einigt sich das Team auf eine niedrigere Anzahl der zu zu erreichenden Storypoints, wodurch die durchschnittliche Velocity sicher gestellt wird. Der Sprint bekommt eine Nummer, nach Jahr und Kalenderwoche, und einen Namen, und zwar „Mit Lars Bo“, da der Entwickler in dieser Woche zurück ins Team gewechselt ist.

Strecke machen

Nach dem Planning bombardiere ich Carsten mit Fragen: Wie kontrolliert das Team Zeit und Aufwand für die Tickets? Was passiert bei Nicht-Einhaltung, bzw. bei Nicht-Erreichen des Ziels? Was ist die durchschnittliche Anzahl von Story Points für einen Team Sprint? Wie werden sie ermittelt? Und wie wird die Dauer des gesamten Projekts in Sprintwochen geschätzt?

Geduldig beginnt Carsten bei dem vierten Punkt des Manifests für agile Software Entwicklung: Wichtiger als das Befolgen eines Plans, ist das Reagieren auf Veränderung.

Und deshalb wird auch nicht die Dauer eines gesamten Projektes geschätzt, erklärt er mir, weil sich eben von Woche zu Woche die Anforderungen und Bedingungen ändern können und das Team genau darauf dynamisch reagieren können muss.

Ich frage weiter, ob die Schätzungen in T-Shirt-Größen, die ich in der Sprint Planung zum ersten Mal im Einsatz gesehen habe, an Zeit gekoppelt sind. Und bekomme die Antwort, dass Zeit augenblicklich auch Druck erzeugt. Carsten erklärt es mir am Beispiel einer Reise von A nach B. Die Zeit, die man brauche um von A nach B zu kommen, könne man je nach Verkehrsmittel schätzen, doch ob man das Ziel in der Zeit auch erreiche, sei relativ ungewiss. Deshalb sei letztlich die Strecke, die man macht, interessant und aussagekräftig.

Auf eine kurze Formel runtergebrochen entstehen die T-Shirt Sizes aus einer Relation von Komplexität des zu lösenden Problems und dem Aufwand. Um mich mit anderen Methoden für Schätzungen vertraut zu machen, schickt mir Carsten einen Link zu der Methodik "magic estimation".

Estimation Game T-Shirt Größen
Magic estimation

Waste not, want not

Bei comm-press treffen sich die Teams regelmäßig auf den umlaufenden Balkonen mit Blick über die Altonaer Altstadt. Das ist nicht nur der Ort, wo nicht nur die neusten Geschmacksmischungen für eZigaretten ausprobiert und diskutiert werden, sondern das ist auch der Ort, an dem der informelle Austausch zwischen den Teams stattfindet. Und obwohl ich nicht „dampfe“, macht es mir Spaß, bei diesen Gesprächen als Zaungast dabei zu sein. Hier draußen setzte ich mit Carsten das Gespräch über Schätzungen fort und über den Wert eines Produktes, in Relation zum Aufwand. Vom Thema Value gelangt Carsten zum Thema Waste. Der Value, der Mehrwert für den Kunden, ist die essentielle Frage und das wichtigste Kriterium der agilen Softwareentwicklung. Doch die eigentlich interessante Frage, die Carsten umtreibt ist: „Was können wir noch weglassen?“, um „Waste“ abzubauen. Zu „Waste“ gehören für ihn z.B. auch lange Kommunikationswege, die es, um den Mehrwert für den Kunden zu generieren, abzukürzen oder kurzzuschließen gilt. Über den #scrum slack-Kanal versorgt er das Team und mich mit einem Artikel zum Thema Waste.

In dem Buch „Scrum in der Praxis“ lese ich von Impediments, und dass die meisten Scrum Master eine „Impediment Liste“ mit Hindernissen und Problemen führen, die es zu lösen und aus dem Weg zu räumen gilt. Ich frage Carsten, ob er eine Impediment Liste führt. Auf den Scrum Boards der Teams habe ich nichts dergleichen entdecken können. Nein, macht er nicht, erklärt er, da Impediments für Carsten unter die Kategorie Waste fallen.

comm-press Dampfer
comm-press Dampfer

Und was noch passierte

An meinem zweiten Tag bin ich zum ersten Mal bei einem Backlog Refinement des Teams Indigo dabei. Dort werden offene Aufgaben noch mal detailliert durchgesprochen und verbindlich auf einzelne Teammitglieder verteilt.

Ich bin verwundert, dass das Backlog Refinement nach einer Stunde beendet wird, obwohl noch einige Tickets „unbesprochen“ bleiben. Ich will wissen, was mit dem Rest der Tickets im Backlog passiert. Und Carsten erklärt, dass nach einer Stunde Diskussion erfahrungsgemäß, das Pensum für eine Woche erledigt ist.

    Retro mit Team Indigo

    Team Indigo hat seinen Sprint beendet. Nun wird in der Retro verhandelt, was letzte Woche los war und was das Team die nächste Woche anders machen kann.

    Auf einem White Board ist die Fläche in vier Segmente unterteilt:

    • ++ bedeutet: Was war gut?
    • Î: Ich habe einen Vorschlag
    • !: Ich hatte eine Erkenntnis (die ich teilen möchte)
    • ?: Ich habe eine Frage/Mir ist etwas unklar

    Jeder aus dem Team bekommt Post-Its, auf die er seine Themen zu den vier Kategorien aufschreibt. Dann kleben die Teammitglieder nacheinander ihre Post-its ans Board, während sie dabei den anderen ihre Anliegen noch einmal kurz erläutern. Als alle Post-ist geklebt sind, wird per Dot Voting priorisiert.

    Retro Board
    Retro Board

    Carsten beginnt mit den Vorschlägen. Er regt an, nach dem Gesichtspunkt zu diskutieren: Was bringt uns weiter? Was ist am einfachsten umzusetzen?

    Wegen einer Fehleinschätzung einer Ticketgröße wird engagiert der Vorschlag eines der Teammitglieder diskutiert, ein bestimmtes Ticket noch mal zu untergliedern. Sowohl die Fürsprecher dieser Idee, als auch die Skeptiker im Team schlagen brauchbare Lösungswege vor. Plötzlich stellt der Scrum Master die Frage in den Raum: Ist das Ticket ein Mehrwert?

    Oder sind Tickets potentieller ‘Waste’? Dann elaboriert er: Ein Ticket hilft die Arbeit zu organisieren. Aber je kleinteiliger die Entwickler werden und je mehr Zeit sie auf einer Story verbringen, desto weniger Zeit verbringen sie mit der Anwendung, und desto weniger Mehrwert schaffen sie für den Kunden. Die Diskussion wird ergebnisoffen weitergeführt. Und dieser Erfahrungsaustausch führt schließlich zu der vorläufigen Lösung, das Ticket in diesem Fall nicht weiter zu unterteilen.

    Völlig neu für mich als Beobachterin ist die respektvolle, zielgerichtete und immer konstruktiv geführte Diskussion des Teams, in der die Beschäftigung mit der Frage: „Was hat nicht funktioniert?“ gar nicht stattfindet. Nach Carstens Definition würde diese Frage ohnehin in die Kategorie Waste gehören und keinen Mehrwert erzeugen.

    Storypoints für Bugs?

    Der Retro von Team Indigo folgt das Sprint Planning. Hier geht es in die nächste Diskussion:

    Sollen Bugs in Zukunft Story Points bekommen? Die Meinung des Scrum Masters ist da eindeutig: Es gibt keine Belohnung für Defects, sondern nur Punkte für die Umsetzung der Anforderungen.

    Im Anschluss an diesem Sprint Planning folgt noch die große Retro beider Teams, die alle zwei Wochen stattfindet. Die Thema Planbarkeit und Übersicht über Überstunden landen aus aktuellem Anlass auf Platz eins der Diskussionsliste. Carsten moderiert und führt noch mal die Argumente auf, die gegen Überstunden sprechen: Darunter sind an erster Stelle Planbarkeit, an zweiter Stelle das Verschwinden der Basis der Vergleichbarkeit von Sprints und deren Velocity durch das Anhäufen von Überstunden, und an dritter Stelle die Gesundheit des Teams. Und nicht zu vergessen Punkt vier: die Gesetzgebung, die besagt, dass Überstunden nur in Notfällen das unternehmerische Mittel der Wahl sind. Dann ruft er noch mal in Erinnerung, dass schlechte Planung keine Notfälle sind und dass die Geschäftsführung Überstunden nicht anordnen, sondern auch Kenntnis über gemachte Überstunden gesetzt werden muss.

    Die große Retro endet damit, dass sich sowohl der Scrum Master als auch ein weiteres Teammitglied als Vermittler anbieten, wenn Störungen/Anfragen von außen an Teammitglieder herangetragen werden und in Zukunft verhindert wird, dass es nicht mehr zu einer übermäßigen Anhäufung von Überstunden einzelner Teammitglieder kommt.

    Backlog Refinement
    Backlog Refinement

    Mut zur Lücke

    Die erste Woche meiner Hospitanz ist vorbei und zu Beginn der zweiten mache ich meine eigene Retrospektive. Wie war die Woche? Und worüber will ich mehr erfahren?

    Zu der ersten Frage habe ich gemischte Gefühle. Ich kämpfe gegen die eigenen zu hohen Erwartungen an alles wissen und verstehen zu wollen. Natürlich will ich wissen, woran die Teams arbeiten, womit sie arbeiten und wie diese Technologien funktionieren. Um mich nicht damit zu überfordern, erinnere ich mich Mantra-artig daran, dass ich jetzt nicht gleich notwendigerweise wieder programmieren lernen und die Softwareentwicklung im Detail durchdringen muss.

    Die zweite Frage zu beantworten, fällt mir leicht, denn ich beobachte bei Carsten seit dem ersten Tag die ausgeprägte Leidenschaft für das Tracking. Nicht umsonst ist er auch Teil des Teams, das sich bei comm-press mit dem Controlling beschäftigt. Darüber möchte ich mehr erfahren. Zunächst lese ich dazu Ralf Hendels Blogpost über das Controlling bei comm-press.

    Dann will ich von Carsten wissen, in wie fern er die Daten, die er als Scrum Master zum Projektfortschritt sammelt, an das Controlling weitergibt. Als Antwort zeigt Carsten mir die Funktionen, die er zur Aufwandschätzung verwendet. Damit ermittelt er Werte aus der optimistischen, der realen und pessimistischen Schätzung. Diese Controlling-Daten, erklärt er, dienen ihm für als Mittel zur Kommunikation mit den Kunden. Gleichzeit, merkt er an, können diese Daten ganz unterschiedlich interpretiert werden.

    Anschließend zeigt er mir noch die Burn Up und Burn Down Charts, die ihm Auskunft über die Team interne Fortschrittmessung geben. Aber auch hier, sagt er, ist es, wie bei dem täglichen Tracking: Die Teams selbst interessieren sich wenig für diese Zahlen. Vielleicht einmal in ein, zwei Jahren, fügt Carsten hinzu: Als Blick auf den Weg, den man zur Agilität gegangen ist.

    The Last Jedi

    Das Ereignis der Woche ist nicht eine weitere Review oder Retro, sondern die Premiere des neuen Star Wars Films. Carsten und Markus geben sich das nächtliche Double Feature, bzw. die morgendliche (7 Uhr!) Vorstellung. Die Frage, ob die Erwartungen an den Film erfüllt wurden, ist heute der Gesprächsstoff auf dem Balkon.

    Auch wenn ich mich damit als Star Wars Laie oute, interessiert mich, welche Rolle der Scrum Master bei Kundenworkshops hat. Da bei comm-press immer das gesamte Team bei den Workshops mit dem Kunden dabei ist, erklärt Carsten mir, dass seine Rolle bei Workshops im Grunde die selbe sei, wie in den Teams. Er ist dafür verantwortlich dem Kunden die agilen Prozesse zu vermitteln und behält den Kern des Workshops im Auge, d.h. Fragen wie „Was will der Kunde wirklich? Anders ausgedrückt, sieht er seine Aufgabe in der beharrlichen Wiederholung der simplen aber essentiellen Frage: „Ist es das, was ihr wirklich braucht?“.

    Zwei Tage später findet ein Redaktionstreffen für die neue comm-press Seite statt, die auf drupal 8 migrieren soll. Neben Fragen, Was ist schon da? Und Was fehlt für den Launch? werden aber auch Design- und Content-Fragen diskutiert.

    Statt mich den Rest des Tages mit dem Scrum-Framework und -Methoden auseinanderzusetzen, beschäftigt mich die Frage: Was und mit was Entwickeln die Entwickler bei comm-press? Ich frische mein verschüttetes Informatikwissen wieder auf, bzw. lege ich erste Grundlagen für nie dagewesenes Wissen, in dem ich mich zu Themen, wie Frontend/Back-End Entwicklung und Web-Design-Architekturen durchs Netz lese und bei den Entwicklern nachfrage. Entwickler Mathias lässt mich bei der Bestandsaufnahme einer in Drupal7 entwickleten Webseite in über die Schulter schauen und erklärt mir Schritt für Schritt seiner Vorgehensweise.

    Was wäre wenn?

    Am nächsten Morgen im Daily ist Scrum Master Carsten unzufrieden. Zu viele Tickets hängen in der Sparte PO fest. Im Planning mit Team Indigo wird daraufhin diskutiert, wie weit eine Deployment-Strategie einen Mehrwert für den Kunden darstellt.

    In der am Nachmittag stattfinden Retro von Team Indigo stellt er die Fragen mal anders. Statt: „Was ist euch wichtig?“, „Was war letzte Woche los?“, „Und was können wir anders machen?“, will er wissen: „Wo gibt es Waste?“ und „Wie kommen wir schneller zu Mehrwert für den Kunden?

    Nach dem Sammeln der Diskussionspunkte, und dem Priorisieren der Themen, macht Entwickler Lars den Vorschlag, aus zwei Composer Dateien eine zu machen, um einen komplizierten Workflow zu vereinfachen. Damit eröffnet er eine intensive Diskussion über den Mehrwert von Stage und Production. Die Meinungen im Team über das Beibehalten des Systems und der Prozesses oder das Ausprobieren des neuen Weges gehen zunächst stark auseinander.

    Der Scrum Master fokussiert die Diskussion der Entwickler immer wieder mit der Frage, in wie fern komplexe Workflows Waste sind.

    Als nach einer halben Stunde kein einhelliger Konsens in der Diskussion erreicht wird, stellt er die Was-Wäre-Wenn-Frage: Was wäre wenn die composer.json gut funktionieren würde?

    Dieser gedankliche Ansatz eröffnet plötzlich die Möglichkeit alte Gewohnheiten zu überdenken und Carsten nutzt die Chance: „Wollen wir das ausprobieren?“ fragt er das Team. „Wagen wir das?“ Und plötzlich sind alle im Team einverstanden es auszuprobieren.

    Danach wird noch kurz geklärt, welche Rahmenbedingungen notwendig sind, damit der Versuch funktionieren kann. Es wird vereinbart, dass alle alles versuchen, dass nichts schief geht, aber wenn etwas schief geht, erklären sich alle bereit gemeinsam dafür zu sorgen, den Fehler zu beheben. Die Diskussion schließt mit dem eindeutigen Ergebnis: Wir probieren das!

    My first Retro

    Nach der Retro fragt Carsten mich, ob ich mit Einwilligung des Teams an meinem letzten Tag die Retro von Team Royal moderieren will. Ich bin berührt von dem Vertrauen und freue mich sehr drauf es auszuprobieren.

    Zur Vorbereitung lese ich in Sven Röpstorff und Robert Wiechmanns Buch „Scrum in der Praxis“ noch mal das Kapitel über Retros und mögliche Versionen einer Retrospektive.

    Keiner der Vorschläge, von Energie-Impuls-Retrospektive, über Liebes-Hass-Brief-Retrospektive bis Agile-Werte-Perspektive scheint mir für die comm-press Teams geeignet.

    Bei allen Vorschlägen im Buch fehlt mir persönlich der Aha-Moment oder die Möglichkeit einer überraschenden Einsicht. Da ich aber gerne eine Methode ausprobieren möchte, begebe ich mich auf die Desktop-Recherche. Ich entdecke den Retromat der ehemaligen Scrum-Masterin Corinna Baldauf.

    Ich finde viele interessante Methoden, aber keine, die ich morgen zum Einstieg wirklich ausprobieren möchte. Daraufhin bespreche ich mich noch mal mit Carsten. Was hat er ausprobiert? Er erzählt, dass er anfänglich viele Spiele und Methoden ausprobiert hat, die aber immer Zeit raubend, weil verwirrend fürs Team waren. Also: Waste!

    Carsten kommt ins Erzählen. Von seinen Anfängen als Scrum Master, die für ihn und das Team viel Ausprobieren bedeuteten, da man nach der Zertifizierung kaum mehr als Grundlagen als Handwerkszeug hat. Und von dem fortwährenden Prozess, den Agilität letztlich bedeutet.

    Besonders gut gefallen mir hierbei seine Grundgedanken zur agilen Einstellung: Im agilen Team ist jeder verantwortlich – aber nicht für Fehler. Und wie stark die Eigenverantwortung jedes Einzelnen im Team die Haltung prägt: Wir wollen uns verbessern.

    Ich kehre zurück zu meiner Vorbereitung für die Retro. Mir ist aufgefallen, dass sich die Team-Mitglieder außer für den Gang auf den Balkon wenig bewegen und deshalb suche ich zwei, drei fürs Büro geeignete Übungen aus der Gymnastik meiner Kampfkunst aus, die nach dem langen Sitzen vor dem Bildschirm Schultern und Rücken stärken.

    Als der Termin für die Retro näher rückt sehe ich im Kalender, dass zwei der Teammitglieder im ‘home office‘ sind, einer im Urlaub und nur der Scrum Master, ein Entwickler und ich physisch im Raum anwesend sein werden.

    Ich ändere mein Vorhaben. Ich ersetzte das gezeichnete Raumschiff auf dem Retro-Whiteboard durch das neuste Dreadnought-Battleship. Ansonsten halte ich mich an den Ablauf, den ich beim Scrum Master in den letzten Retros beobachtet habe.

    Die gemachten Vorschläge und das Dot Voting setzten den Vorschlag, die Teilnahme an regelmäßigen Events, wie Backlog Refinement und Review, freizustellen, ganz oben auf die Agenda. Schon der erste Redebeitrag zeigt, dass die Stimmung gereizt ist und ich befinde mich mitten in einem seit längerem schwelenden Team-Konflikt. Da Zurückhaltung und Moderation und keine Lösungen von mir gefragt sind, bekomme ich einen hoch interessanten Einblick, wie sich das Team in diesem Konflikt neu organisiert.

    Ich bin dankbar, für die Offenheit und das Vertrauen des Scrum Masters, der Teams und von Ralf Hendel, durch die ich bei comm-press zwei Wochen lang Einblicke in die Scrum-Methode in der agilen Software-Entwicklung aus nächster Nähe sammeln durfte. So habe ich einen lebendigen Eindruck von dem Beruf des Scrum Masters bekommen können, der weit über die Theorie hinausreichte.

    Diese Erfahrung bestärkt mich, den nächsten Schritt zu gehen. Ich melde für das Seminar ‘Certified Scrum Master‘ an.