Kommentierte Links (XIV)

Grafik: Pixabay / Geralt - Lizenz

• Haufe.de: Wie Unternehmen agil werden

Den Namen dieses Artikels muss man nicht beachten, darüber wie Unternehmen agil werden wird man hier nicht viel finden. Wesentlich interessanter sind dagegen zwei an dieser Stelle veröffentlichte Zahlen aus der von Haufe durchgeführten Studie "Agilität in deutschen Unternehmen". Denen zufolge halten zwar 70 Prozent der Führungskräfte ihr Unternehmen für agil, von den Mitarbeitern sehen das aber nur 31 Prozent so. Diese Ergebnisse decken sich in etwa mit dem was ich auch angenommen hätte und was ich in verschiedenen Unternehmen bereits gesehen habe: die oberen Hierarchieebenen sind so weit weg von der tatsächlichen Arbeit, dass die blosse Existenz von Sprints oder User Stories sie an die eigene Agilität glauben lässt. Die unteren Dienstränge wissen es besser, werden aber nicht gehört oder ernstgenommen.

• Georg Meck: Wie wollen wir morgen arbeiten?

Zu den in vielen Firmen noch immer unterschätzten Voraussetzungen für agiles Arbeiten gehört die passende Architektur. Die klassischen Einzel- oder Doppelbüros sind im wahrsten Sinne des Wortes betonierte Kommunikationsbarrieren, verschlossene Türen sorgen für Intransparenz, Wohnzimmer-Arbeitsplätze mit Büropflanzen, Bildern und Festnetztelefonen befördern die Herausbildung von Unternehmensbewohnern. Neuartige Open Space-Büros wie in der in diesem Artikel vorgestellten neuen Siemens-Zentrale wirken dem entgegen. Wunder bewirken können sie nicht (einige der unagilsten Unternehmen die ich kennenlernen durfte residieren in luftigen Glaspalästen), aber alleine durch ihre Offenheit und Durchlässigkeit vereinfachen sie die Zusammenarbeit und bringen die Mitarbeiter zusammen. Das ist viel wert.

• Noah Lorang: Real-time dashboards considered harmful

  Was Noah Lorang da beschreibt kann ein echtes Problem sein: Wenn ein Team die falschen Kennzahlen auf den großen Wandmonitoren abbildet besteht die Gefahr, dass es in Aktionismus verfällt sobald diese zu schwanken beginnen. Dabei ist es grundsätzlich richtig, die richtigen KPIs zu monitoren und dafür zu sorgen, dass sie stabil bleiben. Die Kunst besteht darin, herauszufinden welches die richtigen sind. Einige gute Ansätze werden in dem Artikel genannt: längere Darstellungszeiträume, Interaktionsraten, relative statt absolute Werte und Focus auf hohe statt auf niedrige Abweichungen. Unwichtige Metriken werden dadurch weggefiltert und man sicher sein, dass die angezeigten Zahlen so bedeutsam sind, dass man auf Schwankungen schnell reagieren sollte.
  
  

• Adam Taylor: Why login isn’t the first thing you build

Ich gestehe: auch ich habe schon einmal einem Product Owner geraten, die Login-Funktion zum Thema seiner ersten User Story zu machen. Wenn man davon ausgeht, dass man möglichst früh ein Minimum Viable Product will, ist das aber sehr wahrscheinlich falsch. Nach den ersten Stories ist noch so gut wie kein Produkt marktreif und das muss es auch noch gar nicht sein. Es sollte aber bereits so weit sein, dass es dem Auftraggeber, dem Kunden oder einer Testgruppe vorführbar ist, und für diese Zwecke ist ein möglichst großer initialer Funktionsumfang wichtiger als ein vorgeschalteter Login. Dass der später noch gebaut werden muss steht bei den meisten Produkten außer Frage, aber als erstes Feature empfiehlt sich definitiv etwas mit größeren Aha-Effekt.

• Lafable.com: Large Agile Framework Appropriate for Big, Lumbering Enterprises

Eine großartige Parodie auf (pseudo)agile Skalierungsframeworks. In der Theorie klingt das alles nicht schlecht, in der Realität ist es oft nur ein Feigenblatt für Großkonzerne die agil erscheinen möchten ohne ihre "traditionellen" Vorgehensweisen aufzugeben. Wer beide Welten kennt wird es schnell merken - wir sehen hier das klassische Wasserfall/Chaos-Vorgehen mit potemkinscher agiler Fassade.