Auf der WJAX 2010 habe ich einen Vortrag mit dem Titel „Der agile Machiavelli oder wie kippe ich ein agiles Projekt?“ gehalten. Da meine Folien sehr minimalistisch waren und man auch nach fast 10 Jahren agilem Manifest noch überraschend viele „Worst Practices“ in agilen Projekten beobachten kann, hatte ich den Zuhörern versprochen, dass ich das Thema hier im codecentric-Blog noch einmal aufnehmen wollte.
Okay, es hat etwas länger gedauert, bis ich jetzt endlich dazu gekommen bin, damit zu beginnen und anstatt mich mit dem Schnee oder dem Weihnachtsstress herauszureden, gibt es dafür erst einmal ein dickes „Sorry!“ von mir an alle, die schon länger darauf gewartet haben und vielleicht bereits mehrfach hier vorbeigeschaut haben.
In dem Vortrag ging es um „Agile Worst Practices“. Eine Worst Practice ist das Gegenteil einer Best Practice, d.h. es geht um Praktiken, die sich im agilen Umfeld als schlecht erwiesen haben. Das reicht von Praktiken, die die Produktivität ungünstig beeinflussen bis hin zu absoluten „Killern“, die eine sinnvolle agile Arbeit komplett unmöglich machen.
Eine solche Worst Practice kann man jetzt unter verschiedenen Gesichtspunkten betrachten und verwenden. Man kann sie einfach zu verstehen versuchen und aufpassen, dass man sie nicht in seinen eigenen Projekten verwendet. Bei einigen dieser Practices ist es nämlich so, dass sie gar nicht so offensichtlich schlecht sind, sondern dass sich ihr destruktives Potential erst bei genauerem Hinsehen offenbart.
Eine andere Verwendungsweise ist – wie ironisch im Untertitel geschrieben – die Anwendung der Practices mit dem Ziel, das jeweilige Projekt zu kippen. Um jetzt evtl. Missverständnissen vorzubeugen: Das mag zwar aus persönlichen oder machtpolitischen Gründen in bestimmten Situationen opportun erscheinen, aber trotz des gewählten Untertitels war der Vortrag natürlich kein Aufruf zu solch einem aus rein egoistischen Motiven getriebenen Vorgehen.
Umgekehrt kann man sich aber auch überlegen, was man gegen eine solche Practice unternimmt, wenn man mit ihr in einem Projekt konfrontiert wird, d.h. wie man sie „unschädlich“ macht.
Diese verschiedenen Betrachtungs- und Verwendungsweisen spiegeln sich in der Beschreibung der einzelnen Worst Practices wider. Zunächst einmal werde ich die Practice möglichst einprägsam benennen und ihre Funktionsweise beschreiben. Danach werde ich die Konsequenzen darstellen, d.h. welche Wirkung hat die Practice. Abgeschlossen wird die Beschreibung von möglichen Maßnahmen, um der Practice entgegenzuwirken.
Alle Practices entstammen übrigens realen Projekterfahrungen. Ich hatte unter meinen Kollegen – allesamt mit reichlich agiler Projekterfahrung ausgestattet – einmal herumgefragt, welche Worst Practices ihnen denn im Laufe ihrer vielfältigen Projekte begegnet seien und es sprudelte nur so. Auf diese Weise entstand eine Liste von ca. 80 Worst Practices und auch nach Bereinigung der Redundanzen blieb eine beindruckende Sammlung übrig. Das zeigt aus meiner Sicht, wie wichtig und praxisnah das Thema immer noch ist.
Natürlich ist diese Sammlung nicht vollständig oder deckt das gesamte Themenspektrum gleichmäßig ab, aber das ist auch gar nicht mein Ziel. Mein Ziel ist es, eine Menge lebensnahe, dem realen Projektgeschäft entstammende Worst Practices vorzustellen und so dafür zu sensibilisieren. Es gibt auch weitere Quellen, die sich dieses Themas annehmen. Ein paar Referenzen werde ich noch am Ende der Blog-Serie nennen.
Um die ganzen hier beschriebenen Practices ein wenig zu strukturieren, sind sie – soweit möglich – nach Rollen geordnet. Primär werden hier die Scrum Rollen verwendet, d.h. Product Owner, Scrum Master und Team, aber auch eine Reihe umgebender Rollen wie Kunde, Manager, User sowie der Agilitäts-Berater bzw. Coach.
So, und damit das jetzt nicht nur ein „Teaser Post“ wird, hier noch die erste Worst Practice. Ich freue mich auf Eure Kommentare, Anmerkungen und Ergänzungen, aber auch über Eure eigenen Erfahrungen.
Beginnen wir mit den Team Practices: Bevor wir mit dem ausgestreckten Finger auf andere Leute zeigen, ist es zunächst sicherlich sinnvoll zu schauen, welche Worst Practices uns als Team-Mitgliedern zur Verfügung stehen. Viele dieser Practices sind dabei nicht exklusiv auf das Team beschränkt, sondern können auch von anderen Personen angewendet werden.
Team Worst Practice #1: Mein Wissen gehört mir
Beschreibung: Anstatt mein Wissen mit anderen Team-Mitgliedern zu teilen, halte ich es sorgfältig unter Verschluss. Wenn es Aufgaben auf meinem Spezialgebiet gibt, schnappe ich sie mir sofort und passe dabei auf, dass kein anderer versteht, wie ich das gelöst habe. Meine Position im Unternehmen festige ich weiter, indem ich geeignete neue Themen annektiere, bei denen sich noch niemand auskennt und so weitere Wissensmonopole auf mir vereine. Bei all dem Konkurrenzdruck im Unternehmen und der Gefahr durch Outsourcing/Offshoring muss ich ja sehen, wo ich bleibe und meinen Arbeitsplatz sichern.
Konsequenz: Es entsteht eine Wissensinsel. Eine vernünftige Selbstorganisation ist nicht mehr möglich und auch die freie Priorisierung von Tasks ist nicht mehr möglich. Alles muss rund um die „kritische Ressource“ organisiert werden und ist der Mitarbeiter mal nicht da, ist häufig gleich die ganze Iteration gefährdet. Typischerweise ist der Mitarbeiter chronisch überbucht und wird aufgrund seines Spezialwissens zwischen mehreren Projekten aufgeteilt, was eine vernünftige Team-Arbeit in den einzelnen Projekten deutlich erschwert.
Maßnahmen: Wissensinseln sind schwer zu bekämpfen, weil sie zunächst einmal für alle bequem sind. Man hat sowieso mehr als genug zu tun und ist froh, dass da jemand ist, der sich um Aufgabe X kümmern kann und man sich selber nicht auch noch um das (neue) Thema kümmern muss. Die damit verbundenen Probleme versteht man meistens erst, wenn es zu spät ist.
Deshalb ist es wichtig, die Probleme mit Wissensinseln frühzeitig zu erklären (Verständnis für das Problem schaffen). Hier ist insbesondere der Scrum Master gefragt, für Transparenz zu sorgen und die möglichen Konsequenzen aufzuzeigen. Neben der Transparenz sollte er auch noch darauf hinwirken, dass Maßnahmen ergriffen werden, die solchen Wissensinseln entgegenwirken. Solche Maßnahmen könnten z.B. sein:
- Aufstellen einer Team-Regel, dass jedes Thema von mindestens 2, besser 3 Personen verstanden sein muss.
- Pair Programming für kritische Themen zur Regel machen.
- Wenn der Scrum Master eine Wissensinsel bemerkt, auf die das Team nicht reagiert, kann er von den Team-Mitgliedern Maßnahmen einfordern, wie sie einen evtl. Ausfall von dem Mitarbeiter kompensieren wollen. Dabei kann er sie auf ihr Sprint Commitment erinnern (klingt erst einmal nicht nett, hilft aber sehr gut, die inhärente „Es wird schon gutgehen“-Attitüde zu durchbrechen).
Das einfach mal als ein paar Ideen. Wissensinseln sind ein sehr schwieriges Thema, auch in traditionellen Projekten und es gibt keine echten Patentrezepte. Hat man sie aber erst einmal als Problem erkannt und dies für alle Beteiligten transparent gemacht, ist der erste wichtige Schritt getan.
So, dieses war der erste Streich … den nächsten Post in dieser Serie findet Ihr hier .
PS: Feedback, Ergänzungen, eigene Erfahrungen, usw. sind immer herzlich willkommen!
War dieser Beitrag hilfreich?
Weitere Beiträge
von Uwe Friedrichsen
16.10.2018 Dein Job bei codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
Weitere Artikel in diesem Themenbereich
Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog-Autor*in
Uwe Friedrichsen
CTO
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.