So nutzen Sie Scrum mit mehr Produktivität und weniger Aufwand

Der Umgang mit Softwareentwicklung ist nicht die sauberste und einfachste Sache. Es umfasst eine Vielzahl technischer und nichttechnischer Probleme. Der technische Aspekt ist sicherlich viel komplexer und erfordert harte Fähigkeiten, kann aber gleichzeitig mit den richtigen Taktiken und Werkzeugen irgendwie bewältigt werden. Die nichttechnische Welt hingegen verfügt über viel mehr Freiheitsgrade. Es weist die gleiche Variabilität und Unvorhersehbarkeit auf wie die menschliche Natur.

Wie bei jedem anderen Produktherstellungsprozess wurden seit den Anfangsjahren des Softwareentwicklungsabenteuers eine Reihe bewährter Verfahren eingeführt und getestet. Bei den agilen Methoden handelt es sich um eine Reihe verschiedener Methoden, um vor allem mit der extremen Variabilität der Anforderungen und auch mit der mangelnden Fokussierung auf die wichtigsten Ziele zur Lieferung des Endprodukts umzugehen.

Manchmal gehen solche Methoden über ihren ursprünglichen Zweck hinaus und das Endergebnis ist alles andere als ideal. Scrum ist eine dieser Methoden. Es wird eher als Framework beschrieben. Es basiert auf einem grundlegenden Satz von Prinzipien, Regeln, Ereignissen und Rollen. In diesem Artikel diskutieren wir, wie dieser Rahmen mit Urteilsvermögen und Flexibilität genutzt werden kann und einige strenge Interpretationen vermieden wird, die alles andere als ideal sein könnten.

Sehr kurze Einführung in Scrum

Die agilen Methoden basieren auf den folgenden allgemeinen Prinzipien, die im sogenannten „Agile Manifest“ definiert sind:

• „Individuen und Interaktionen über Prozesse und Tools“
• „Funktionierende Software statt umfassender Dokumentation“
• „Kundenzusammenarbeit über Vertragsverhandlungen“
• „Auf Veränderungen reagieren, indem man einem Plan folgt“

(Quelle: Agile Manifesto )

Laut dem Agilen Manifest sind in den obigen Aussagen zwar die Punkte auf der rechten Seite wichtig, die auf der linken jedoch wichtiger.

Aus Sicht des Entwicklungsprozesses implizieren alle agilen Methoden einen iterativen und inkrementellen Prozess anstelle des klassischen Wasserfallmodells: Die gesamte Entwicklung besteht aus einer Reihe inkrementeller Schritte, und jeder Schritt besteht aus denselben Phasen, die ein Ganzes charakterisieren Wasserfallprojekt: eine Sammlung von Anforderungen, Analyse, Design und Codierung. Das heißt, jeder Schritt stellt einen Schritt in der gesamten Entwicklung dar und kann als eigenständiges Gesamtprojekt betrachtet werden.

Die Scrum- Methodik kann als besondere Abweichung der oben genannten Prinzipien angesehen werden. Scrum ist ein Rahmenwerk, innerhalb dessen ein Team seine eigenen Prozesse nutzen kann, um ein bestimmtes Softwareprodukt zu entwickeln. Es zeichnet sich im Wesentlichen durch Rollen , Ereignisse und Artefakte aus.

Die Rollen sind:

• Das Team : Es kann Analysten, Entwickler, Tester und im Allgemeinen alle am Projekt beteiligten Fachleute umfassen. Es soll im Rahmen der Scrum-Planungssitzungen selbstorganisiert funktionieren.

• Der Scrum Master : Er/sie koordiniert alle Scrum-Prozesse, organisiert die Meetings und so weiter.

• Der Product Owner : Er/sie trägt die Verantwortung für das Produkt. Er/sie verwaltet das sogenannte Product Backlog , das alle erforderlichen Features in übersichtlicher Form enthält. Er/sie kann sie mit dem Team besprechen und von diesem Hilfe erhalten, ist aber allein verantwortlich.

  
  

Veranstaltungen sind:

• Der Sprint : stellt einen einzelnen Schritt in der iterativen Entwicklung dar. Die Dauer beträgt in der Regel zwei Wochen bis einen Monat.

• Sprint-Planung : Es handelt sich um ein Meeting mit einer maximalen Dauer von 4 Stunden für Sprints von zwei Wochen und maximal acht Stunden für Sprints von einem Monat. Es wird vom Scrum Master organisiert und geplant und umfasst das Team und den Product Owner. In diesem Meeting werden einige Funktionen des Product Backlogs ausgewählt, bewertet und besprochen, um sie im aktuellen Sprint zu entwickeln. Funktionen werden basierend auf ihrer Priorität ausgewählt.

• Tägliche Scrum-Meetings : Dabei handelt es sich um tägliche Meetings, die nicht länger als fünfzehn Minuten dauern. Sie werden vom Scrum Master geplant. In diesen Besprechungen beschreibt jedes Teammitglied, was es zur Umsetzung der aktuellen Aufgaben getan hat, welche Probleme aufgetreten sind und wie mögliche Schwierigkeiten überwunden werden können. Der Scrum Master kümmert sich um die Terminplanung und Koordination dieser Meetings und deren korrekte Durchführung.

• Das Sprint Review : Es ist ein Treffen am Ende des aktuellen Frühlings. Es dauert zwei Stunden für zweiwöchige Sprints und vier für einmonatige Sprints. Es wird vom Scrum Master organisiert und die Teilnehmer sind das Scrum-Team, der Scrum Master, der Product Owner und alle erforderlichen Stakeholder gemäß der Entscheidung des Product Owners. Der aktuelle Zuwachs wird besprochen. Es wird erläutert, was gut und was schief gelaufen ist, und am Ende wird das Product Backlog bei Bedarf aktualisiert.

• Die Sprint-Retrospektive : Es handelt sich um ein einstündiges Treffen für zweiwöchige Sprints und zwei Stunden für einmonatige Sprints. Es findet unmittelbar nach der Sprint-Überprüfung und vor der nächsten Sprint-Planung statt. Während dieses Treffens werden auf der Grundlage der Erfahrungen der letzten Iteration alle Maßnahmen zur Verbesserung und Steigerung der Qualität des Endprodukts besprochen und für den nächsten Sprint geplant.

  
  

Artefakte sind:

• Product Backlog : Es handelt sich um ein sich entwickelndes Dokument, das alle Anforderungen des Produkts enthält. Jedes Element wird als User Story bezeichnet und verfügt über Attribute wie Beschreibung, Reihenfolge, Schätzung und Wert. Die Elemente mit der höheren Ordnung sind klarer und detaillierter.
• Sprint Backlog : Es enthält die für den nächsten Sprint ausgewählten Product Backlog-Elemente, kombiniert mit der notwendigen Planung.
• User Story : Wie oben erwähnt, ist eine User Story ein Element des Product Backlogs. Eine User Story folgt einer allgemeinen Textstruktur: „ Als <einiger Benutzer> möchte ich <eine Aufgabe erledigen>, damit <ich ein Ziel erreichen kann>. Sie sollte außerdem eine Reihe von Akzeptanzkriterien haben, jedes mit das folgende Schema: Gegeben <irgendeine Vorbedingung>, wenn <der Benutzer eine Aufgabe ausführt> dann <irgendeine Systemstatusänderung auftritt>.
• Burn-Down-Diagramm : Hierbei handelt es sich um ein Diagramm, in dem die horizontale Achse die Zeit und die vertikale Achse den für jeden Zeitschritt noch zu erledigenden Arbeitsaufwand darstellt. Der Arbeitsaufwand lässt sich anhand sogenannter Story Points messen. Der Story Point ist eine Messeinheit der Arbeit, die alle Variablen berücksichtigt, die die Entwicklungsarbeit beeinflussen können, wie z. B. Fähigkeiten, Komplexität, Werkzeuge usw.
• Inkrement : Dies ist das bisherige Gesamtinkrement, dh die Summe der bisher abgeschlossenen Product Backlog- Elemente zuzüglich aller anderen Elemente, die in den vergangenen Iterationen bereits abgeschlossen wurden.

Verwechseln Sie Scrum nicht mit irgendeiner Form von Doktrin

Sie können die oben aufgeführten Elemente als Grundlage betrachten, auf der eine Gruppe von Fachleuten arbeiten kann. Sie können als nützliches Werkzeug angesehen werden, aber was in einem Projekt wirklich für Zusammenhalt, Kommunikation und Effektivität sorgt, sind die Menschen selbst. Tatsache ist, dass ein Projekt trotz strikter Befolgung all dieser Vorschriften und des Engagements des Scrum Masters ins Chaos abdriften und kläglich scheitern kann.

Das liegt daran, dass Menschen Regeln, Methoden und Rahmenbedingungen oft mit einer Art göttlichen Motor verwechseln, der die Menschen auf den richtigen Weg bringen soll. Es ist ein häufiger psychologischer Fehler. Eine sehr wichtige Überlegung ist, dass die Realität sich von Theorien unterscheidet und es sich um ein sehr komplexes und wildes Tier handelt. Wenn Sie glauben, dass Sie es mit einer Liste von Regeln und Mustern bändigen können, sind Sie zum Scheitern verurteilt.

Der eigentliche Zweck von Scrum besteht darin, die Menge an „Hintergrundgeräuschen“ im Entwicklungsprozess zu minimieren und die Konzentration auf die wichtigsten Dinge zu verbessern. Wenn es mit der richtigen Flexibilität und Bescheidenheit eingesetzt wird, kann es dabei wirkungsvoll sein.

Im folgenden Abschnitt beschreibe ich einen realen Anwendungsfall, bei dem ich eine Reise in die Welt von Scrum unternommen habe. Es war eine Reise unerfahrener Menschen, darunter auch ich, die bereit waren, die agilen Prinzipien zum ersten Mal konsequent zu übernehmen. Viele Projekte, an denen ich zuvor gearbeitet habe, wurden iterativ erstellt, jedoch ohne die gesamte Zeremonie eines echten agilen Frameworks.

Ein echter Anwendungsfall

Wir sprechen hier von einem realen Anwendungsfall, bei dem eine alles andere als strikte Übernahme des Scrum-Frameworks vorgenommen wurde. Bei dem Projekt ging es um ein Softwaresystem, das darauf abzielte, alle in einem Labor für anatomische Pathologie anfallenden Aktivitäten zu verfolgen, von der Entnahme der Gewebeproben über deren Behandlung in verschiedenen Schritten bis hin zur endgültigen Verteilung der Gewebeschnitte. Das System sollte in bestimmten Phasen auch über spezielle Softwaretreiber in externe Automatisierungsmaschinen integriert werden.

An diesem Projekt war ich als Software-Architekt beteiligt. Ich musste mit dem Projektmanager zusammenarbeiten, um die Hauptprobleme zu skizzieren und einen grundlegenden Architekturentwurf zu entwerfen. Wenn Sie die agilen Prinzipien bis zum Äußersten befolgen, ist es nicht das Beste, sich vorher Gedanken über die Architektur zu machen. Sogar der architektonische Entwurf wird in einem iterativen Szenario betrachtet. In den meisten Situationen benötigen Sie jedoch noch eine Ausgangsbasis, die Sie mit allen beteiligten Stakeholdern besprechen müssen.

Ich bin an diese vorläufige Architekturstudie herangegangen und habe versucht, eine klare Trennung der Kontexte zu erreichen, in einem strukturierten Ansatz, der auf Ansichten , Standpunkten und Perspektiven basiert. Die Verfolgung eines solchen Ansatzes ist wichtig, um eine klare Trennung der Probleme zu erreichen und die Diskussion auf die jeweilige Art von Interessengruppen zuzuschneiden.

Ein Teil der besprochenen Architektur war tatsächlich die Entwicklungsphase und ihre Organisation. Das Unternehmen selbst hatte noch keine agilen Methoden eingeführt. Dennoch wollten wir in Absprache mit dem Manager und den anderen Beteiligten diese Lücke schließen und haben uns dafür entschieden, uns vom Scrum-Methodik-Framework inspirieren zu lassen.

Wir waren überhaupt nicht in Scrum geschult, waren uns aber alle der Grundlagen bewusst. Die wichtigsten methodischen und technischen Richtlinien, die wir für das Projekt im Sinn hatten, waren:

• Eine Reihe grundlegender Praktiken, die wir befolgen müssen, um uns in einem iterativen Ansatz auf das Teil- und Gesamtziel zu konzentrieren (Scrum in unserer endgültigen Entscheidung).
• Verfolgung von Aktivitäten/Quellen durch Automatisierungstools.
• Verhaltensgesteuerter Entwicklungsansatz gepaart mit Unit- und Integrationstests .

Scrum-Praktiken

Motiviert durch die Notwendigkeit, einen soliden methodischen Rahmen durchzusetzen, aber gezwungen durch unseren Mangel an fundierten Kenntnissen, haben wir uns dafür entschieden, einige der Hauptregeln von Scrum zu übernehmen, ohne zu weit zu gehen. Zunächst einmal war uns ein iterativer Ansatz sehr wichtig. Scrum deckt dies durch die sogenannten Sprints ab, die wir als iterative Arbeitseinheiten betrachten können. Jeder Sprint soll eine ausgewählte Anzahl von Features aus dem Backlog abdecken und hat eine bestimmte Zeitdauer.

Für die Dauer unserer Sprints haben wir zwei Wochen gewählt. Bevor wir mit dem eigentlichen Geschäft beginnen, haben wir einen herkömmlichen Sprint Nummer Null von einer Woche aufgesetzt, um Vorarbeiten und organisatorische Aufgaben zu erledigen. In diesem vorläufigen Sprint haben wir auch die erste Version des Backlogs geschrieben, in der alle Funktionen nach Priorität aufgelistet sind. Wir haben keine bestimmte Methode zur Bewertung des Aufgabenaufwands gewählt, sondern lediglich eine normale Diskussion zwischen Teammitgliedern.

Zu Beginn jedes Sprints würden wir, wie bei den Scrum-Regeln, die bereits geleistete Arbeit besprechen, alle aufgetretenen Probleme bewerten und die Funktionen auswählen, die im kommenden Sprint implementiert werden sollen.

Der Projektmanager spielte die Rolle des Product Owners, unterstützt von einem Fachexperten. Dies machte in der konkreten Situation Sinn, da kein echter Produktmanager beteiligt war und der Projektmanager selbst über umfassende Kenntnisse der Kundenanforderungen verfügte. Was den Scrum Master betrifft, habe ich das eine Zeit lang gemacht und die Rolle dann an einen anderen Kollegen übergeben, auch wenn wir beide nicht vollständig darin geschult waren.

Unser Team war heterogen mit Leuten, die aus verschiedenen Städten arbeiteten. Wir waren damals gezwungen, eine virtuelle Version von Stand-up-Meetings zu organisieren, indem wir jeden Tag zur gleichen Zeit Skype-Anrufe anberaumten. Die Sitzungen dauerten etwa 15 Minuten. Einige der Teammitglieder haben diesbezüglich irgendeine Form von Widerstand, vielleicht weil sie es als eine Form der Kontrolle interpretierten, was jedoch nicht der Fall ist.

Wir haben einige Zeit damit verbracht, ihnen die wahre Bedeutung der täglichen Besprechungen bewusst zu machen: eine kurze Diskussion zwischen Teamkollegen, um sich auf die Hauptthemen zu konzentrieren, die Kommunikation zu verbessern und Möglichkeiten zur Verbesserung und Erleichterung der Arbeit für alle zu finden. Eine Zeit lang sagten sie immer wieder, es sei Zeitverschwendung und eine Ablenkung von der eigentlichen Arbeit, aber am Ende haben wir es geschafft, sie zu überzeugen.

Verfolgung von Aktivitäten/Quellen durch Automatisierungstools

Neben den Methodenpraktiken brauchten wir auch die Werkzeuge, um diese Hauptprobleme zu lösen:

• Den Code versionieren, seine Änderungen verfolgen und sie im gesamten Team teilen.

• Verfolgung der Aktivitäten und Fehlerbehebung: Was muss getan werden, wer ist wofür zuständig und der Status davon.

• Quellcodeänderungen mit Aktivitäten abgleichen.

  
  

Der Informationsfluss in einem Projekt ist viel zu komplex, als dass er sich nur auf methodische Praktiken verlassen könnte, um ihn zu steuern. Sie benötigen eine solide Werkzeugbasis, um die Arbeit zu erleichtern. Je mehr Aufgaben Sie automatisieren, desto mehr können Sie sich auf wichtige Dinge konzentrieren und ein besseres Produkt produzieren.

Für die Codeversionierung haben wir Git verwendet, da dies die natürlichste Wahl ist. Git kann auf vielfältige Weise verwendet werden und wir haben Gitflow persönlich als Workflow-Muster übernommen.

Um die Aktivitäten zu verfolgen, verwendeten wir Redmine , eine allgemeine Plattform für das Projektmanagement.

Um das dritte Problem zu lösen, haben wir unser Git-Repository so in Redmine integriert, dass Git-Commits mithilfe eines Issue-Identifikationscodes im Commit-Kommentar mit bestimmten Redmine-Tickets verknüpft werden können. Auf diese Weise hatten wir eine vollständige Zuordnung zwischen Aktivitäten und Git-Arbeitseinheiten.

Verhaltensgesteuerter Entwicklungsansatz gepaart mit Unit- und Integrationstests

Wir waren fest entschlossen, unseren Entwicklungsprozess auf einen verhaltensorientierten Ansatz zu stützen. BDD passt sehr gut zu Scrum und allgemein zu den agilen Prinzipien, insbesondere in dem Teil, der die Kommunikation betrifft. Es ermöglicht das Schreiben von Testszenarien in einem Format, das auch von technisch nicht versierten Personen verstanden werden kann, und liefert mit den richtigen Tools einen visuellen Bericht über den aktuellen Status. Es zieht die logischen Grenzen des Produkts und zwingt die Entwicklungsarbeit innerhalb dieser Grenzen.

Die BDD-Funktionstests waren nur die äußere Schicht der gesamten Testinstrumentierung. Wir haben auch Unit- und Integrationstests verwendet. Um nicht von der Komplexität einer solchen Entwicklungsumgebung überwältigt zu werden, mussten wir die richtigen Tools und Automatisierungsfunktionen verwenden.

Die wichtigsten beteiligten Technologien waren:

• Gurke : integriert in die Spring Boot-Anwendung mit REST-Diensten

• Weitere Testtools: JUnit- , Mockito- und Spring Boot-Bibliotheken zur Unterstützung von Integrationstests.

  
  

Die folgende mentale Karte zeigt eine Zusammenfassung der oben besprochenen Dinge:

Überlegungen

Hat sich die Einführung von Scrum, wenn auch auf einfache und flexible Weise, gelohnt? Die Antwort ist ja. Lassen Sie uns jedoch klarstellen, dass wir darin nicht die Lösung aller Probleme sehen können, und wenn wir es übernehmen, ohne seinen eigentlichen Geist zu verstehen, könnte es sogar schädlich sein. Der Kern einer Methodik besteht darin, ein kollektives Denkschema anzubieten, das die Menschen dazu bringt, mit maximalem Informationsaustausch und Engagement zusammenzuarbeiten. Wenn sich die Menschen jedoch darauf konzentrieren, den Regeln einer exotischen Zeremonie statt auf die eigentliche Arbeit zu folgen, verschwindet der ursprüngliche Zweck.

Eine Sportanalogie

Sie können das oben Gesagte anhand einer Sportanalogie besser verstehen. Nicht alle Menschen mögen Fußball, aber fast jeder hat zumindest eine minimale Vorstellung davon, wie es funktioniert. Zunächst einmal handelt es sich um ein kollektives Spiel. Zwei Mannschaften stehen sich auf einem Spielfeld gegenüber und versuchen, einen Ball in ein Tor zu befördern. Um diese scheinbar einfache Aufgabe zu bewältigen, müssen sie individuelle Initiativen mit kollektiven Strategien und Taktiken kombinieren. Diese Strategien und Taktiken werden im Vorfeld vom Trainer vermittelt und machen einen großen Teil der gesamten Trainingszeit aus.

Um wirklich wirksam zu sein, müssen die oben beschriebenen kollektiven Regeln, die von den Fußballspielern befolgt werden, ohne Anstrengung und ohne überhaupt zu glauben, dass sie existieren, umgesetzt werden. Sie müssen automatisch erfolgen, wie zum Beispiel die Gesten beim Autofahren. Eine Grundvoraussetzung zum Erreichen dieses Ziels besteht darin, dass sie so einfach sein müssen, dass sie von allen Spielern in der begrenzten Zeit, die zur Vorbereitung auf die Meisterschaft erforderlich ist, vollständig verstanden werden können.

Wenn Sie sich darauf konzentrieren, der Scrum-Zeremonie zu folgen und nicht auf die eigentliche Arbeit, bringen Sie am Ende Chaos statt Ordnung. Wenn Sie hingegen einen pragmatischeren Ansatz verfolgen, flexibel sind und sogar all die Dinge loswerden, die unserer spezifischen Erfahrung nach nicht funktionieren, können Sie das Beste daraus machen. Sie können sogar darüber nachdenken, einige Scrum-Ansätze zu verschieben, wenn Sie Schwierigkeiten damit haben, sie zu befolgen, und dann versuchen, sie in einer späteren Phase einzuführen.

Führung der Manager

Lassen Sie uns ein Konzept hervorheben: Agile Methoden und insbesondere Scrum können nur funktionieren, wenn die Teammitglieder entweder bereit sind, sie zu übernehmen oder sich zumindest ihrer Vorteile bewusst sind. Es kann nicht funktionieren, wenn es nur von Führungskräften in einem Unternehmen eingeführt wird, um dem allgemeinen Trubel zu folgen und der Welt draußen zu sagen: „Sehen Sie? Wir sind agil!“ Um es klar zu sagen: Wenn der Zweck nur im Marketing besteht, wäre es besser, einfach so zu tun, als würde man diese Methoden befolgen. Es besteht keine Notwendigkeit, in die internen Prozesse eine Belastung einzuführen, die nur einem Werbezweck dient.

Die Moral der Geschichte: Agile Methoden können nur dann einen positiven Einfluss haben, wenn sie von den Ingenieuren zusammen mit den Managern übernommen und nicht nur von den Managern aufgezwungen werden. Die meisten Manager, insbesondere diejenigen ohne technischen Hintergrund, wissen nichts darüber, wie sich eine Methodik auf den Lebenszyklus eines Softwareprojekts auswirken könnte, während Ingenieure, insbesondere leitende Ingenieure, dies wissen. Jahrelange Erfahrung ist besser als die besten Bücher und die besten Kurse.

Darüber hinaus werden Organisationen, basierend auf meiner seltsamen Erfahrung in italienischen Unternehmen, oft von einer Kultur bestimmt, die aus einer Art mittelalterlichem Erbe zu stammen scheint. In diesem Zusammenhang könnten die Rollen des Scrum Masters und sogar der Product Owner einfach als Quelle der Autorität auf einem Karriereweg und nicht als operative Rollen angesehen werden.

Um ehrlich zu sein, habe ich kürzlich mit dieser harten Realität experimentiert. Normalerweise haben diese Leute nicht die geringste Ahnung von den eigentlichen Prinzipien einer Methodik und belästigen die Leute ständig mit Regeln, die sie nicht einmal verstehen.

In diesen schrecklichen Umgebungen sind Extreme Programming und Scrum nur bedeutungslose Titel. In diesen Kontexten sind die Manager Quellen der Entropie, mit denen man umgehen muss, und um ein angemessenes Produktivitätsniveau zu erreichen, muss das Team seine eigene Arbeit und sogar die Manager verwalten, um ihren schlechten Einfluss zu reduzieren. Das erklärt den Titel dieses Abschnitts: „Managing the Managers“.

Ausgewogenheit zwischen Methodik, Testpraktiken, Tracking-Aktivitäten und zugehörigen Tools

In dem in diesem Artikel beschriebenen Anwendungsfall haben wir über Methodik, aber auch über Teststrategien, Tracking-Aktivitäten und die zu ihrer Unterstützung eingesetzten Tools gesprochen. Die besten Methodik-Frameworks können nicht alle komplexen Probleme bei der Softwareentwicklung allein lösen.

Tatsächlich ist BDD, das Funktionstests abdeckt, eine sehr effektive Möglichkeit, Wissen über die Logik des zu entwickelnden Softwaresystems weiterzugeben. Es baut eine starke Bindung zwischen allen Teammitgliedern und dem Product Owner auf und verbessert die Konzentration auf die wichtigeren Aspekte des Projekts. Es deckt also einen Teil der Probleme ab, die Scrum abdecken soll.

Unit- und Integrationstests hingegen sind stärker in die inneren Prozesse der Softwareentwickler eingebunden, erleichtern aber indirekt den Umgang mit Änderungen und lassen sich gut mit dem iterativen Ansatz von Scrum kombinieren.

Abschluss

Softwareentwicklung ist selbst bei minimalen Projekten, die von einem einzelnen Entwickler bearbeitet werden, eine komplexe Angelegenheit. Wenn für ein Projekt ein Team entwickelt werden muss, ergeben sich eine Reihe organisatorischer Probleme. Agile Methoden sind ein Versuch, diese Probleme zu lösen, aber sie wären nur dann wirklich nützlich, wenn man sie mit Vorsicht anwendet und jede Form sinnloser Vergrößerung vermeidet.