Blog

Unsere Aufgaben als Coaches im agilen Umfeld sind vielfältig. Wir helfen Organisationen bei agilen Transformationen, in der Einführung oder Anwendung agiler Praktiken. Dazu gehört auch, beim Kunden interne Scrum Master und noch weniger erfahrene Agile Coaches weiterzuentwickeln. Wir unterstützen sie, dazu zu lernen und neue Methoden mit Unterstützung auszuprobieren. Dazu wenden wir Praktiken an, die wir bei der Weiterentwicklung von Nagarro-Coaches bereits ebenso erfolgreich angewendet haben. Ich möchte Ihnen in diesem Artikel einen Einblick geben, wie wir dabei vorgehen.

Agile Coaches unterstützen Organisationen auf ihrer agilen Reise. Sie helfen Teams und Management, agile Praktiken anzuwenden, sich dabei laufend zu verbessern. Wie können wir diesen Prozess gezielt gestalten? Anhand eines Praxisbeispiels möchte ich einen möglichen Weg skizzieren.

Agiles Vorgehen verändert Unternehmen. Viele der Ideen lassen sich in allen Geschäftsbereichen anwenden, nicht nur in der IT. Gilt das auch für die agilen Werte und Prinzipien, die sich auf Software und Projekte beziehen?

Behavior Driven Development – oder kurz BDD – ist eine von Dan North entwickelte Technik, mit der bereits beim Erstellen der User-Stories das Verhalten der Applikation konkret und menschenlesbar beschrieben werden soll. Dies dient mehreren Zwecken, birgt aber auch ein paar Herausforderungen und scheint in der Theorie weit simpler als es in der Praxis ist. Da ich in einigen Projekten Erfahrungen mit BDD sammeln konnte, möchte ich anhand eines konkreten Beispiels einen kleinen Einblick in eine von vielen möglichen Varianten geben, BDD in der agilen Softwareentwicklung einzubetten.

Komplexe IT-Vorhaben erfolgreich ins Ziel zu bringen, erfordert eine geeignete Zusammenarbeit aller involvierten Personen und Rollen. Gerne vergleiche ich es mit einem Fußballspiel: Jeder Teamplayer hat seine persönlichen Talente und seine Rolle im Team, jeder unterstützt kritische Situationen und übernimmt Verantwortung auf dem Spielfeld. Und gerade dieses Zusammenspiel macht eine gute Mannschaft aus, die ein gemeinsames Ziel verfolgt.

Agile Enterprise - sein oder nicht sein? - Dieser Frage widmete sich der Quality Leadership Circle (kurz QLC) am 29. Oktober 2019. Digitalisierungsverantwortliche aus unterschiedlichen Branchen trafen sich erneut in der Bel-Etage des Wiener Cafe Landtmanns und tauschten sich diesmal zum Thema „Enterprise Agility“ aus. Es war eine spannende Diskussion mit kontroversen Ansätzen und ich freue mich Ihnen hier einen kleinen Eventrückblick zu bieten. Eines darf ich vorweg verraten – Agilität hat weit mehr mit einer Wiener Melange zu tun, als Sie im ersten Moment vielleicht glauben werden!

Die Transformation Ihrer Organisation in eine agile Organisation ist eine Kunst für sich, wenn man mit den rasanten Änderungen und der Komplexität des modernen Geschäftslebens Schritt halten möchte. Eine erfolgreiche Transformation hängt von einer Vielzahl von Faktoren ab, wie zum Beispiel den involvierten Personen, dem aktuellen Entwicklungsstand, dem verfügbaren Zeitrahmen sowie Unternehmenskultur und Führung. Nachfolgend einige Empfehlungen, um bei Transformationen erfolgreich zu sein, die sich mit Kultur, Strategie und Taktik befassen.

Agile Projekte gewinnen im Vergleich zu Wasserfallprojekten an Bedeutung. Agilität wird in der Softwareentwicklung gerne mit Veränderung, Flexibilität, kürzerem Time-to-Market, Eigenverantwortung etc. in Verbindung gebracht. Das klingt positiv - und wenn es richtig gemacht wird, ist es das auch - selbst wenn Rückschläge vorprogrammiert sind. Es gibt viele gängige Definitionen dafür, was "Agilität" bedeutet und viele Unternehmen bzw. Agilisten haben ihren ganz eigenen Ansatz. Eines jedoch ist sicher: Agilität ist KEIN Chaos!

Im ersten Teil haben wir uns mit Grundlagen, Story Points, Velocity und Releaseplanung beschäftigt. Teil 2 behandelt mögliche Varianten, den Fortschritt während eines Sprints zu ermitteln und zeigt die Vor- und Nachteile unterschiedlicher Messmethoden auf, die dafür eingesetzt werden können.

Jeder, der in einem agilen Umfeld arbeitet, kennt eines der wichtigsten Prinzipien: "Funktionierende Software ist das wichtigste Fortschrittsmaß". Ja, das ist es. Was uns nicht daran hindert, weitere Metriken einzusetzen, um den Fortschritt eines Teams zu erkennen und darzustellen. Welche Möglichkeiten stehen dafür zur Verfügung? Worauf müssen wir dabei achten? Meine wichtigsten Erkenntnisse dazu aus der Praxis als Scrum Master habe ich in einer zweiteiligen Artikelserie zusammengefasst.