Fooxes Consulting

Remote Work - How To - Agile Arbeitsabläufe

- Hannes Kleist - 09.02.2021

Remote Work - How To - Agile Arbeitsabläufe

5 Agile Arbeitsabläufe

Ihre Ziele stehen nun fest, die Key Results ebenfalls. Jetzt, wo Sie wissen, in welche Richtung sich Ihre Teams bewegen sollen, dürfen Sie sich Ideen und Projekte einfallen lassen, wie Sie all diese Ziele auch tatsächlich erreichen können.

Falls Sie nun versucht sind, Ihr Team einen Haufen von Aktivitäten brainstormen zu lassen oder noch schlimmer, sich selbst welche einfallen zu lassen, um diese Aktivitäten in allen Einzelheiten zu planen und in einem wunderschönen Gantt-Diagramm festzuhalten: Tun Sie es nicht!

5.1 Das Gantt-Diagramm wird Sie umbringen

Diese Diagramme sind wirklich beeindruckend auf den ersten Blick. Das einzige Problem an ihnen ist, dass sie leider immer, aber auch wirklich immer falsch sind.

Diagramme können unsere komplexe Welt mit unzähligen Wirkungszusammenhängen nicht realistisch abbilden - und schon gar nicht aktuell halten. Das ist in Projekten nicht anders. Es gibt viele Abhängigkeiten, an der einen Stelle gehen unverhofft DInge kaputt, die man wieder reparieren muss, der ursprüngliche Umfang des Projekts ändert sich häufig noch während des Projekts und das Ergebnis weicht meist massiv ab von dem Bild, das man am Anfang davon gezeichnet hat. Das ist auch nicht weiter schlimm - außer man plant Projekte wasserfallartig und kann nicht auf Unvorhersehbarkeiten reagieren - wie Bauprojekte von Opernhäusern oder Flughäfen schmerzlich gezeigt haben.

PriceWaterhouseCooper und der Harvard Business Review haben ein paar Zahlen zu IT-Projekten zusammengestellt:

Sie fragen sich vielleicht: Wie schwer kann denn ein Projekt sein und was soll dabei überhaupt schief gehen?

Absteigend nach Schweregrad der Auswirkungen sind das die Top-Gründe, warum Projekte meist furchtbar schief laufen:

1. Der Scope verändert sich während des Projekts

Sie bekommen einen neuen Chef, einen neuen Mitarbeiter oder noch besser, Sie erhalten Feedback von Ihrem Kunden, das den Scope Ihres Projekts komplett über den Haufen wirft.

2. Abhängigkeiten

Ihr Projekt ist von vielen internen und externen Variablen abhängig, die Auswirkungen auf Ihre Arbeit haben und die Sie weder vorhersagen noch vorausplanen können. Das kann die Agentur sein, die Ihnen falsche Designs liefert, das Marketing, das plötzlich ein Re-branding plant, oder der CEO, dem das ganze “Look and Feel” irgendwie nicht gefällt. Nichts davon ist planbar, einiges davon wird in Ihrem Projekt passieren.

3. Misskommunikation

Erwartungen an ein Projekt sind unglaublich schwer zu verbalisieren. Vielen Stakeholdern ist zu Beginn auch noch gar nicht klar, wie sie sich ein erfolgreiches Ergebnis vorstellen. Nur etwa 5 Prozent der Vorstellungen werden anfangs sichtbar und verbalisiert, die restlichen 95 Prozent schlummern in den Köpfen der Menschen und kommen erst im Laufe des Projekts zum Vorschein, wenn Ihr Team schon einiges an Zeit und Ressourcen investiert hat.

4. HIPPOs

Sie haben es wahrscheinlich selbst schon erlebt: Das ganze Team ist von einem Projektentwurf begeistert, aber dem CEO gefällt die Farbe nicht. Und plötzlich muss man wieder bei Null anfangen. HIPPO (=highest paid person’s opinion), also die Meinung der bestbezahlten Person im Raum, kann Ihren Zeitplan total durcheinander bringen.

Was können Sie also tun, damit Ihr Projekt nicht ebenso wahrscheinlich als Desaster endet? Wir empfehlen, alle Projekte, die länger als zwei Wochen dauern, agil umzusetzen. Dazu nutzen wir die Scrum-Methodik.

5.2 Roles and Responsibilities

In Scrum gibt es zwei wichtige Rollen, die Sie definieren und zuweisen müssen, damit solche Projekte funktionieren:

  1. Den Project bzw. Product Owner
  2. Den Scrum Master

5.3 Project oder Product Owner

Jedes Scrum-Projekt braucht einen Project oder Product Owner. Das ist eine Person, die Entscheidungen treffen kann, wenn Probleme während des Projekts auftreten. Der Project Owner sollte jemand sein, der wirklich Zeit für das Projekt hat und etwa 30 Minuten pro Tag und einen Tag pro Sprint für dieses Projekt arbeiten kann. Diese Rolle sollte also kein Top-Manager mit ohnehin vollem Terminkalender übernehmen.

Der ideale Project Owner ist stark darin, seine Stakeholder permanent auf dem Laufenden zu halten und ihre Erwartungen proaktiv und erfolgreich zu managen.

Ein Project Owner muss:

1. Anforderungen formulieren

Anforderungen an ein Feature aus einer menschlichen Nutzersicht beschreiben (die sogenannten Stories) und Kriterien festlegen, wann dieses Feature als erfolgreich abgeschlossen gilt.

2. Anforderungen priorisieren

alle Anforderungen nicht nur priorisieren, sondern sie in eine Reihenfolge bringen, in der sie das Team abarbeiten wird.

3. An Meetings Teilnehmen

an Dailies (15 Minuten Call pro Tag), Plannings (1h Call pro Woche), Demos (30 Minuten pro Woche) und Retros (30 Minuten pro Woche) teilnehmen (insgesamt 3 Stunden Zeitaufwand pro Woche).

4. Features abnehmen

in der Demo widersprechen, wenn ein Feature nicht so umgesetzt ist, wie es anfangs spezifiziert wurde.

Eine gute Story besteht aus folgenden Punkten:

  1. Wer ist die Person, für die wir das Feature bauen?
  2. Was muss sie damit tun können?
  3. Warum will die Person das tun? Dieser Punkt ist wichtig, denn er hilft dem Team, kluge Entscheidungen in der Umsetzung zu treffen. Das Team findet vielleicht Abkürzungen oder andere Wege, bestimmte Dinge zu tun, wenn wir diese Art von Hintergrundwissen haben.
  4. Die Abnahmekriterien: Wann sehen wir diese Anforderung als erfüllt an?

Übrigens: Sie sollten sich wirklich darauf konzentrieren, nur das Nötigste aufzuschreiben und sich lieber auf ein gemeinsames Verständnis der Dinge verlassen. Lange Anforderungsdokumentationen werden selten gelesen, sind meist schlecht geschrieben und werden nie aktualisiert.

Lassen Sie mich Ihnen zwei Beispiele für eine User Story geben. Die erste stammt aus einem Software-Projekt:

Story 1

“Als Nutzer möchte ich in der Lage sein, alle meine E-Mails in einer Liste anzuschauen, damit ich sehen kann, welche wichtiger sind.”

Abnahmekriterien

  1. E-Mails werden vom Server geladen.
  2. E-Mails werden alle 15 Minuten vom Server aktualisiert, oder wenn man sie abruft.
  3. E-Mails werden in einer Liste absteigend nach Datum mit Absender, Betreff und einer 2-zeiligen Textvorschau angezeigt.
  4. Ein Tabulator auf eine E-Mail öffnet eine Detailansicht dieser E-Mail.

Das zweite Beispiel stammt aus einer Marketingkampagne, die wir gestartet haben:

Story

“Als Marketing-Manager möchte ich, dass alle Besucher unserer Website Retargeting-Anzeigen in Social Media sehen, damit wir die Aufmerksamkeit der Menschen erhöhen.”

Abnahmekriterien

  1. Targeting-Pixel für Facebook sind auf der Website installiert und melden Daten.
  2. Targeting-Pixel für LinkedIn sind auf der Website installiert und melden Daten.
  3. Es wurde eine Anzeigenkampagne auf Facebook erstellt, die Website-Nutzer 30 Tage lang nach dem Besuch der Website targeted und Daten meldet.
  4. Es wurde eine Anzeigenkampagne auf LinkedIn erstellt, die Website-Nutzer 30 Tage nach dem Besuch der Website targeted und Daten meldet.

5.4 Scrum Master

Ein Scrum-Master ist kein klassischer Projektmanager, der sein Team mit einer Peitsche antreibt, sondern jemand, der das Team befähigt und ihm hilft.

Warum sollten Sie das wollen?

Ein Team mit einem Projektleiter, der oft die Peitsche schwingt, wird schnell in eine passive Geisteshaltung verfallen. Diese Teams arbeiten irgendwann nur noch dann, wenn man sie antreibt und zeigen kaum noch eigene Initiative oder Verantwortung.

Was Sie wollen, ist genau das Gegenteil: Ein Team, das sich persönlich verantwortlich für den Projekterfolg fühlt und alles daran setzt, dieses Ziel gemeinsam zu erreichen. Letztendlich wollen Sie, dass Ihr Team gemeinsam Zeitpläne aufstellt, seinen Arbeitsaufwand einschätzt und die richtigen Prioritäten setzt und nicht, dass ein Projektmanager alles plant und sich allein mit den AUftraggebern abstimmt.

5.5 Fokus auf “Shipping”

Sie kennen wahrscheinlich das Sprichwort: “Das Bessere ist der Feind des Guten”. Die meisten Projekte wie z.B. der Bau von Flughäfen oder Opernhäusern ;-) scheitern, weil deren Komplexität bei der Planung nicht absehbar ist und Dinge eben auch mal schief gehen.

Unter Risikokapitalgebern ist bekannt: Jedes neue Produkt oder Unternehmen wird zu 90 Prozent in den ersten drei Jahren scheitern. Nur 10 Prozent werden die ersten drei Jahre überleben, und nur 10 Prozent von diesen, also ein Prozent, überleben mit ihrer ursprünglichen Geschäftsidee.

Bei dieser extrem hohen Wahrscheinlichkeit zu scheitern fragen Sie sich zurecht: Warum sollen Sie 100 Prozent Ihrer Ressourcen in ein Projekt stecken, das eine einprozentige Chance auf Erfolg hat?

Es gibt eine einfache Alternative: Führen Sie Ihre Projekte nach der Lean-Startup-Methode: ship, measure, iterate.

Bauen Sie also anfangs einen Prototyp Ihres Projekts, für den Sie so wenig Ressourcen wie möglich einsetzen und finden Sie so früh wie möglich heraus, ob Ihre Idee Erfolg haben kann oder zu den 90 Prozent gehört, die am Ende scheitern werden.Wenn Sie also ohnehin bereits mit der Scrum-Methodik arbeiten, haben Sie kein Problem. Denn mit Scrum liefert Ihr Team alle zwei Wochen, also nach jedem Sprint, ein funktionierendes Produkt ab.

Statt also 1 Million Euro zu investieren in ein von vorn bis hinten durchgeplantes Projekt, das lediglich eine Erfolgsquote von 1 Prozent hat, könnten Sie auch einfach zehn verschiedene Ideen mit je 50.000€ Startbudget testen und dem erfolgversprechendsten Kandidaten ein Budget von 500.000€ zur Verfügung stellen. Die Mathematik dahinter ist ein bisschen knifflig, aber Sie können mir vertrauen, wenn ich Ihnen sage, dass dieses Modell eine 79-prozentige Chance hat, einen Gewinner hervorzubringen.

“If you’re not embarrassed when you ship your first version, you waited too long.”

Matt Mullenweg, Co-Founder of WordPress & Automattic

5.6 Der wöchentliche Scrum-Zyklus

Mit Scrum führen Sie Ihre Projekte in 2-wöchigen Zyklen, den sogenannten Sprints, durch.

Grooming

Jede Woche kommen Sie zum gemeinsamen Grooming zusammen, um neue Anforderungen und Ideen zu besprechen, die Sie in Ihrem Projekt angehen sollten. Sie erstellen “Stories”, die festhalten, was konkret getan werden muss, und sammeln diese in Ihrem Projekt-”Backlog”, was im Grunde nichts anderes ist als eine glorifizierte To-Do-Liste.

Planning

Zu Beginn eines Sprints haben Sie ein gemeinsames Planning-Meeting mit dem gesamten Team inklusive aller Stakeholder. Sie gehen die Liste der offenen Fragen nach Wichtigkeit aus der Sicht des Project Owners durch, denn dieser entscheidet über die Prioritäten. Der Project Owner erklärt, worum es bei der Aufgabe geht, das ganze Team stellt Fragen dazu und schätzt anschließend die Komplexität der Aufgabe ein. Dann kommt die Aufgabe auf den Backlog des anstehenden Sprints. Sobald das Team sagt, “Das ist alles, was wir im kommenden Sprint erledigen können”, endet das Meeting und das Team legt los.

Daily

Jeder Tag beginnt mit einem kurzen 10-minütigen Call mit dem gesamten Team inklusive Kunden, bei dem jeder drei Fragen beantwortet:

  1. Was habe ich gestern erledigt?
  2. Was werde ich heute in Angriff nehmen?
  3. Was blockiert mich gerade?

Auf diese Weise weiß jeder, wie das Projekt aktuell läuft, ohne zeitraubende E-Mails, Check-ins oder Statusberichte. Sie werden frühzeitig Blocker identifizieren und das Team kann Rückfragen an den Kunden stellen, um eventuelle Missverständnisse auszuräumen, bevor Arbeit in eine Aufgabe geflossen ist. Das bedeutet weniger E-Mails für Sie als Führungskraft und mehr produktive Arbeitszeit für Ihr Team.

Demo

Sobald ein Feature fertig ist, zeigt das Team es dem Product Owner in einem Video-Call, um sicherzustellen, dass es die Anforderungen richtig umgesetzt hat.

Am letzten Tag des Sprints geht das Team gemeinsam mit dem Project Owner durch alle umgesetzten Features. Ideal ist, bei diesen Calls so viele Stakeholder wie möglich mit einzubeziehen, damit diese ein Gefühl für den Fortschritt und ein regelmäßiges Update zum “Look and Feel” ihres Produkts bekommen.

Das Team sollte zu diesen Demos immer eine funktionierende Version des Produkts (Website, Marketingplan o.ä.) bereitstellen, das es mit den Stakeholdern teilt, eine Testkampagne durchführen oder sogar erste Nutzer einbeziehen, um Feedback zu erhalten und die Richtung so früh wie möglich zu justieren.

Retro

Im Retro zeigt Scrum seine wahre Stärke. Alle zwei Wochen rekapituliert das Team gemeinsam, was im vergangenen Sprint gut gelaufen ist, was es hätte besser machen können und was es nächstes Mal anders machen möchte.

Wenn wir Retros durchführen, sind wir extrem ehrlich und nehmen kein Blatt vor den Mund. Genau deshalb ist es entscheidend, dass Retros nicht in Schuldzuweisungen enden, sondern konstruktiv und an der Sache orientiert diskutiert wird. Damit können Sie kontinuierlich Ihren Prozess verbessern und eine positive Unternehmenskultur aufbauen, die Ihre Mitarbeiter wertschätzt und nicht abwertet.

Da wir den unseren Output als Softwareentwickler ziemlich genau messen können, haben wir analysiert, wie sehr wir uns tatsächlich verbessern mit jedem Sprint: Normalerweise sehen wir pro Sprint eine Verbesserungen von 10 Prozent. Das bedeutet eine Verbesserung um 250 Prozent in einem Jahr oder x13.000 über 10 Jahre.

Diese ständige Verbesserung ist die wahre Superkraft von Scrum - und uns ;-).

5.7 Vorteile

Diese ganze Scrum-Methodik mag für Sie vielleicht etwas seltsam klingen. Doch in 13 Jahren Digitalbranche haben wir gelernt, welche Elemente es zwingend in Projekten braucht, um erfolgreich Software zu entwickeln. Diese Key Learnings möchten wir gern mit Ihnen teilen, denn sie entscheiden über Erfolg oder Misserfolg Ihres nächsten Projekts. Ist nur eines der folgenden Element nicht gegeben, wird es kaum möglich sein für Sie, Ihr Projekt erfolgreich abzuliefern.

1. Tiefgreifendes Vertrauen

Wenn Sie als Auftraggeber oder Stakeholder Ihr Projektteam als Dienstleister betrachten, an die Sie etwas outsourcen können, werden Sie gemeinsam scheitern. Wenn Ihr Team Sie eine Melkkuh betrachtet, die von nichts eine Ahnung hat, werden Sie ebenfalls scheitern.

Alle komplexen Aufgaben sind nur mit gemeinschaftlicher Anstrengung zu meistern. Deshalb möchten Sie darauf vertrauen, dass Ihr Team wirklich hart für Sie arbeitet, Ihnen gute Ratschläge gibt und vor allem jederzeit ehrlich und offen mit Ihnen kommuniziert.

Im Gegenzug wird Ihr Team darauf vertrauen, dass Sie da sind, wenn es Sie braucht, dass Sie offen sind für ihre Gedanken und Fragen und dass Sie ihnen erzählen, wenn etwas bei Ihnen passiert, das relevant für Ihr Projekt sein könnte.

In unseren eigenen Projekten sind wir alle ein Team und unterscheiden nicht zwischen Kunden, unseren Entwicklern und den externen Anbietern, mit denen wir zusammenarbeiten. Wir wollen großartige Software mit Impact abliefern, auf die wir kollektiv stolz sein können. Das ist auch ein Grund, warum wir nur zwei von zehn Kundenprojekten annehmen. Sowohl das Kundenteam als auch das Projekt müssen unsere hohen Anforderungen erfüllen, damit wir gemeinsam etwas Großartiges aufbauen können. Das ist selten in unserer Dienstleistungsbranche. Aber es hat sich oft bewährt für uns und wir meinen das tatsächlich ernst.

2. Konzentriertes Arbeiten

Sie würden nicht glauben, wie viel Zeit die meisten Menschen damit verbringen, nicht den Job zu machen, für den sie eigentlich angestellt wurden. In einigen Softwarefirmen bringen es Entwickler nur auf zwei bis vier Stunden echte Programmierzeit pro Tag. Und selbst diese Zeit wird alle 5 Minuten von einer Message, einer E-Mail oder einem Anruf unterbrochen.

Wir gehen davon aus, dass Sie - wie auch wir - die smartesten Menschen in Ihrer Branche eingestellt haben. Lassen Sie Ihre Leute also echten Wert schaffen für Ihr Unternehmen und verteidigen Sie ihre konzentrierte, ungestörte Arbeitszeit mit allen Mitteln.

3. Kontinuierliche Verbesserung

Mit den meisten Projekten betreten Sie komplettes Neuland. Zu Beginn haben Sie vielleicht eine vage Vision von dem, was Sie erreichen wollen. Nichts anderes passiert in der Softwareentwicklung: etwas Vages (Vision) zu etwas Konkretem zu machen (Code).

Diese vage Vision sind lediglich ein Prozent von dem, was Sie im Laufe des Projekts lernen werden. Das ist alles, was Sie im Projekt tun: gemeinsam dazulernen. In jedem Projekt werden Sie auf Probleme stoßen und kreative Lösungen finden müssen. In diesem Prozess entsteht Reibung, und da wir Menschen alle mit tiefen Vorurteilen (Biases) und anerzogenen Denkmustern behaftet sind, werden wir uns häufig gegenseitig missverstehen. Das ist normal.

Wichtig ist, mit dem gesamten Team offen und ehrlich zu sprechen darüber, was gut läuft und was Sie gemeinsam verbessern müssen. Es gibt keine Schuldzuweisungen, keine Fehler werden vertuscht, keine Zweifel bleiben unausgesprochen. Alles kommt auf den Tisch - und zwar konstruktiv und 100% ehrlich. Sie werden überrascht sein, wie anders sich so ein Projekt anfühlt und wie viel Freude Sie gemeinsam daran haben zu sehen, dass Ihr team jede Woche zehn Prozent besser wird.

5.8 Tools

Sie können für Ihr Scrum-Projekt jedes Tool nutzen, mit dem Sie Ihren To-Dos einen flexiblen Status zuzuweisen können. Wir verwenden dafür gerne Trello, für komplexe Software-Projekte nutzen wir Trellos großen Bruder Jira.

Jedes To-Do wird auf einer Trello-Karte festgehalten, auf der die Story und die Abnahmekriterien stehen. Trello hat übersichtliche Spalten, die wir für den Status des To-Dos verwenden: Grooming, Backlog, Sprint-Backlog, Doing, Review, Done, Abandoned.

Zu jeder Karte fügen wir die Personen hinzu, die daran arbeiten. So können Mitarbeiter nach ihren Karten filtern. Innerhalb der KArten verwenden wir Checklisten für konkrete To-Dos, und auch hier weisen wir wieder Verantwortlichkeiten zu.

Dieses Zuweisen und Hinzufügen von Nutzern erzeugt E-Mail-Benachrichtigungen bei ihnen, sodass die Leute buchstäblich den ganzen Tag in Ihrem E-Mail-Posteingang bleiben können, um an ihren Aufgaben zu arbeiten.

Außerdem unterstützt Trello durch seine Kommentar- und Anhang-Funktion, Themen asynchron zu diskutieren. Zur Erinnerung: Asynchrones Arbeiten bedeutet weniger Meetings, mehr Flexibilität bei der Wahl des Arbeitsortes und eine entspannte Arbeitsweise.

Übrigens: Wir haben auch unsere Dailys asynchron gemacht, indem wir einen Slack-Channel dafür nutzen. Das würde ich aber nur bei Projekten empfehlen, bei denen das Team schon sehr eingespielt ist und der Ablauf reibungslos funktioniert. Bei neuen Teams, Themen und Dingen, die für Spannung sorgen könnten, braucht man diese 10 Minuten echte menschliche Interaktion miteinander, um eine starke Bindung im Team aufzubauen und Probleme schnell zu lösen.

“More than remote, we value async, which means work at any time you prefer. The whole process is constructed around it. Async/remote is part of our DNA. I think it’s now part of our lifestyle too. There’s a lot of freedom with such an approach.”

Andrzej Krzywda, Founder of Arkency

Zusammenfassung

Da haben Sie es also. Wenn Sie Ihre Arbeitsabläufe nach einer agilen Methodik durchführen, lädt dies Ihre Teams super auf und reduziert gleichzeitig den Stress. Anstelle von…

</table> In der nächsten Lektion schauen wir uns an, wie Sie die Kommunikation in Ihren Teams außerhalb der Scrum-Meetings gestalten können.

Waterfall

Scrum

Lange Planung bei Projektstart Kurze Vorprojektplanung, anschließend kurze wöchentliche Planungsrunden
Alles auf einmal erstellen Die kleinstmögliche Version des Produkts bauen, Feedback einholen und iterieren
200 “Must-Have”-Features

(90 Prozent davon werden nie genutzt) </td>

Das Produkt ist fertig, wenn Ihre Nutzer Ihnen sagen, dass es gut genug ist.

Das kann bereits nach zehn Features sein. </td> </tr>

Kann nicht gestoppt werden, bis es beendet ist Kann jederzeit angehalten, abgebrochen werden oder auch live gehen
Änderungen sind schwierig und teuer Änderungen sind einfach umzusetze n und kostenlos
Sie wissen erst nach dem Projekt, was Sie falsch gemacht haben. Regelmäßige Retros, um jede Woche besser zu werden
Ellenlange schriftliche Statusreports Tägliche 10-minütige Status-Calls
### Buchempfehlungen [Scrum](https://www.amazon.de/-/en/Jeff-Sutherland/dp/1847941095/ref=sr_1_1?dchild=1&keywords=Scrum+-+A+revolutionary+approach+to+building+teams%2C+beating+deadlines+and+boosting+productivity&qid=1606979955&sr=8-1) Jeff Sutherland
### Die führenden Remote-Unternehmen schreiben dazu: Zapier zum Thema “Agile Prozesse” Guides Zapier, Automatisierungs-Software, USA, 362 Mitarbeiter, gegründet 2011 [https://zapier.com/learn/project-management/project-management-systems/](https://zapier.com/learn/project-management/project-management-systems/) Auth0 zum Thema “Agile Prozesse” Blog Auth0, Software & Network, USA, 735 Mitarbeiter, gegründet 2013 [https://auth0.com/blog/why-staying-agile-is-key-to-startup-success/](https://auth0.com/blog/why-staying-agile-is-key-to-startup-success/) Doist zum Thema “Agile Prozesse” Blog Doist, Todo-Software , Portugal, 83 Mitarbeiter, gegründet 2007 [https://blog.doist.com/agile-development-remote-team/](https://blog.doist.com/agile-development-remote-team/) Toggl zum Thema “Agile Prozesse” Blog Toggl, Zeiterfassungs-Software, Estland, 85 Mitarbeiter, gegründet 2007 [https://toggl.com/blog/beginners-guide-to-agile-project-management](https://toggl.com/blog/beginners-guide-to-agile-project-management) Stack Overflow zum Thema “Agile Prozesse” Podcast Stack Overflow, Q&A Plattform, USA, 300 Mitarbeiter, gegründet 2008 [https://the-stack-overflow-podcast.simplecast.com/episodes/is-scrum-making-you-a-worse-engineer](https://the-stack-overflow-podcast.simplecast.com/episodes/is-scrum-making-you-a-worse-engineer)

Newsletter

Erhalte Artikel und Buch-Reviews in Deine Inbox jede Woche
Hannes Kleist
Signature Hannes Kleist
Geschäftsführer