Im Moment werde ich häufig mit der Frage konfrontiert, was Agilität eigentlich bedeutet. Ich arbeite in einem Unternehmen, dass (Gott sei Dank) nicht jeden Hype mit macht. Deswegen diskutiere ich mit vielen verschiedenen Leuten über dieses Thema. Dabei werde ich mit verschiedenen Meinungen und auch missverständlichen Aussagen konfrontiert. Diese Aussagen möchte ich in diesem Artikel kommentieren.
Zu den häufigsten Aussagen, die mir im Gedächtnis geblieben sind gehören:
- agil bedeutet "ohne Dokumentation zu entwickeln"
- agil bedeutet "nicht zu modellieren"
- agil und ingenieurmäßig sind gegensätzliche Vorgehensweisen
- in agilen Projekten lässt sich der Fortschritt nicht messen oder kontrollieren
- agil funktioniert nicht für komplexe Großprojekte
- die Anforderungen an die Entwickler in agilen Projekten sind höher
- in komplexen Großprojekten lässt sich nicht alle 4 oder 6 Wochen ein Produktionsrelease freigeben
- um Agilität einzuführen ist ein umfangreiches Veränderungs-Management notwendig
Bedeutung: Agilität
Ich werde hier keine Definition erarbeiten, was Agilität oder Agile Software Entwicklung im Allgemeinen bedeutet. Das ist auch garnicht notwendig. Wer daran interessiert ist, kann sich hier einen Überblick verschaffen:
Agile Softwareentwicklung als Regelkreis
Später im Blog möchte ich zu den oben erwähnten Aussagen Stellung nehmen. Dazu möchte ich noch ergänzend zu den genannten Artikeln beschreiben, wie sich ein agiles Projekt als Regelkreis darstellen lässt.
Abbildung 1: Neutraler Regelkreis
Abbildung 1 zeigt einen neutralen Regelkreis. Der Regelkreis besteht aus zwei Elementen: dem (1) Regler, der die (2) Regelstrecke steuert. Regler und Regelstrecke sind in Form einer Rückkopplung miteinander verbunden. Diese Rückkopplung ermöglicht eine permanente, zyklische Interaktion. Die Rückkopplung ermöglicht das selbstregulierende Verhalten des Regelkreises. Output der Regelstrecke ist die Regelgröße, die den aktuellen Zustand der Regelstrecke meldet. Die Regelgröße wird laufend mit der Führungsgröße verglichen. Aus der Abweichung zwischen Regelgröße und Führungsgröße generiert der Regler die Stellgröße, mit der das Verhalten der Regelstrecke beeinflusst wird. Neben der Stellgröße wird das Verhalten der Regelstrecke durch Störgrößen beeinflusst.
Das Konzept des Regelkreises übertragen wir nun auf ein agiles (Scrum) Projekt.
Abbildung 2: Regelkreis in einem Scrum-Projekt
Die Führungsgröße in einem agilen Projekt ist das Product Backlog in dem alle (fachlichen und technischen) Anforderungen priorisiert aufgelistet werden. Das funktionsübergreifende Team (der Regler) analysiert das Backlog, vergleicht es mit dem aktuellen Entwicklungsstand der Anwendung (die Regelgröße) und bildet daraus das Sprint Backlog (die Stellgröße). Im Entwicklungsprozess wird die Anwendung entwickelt, einziger relevanter Output der Regelstrecke ist die laufende Software. Als typische Störgrößen, die auf die Regelstrecke wirken können neue Erkenntnisse des Kunden oder Fehlinterpretationen der Entwickler genannt werden.
Falsch: agil bedeutet "ohne Dokumentation zu entwickeln"
Die Aussage, das in agilen Projekten nichts dokumentiert wird, treffe ich sehr häufig an. Agil und "ohne Dokumentation" gehören aber definitiv nicht zusammen. In agilen Projekten ist die einzige relevante Regelgröße (Output des Entwicklungsprozesses) die laufende Software. Das ist in traditionellen Projekten oft anders. Dort wird ein erstelltes Dokument als messbares Ergebnis oder Meilenstein angesehen. Aber was haben wir damit erreicht? Kann der Kunde mit einem Dokument was anfangen? Dokumente sind in agilen Projekten keine Meilensteine, weil sie dem Kunden keinen Nutzen bringen und weil man in Wahrheit damit auch nicht den Fortschritt des Projektes messen kann. Nur die laufende Software ist relevant. Hier wird ultimativ klar, ob die Anforderungen des Kunden richtig umgesetzt worden sind. Deswegen stehen zum Beispiel Entwurfs- oder Analyse-Dokumente nicht im Mittelpunkt des Interesses, sondern dienen nur als Mittel zum Zweck. Wenn es aber hilft die Anforderungen aus dem Backlog umzusetzen, dann wird dokumentiert. Wenn es hilft dem Endbenutzer die neuen Feautures nahe zu bringen, dann wird auch dokumentiert.
Wenn ein Entwickler in einem agilen Team aus Zeitgründen zwischen kodieren und dokumentieren auswählen muss, und er kommt auch ohne Dokumentation zum Ziel (laufende Software), dann entscheidet er sich für kodieren.
Falsch: agil bedeutet "nicht zu modellieren"
Diese Aussage ist genauso falsch wie die Aussage zur Dokumentation. Selbst in Extreme Programming (XP), der wohl unformalsten agilen Vorgehensweise, wird vorgeschlagen komplexe/wichtige Teile des Systems zu modellieren, wenn es hilft sauber zu implementieren. Dazu wird aber eher Bleistift und Papier oder das Whiteboard vorgeschlagen, anstatt ein UML Tool.
Falsch: "Agil" und "ingenieurmäßig" sind gegensätzliche Vorgehensweisen
Diese Aussage habe ich aus diesem Artikel entnommen. Folgende Zitate aus dem
Artikel dienen dem besseren Verständnis:
"Sie fragen sich, ob es nicht sinnvoller wäre, die Softwareentwicklung vernünftig ingenieurmäßig aufzubereiten, um deterministisch eine Produktionsqualität, wie z. B. im Fahrzeug- oder im Hausbau, zu erzielen, anstatt sich auf Behelfslösungen wie agile Vorgehensmodelle zu verlassen."
"Ein ausschließlich ingenieurmäßiges Vorgehen funktioniert nicht in komplexen Umgebungen, mit denen wir bei der Softwareentwicklung häufig konfrontiert sind."
Die Aussagen interpretiere ich so, dass nach Meinung des Autors ein "ingenieurmäßiges Vorgehen" im Kontrast stehen würde zum agilen Vorgehen. Der Autor lässt gleichzeitig leider weitgehend offen, was genau mit "ingenieurmäßig" gemeint ist. Das habe ich zum Anlass genommen, und habe auf Wikipedia die Einträge zu Ingenieur und Ingenieurwissenschaften gelesen. Den Einträgen kann ich nichts entnehmen, was gegen agile Vorgehensweisen zur Umsetzung von Software-Projekten spricht. Meinte der Autor mit "ingenieurmäßig" vielleicht "Software Engineering"? Software Engineering wird gerne als Teil der Ingenieurwissenschaften verstanden, erfasst aber alle Bereiche der Software-Technik und damit auch die agilen Vorgehensweisen. Der Begrif "ingenieurmäßig" ist also zumindest irreführend und etwas unglücklich gewählt.
Später im Artikel wird aber auch klar, dass der Autor nicht "ingenieurmäßig" meinte. Eigentlich war gemeint, das agile Verfahren im Kontrast stehen zu formalen, stark prozessorientierten Vorgehensweisen. Letztere haben die Eigenschaften dem Team sehr fein aufzugliedern, wer, was, wann tun soll. Das "wie" wird also nicht dem Individuum (Entwickler, Analyst etc.) überlassen, sondern wird klar vorgegeben. Folgende Zitate (aus Wikipedia) machen eigentlich ganz gut die Gegensätze zwischen agilen und prozessorientierten Vorgehensmodellen klar:
"Agile software development is a group of software development methodologies based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams."
"So-called "lightweight" software development methods evolved in the mid-1990s as a reaction against "heavyweight" methods, which were characterized by their critics as a heavily regulated, regimented, micromanaged, waterfall model of development. Proponents of lightweight methods (and now "agile" methods) contend that they are a return to development practices from early in the history of software development."
Aus den Zitaten finde ich folgende Punkte wichtig:
"heavyweight" vs. "leightweight": Wenig vs. viel Dokumentation speziell über Prozess und Kommunikation
"micromanaged" vs. "self-organizing": Wenig Freiraum vs. viel Freiraum für das Team/Individuum
Weiterhin würde ich noch folgende Gegensätze zwischen traditionellen und agilen Verfahren sehen:
"funktionsübergreifend" vs. "prozessorientiert"
Das muss ich ein wenig erklären. Schon im Regelkreis oben habe ich explizit ein funktionsübergreifendes Team eingezeichnet. Es ist wichtig in agilen Projekten, dass alle notwendigen fachlichen und technische Kompetenzen in einem Team sind. Das heist es gibt fachliche und technische Experten in einem Team. Ein Projekt nach Analyse, Entwicklung und Test zu trennen ist nicht der agile Gedanke.
"developercentric" vs. "managementcenric"
Wenn man sich die agilen Verfahren anschaut, dann sieht man schnell, dass alles auf den Entwickler zugeschnitten ist. Die allermeisten agilen Methoden und Techniken sind Techniken direkt für den Entwickler, oder erfordern seine Beteiligung. Der Entwickler, der der ES TUT, steht im Mittelpunkt. Herkömmliche Vorgehensweisen zielen dagegen eher darauf ab, dass das Projektmanagement kontrollieren und messen kann.
Das sind m.E. wichtige Gegensätze, die "agil" von "prozessorientiert" unterscheiden. Weil wir oben den Entwickler als Mittelpunkt des Universums definiert haben, sei an der Stelle auch mal der Fairness halber auf ein wichtiges Problem agiler Vorgehensweisen hingewiesen: Angelehnt an die X-Y-Theorie von Douglas McGregor, wird bei agilen Projekten wohl eher die Theorie Y angenommen - "der Mensch ist engagiert". Denn "self-organizing" setzt Dinge wie Identifikation mit dem Produkt/Job, Verantwortungsgefühl und Interesse voraus. Typische Eigenschaften richtig motivierter Mitarbeiter. Dieses Thema werde ich später noch einmal aufgreifen und auch erklären, was es mit der X-Y-Theorie auf sich hat.
Fazit von allem: Ingenieurmäßig = Software-Engineering = Software-Technik = Obermenge aller Vorgehensweisen inkl. "Agile Software-Entwicklung". Daraus folgt, dass "agil" auch "ingenieurmäßig" ist.
Falsch: in agilen Projekten lässt sich der Fortschritt nicht messen oder kontrollieren
Ich finde das kann man ganz gut an dem oben eingeführten Regelkreis erklären. Ich glaube nämlich das sich der reale Fortschritt eines Projektes nirgendwo besser ablesen läst als in einem agilen Projekt: nämlich durch laufende Software. Schonmal in einem Projekt gearbeitet, dass 3 Wochen vor Ablieferung nochmal 3 Monate Verzug anmelden musste? Oder schonmal 3 Monate an etwas entwickelt, was der Kunde dann später völlig auf den Kopf gestellt hat? Vielleicht lag es daran, dass die falschen Regelgrößen gemessen wurden. Dokumente sind keine verwertbaren Regelgrößen mit denen man den Fortschritt bemessen könnte. In agilen Projekten gibt es nur eine universelle Regelgröße: die laufende Software. Daran kann man abmessen, ob die Anforderungen des Kunden, die im Product Backlog standen, wirklich abgearbeitet wurden.
Es gibt keine bessere Fortschrittskontrolle (Regelgröße im Regelkreis) als laufende Software.
Kein Dokument kann ein laufendes System ersetzen, mit dem der Kunde die ersten Schritte gehen kann. So früh wie möglich und so schnell wie möglich sollte man deswegen dem Kunden die laufende Software zeigen. In agilen Projekten ist das ein wesentliches Kriterium. Wenn man jetzt noch die hoch priorisierten Anforderungen zuerst bearbeitet (die stehen im Product Backlog ganz oben), dann hat man das Maximum an Planbarkeit in einem Software-Projekt erreicht.
Falsch: agil funktioniert nicht für komplexe Großprojekte
Ich habe selbst noch kein großes Projekt mit vielen Personen mit agilen Verfahren entwickelt. Es waren aber schon Projekte mit 20 oder mehr beteiligten Personen. Gehen wir mal davon aus, das Problem, dass durch Großprojekte gelöst werden soll, sei "komplex". Das ist sicher eine Anahme, die alle, die in einem 20+ oder sogar 100+ Personen-Projekt gearbeitet haben bestätigen würden. Im folgenden möchte ich kurz besprechen, was "komplex" eigentlich bedeutet und warum gerade agile Projekte zur Lösung komplexer Probleme gut geeignet sind.
In seinem Artikel Komplexität - Was ist das? erklärt Fredmund Malik was sich hinter dem Begriff Komplexität verbirgt. Der Artikel ist eine schöne Einführung in das Thema. Viele der folgenden Formulierungen sind direkt aus dem Artikel entnommen. Malik schlägt vor, Komlexität als reale, objektive Eigenschaft der Welt, sowohl der natürlichen wie derkünstlichen Systeme anzusehen. Komplexität kann dabei gemessen werden, und zwar mit Hilfe des Komplexitätsmaßes "Varietät". Varietät ist die Anzahl möglicher, unterscheidbarer Zustände, die ein System haben kann.
In der Natur bestehen nach dieser Definition viele Systeme mit astronomisch hoher Komplexität. Wie löst die Natur das Problem der Steuerung dieser Systeme?
"Zwei der wichtigsten kybernetischen Prinzipien der Natur sind Selbstregulierung und Selbstorganisation. Es sind universelle Architektur- und Funktionsgesetzmässigkeiten der Natur."
Diese beiden Prinzipien scheinen die Erklärung zu sein, wie die Natur mit der immensen Komplexität zurecht kommt. Weiterhin führt Malik an:
"Natürliche Systeme haben keine Regler, sie regeln sich selbst; sie haben keine Organisatoren, sie organisieren sich selbst. [...] Bei den Systemen der Natur sind Selbstregulierung und Selbstorganisation Fähigkeiten, die in ihrer Struktur eingebaut sind. Es gibt keine anderen natürlichen Systeme. In den von Menschen geschaffenen Systemen, seien es technische oder soziale Systeme oder Mischformen, kommen Selbstregulierung und Selbstorganisation meistens nicht von allein vor; sie müssen vielmehr gezielt "hineinorganisiert" werden. [...] Die Grundstrategie kybernetischen Managements lautet somit: Organisiere das Unternehmen so, dass es sich so weit wie möglich selbst organisieren und selbst regulieren kann."
Darauf aufbauend formuliere ich folgende These:
Agile Vorgehensweisen sind der Versuch ein Projekt so zu organisieren, dass es sich so weit wie möglich selbst organisieren und selbst regulieren kann.
Warum sehe ich das so? Ich habe oben einen Regelkreis gezeichnet, in dem die agierenden Systemelemente (die Teammitglieder) den Entwicklungsprozess (also sich selbst) regulieren. Es ist genau diese Eigenschaft, die ich aufzeigen wollte. Agile Projekt-Teams regeln und organisieren sich selbst. Es gibt kein formales Vorgehensmodell, dass die Handlungen der Team-Mitglieder streng festlegt. Als Stellgröße für die Regelstrecke käme demnach nicht nur das Sprint-Backlog in Frage, sondern auch z.B. eine neue organisatorische Absprache zwischen zwei Team-Mitgliedern, oder zwischen dem Team und der Umwelt (z.B. mit dem Management). Zentraler Punkt ist, dass das Team sich eigenständig an die zu lösende Aufgabe anpassen soll.
Mein Zweifel an strengen Vorgehensmodellen lautet: ein zu formal festgelegter Entwicklung-Prozess engt das Team auf eine Weise ein, die es dem Team unmöglich macht, sich effizient an eine zu lösende komplexe und unbekannte Aufgabe anzupassen.
Denn: wenn man das Problem nicht kennt und das Problem komplex ist, dann reicht es nicht aus, sich auf einen festgelegten Prozess zur Lösung des Problems zu verlassen. Wie kann das Lösungsverfahren feststehen, wenn man das zu lösende Problem garnicht kennt?
Wir sollten uns also wenn möglich (nicht immer!) von dem "Kontrolle durch Prozesse"-Gedanken verabschieden. Denn:
"Einfache Systeme kann man mit einfachen Mitteln unter Kontrolle bringen. Komplexe Systeme benötigen komplexe Mittel. [...] Um ein System unter Kontrolle zu bringen, benötigt man mindestens so viel Varietät (oder Komplexität), wie das System selbst hat. [...] Der weit verbreitete Slogan "Keep it simple" hat daher seine klare – allerdings eng begrenzte – Berechtigung. Wenn es gelingt, die Dinge einfach zu halten, können die Steuerungs- und Regulierungsmechanismen auch einfach sein."
Ich will's auch mal anders ausdrücken: viele Leute sagen "es liegt an den Personen, die das Projekt machen, ob es ein Erfolg wird oder nicht". Wer das denkt, liegt voll auf der geschilderten Argumentationslinie. Ich erkläre mir diese Aussage nämlich so: Ein gut ausgebildeter, fachlich kompetenter Mensch (oder noch besser: ein ganzes Team) verfügt über eine enorme Varietät was sein Verhalten gegenüber den komplexen Problemstellungen des Projektes angeht. Er kennt immer eine adäquate Lösung, auch für vorher unbekannte Probleme. Keine Dokumentation eines formalen Vorgehens würde die Rolle der Leistungsträger im Projekt (und dessen Varietät im Verhalten) adäquat beschreiben können, oder? Und wenn es das nicht kann, sollen wir dann trotzdem strikt nur das tun, was tatsächlich im Vorgehensmodell beschrieben ist?
Auch Carola Lilienthal widmet sich in Ihrer Dissertation dem Thema Komplexität. Sie führt den Begriff der Verstehenkomplexität an. Dabei geht es um die subjektiv enpfundene Komplexität. Darüber hinaus werden zwei weitere Dimensionen der Komplexität für einen Entwickler angeführt: die Komplexität der Interaktion mit dem Team und die Komplexität der Software selbst. Daraus ergibt sich meine dritte These.
In einem großen Software-Projekt führen zu formale Regelungen bzgl. der Tätigkeit zu einer Erhöhung der Komplexität für den Entwickler.
Denn: der Entwickler muss ja nicht nur feststellen, ob der von ihm gewählte Lösungsweg für eine Aufgabe mit hoher Wahrscheinlichkeit zum Ziel führt. Er muss ja auch feststellen, ob der Lösungsweg im Rahmen des vorgegebenen Vorgehensmodells zulässig ist. Wenn nicht, muss er im schlimmsten Fall eine Genehmigung einholen. Agile Verfahren versuchen vergleichsweise wenig zu reglementieren. So hat der Entwickler einen schnellen Überblick über das, was er wirklich wissen muss. Der Baukasten agiler Praktiken (Pair Programming, Daily Standups, Scrum Boards, Testautomatisierung, Continuous Integration etc.) ist zumindest begrenzt, in jedem agilen Umfeld gleich und flexibel anpassbar.
Fazit: Agilisten machen das, was zur Lösung des Problems nötig ist, und begehen nicht dogmatisch einen vorgegeben Lösungsweg.
Viel positives über den Gedanken der Selbstregulation und -organisation, oder? Ich möchte dem Leser hier aber nicht die Kehrseite der Medaille ersparen. Denn auch mit Selbstregulation und Selbstorganisation kommt es in der Praxis zu Problemen. Einige Gedanken (aus der Wiki-Seite zu Selbsorganisation) seien hier genannt:
Überforderung: Es ist durchaus vorstellbar, dass Mitarbeiter mit starker Freizeitorientierung lieber ein vorgeschriebenes Pensum erledigen, um sich so wenig wie möglich mit dem
„notwendigen Übel“ Arbeit auseinandersetzen zu müssen. Vor allem kann aber die ungewohnte Freiheit zu Beginn Angst und Überforderungsgefühle auslösen.
Konflikte: Das Konfliktpotential ist grundsätzlich höher, wenn Verteilungs- und Kompetenzregelungen fehlen und selbst ausgehandelt werden müssen.
Hohe Anforderung an die Führung: Durch die Selbstorganisation kann es zu einer Abänderung der offiziellen Regeln und autogen entstehenden Regeln kommen, die die Unsicherheit über die tatsächliche geltende Ordnung erhöhen, dies führt zu einem Dilemma der Führungskräfte.
Zeitaufwand und Kosten: Häufige Strukturänderungen, welche auch noch konfliktgeladen sind, erfordern Zeit. Daher kann die Lösungs- und Entscheidungsfindung in selbstorganisierten Systemen länger dauern als bei klaren Vorgaben von oben.
Wie sagt man so schön? Nicht ist umsonst, außer der Tod, und der kostet das Leben ;-)
Richtig: die Anforderungen an die Entwickler in agilen Projekten sind höher
Diese Aussage muss man wohl so stehen lassen. Die Skill-Anforderungen an Mitglieder agiler Projekte sind aus meiner Sicht etwas höher. Ich beziehe mich hier mal auf die schon angesprochene X-Y-Theorie. Dort werden folgende Bilder von Mitarbeitern skizziert:
Theorie X - "der Mensch ist unwillig" - Folgende Attribute prägen dieses Bild: Abneigung gegen Arbeit, meistens muss der Mitarbeiter deswegen gelenkt und geführt werden, er muss "an die Hand genommen" werden. Er zieht Routineaufgaben vor, strebt nach Sicherheit, scheut sich vor Verantwortung. Der Manager muss jeden Handlungsschritt detailliert vorgeben, energisch anleiten und führen sowie streng kontrollieren.
Theorie Y - "der Mensch ist engagiert" - Folgende Attribute prägen dieses Bild: Arbeit hat einen hohen Stellenwert und ist wichtige Quelle der Zufriedenheit, von Natur aus leistungsbereit und von innen motiviert. Er strebt nach Selbstverwirklichung, strebt nach mehr Selbstbestimmung, größere Verantwortungsbereiche, flexiblere Organisationsstrukturen, Gruppen- und Projektarbeit etc. Er identifiziert sich mit den Zielen der Organisation. Externe Kontrollen sind deswegen nicht notwendig, denn er wird Verantwortung übernehmen und Eigeninitiative entwickeln.
Theorie Z - "der Mensch ist je nachdem" - Es wird angenommen, dass eine starke Mitarbeiterbeteiligung zu Engagement und höherer Produktivität führt. Hier spielen folgende Mechanismen eine Rolle: lebenslange Beschäftigung, Beteiligung an Entscheidungsfindung, individuelle Verantwortungsübernahme der Mitarbeiter, Leistungsbeurteilung, Beförderung in langen Zyklen, keine formalisierten Verhaltensregeln, hoher Stellenwert interpersonaler Beziehungen.
Agile Vorgehensweisen erfordern engagierte Mitarbeiter oder zumindest solche, die sich "mitnehmen lassen" und sich dann konstruktiv einbringen.
Wir können also nur mit Typ Y und Z in agilen Projekten arbeiten. Warum? Werfen wir mal einen Blick auf ein paar Eigenschaften von Mitarbeiter Typ X und bewerten diese in Bezug auf das Anforderungsprofil in agilen Projektteams:
Nochmal erinnern: Der oben eingeführte Regelkreis verdeutlicht, dass sich das agile Team selbst steuert und organisiert. Der Mitarbeiter vom Typ C hat eine Abneigung gegen Arbeit. Daher muss er gelenkt und eng geführt werden. Überträgt man die Führungsverantwortung (für sich) auf ihn selbst (Selbstregulation), muss damit gerechnet werden, dass nichts oder nur wenig passiert.
Außerdem zieht er Routineaufgaben vor. Eine Idee agiler Projektteams liegt aber gerade darin, der Komplexität des Projektes durch ebenso hohe Komplexität (Varietät) im
Problemlösungsverhalten zu begegnen. In einem solchen Umfeld ist Routine nicht der Alltag, sondern Veränderung und dazu lernen.
Typ X meidet Verantwortung. Selbstorganisation und Sellbstreguation bedeutet dagegen hohe Verantwortung, weil das Entwicklungsvorgehen ja gerade nicht mehr von außen detailliert vorgegeben wird. Der Entwickler muss viel selbst entscheiden, was in konservativen Führungsmodellen durch die Führungskraft entschieden werden sollte.
Ich glaube das reicht aus um darzustellen, dass Typ X von der Mentalität nicht gerade in ein agiles Projekt passt.
Bisher haben wir nur über die Anforderungen an die Grundmotivation der Mitarbeiter gesprochen. Darüber hinaus besteht aber auch eine hohe Anforderung an das "Skill-Niveau". Wer in Extreme Programming einsteigen will, kann auf Ron Jeffries Seite einiges lernen, oder man wirft mal einen Blick in das Inhaltsverzeichnis das Extreme Programming Buch von Kent Beck und Martin Fowler. Oder hier: Agile Developer Skills, das ist auch eine gute Referenz. Und wem das noch nicht reicht, der kann sich auch noch mit anderen Ideen rund um Agile beschäftigen, zum Beispiel mit Alaister Cockburn oder Jeff De Luca. Eine gute Übersicht über die agilen Muster und Methoden (die allen agilen Vorgehensweisen gemein sind) gibt dieses Buch. Alles zusammen veranlasst mich zu der These:
Agile Enticklung setzt ein hohes Maß an erforderlichen technischen und methodischen Fähigkeiten der Team-Mitglieder voraus. Ohne diese Fähigkeiten wären agile Teams ebenso risikoreich unterwegs wie andere Teams.
Ich nenne nur mal ein paar Beispiele der Techniken, die man unbedingt beherschen sollte:
- Testgetriebene Entwicklung (insb. Unit Tests)
- Objekt-orientiertes Design und Programmierung inkl. Analyse- und Design-Muster
- Gemeinsames Planen: User Stories, Release Planung, Iterationen
- Versionskontrolle, z.B. mit CVS oder Subversion
- Detaillierte Kenntnisse der eigenen Entwicklungsumgebung, z.B. Eclipse
- Continuous Integration
- Pair Programming
Wer also denkt, agile Softwareentwicklung wäre keine umfangreiche Vorgehensweise, der irrt. So gesehen handelt es sich sehr wohl um eine umangreiche Vorgehensweise. Der Unterschied zu anderen "Schwergewichten" liegt eher in der beschriebenen Betonung der Selbstregulation und -organisation bei der Auswahl der Techniken aus dem agilen Werkzeugkasten. Wie schon gesagt:
Das funktionsübergreifende Entwicklungsteam darf das tun, was nötig ist um das Ziel zu erreichen, und es entscheidet selbst, was das Nötige ist.
Noch ein letztes Wort zu Skills: Zu den ganzen harten erlernbaren Fähigkeiten kommt das erhöhte Maß an erforderlichen "Soft-Skills" hinzu. Die Fähigkeit und der Wille zur konstruktiven Kommunikation ist wohl das wichtigste Mittel bei der Problemlösung in komplexen dynamischen Projekten. Interaktion zwischen den Menschen hat daher einen sehr hohen Stellenwert. Wir befinden uns nämlich in einem Umfeld in dem häufig adhoc-Absprachen stattfinden, um sich z.B. auf geänderte Rahmenbedingungen einzustellen. Außerdem funktionieren Pair Programming oder Daily Standups auch nur dann wirklich gut, wenn der Entwickler gerne und "gut" kommuniziert.
Falsch: in komplexen Großprojekten lässt sich nicht alle 4 oder 6 Wochen ein Produktionsrelease freigeben
Diese Aussage kann ich so ohne weiteres nicht nachvollziehen. Ich habe schon komplexe Software mit agilen Vorgehensweisen entwickelt und konnte noch kürzere Releasezyklen erreichen. Meine Vermutung ist, dass viele Organisationen "noch nicht so weit sind", aber generell unmöglich ist es sicher nicht. Eine gute Voraussetzung für kurze Releasezyklen sind nach meiner Erfahrung:
Funktionierende Continuous Integration (CI) Umgebung
Wenn die Anwendung jeden Tag kompiliert, zusammengesetzt, getestet und qualitätsgesichert wird, dann hat man jederzeit einen schnellen Überblick. Man weiß jeden Tag ob die Software lauffähig ist. CI ist im Sinne unseres Regelkreises praktisch die laufende automatische Überwachung der Regelgröße (laufende Software).
Ausgiebige Testautomatisierung (Unit Tests und GUI Tests)
Wenn man die gesamte Anwendung immer wieder von Hand durchtesten muss, dann wird es schwer mit kurzen Releasezyklen. Statt dessen sollte eine gute Abdeckung an automatisierten Tests bestehen, wodurch der Regressionstest automatisch abläuft.
Funktionsübergreifendes Team, dass den Kunden "beinhaltet"
Wenn der Kunde im Team ist, dann hat er laufend Rückkopplung über den Stand der aktuellen Entwicklung. Er ist also nicht am Ende eines Entwicklungszyklus plötzlich mit der Anwendung konfrontiert, sondern hat zusammen mit den Entwicklern an der Erstellung gearbeitet.
Falsch: um Agilität einzuführen ist ein umfangreiches Veränderungs-Management notwendig
Hier gibt es aus meiner Sicht zwei Denkphilosophien. Die eine Seite sagt, dass agile Verfahren wie z.B. Scrum einen "Big Change Up Front" benötigen. Andere wehren sich gegen diese Vorgehensweise, weil die zu viele Risiken mit sich bringt. Ich schliesse mich folgender These von Ron Jeffries an:
"[...] big change up front or itty-bitty change up front isn’t the most important thing to me. Choosing the best moves we can manage, every day, that’s what I’m talking about."
Das trifft es aus meiner Sicht auf den Punkt. Bleibt nur noch die Frage, welches die "besten Moves" sind. Es bringt nichts sich dabei einer agilen Vorgehensweise zu verschreiben, ohne zu berücksichtigen was wirklich notwendig für die Organisation und deren Individuen ist. Allan Shalloway sagt:
"We assume that the change here [...] is the correct thing to do without understanding the nature of our true challenge."
Ron Jeffries sagt zu dem Thema "Auswahl der richtigen agilen Methode oder Technik":
"There probably is no best process for everyone. But the best start, for everyone, is probably to decide to improve, pick a way to start improving, and not to stop."
Daraus leite ich folgende Thesen ab:
Es macht keinen Sinn sich einer agilen Methode zu verschreiben, ohne vorher genau die Natur der eigenen Organisation zu betrachten.
Zu Beginn einer "agilen Transition" muss man sich im Team erstmal entscheiden, dass man sich verbessern will, und das man nicht aufhören will, sich zu veressern.
Das Team soll eigenständig entscheiden, welche agilen Techniken zu einer Verbesserung des aktuellen Entwicklungsprozesses führen.
In diesem Sinne macht es auch keinen Sinn ein Pilotprojekt mit einer festgelegten Methode zu starten. Denn dann hat man nicht in die eigentlichen Probleme der Organisation geschaut und man hat nicht das Team entscheiden lassen, welche Techniken den aktuellen Entwicklungsprozess wirklich verbessern. Statt dessen wird einfach eine komplett neue Technik angewand, und damit wird gesagt: alles was Ihr bislang gemacht habt ist nicht gut. Aber auch, wenn im Pilotprojekt alle die neue Vorgehensweise super finden und der Pilot erfolgreich wird, bleit die Frage: waren in dem Pilotprojekt vielleicht nur Mitarbeiter vom Typ Y - also hoch motivierte?
Ein guter Weg aus meiner Sicht ist es also, nicht "revolutionär" vorzugehen, sondern eher "evolutionär". Und man sollte langsam vorgehen, damit man auch jeden mitnimmt auf die Reise, der eigentlich mit will. Allan Shallaway schlägt Kanban als Einführungsmethode für Agilität vor und sagt:
"The Lean/Kanban alternative is to first understand your current process and to gradually change it. You do this by creating visibility into it using a Kanban board which represents the value stream. You discuss your policies to make them explicit. You manage your work in progress to do step by step improvements to your work flow."
Wir sollen also sozusagen folgendes machen:
Visualisiere Deinen Entwicklungsprozess und spreche darüber, was man verbessern könnte. Schaue dabei in den Werkzeugkasten agiler Verfahren. Da findest Du viele Best Practices. Nutze sie aber nur, wenn es Dich verbessert.
This comment has been removed by a blog administrator.
ReplyDelete