Neulich auf einer Grillparty: "Wir beraten und vermitteln agile Methoden." - "Ach ja, schon mal gehört. Das mit den Klebezettel, und ein paar Leute die im Kreis rum stehen und quatschen. Macht man in der Software-Entwicklung, aber sonst?"
Nun, natürlich sind agile Methoden mehr als das. Viel mehr. Vor allem aber haben agile Methoden Konsequenzen, die bis weit in das Privatleben derjenigen hinein reichen, die sich die Philosophie zu eigen gemacht haben. Man kann einfach nicht mehr anders, und plötzlich merkt man, dass man sogar im Privaten nach agilen Prinzipien plant.
So ergab es sich kürzlich, dass wir zu Hause einen ambitionierteren Grillabend planten. Die Grill-Rezeptbücher des Must-Have-Grillherstellers waren gesichtet und die in Frage kommenden Rezepte mit – natürlich – kleinen Klebezetteln markiert. Da wir ein wenig angeben wollten und noch dazu Vegetarier unter den Gästen waren, kamen ein paar Rezepte zusammen, Burger mit und ohne Fleisch, Salate mit mehr oder weniger gegrillten Zutaten und Grill-Gemüse.
Die Zutatenliste war noch recht schnell zusammengestellt, aber wie nun am Tag selbst den Überblick behalten? Wie alles rechtzeitig vorbereiten, wenn der Halloumi vorab möglichst genau 30 Minuten in der Marinade ziehen soll, wenn der Salat weder trocken noch wässrig, das Grillgemüse nicht eiskalt und vor allem anderen die Burger nicht erst am späten Abend fertig werden sollen?
Die Lösung bestand, wer würde es erraten, aus Klebezetteln: jeweils ein Rezepttitel, wichtigste Zutaten, sowie Grilldauer. Und dann: Auf jedem Zettel, gut sichtbar in den unteren beiden Ecken, zwei Nummerierungen. Links die für die Vorbereitung: Zuerst die Patties für den gefüllten Burger vorbereiten, danach die Bohnen putzen und schnippeln und drittens den grünen Salat vorbereiten und die zu grillenden Zwiebeln in Ringe schneiden. Und so weiter und so fort.
Und rechts auf den Klebezetteln dann die Reihenfolge für den Grillmeister: zuerst die Zwiebeln und die Paprika für den Salat, dann schon mal die Burger-Brötchen anrösten, später die Bohnen und zum Schluss die Burger selbst, erst die vegetarischen, dann die mit Fleisch.
So hatten wir alles im Blick und konnten in der Eile der Aktion ganz einfach sortieren: Am Nachmittag der linken Nummerierung nach die Vorbereitung abhaken, irgendwann den Grill anheizen (zugegeben, dafür hatten wir keinen Klebezettel) und dann auch hier, mit Blick auf die rechten Zahlen, eine Zutat nach der anderen auf dem Grill platzieren - alles schön der Reihenfolge nach, der Planung sei Dank.
Schön. Einmal etwas angegeben, leckere Sachen gegrillt und auch noch total spießig alles vorgeplant. Und Klebezettel, ja, haben wir kapiert, sind praktisch. So what?
Nun, es geht hier nicht nur ums Grillen und nicht einmal um Klebezettel. Natürlich geht es auch nicht um agile Methoden im eigentlichen und gesamten Sinne. Grillen ist, bei allen Ambitionen, dann doch weit weniger komplex als die Entwicklung von digitalen Produkten, für die wir agile Methoden gemeinhin propagieren.
Aber es macht klar, woran sich agile Methoden so erfolgreich bedienen: Aufgaben klein schneiden, übersichtlich machen und sortieren, nach den Kriterien, die man jeweils braucht. Und wenn nötig, eben auch nach mehreren Kriterien, die sich je nach Perspektive oder Zeitpunkt ändern. Agiles Taskmanagement, so einfach, so effektiv.
Rufen Sie uns an: 030 – 555 74 70 0
Toller Artikel, entspricht voll meiner Denkweise. Es zeigt einfach, dass agile Prinzipien einen Kulturwandel voraussetzen und nicht nur ein Methodenset für Softwareentwicklung sind. Eine kleine Sache ist mir aber aufgefallen: Der Satz "... irgendwann den Grill anheizen (zugegeben, dafür hatten wir keinen Klebezettel)". Meines Erachtens ist es genau richtig, dass ihr dafür keinen Klebezettel hattet. Im Sinne von User Stories hat der Enduser (der Essende) nichts vom Grill anmachen. Insofern ist das Grillanmachen doch im ersten Rezept enthalten und bei allen weiteren fällt der Schritt eben weg. Viel mehr wäre ein Zettel für das Grillanmachen ein typischerweise fälschlich gemachter technischer Schnitt der Anforderungen (sowas wie "Datenbankanforderungen"). Warum ich so darauf herumreite: In der Praxis fällt man genau an dieser Stelle häufig raus aus dem User-Story-Schema und schreibt eben solche Tasks wie "Datenbankanforderungen". Das macht auch irgendwie Sinn, schließlich ist es eine eigene Aufgabe, die Zeit kostet und Voraussetzung für alle weiteren ist. Ich frage mich nur immer, wie man den Spagat schafft, auf der einen Seite User Stories, auf der anderen Seite diese völlig abhängige und nicht testbare Anforderung zu schreiben, die dann doch wieder eine Klammer um alle Anforderungen bildet...