Agile Entwicklungsmetoden und ihre Rolle bei itdesign
Kaum ein Begriff war in der Diskussion um Software-Entwicklung in den letzten Jahren so sehr in aller Munde wie das Wort agil. So gibt es kaum ein Software-Unternehmen, das nicht schon Erfahrungen auf dem Gebiet der agilen Entwicklung gemacht hat. Doch wer die Diskussion aufmerksam verfolgt, stellt schnell fest, dass die Meinungen zu Sinn, Nutzen und Effizienz der agilen Entwicklung sehr breit gestreut sind. Es lassen sich drei Gruppen identifizieren.
Drei Haltungen zur agilen Entwicklung
Die erste Gruppe bilden Vertreter des agilen Gedankens, die sich vor allem auf das agile Manifest berufen (Kent Beck, http://agilemanifesto.org), sich aber häufig schwer damit tun, diese Gedanken vollständig in die Prozesse des Unternehmens zu integrieren.
Die zweite Gruppe sind Vertreter bestimmter agiler Entwicklungsmethoden, welche meist einer einzelnen speziellen agilen Methode vertrauen und diese häufig mit mehr oder weniger ausgeprägtem Eifer vertreten und versuchen, ihre Mitmenschen zu dieser Methode zu bekehren.
Die dritte Gruppe kommt meist aus weniger technisch geprägten Bereichen wie Beratung, Vertrieb oder Management und belächelt die agile Entwicklung eher. Hierbei gibt es die Auffassung, dass die agile Entwicklung im Wesentlichen nur das beschreibt, was eigentlich auch vorher schon gemacht wurde. Zudem gibt es die etwas skeptische Auffassung, dass Agilität nur als Deckmantel für das nicht Einhalten von Prozessen, das nicht Erstellen von Spezifikationen und eine nicht vorhandene seriöse Planung genutzt wird.
Populäre agile Methoden und Prinzipien
In den 90er Jahren zeigte sich, dass die klassische Software-Entwicklung, beispielsweise nach dem Wasserfallmodell, wegen mangelnder Flexibilität oft den Anforderungen an ein Software-System nicht gerecht wurde. Daher kam die Idee für neue und weniger bürokratische Entwicklungsmethoden auf. Diese wurden im Jahr 2001 im Agilen Manifest festgehalten.
Die frühen agilen Ideen wurden unter dem Schlagwort extreme programming zusammengefasst. Sie brachten innovative Neuerungen wie continuous integration hervor. Continuous integration bedeutet, dass man regelmäßig eine neue lauffähige Version über einen automatischen Build erstellt. Des Weiteren kam die Technik des pair programmings auf, bei der man zu zweit arbeitet, um Fehler zu vermeiden und um den Know-how-Transfer zu fördern. Ein sehr wichtiges Prinzip ist die collective code ownership, die besagt, dass das ganze Team gemeinsam für den gesamten Quellcode verantwortlich ist. Dies stellt das klassische Verteilen von Arbeitspaketen an Entwickler und die daran gekoppelte klassische Projektplanung in der Software-Entwicklung in Frage, die auf einer Projekt-Task-Resource-Zuordnung und Gantt-Diagrammen basiert.
SCRUM, eine der populärsten agilen Methoden
Eine der populärsten agilen Methoden ist SCRUM, welche durch strenge Regeln und ein vorgegebenes Rollenmodell in nur wenigen Wochen einführbar ist. In SCRUM wird in Sprints genannten Iterationen gearbeitet, die typischerweise zwischen einer und drei Wochen dauern. Zu Beginn des Sprints definieren der Product Owner, der in SCRUM für die fachliche Anforderung zuständig ist, und das Team gemeinsam die Anforderungen, welche während des Sprints in der vom Product Owner vorgegebenen Reihenfolge umgesetzt werden. Die Dauer eines Sprints ist konstant und darf nicht geändert werden.
Diese Methode ist inzwischen in vielen Ländern sehr verbreitet. Trotzdem geriet sie in den letzten Jahren aber auch in die Kritik, da Teilprozesse der Entwicklung wie Wartung nicht Bestandteil der ursprünglichen Methode sind. Die Regel in SCRUM, dass das Abziehen von Entwicklern während eines Sprints strengstens verboten ist, führt vor allem bei kleineren Unternehmen zu großen Problemen. In einigen Fällen muss dann zwischen einer eigentlich benötigten und objektiv sinnvoll erscheinenden Flexibilität und dem Festhalten an SCRUM entschieden werden.
Zunehmende Beliebtheit von KANBAN
Eine Methode, die sich in den letzten Jahren zunehmender Beliebtheit erfreut, ist KANBAN, eine Methode, die ihren Ursprung in der Automobilindustrie hat. KANBAN basiert auf dem Pull-Prinzip und funktioniert auch in der Software-Entwicklung vergleichbar mit einer Fertigungsstraße. Im Vergleich zu SCRUM hat KANBAN kein vorgegebenes Rollenmodell und schreibt auch keine feste Iterationsdauer fest. Durch diese Flexibilität lässt sich KANBAN zwar einerseits sehr gut an bestehende Anforderungen und Prozesse adaptieren. Die gleiche Flexibilität kann aber auch zum Fallstrick werden. Denn es besteht die Gefahr, dass man sehr viel Zeit auf das Ändern und Testen des Prozesses verwendet und die eigentlichen Probleme und Herausforderungen deshalb auf der Strecke bleiben.
Nach den Erfahrungen, welche die itdesign GmbH mit agilen Methoden gesammelt hat, ist festzuhalten, dass man bei der Einführung agiler Methoden immer zwei Aspekte berücksichtigen muss. Zum einen die weiche Seite, die das Befolgen des agilen Manifests und des Team-Gedankens umfasst. Zum anderen muss die harte Prozess-Sicht gleichermaßen im Auge behalten werden. Hier sind Zielkonflikte vorprogrammiert, wenn man einerseits agile Denkweise und Teamgeist der Mitarbeiter fordert, jedoch andererseits Prozesse und Kennzahlen nur auf persönliche Leistungen und Erfolge des Einzelnen ausrichtet.
Mit der Software identifizieren und Verantwortung übernehmen
Ebenso sicher ist, dass ein noch so agiler Prozess keinen Erfolg bringen kann, wenn die Team-Mitglieder sich mit der produzierten Software nicht identifizieren und sie nicht bereit sind, Verantwortung für Fehler und Entscheidungen zu übernehmen. Ein weiterer Punkt, den wir im Umgang mit agilen Methoden gelernt haben, ist, dass man bei der Beurteilung von Entwicklungs-Methoden Faktoren wie Teamgröße, Entwicklungszeit und verwendeter Technologie nicht vernachlässigen darf.
So ist SCRUM nach unserer Einschätzung sehr gut für das Entwickeln von komplett neuen Funktionalitäten geeignet und hat seine Stärke vor allem in der Know-how-Verteilung und der Förderung des Teams als eigenständige Einheit. Eine strenge Befolgung der SCRUM-Regeln ist aber in der Produktwartung oder auch bei der Verbesserung der Kompatibilität zu Fremdsystemen nicht optimal. Der schnellen Beseitigung technischer Probleme steht der feste Sprint-Rahmen im Weg. Die elektronische Ressourcen-Zuteilung, welche bei SCRUM verboten ist, hat sich bei der Fehlerbehebung als effizientes Instrument bewährt.
Konkrete Umsetzung agiler Methoden bei der itdesign GmbH
Die Konsequenz für die itdesign GmbH ist, die für uns geeigneten Elemente aus SCRUM und KANBAN zu kombinieren. Diese Verbindung von SCRUM und KANBAN wird oft als SCRUMBAN bezeichnet und wird momentan noch kontrovers diskutiert. Während sich in SCRUM alles um den Sprint als Bezugsgröße dreht, stellt KANBAN, welches von David Anderson zum ersten Mal im Software-Umfeld eingeführt und dokumentiert wurde, die Begrenzung der WIP, Work in Progress, in den Vordergrund. Ziel ist, möglichst wenige Aufgaben gleichzeitig zu bearbeiten und bei diesen jeweils eine möglichst kurze Durchlaufzeit zu erreichen. Dabei liegt der Fokus bei der itdesign GmbH darauf, die Weiterentwicklung des Produkts, ähnlich wie in SCRUM, gemeinsam mit dem ganzen Team durchzuführen und diesen Teilprozess in den KANBAN-Prozess zu integrieren, welcher einen zeitnahen Test enthält.
Die Rolle des Product Owners haben wir unverändert aus SCRUM übernommen. Zusätzlich zum eigentlichen SCRUM-Team wird das SCRUM-Board aber auch von einem Qualitätssicherungs-Team verwendet, welches die neuen Funktionalitäten und behobenen Fehler testet. Diese Erweiterung zum klassischen SCRUM beseitigt unserer Meinung nach eine der größten Schwachstellen von SCRUM, denn in SCRUM testet das Team selbst und liefert theoretisch fertige und fehlerfreie Funktionalität ab. Da aber das Team oft einem hohen Druck hinsichtlich der zu erreichenden Geschwindigkeit ausgesetzt ist, wird im Zweifel an der Qualität gespart, um das Sprint-Ziel zu erreichen.
Getrennte Teams für Entwicklung und Test
Außerdem sind die für das SCRUM-Team geforderten Mitarbeiter, die begabte und motivierte Entwickler und zugleich ebenso begabte und motivierte Tester sein sollen, in der Realität sehr selten. Das Review-Meeting, in dem das Team in regelmäßigen Abständen allen Interessierten die umgesetzten Änderungen präsentiert, wurde aus SCRUM übernommen. Außerdem erlauben wir in unserem Prozess, die Priorität der Anforderungen und Fehlerkorrekturen, so lange diese noch nicht umgesetzt werden, zu jeder Zeit zu ändern. Bei SCRUM darf man den Umfang und die Umsetzungs-Reihenfolge eines begonnenen Sprints nicht mehr ändern.
Der Sprint als fester Bezugsrahmen entfällt in KANBAN komplett, da die Umsetzungs-Geschwindigkeit kontinuierlich gemessen wird und das parallele Entwickeln an mehreren Quellcode-Zweigen in KANBAN ausdrücklich erlaubt ist. So sind der Umfang und auch der Zeitpunkt eines Release vom KANBAN-Prozess und den dafür benötigten Meetings entkoppelt.
Verbesserungen der Zusammenarbeit und des Entwicklungsprozesses
Mit den gesammelten Erfahrungen der eingesetzten agilen Entwicklungs-Methoden konnte die Software-Entwicklung gewinnbringend umstrukturiert werden. An erster Stelle, dies ist allen erprobten Methoden gemein, steht die Transparenz der Arbeitsschritte für alle Beteiligten. Es hat sich gezeigt, dass jede Aktivität in der Projektentwicklung, dem Support und der Produktentwicklung für alle an einer zentralen Stelle sichtbar und damit nachvollziehbar sein muss. Jeder Mitarbeiter sieht, wer an welcher Aufgabe arbeitet und wen er nach dem Fortschritt einer Arbeit fragen kann. Nur so wird die nötige Informationsbasis für eine zuverlässige Planung geschaffen. Bei der itdesign GmbH wurde hierzu eine Visualisierung in CAS genesisWorld umgesetzt, welche die benötigten Informationen liefert und allen Mitarbeitern auf einen Blick zugänglich macht.
Die Rolle von Kommunikation und Transparenz in der Entwicklung
An zweiter Stelle ist die gesteigerte Kommunikation innerhalb der Entwicklung zu nennen. Ein kurzes tägliches Statustreffen hilft, den Fokus auf den wichtigsten Aufgaben zu halten und allen ein Bild der aktuellen Situation zu vermitteln. Die intensive Auseinandersetzung mit der Strukturierung der Software-Entwicklung im Bereich CRM führte zu gut dokumentierten Prozessen, die auch die Schnittstellen zu Abteilungen wie Support oder Produktmanagement mit einbeziehen. Bereits heute zeigt sich eine gewisse Strahlkraft dieses Lernprozesses, so dass in der Schwesterabteilung PPM die neu gewonnenen Erkenntnisse ebenfalls genutzt werden.
.
Drei Haltungen zur agilen Entwicklung
Die erste Gruppe bilden Vertreter des agilen Gedankens, die sich vor allem auf das agile Manifest berufen (Kent Beck, http://agilemanifesto.org), sich aber häufig schwer damit tun, diese Gedanken vollständig in die Prozesse des Unternehmens zu integrieren.
Die zweite Gruppe sind Vertreter bestimmter agiler Entwicklungsmethoden, welche meist einer einzelnen speziellen agilen Methode vertrauen und diese häufig mit mehr oder weniger ausgeprägtem Eifer vertreten und versuchen, ihre Mitmenschen zu dieser Methode zu bekehren.
Die dritte Gruppe kommt meist aus weniger technisch geprägten Bereichen wie Beratung, Vertrieb oder Management und belächelt die agile Entwicklung eher. Hierbei gibt es die Auffassung, dass die agile Entwicklung im Wesentlichen nur das beschreibt, was eigentlich auch vorher schon gemacht wurde. Zudem gibt es die etwas skeptische Auffassung, dass Agilität nur als Deckmantel für das nicht Einhalten von Prozessen, das nicht Erstellen von Spezifikationen und eine nicht vorhandene seriöse Planung genutzt wird.
Populäre agile Methoden und Prinzipien
In den 90er Jahren zeigte sich, dass die klassische Software-Entwicklung, beispielsweise nach dem Wasserfallmodell, wegen mangelnder Flexibilität oft den Anforderungen an ein Software-System nicht gerecht wurde. Daher kam die Idee für neue und weniger bürokratische Entwicklungsmethoden auf. Diese wurden im Jahr 2001 im Agilen Manifest festgehalten.
Die frühen agilen Ideen wurden unter dem Schlagwort extreme programming zusammengefasst. Sie brachten innovative Neuerungen wie continuous integration hervor. Continuous integration bedeutet, dass man regelmäßig eine neue lauffähige Version über einen automatischen Build erstellt. Des Weiteren kam die Technik des pair programmings auf, bei der man zu zweit arbeitet, um Fehler zu vermeiden und um den Know-how-Transfer zu fördern. Ein sehr wichtiges Prinzip ist die collective code ownership, die besagt, dass das ganze Team gemeinsam für den gesamten Quellcode verantwortlich ist. Dies stellt das klassische Verteilen von Arbeitspaketen an Entwickler und die daran gekoppelte klassische Projektplanung in der Software-Entwicklung in Frage, die auf einer Projekt-Task-Resource-Zuordnung und Gantt-Diagrammen basiert.
SCRUM, eine der populärsten agilen Methoden
Eine der populärsten agilen Methoden ist SCRUM, welche durch strenge Regeln und ein vorgegebenes Rollenmodell in nur wenigen Wochen einführbar ist. In SCRUM wird in Sprints genannten Iterationen gearbeitet, die typischerweise zwischen einer und drei Wochen dauern. Zu Beginn des Sprints definieren der Product Owner, der in SCRUM für die fachliche Anforderung zuständig ist, und das Team gemeinsam die Anforderungen, welche während des Sprints in der vom Product Owner vorgegebenen Reihenfolge umgesetzt werden. Die Dauer eines Sprints ist konstant und darf nicht geändert werden.
Diese Methode ist inzwischen in vielen Ländern sehr verbreitet. Trotzdem geriet sie in den letzten Jahren aber auch in die Kritik, da Teilprozesse der Entwicklung wie Wartung nicht Bestandteil der ursprünglichen Methode sind. Die Regel in SCRUM, dass das Abziehen von Entwicklern während eines Sprints strengstens verboten ist, führt vor allem bei kleineren Unternehmen zu großen Problemen. In einigen Fällen muss dann zwischen einer eigentlich benötigten und objektiv sinnvoll erscheinenden Flexibilität und dem Festhalten an SCRUM entschieden werden.
Zunehmende Beliebtheit von KANBAN
Eine Methode, die sich in den letzten Jahren zunehmender Beliebtheit erfreut, ist KANBAN, eine Methode, die ihren Ursprung in der Automobilindustrie hat. KANBAN basiert auf dem Pull-Prinzip und funktioniert auch in der Software-Entwicklung vergleichbar mit einer Fertigungsstraße. Im Vergleich zu SCRUM hat KANBAN kein vorgegebenes Rollenmodell und schreibt auch keine feste Iterationsdauer fest. Durch diese Flexibilität lässt sich KANBAN zwar einerseits sehr gut an bestehende Anforderungen und Prozesse adaptieren. Die gleiche Flexibilität kann aber auch zum Fallstrick werden. Denn es besteht die Gefahr, dass man sehr viel Zeit auf das Ändern und Testen des Prozesses verwendet und die eigentlichen Probleme und Herausforderungen deshalb auf der Strecke bleiben.
Nach den Erfahrungen, welche die itdesign GmbH mit agilen Methoden gesammelt hat, ist festzuhalten, dass man bei der Einführung agiler Methoden immer zwei Aspekte berücksichtigen muss. Zum einen die weiche Seite, die das Befolgen des agilen Manifests und des Team-Gedankens umfasst. Zum anderen muss die harte Prozess-Sicht gleichermaßen im Auge behalten werden. Hier sind Zielkonflikte vorprogrammiert, wenn man einerseits agile Denkweise und Teamgeist der Mitarbeiter fordert, jedoch andererseits Prozesse und Kennzahlen nur auf persönliche Leistungen und Erfolge des Einzelnen ausrichtet.
Mit der Software identifizieren und Verantwortung übernehmen
Ebenso sicher ist, dass ein noch so agiler Prozess keinen Erfolg bringen kann, wenn die Team-Mitglieder sich mit der produzierten Software nicht identifizieren und sie nicht bereit sind, Verantwortung für Fehler und Entscheidungen zu übernehmen. Ein weiterer Punkt, den wir im Umgang mit agilen Methoden gelernt haben, ist, dass man bei der Beurteilung von Entwicklungs-Methoden Faktoren wie Teamgröße, Entwicklungszeit und verwendeter Technologie nicht vernachlässigen darf.
So ist SCRUM nach unserer Einschätzung sehr gut für das Entwickeln von komplett neuen Funktionalitäten geeignet und hat seine Stärke vor allem in der Know-how-Verteilung und der Förderung des Teams als eigenständige Einheit. Eine strenge Befolgung der SCRUM-Regeln ist aber in der Produktwartung oder auch bei der Verbesserung der Kompatibilität zu Fremdsystemen nicht optimal. Der schnellen Beseitigung technischer Probleme steht der feste Sprint-Rahmen im Weg. Die elektronische Ressourcen-Zuteilung, welche bei SCRUM verboten ist, hat sich bei der Fehlerbehebung als effizientes Instrument bewährt.
Konkrete Umsetzung agiler Methoden bei der itdesign GmbH
Die Konsequenz für die itdesign GmbH ist, die für uns geeigneten Elemente aus SCRUM und KANBAN zu kombinieren. Diese Verbindung von SCRUM und KANBAN wird oft als SCRUMBAN bezeichnet und wird momentan noch kontrovers diskutiert. Während sich in SCRUM alles um den Sprint als Bezugsgröße dreht, stellt KANBAN, welches von David Anderson zum ersten Mal im Software-Umfeld eingeführt und dokumentiert wurde, die Begrenzung der WIP, Work in Progress, in den Vordergrund. Ziel ist, möglichst wenige Aufgaben gleichzeitig zu bearbeiten und bei diesen jeweils eine möglichst kurze Durchlaufzeit zu erreichen. Dabei liegt der Fokus bei der itdesign GmbH darauf, die Weiterentwicklung des Produkts, ähnlich wie in SCRUM, gemeinsam mit dem ganzen Team durchzuführen und diesen Teilprozess in den KANBAN-Prozess zu integrieren, welcher einen zeitnahen Test enthält.
Die Rolle des Product Owners haben wir unverändert aus SCRUM übernommen. Zusätzlich zum eigentlichen SCRUM-Team wird das SCRUM-Board aber auch von einem Qualitätssicherungs-Team verwendet, welches die neuen Funktionalitäten und behobenen Fehler testet. Diese Erweiterung zum klassischen SCRUM beseitigt unserer Meinung nach eine der größten Schwachstellen von SCRUM, denn in SCRUM testet das Team selbst und liefert theoretisch fertige und fehlerfreie Funktionalität ab. Da aber das Team oft einem hohen Druck hinsichtlich der zu erreichenden Geschwindigkeit ausgesetzt ist, wird im Zweifel an der Qualität gespart, um das Sprint-Ziel zu erreichen.
Getrennte Teams für Entwicklung und Test
Außerdem sind die für das SCRUM-Team geforderten Mitarbeiter, die begabte und motivierte Entwickler und zugleich ebenso begabte und motivierte Tester sein sollen, in der Realität sehr selten. Das Review-Meeting, in dem das Team in regelmäßigen Abständen allen Interessierten die umgesetzten Änderungen präsentiert, wurde aus SCRUM übernommen. Außerdem erlauben wir in unserem Prozess, die Priorität der Anforderungen und Fehlerkorrekturen, so lange diese noch nicht umgesetzt werden, zu jeder Zeit zu ändern. Bei SCRUM darf man den Umfang und die Umsetzungs-Reihenfolge eines begonnenen Sprints nicht mehr ändern.
Der Sprint als fester Bezugsrahmen entfällt in KANBAN komplett, da die Umsetzungs-Geschwindigkeit kontinuierlich gemessen wird und das parallele Entwickeln an mehreren Quellcode-Zweigen in KANBAN ausdrücklich erlaubt ist. So sind der Umfang und auch der Zeitpunkt eines Release vom KANBAN-Prozess und den dafür benötigten Meetings entkoppelt.
Verbesserungen der Zusammenarbeit und des Entwicklungsprozesses
Mit den gesammelten Erfahrungen der eingesetzten agilen Entwicklungs-Methoden konnte die Software-Entwicklung gewinnbringend umstrukturiert werden. An erster Stelle, dies ist allen erprobten Methoden gemein, steht die Transparenz der Arbeitsschritte für alle Beteiligten. Es hat sich gezeigt, dass jede Aktivität in der Projektentwicklung, dem Support und der Produktentwicklung für alle an einer zentralen Stelle sichtbar und damit nachvollziehbar sein muss. Jeder Mitarbeiter sieht, wer an welcher Aufgabe arbeitet und wen er nach dem Fortschritt einer Arbeit fragen kann. Nur so wird die nötige Informationsbasis für eine zuverlässige Planung geschaffen. Bei der itdesign GmbH wurde hierzu eine Visualisierung in CAS genesisWorld umgesetzt, welche die benötigten Informationen liefert und allen Mitarbeitern auf einen Blick zugänglich macht.
Die Rolle von Kommunikation und Transparenz in der Entwicklung
An zweiter Stelle ist die gesteigerte Kommunikation innerhalb der Entwicklung zu nennen. Ein kurzes tägliches Statustreffen hilft, den Fokus auf den wichtigsten Aufgaben zu halten und allen ein Bild der aktuellen Situation zu vermitteln. Die intensive Auseinandersetzung mit der Strukturierung der Software-Entwicklung im Bereich CRM führte zu gut dokumentierten Prozessen, die auch die Schnittstellen zu Abteilungen wie Support oder Produktmanagement mit einbeziehen. Bereits heute zeigt sich eine gewisse Strahlkraft dieses Lernprozesses, so dass in der Schwesterabteilung PPM die neu gewonnenen Erkenntnisse ebenfalls genutzt werden.
.