Agile Methoden sind heutzutage in vielen Bereichen im Mainstream angekommen, allen voran in der Softwareentwicklung. Doch was bedeutet „agil“ eigentlich und wie hilft es, effizienter und flexibler zu arbeiten? Dieser Beitrag dreht sich darum, wie agile Arbeitsweisen den Entwicklungsprozess optimieren, welche agilen Strukturen sich etabliert haben und wo ihr auf Stolpersteine achten solltet.
Was ist agile Softwareentwicklung?
Gemäss Wörterbuch bedeutet Agil «von grosser Beweglichkeit zeugend; regsam und wendig». In diesem Zusammenhang kann man also von einer flexiblen, schnellen Anpassung an Veränderungen reden. Um dies zu bewerkstelligen, wird eine iterative Vorgehensweise verfolgt. Anders als bei klassischen Praktiken wie der Wasserfallmethode, wo ein starrer Plan durchgezogen wird, setzt der agile Ansatz auf kurze Zyklen, sogenannte Sprints, bei denen ständig Feedback eingeholt wird und Anpassungen vorgenommen werden. Das Ziel der agilen Softwareentwicklung ist es, regelmässig funktionierenden Softwarecode zu liefern.
Wie optimieren agile Arbeitsweisen den Entwicklungsprozess?
Da die Entwicklung in kürzeren Iterationen erfolgt, kann schnell auf Veränderungen der Anforderungen reagiert werden, beispielsweise direkt im nachfolgenden Sprint. Somit wird sichergestellt, dass die Bedürfnisse der Kunden zeitnah und kontinuierlich erfüllt werden. Auch können Fehler prompt behoben werden und im besten Fall merken die Endbenutzer nach jedem Sprint direkt eine Verbesserung der Software. Solche positiven Erfahrungen erhöhen die Kundenzufriedenheit. Im Team fördert es die Kommunikation und ich merke, wie es meine Motivation steigert: Weil die Arbeit in kompakte Pakete aufgeteilt ist, können Ergebnisse relativ zeitnah geliefert werden. Ich denke jeder Mensch mag es, eine Aufgabe abzuhaken.
Beispiele agiler Strukturen
- Scrum hat seinen Ursprung in der Softwareentwicklung, wird mittlerweile aber auch für andere Projekte verwendet. Grundsätzlich werden Teams in der Grösse von 3 bis 9 Personen definiert. Innerhalb der Teams werden Rollen verteilt. Der Scrum Master ist für die Organisation der Meetings zuständig und kümmert sich darum, dass das Team effizient arbeiten kann. Er hält üblicherweise nicht gleichzeitig die Rolle des Projektleiters inne. Der Product Owner vertritt die Interessen der Kunden. Er legt das Backlog fest und definiert somit, in welcher Reihenfolge die Arbeiten erledigt werden. Der Rest des Scrum Teams ist für die Planung und Arbeitsaufteilung selbst verantwortlich.
- Kanban ist eine Methode, welche Teams dabei unterstützt, die zu erledigende Arbeit effizient aufzuteilen. Mithilfe eines Kanban-Boards werden die Arbeitspakete visualisiert, wodurch alle beteiligten ihr Arbeitspensum und ihre Arbeitsabläufe im Blick haben. Das Board ist in Spalten organisiert, welche üblicherweise jeweils für einen Arbeitsschritt stehen, beispielsweise «To do», «In Progress» und «Done». Kanban eignet sich hervorragend im Zusammenspiel mit Scrum.
Stolpersteine
Das Wort ‘Agil’ kann meiner Meinung nach falsch interpretiert werden. Es ist beispielsweise nicht förderlich, mitten im Sprint die definierten Arbeitspakete anzupassen. Prioritäten, Anforderungen und Ziele sollten beim Sprint-Meeting verbindlich definiert werden, ansonsten geht schnell die Übersicht verloren und die Effizienz leidet. Ein weiteres Problem kann bei der Produktdokumentation entstehen: Da sich Funktionalitäten von Sprint zu Sprint weiterentwickeln und sich Anforderungen verändern können, sind Dokumentationen schnell veraltet.
Die richtige Balance zwischen Kommunikation und Arbeit ist der Schlüssel zum Erfolg
Die Kommunikation zwischen Entwicklern, Stakeholdern und Endnutzern ist ein zentraler Bestandteil von agilen Methoden. Tägliche «Stand-up» Meetings und ein- oder zweiwöchentliche Sprint-Meetings sorgen dafür, dass alle Beteiligten am selben Strang ziehen und senken das Risiko von Missverständnissen. Leider wird damit auch einiges an Overhead generiert. Wer in einem Meeting sitzt kann nicht gleichzeitig arbeiten. Aus eigener Erfahrung sind tägliche «Stand-up» Meetings ein unnötiger Zeitfresser – und in einer Woche kann aufgrund der relativ kleinen Grösse unseres Teams nicht genügend bearbeitet werden, um ein Sprint-Meeting zu rechtfertigen. Daher erachte ich es als wichtig, die Herangehensweise der Kommunikation – wie viele Meetings braucht es wirklich und welche kann man streichen – kontinuierlich zu evaluieren. Kurz: Auch Meetings sollten agil angegangen werden.
