Die Geschichte und der Kontext, die der agilen Softwareentwicklung Leben eingehaucht haben.
Vor Agile wurde die meiste Software mit der „Wasserfall"-Methode entwickelt: alle Anforderungen im Voraus sammeln, alles entwerfen, alles bauen und dann am Ende testen. Das funktionierte bei Brücken und Gebäuden, aber Software ist anders.
Das Problem? Bis zur Auslieferung hatten sich die Anforderungen geändert. Nutzer wussten nicht, was sie wollten, bis sie es sahen. Und Fehler am Ende zu finden bedeutete teure Nacharbeit.
Die Statistiken waren brutal:
Die grundlegende Erkenntnis
Softwareentwicklung ist eher wie wissenschaftliche Forschung als wie Bauwesen. Man lernt unterwegs, und der Plan muss sich an neues Wissen anpassen.
Im Jahr 2001 trafen sich siebzehn Softwareentwickler in einem Skigebiet in Utah. Sie kamen aus unterschiedlichen Bereichen – Extreme Programming, Scrum, Crystal und andere – teilten aber eine gemeinsame Frustration über schwergewichtige Prozesse.
Was sie schufen, war kein neuer Prozess. Es war eine Reihe von Werten und Prinzipien, die jeden Prozess leiten konnten. Das Agile Manifest war bewusst kurz: vier Werte und zwölf Prinzipien.
Die zentrale Erkenntnis: Nutze Veränderung als Wettbewerbsvorteil, bekämpfe sie nicht.
Agile basiert auf Empirie – der Idee, dass Wissen aus Erfahrung kommt und Entscheidungen auf Grundlage dessen getroffen werden, was beobachtet wird.
Drei Säulen stützen die Empirie:
Transparenz — Jeder kann sehen, was wirklich passiert. Kein versteckter Status, keine Überraschungen.
Überprüfung — Untersuche regelmäßig die Arbeit und wie das Team zusammenarbeitet.
Anpassung — Wenn etwas nicht funktioniert, ändere es. Warte nicht auf Erlaubnis.
Das unterscheidet sich grundlegend vom traditionellen Projektmanagement, das davon ausgeht, dass man alles im Voraus planen kann, wenn man sich nur genug Mühe gibt.