Letzte Änderung am 11. Dezember 2022 by Christoph Jüngling
“Agile Methoden” sind seit einiger Zeit in aller Munde, man könnte es fast schon einen “Hype” nennen. Dennoch ist es alles andere als eine bloße Modeerscheinung; richtig angewandt helfen agile Vorgehensmodelle, klassische Fehler zu vermeiden, ohne neue zu machen.
Ein entscheidendes Problem sehe ich jedoch dabei: Agile Methoden sind noch nicht in den Köpfen aller Entscheider angekommen. Und manchmal habe ich den Eindruck, mich wie Don Quichotte bei seinem sprichwörtlichen Kampf gegen Windmühlenflügel wiederzufinden. Doch warum ist das so? Was unterscheidet die agilen Methoden von den klassischen?
In diesem Artikel
Retrospektive
Seit ich mich mit agilen Techniken beschäftige, insbesondere Scrum und Kanban, frage ich mich, wie ich diese Methodiken so bei meinen Kunden einführen kann, dass ich nicht von anderen Abteilungen und Chefs abhängig bin, aber trotzdem agil arbeiten kann (Sprint, Velocity, Time-Boxed, etc.). Am kommenden Montag (6.10.2014) wird sich der Agile-Monday Kassel unter anderem mit dieser Frage beschäftigen. Grund genug, sich im Vorfeld zu überlegen, wie ich es tun würde. Zu Beginn soll eine Retrospektive helfen, mir darüber klar zu werden, was ich bisher getan habe. Ich werde dazu die leicht abgewandelten Daily-Scrum-Fragen verwenden.
Was habe ich bisher getan?
Es fing alles damit an, dass ich im Zuge eines längeren Bugfixings einen ausgedruckten Zettel an die Wand hängte: “Bitte haben Sie etwas Geduld, wir arbeiten gerade an Bug 521” Einige Kollegen fanden das lustig, aber immerhin wurde es wahrgenommen. Erst kamen weitere Bugnummern handschriftlich hinzu. Später dann fanden sich drunter weitere Zettel, bis ich schließlich damit begann, den Schrank hinter meinem Schreibtisch mit kleinen gelben Zetteln zu pflastern. Die Türen waren die Spalten, und das war der Beginn meines ersten persönlichen Scrum- oder Kanban-Boards. Einfach, leicht einzurichten, kein technischer Overkill, eben: agil.
Damit habe ich einfach eine Zeit lang gearbeitet. Einige Kollegen interessierten sich für die dahinterliegende Methodik, die ich ihnen natürlich bereitwillig erklärt habe. Einer hat spontan mit einer abgespeckten Version angefangen.
Später wünschte meine Entwicklergruppe, es im Team mit Scrum zu versuchen. Leider zeigte die Velocity über 1,5 Jahren hinweg immer noch starke Schwankungen.
Was hindert mich an meinem Vorhaben?
Ein Punkt, der schief gelaufen ist, war sicherlich die unvermeidliche Tatsache, dass auch Benutzerbetreuung zu unseren Aufgaben gehörte. Dann zu sagen “schreib einen Bugreport, wir kümmern uns in zwei Wochen (d.h. im nächsten Sprint) darum” ist natürlich inakzeptabel.
Vielleicht fehlte am Anfang einfach die Erkenntnis, dass unser Projekt eigentlich keines war. Wir haben nichts Neues entwickelt, sondern ein bestehendes System gepflegt, was zum Teil aus dem Beheben von Bugs und dem Entwickeln neuer Features bestand. Daher wäre Kanban als Methode vermutlich geeigneter gewesen. Dennoch hat uns Scrum gezeigt, dass man mit wenig Planung bereits Vorteile erlangen kann.
Was will ich als nächstes tun?
Ich werde das aktuelle Kanban-Board weiterführen. Die Gruppe hat zum Teil sowieso andere Aufgaben bekommen, so dass eine Fortführung mit der alten Velocity ohnehin nicht mehr in Frage käme.
Vielleicht steht uns auch eine komplette Neuentwicklung ins Haus. Dann wird es interessant, denn in einem wenig agilen Umfeld innerhalb der Gruppe trotzdem agil zu arbeiten, das wird eine Herausforderung.
Daher freue ich mich auf den nächsten Agile Monday. Am 6. Oktober 2014 um 19 Uhr ist es soweit.
Eigentlich sollte dieser Beitrag zur Blogparade von Patrick Koglin schon vor ein paar Monaten “Zusammenarbeiten und arbeiten lassen – Was ist agil? Wie sieht das aus?” erscheinen. Aber besser spät als nie, oder?
Neueste Kommentare