Kommentierte Links (IX)

Grafik: Pixabay / Geralt - Lizenz

• Harvard Business Review: The New New Product Development Game

Bis heute kommt es immer wieder vor, dass ich auf meinen Projekten Manager treffe, die der Meinung sind, dass Scrum und ähnliche Methoden "neumodische Erscheinungen" wären, die sich "erstmal bewähren müssen". Ich weise diese Leute dann in der Regel auf diesen Artikel von Hirotaka Takeuchi und Ikujiro Nonaka hin, den die beiden vor ziemlich genau 30 Jahren im Harvard Business Review veröffentlicht haben (Ausgabe Januar 1986). In ihm wurde der Begriff Scrum zum ersten mal für die Beschreibung von Arbeitsprozessen benutzt und in ihm finden sich bereits die grundlegenden Ideen, auf denen agile Methoden heute beruhen: Built-in instability (heute würde man sagen Agilität), Self-organizing project teams, Overlapping development phases, “Multilearning”, Subtle control, Organizational transfer of learning. Eine erstaunlich lange Geschichte für eine neumodische Erscheinung.

• DZone: 38 Scrum Master Interview Questions To Avoid Imposters

Ich habe es selber schon mehrfach schmerzlich erleben müssen - gute Scrum Master zu finden ist schwer, und immer wieder werden Stellen an völlig ungeeignete Personen vergeben (nicht zuletzt aufgrund von vom Thema überforderten Recruitern und Personalern). Dieser Interview-Leitfaden hier hätte einigen Projekten die ich kenne einen Großteil ihrer Probleme von vornherein erspart, da er die falschen Kandidaten sicher ausgesiebt hätte. Natürlich gibt es aber auch einen Haken: Stefan Wolpers, der Verfasser der 38 Fragen, liefert nämlich die Antworten nicht mit. Ohne Kenntnis und Verständnis der Methode kann der Interviewer also nur bedingt etwas mit ihnen anfangen. Nochmal umgekehrt betrachtet ist das aber wieder gut, den wer keine Ahnung von Scrum hat sollte auch keine Einstellungsinterviews mit Scrum Mastern führen.

• Dave Smith: A developer’s guide to interviewing

Das Ganze von der anderen Seite betrachtet. In einem Job-Interview sollten nicht nur die Vertreter der einstellenden Firma Fragen stellen, sondern auch derjenige der sich für den Job interessiert - und die Fragen von Dave Smith würden einige Firmen die ich kenne nicht gut dastehen lassen. Was mir besonders gefällt: er fragt nicht nach der eingesetzten Methode (behaupten, dass man Scrum macht kann jeder) sondern versucht aus Informationen über Arbeitsabläufe und Standards Rückschlüsse zu ziehen. Woher wissen die Angestellten woran sie arbeiten müssen? Wie halten sie es mit Unit Tests? Gibt es Continuous Integration? Wie ist der Bugfixing-Prozess? Und so weiter. Ein paar dieser Fragen nehme ich sicher in mein nächstes Interview mit.

• Joshua Partogi: Scrum does not work here in Asia

Geschichten wie die von Joshua Partogi habe ich bereits von einigen Scrum Mastern und Coaches gehört, die in Süd- oder Ostasien unterwegs waren. Scrum wird als reine Softwareentwicklungs-Methodik gesehen, die notwendigen Änderungen im restlichen Unternehmen werden dagegen ignoriert oder verleugnet. Dazu kommen Hierarchie-Gläubigkeit, die Unfähigkeit Konflikte sachlich (oder überhaupt) auszutragen, zwanghafter Konformismus und die Verwechselung von billiger Personalbeschaffung mit billiger Softwareentwicklung. Das Ergebnis ist Cargo Cult, also etwas das irgendwie nach Scrum aussieht aber nichtmal in Ansätzen so funktioniert. Der aus meiner Sicht bemerkenswerteste Aspekt ist Partogi aber gar nicht bewusst: In vielen deutschen (und generell westlichen) Großunternehmen findet man praktisch alles was er sagt genauso wieder, weshalb die Scrum-Einführungen auch dort regelmässig kläglich scheitern. Manche Verhaltensmuster sind eben universeller als man denkt.

• Grant Amons: Ditching Scrum for Kanban — The best decision we’ve made as a team

Die Überschrift sagt eigentlich bereits alles: ein Team wechselt von Scrum zu Kanban und wird glücklich. Obwohl die Scrum-Einführung vieles verbessert hatte brachte sie nämlich auch Unzufriedenheit mit sich, da regelmässig Sprint-Ziele verfehlt wurden und Aufwandsschätzungen sich als falsch herausstellten. Nach dem Wechsel gab es diese Probleme nicht mehr und alle lebten happily ever after. Spontan würden mir dazu zwei Gedanken in den Sinn kommen: Erstens - hat dieses unzufriedene Team wirklich vorher Scrum gemacht, oder war bereits die Umsetzung falsch? (Besser ausformuliert findet sich diese Frage bei Hannah Kane). Und zweitens - ist das was dort jetzt gemacht wird wirklich Kanban? Beschrieben wird es als Scrum ohne feste Sprints und ohne Retrospektive - müsste es da nicht mehr geben, etwa ein Work in Progress-Limit, einen Eliminate Waste-Grundsatz oder einen Kaizen-Prozess? Unabhängig davon kann es aber durchaus sein, dass Kanban für manche Teams besser funktioniert als Scrum, allerdings nennt Amons auch eine sehr wichtige Voraussetzung für den Wechsel: bevor man sich entscheidet Scrum wieder abzuschaffen sollte man es zuerst verstanden haben, sonst weiss man nicht was man tut (siehe dazu auch: Shuhari und Harikiri).