ZA018 - Agile Methoden in der Praxis
02.07.2012 
1 Stunde 7 Minuten
Zusammenfassung
Eine spannende Episode mit Michael Mahlberg, dem absoluten Spezialisten zu agilen Methoden. Wir unterhalten uns über die Entstehung der agilen Methoden und ihre Anwendung heute in der Praxis. Eine ausgesprochen tolles Gespräch.
Wir hätten auch drei Stunden weiter quatschen können, um es abzukürzen planen noch eine weitere Episode zusammen.
Geben Sie uns Feedback: Was sind Ihre Erfahrungen? Wie arbeiten Sie mit agilen Methoden und wann war es hilfreich? Auch immer her mit Ihren Fragen, wir werden Sie dann besprechen.
Der Inhalt dieser Episode:
- Warum agile Methoden?
- Verschiedene Ebenen der Agilen Methoden
- Einführung agiler Methoden
- Manager verstehen agile Methoden falsch!
- Sind agile Methoden für jeden nutzbar?
- Agile Methoden und Kommunikation
Anmerkungen zur Episode:
- Kleiner Versprecher von Michael: er hat die agile-cologne nicht gegründet, sondern übernommen…
- Ich wollte noch mal nachschauen: Toyota hat nicht 1920 sondern erst 1943 mit Kanban begonnen. Was immer noch unglaubliche 69 Jahre sind…
Themen: Agiles Manifest, Natoveröffentlichung, V-Model XT, Methode M, DOD-STD-2167A, Winston Royce, IBM-Modell in den 70gern, Agile Pyramide bzw. Dreieck, Xtreme Programming, Scrum, Refactoring, Scrum in 5 Minuten, Scrum? Das ist doch das mit den Kreisen!, Kanban, SW-Kanban, Kanban-Simulation, Kaizen, Kanban bei Toyota, Lean SW-Development, Tom und Mary Popendik, Kegel der Unsicherheit, Clausewitz, Agiles Testen, Space Shuttle Software (STS1), Last Minutes Changes bei Airbus, Test Driven Development, Kent Beck: Extreme Programming* und Extreme Programming Explained, Jutta Eckstein: Agile Softwareentwicklung in großen Projekten*
Michael Mahlberg im Netz
- Sein Blog Shu Ha Ri
- Sein Blog agile aspects
- Seine Weltreise als Software Craftsmanship
- Michael Mahlberg bei Xing, Twitter und LinkedIn
- Seine Präsentationen bei Slideshare
- Seine Firma The Consulting Guilde
Abonnieren Sie den kostenlosen Podcast und erhalten Sie zukünftig alle neuen Episoden direkt auf Ihr Smartphone:
- Klicken Sie hier um in iTunes zu abonnieren
- Klicken Sie hier um über RSS zu abonnieren (non-iTunes feed)
*Affiliate Links
Hallo Maik,
wieder einmal ein interessanter Beitrag. Danke an Dich und auch an Michael für den schönen und lebendigen Über- und Weitblick.
Insbesondere diese Aspekte möchte ich unterstreichen bzw. erwähnen:
1. Der "Agile- oder Scrum-Reflex"
Hier begegnet mir auch häufig der Impetus den Einsatz von "Agile oder Scrum oder … als Allheil-Mittel" für Projekt-Probleme zu fordern – ohne entsprechende Analysen, nur weil es in letzter Zeit "en vogue" ist.
Möglicherweise ist "etwas" ganz anderes die richtige Antwort auf diese Probleme – oder eben doch Scrum, oder auch Kanban, oder XP in Kombination mit Scrum, oder… – auf welcher Ebene auch immer
(s.a. "Options-los – Scrum – Produkt, Nutzen oder Mehr-Wert ?" [1] oder "Projekt- oder Produkt-Entwicklungen – Erfolgreich mit agilen Methoden" [2]).
Hier wird häufig – gefühlt in letzter Zeit immer häufiger – der zweite vor dem ersten Schritt getan.
Bei einigen Managern scheint es "chick" zu sein angeben zu können: "wir scrum'men jettzt auch".
2. Nicht jeder Mitarbeiter ist "Agile" -Kompatibel
Genau diese Erfahrung muss aber – ehrlicherweise(!) – kommuniziert werden. Leider erlebe ich hier immer wieder, dass einige Mitarbeiter geradezu genötigt werden "agil" zu sein.
Ein "Agile Mindset" entsteht aber nicht auf Anordnung… solche Organisation sind selbst noch weit, weit weg von diesem Mindset.
3. "agiler Werkzeug-Kasten"
Die Idee des "agilen Werkzeugkastens" ist sehr charmant (und benutzte ich selbst gern [2]):
für die Situation A nehme ich dies, für B das, und für C dann jenes – und für D, E und F "machen wir es wie immer".
Vorsicht, hier ist man schnell – zu schnell – z.B. bei "Scrum, but"!
(und dann auch noch mit dem Bild des "agilen Werkzeugkastens" legitimiert)
Das funktioniert auf lange Sicht nur ganz, ganz bedingt – und dann auch nur allerhöchsten sub-optimal.
Sicher, man kann z.B. bei Software-Kanban mit den Elementen Visualisierung, WIP-Limits, Messung des Flows und Service-Klasses bereits spür- und messbar Verbesserungen erzielen.
Wenn es aber zu einer Unternehmensweiten Change- und Kaizen-Inititative kommen soll, trifft man sehr schnell an die Grenzen einer "Agile Transition" – bei Kaizen genauso wie bei Scrum oder XP.
Hier muss(!) das Management ganz unmittelbar (oder zuerst?) in's Boot geholt werden. Sonst kommt es ganz schnell z.B. zu:
“Agile” macht ja nur Probleme, oder…Transparenz muss gewollt sein [3]
4. Scrum Framework ist wie ein Interface (o. eine Abstract Class) …
… und muss /nur/ noch durch eine spezifische Implementierung umgesetzt werden (die typische Software-Entwickler-Sicht).
Auch hier wird gern mit "spezifischer Implementierung" der Weg für z.B. "Scrum, but" und "bei uns läuft das aber so" legitimiert (s.a. "Manifesto for Half-Arsed Agile Software Development" [4])
1. Interfaces müssen vollständig implementiert werden (ein "cherry picking" funktioniert nicht)
2. vollständig könnte auch bedeuten, dass einige Methoden nur als "Dummy" oder leerer Adapter implementiert werden; dann funktioniert das "Ganze aber maximal nur in Teilen"
3. vollständig kann nur heissen, dass der "Vertrag" des Interfaces erfüllt wird;
dies bedeutet "syntaktisch" und "semantisch" !!!
(und jetzt bitte noch den Bogen zu Scrum spannen ;-)
…und so weiter und so fort…
Eine für die Mittagspause viel zu lange, dennoch insgesamt zu kurze Antwort. Es gäbe noch so viele weitere Punkte…
Nochmals "Danke!" an euch beide und
CU
Boeffi – boeffi.net
[1] http://boeffi.net/blog/scrum-produkt-nutzen-oder-…
[2] http://boeffi.net/blog/agile-supervision/
[3] http://boeffi.net/scrum/agile-macht-ja-nur-proble…
[4] http://www.halfarsedagilemanifesto.org/
Hallo Boeffi,
danke dir für dein super Input, Ich kann dir absolut folgen.
Ich glaube, wir müssen mal eine gemeinsame Episode fixieren. Dann können wir die Punkte für die Hörer direkt im Gespräch vertiefen! Michael hatte es ja schon angeregt :-)
Schönen Gruß aus Köln,
Maik