CAS Agile Organisation

making your organisation agile

Archive for the 'Agile Basics' Category

4 Hauptwerte des agilen Manifestes

Posted by Cindy Wittmer on 25th October 2019

In meinem heutigen Blogg werde ich die 4 Hauptwerte des agilen Manifestes erörtern und auf mein heutiges Umfeld transformieren. Ob wir diesen Werten gerecht werden?

Individuen und Interaktionen mehr als Prozesse und Werkzeuge
In  einem Team geht es um Menschen und wie diese miteinander arbeiten. Alleine kreativ zu sein ist schwierig. In einem Team können verschiedenste Talente miteinander verbunden werden und wenn diese Fähigkeiten kombiniert werden, entsteht ein produktiver Organismus, der mehr ist als die Summe aller Fähigkeiten der Individuen. Ein positiver Team-Groove macht Spass, fördert die Kreativität und reduziert den negativen Stress.

Prozesse und Werkzeuge führen oft dazu, dass die persönliche Interaktion reduziert wird. Tasks und Issues werden direkt in einem Tool erfasst und automatisch an die verantwortliche Person gesandt. Hinter definierten Prozessen verstecken sich Mitarbeiter, um nicht über den Zaun schauen zu müssen. Sie sagen: „Der andere ist für den nächsten Prozessschritt zuständig. Das geht mich nichts mehr an.“ Die Zusammenarbeit bleibt dabei auf der Strecke. Deshalb sollen Methoden so gewählt werden, dass sie die Interaktion fördern und nicht unterbinden.

In unserem Team wird durch örtliche Nähe, aber auch durch eine sehr offene Kommunikationskultur der Kontakt gefördert. Obwohl wir offiziell nicht agil sind, werden Probleme angesprochen und zusammen gelöst. Die Tools und Prozesse, die wir verwenden, laden aber nicht unbedingt zur Zusammenarbeit ein. In einem festgelegten Prozess müssen Dokumente erstellt werden. Im Dokumenten-Review können Befunde direkt erfasst und müssen nicht besprochen werden. Tasks werden elektronisch zugeordnet und übermittelt. All das gibt dem Menschen die Möglichkeit sich zu verstecken. Ich bin nicht per se der Meinung, dass man diese Mittel nicht nutzen soll. Wir sollten sie aber nicht zum Eigenzweck, sondern als Unterstützung für die persönliche Interaktion anwenden. Leider ist der Prozess im Moment aber so aufgesetzt, dass der persönliche Austausch nicht vorgesehen ist. Als eigenständige Personen können wir uns aber selbstverständlich trotzdem dafür entscheiden – aber ob das jeder tut?

Funktionierende Software mehr als umfassende Dokumentation

Für die Aufarbeitung einer Anforderung ist die schriftliche Form aus meiner Sicht enorm hilfreich. Sobald ich eine Anforderung formulieren muss, werden missachtete Punkte und vergessene Aspekte klarer. Zusätzliche gebe ich durch das geschriebene Wort anderen die Möglichkeit meine Gedanken zu verstehend. Diese Basis kann dann als Diskussionsgrundlage herbei gezogen werden.

Die Dokumentation darf aber nicht dazu verkommen, als einziges Kommunikationsmittel genutzt zu werden. Inhalte sollen von Angesicht zu Angesicht besprochen und die Anforderungen erklärt werden. Falls sich bei der Diskussion Änderungen ergeben, sollen die gleich in die Beschreibung miteinfliessen.

Im offiziellen Prozess unserer Organisation wird die Abgabe von spezifischen Dokumentationen festgelegt. Templates werden zur Verfügen gestellt und die geschriebenen Dokumentationen durch ein unabhängiges Board reviewed. Ich bin nicht sicher, ob dieser Prozess dem Ziel einer funktionierenden Software dient. Die Dokumente dienen nicht als Arbeitspapier, sondern müssen zur Zufriedenheit des Reviewboards gestaltet werden.

Bei uns im Projekt konnten wir uns mehrheitlich von diesem Prozess lösen. Wir haben auch Spezifikationen, die werden aber in erster Linie als Arbeitspapier verwendet. Häufig findet aber auch bei uns die Kommunikation via Mail statt, damit die sprachliche Barriere zum italienischen Provider ein bisschen überwunden werden kann. Vielleicht könnten wir uns einige Fragerunden sparen, wenn wir hier mehr Schwerpunkt in den persönlichen Kontakt via ConfCall legen würden.

Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung

Gibt es was Zermürbendes als wochenlange Vertragsverhandlungen? Monate gehen ins Land bevor auch nur ein Strich Code geschrieben wird. Penaltys werden für den Fall einer zu späten oder unvollständigen Lieferung definiert und Preise gedrückt. Schlussendlich ist die Stimmung schon schlecht, bevor sich die Teammitglieder überhaupt kennen gelernt haben. Am Schluss werkelt jeder in seinem Kämmerchen und der prophezeite Penalty wird tatsächlich Realität. Waren das jetzt erfolgreiche Vertragsverhandlungen?

Bei uns habe ich beides schon erlebt. Projekte, die an den Vertragsverhandlungen scheiterten, weil die Energie nicht für die Software verwendet wurde, aber auch gute Zusammenarbeit und erfolgreiche Einführungen. Aus meiner Sicht steht und fällt der Erfolg mit der Wertschätzung, die die Teammitglieder spüren. Weiss der Entwickler des externen Providers, dass sein Input geschätzt wird? Kann ich mich als Business Analyst darauf verlassen, dass die Anforderungen so umgesetzt werden, wie ich sie priorisiert und kommuniziert habe? Die Zusammenarbeit ist ein Geben und Nehmen, das durch harte Vertragsverhandlung gestört werden kann.

Reagieren auf Veränderung mehr als das Befolgen eines Plans

Im Grundsatz einen Plan zu haben, ist sicher sinnvoll. Mit einer Liste von Anforderungen, eingeordnet in den Kontext der Zeit, kann beurteilt werden, welche Ressourcen nötig sind und ob die Timeline eingehalten werden kann. Eine Planung zwingt aber auch zu einer klaren Priorisierung der Anforderungen. Aber der Plan darf nicht Sakrosankt sein, sondern soll unkompliziert angepasst werden können. Die Aufnahme neuer Anforderungen muss möglich sein, die Umpriorisierung von bestehenden Tasks darf nicht zu einem riesen Akt verkommen. Das Projektteam muss die Fähigkeit beibehalten agil auf Veränderungen zu reagieren.

Ich hab schon erlebt, wie Projekte laufen, die ohne Task- und Ressourcenplanung geführt werden. Am Schluss mussten wichtige Anforderungen verschoben werden, weil die Zeit ausging.

Aktuell erlebe ich eine Situation, die in einem agilen Projekt mit grosser Wahrscheinlichkeit nicht geschehen wäre. Geplante Tasks haben weniger Zeit benötigt als erwartet, die neu geschaffene Zeit wird aber nicht durch Umplanung sinnvoll genutzt. In einem agilen Projekt könnte man im Sinne der Unternehmung agil auf diese Situation reagieren und die Zeit zweckmässig nutzen.

Diese Zusammenstellung zeigt, dass wir in unserer Unternehmung zwar nicht Meilenweilt von einer agilen Unternehmung entfernt sind, aber doch noch viele Stolpersteine vor uns liegen. Projekte sind ein People-Business und als das sollte es auch behandelt werden.   sdqformat

erörtern und auf mein heutiges Umfeld transformieren. Ob wir diesen Werten gerecht werden?

Individuen und Interaktionen mehr als Prozesse und Werkzeuge
In  einem Team geht es um Menschen und wie diese miteinander arbeiten. Alleine kreativ zu sein ist schwierig. In einem Team können verschiedenste Talente miteinander verbunden werden und wenn diese Fähigkeiten kombiniert werden, entsteht ein produktiver Organismus, der mehr ist als die Summe aller Fähigkeiten der Individuen. Ein positiver Team-Groove macht Spass, fördert die Kreativität und reduziert den negativen Stress.

Prozesse und Werkzeuge führen oft dazu, dass die persönliche Interaktion reduziert wird. Tasks und Issues werden direkt in einem Tool erfasst und automatisch an die verantwortliche Person gesandt. Hinter definierten Prozessen verstecken sich Mitarbeiter, um nicht über den Zaun schauen zu müssen. Sie sagen: „Der andere ist für den nächsten Prozessschritt zuständig. Das geht mich nichts mehr an.“ Die Zusammenarbeit bleibt dabei auf der Strecke. Deshalb sollen Methoden so gewählt werden, dass sie die Interaktion fördern und nicht unterbinden.

In unserem Team wird durch örtliche Nähe, aber auch durch eine sehr offene Kommunikationskultur der Kontakt gefördert. Obwohl wir offiziell nicht agil sind, werden Probleme angesprochen und zusammen gelöst. Die Tools und Prozesse, die wir verwenden, laden aber nicht unbedingt zur Zusammenarbeit ein. In einem festgelegten Prozess müssen Dokumente erstellt werden. Im Dokumenten-Review können Befunde direkt erfasst und müssen nicht besprochen werden. Tasks werden elektronisch zugeordnet und übermittelt. All das gibt dem Menschen die Möglichkeit sich zu verstecken. Ich bin nicht per se der Meinung, dass man diese Mittel nicht nutzen soll. Wir sollten sie aber nicht zum Eigenzweck, sondern als Unterstützung für die persönliche Interaktion anwenden.·      

Funktionierende Software mehr als umfassende Dokumentation

Für die Aufarbeitung einer Anforderung ist die schriftliche Form aus meiner Sicht enorm hilfreich. Sobald ich eine Anforderung formulieren muss, werden missachtete Punkte und vergessene Aspekte klarer. Zusätzliche gebe ich durch das geschriebene Wort anderen die Möglichkeit meine Gedanken zu verstehend. Diese Basis kann dann als Diskussionsgrundlage herbei gezogen werden.

Die Dokumentation darf aber nicht dazu verkommen, als einziges Kommunikationsmittel genutzt zu werden. Inhalte sollen von Angesicht zu Angesicht besprochen und die Anforderungen erklärt werden. Falls sich bei der Diskussion Änderungen ergeben, sollen die gleich in die Beschreibung miteinfliessen.

Im offiziellen Prozess unserer Organisation wird die Abgabe von spezifischen Dokumentationen festgelegt. Templates werden zur Verfügen gestellt und die geschriebenen Dokumentationen durch ein unabhängiges Board reviewed. Ich bin nicht sicher, ob dieser Prozess dem Ziel einer funktionierenden Software dient. Die Dokumente dienen nicht als Arbeitspapier, sondern müssen zur Zufriedenheit des Reviewboards gestaltet werden.

Bei uns im Projekt konnten wir uns mehrheitlich von diesem Prozess lösen. Wir haben auch Spezifikationen, die werden aber in erster Linie als Arbeitspapier verwendet. Häufig findet aber auch bei uns die Kommunikation via Mail statt, damit die sprachliche Barriere zum italienischen Provider ein bisschen überwunden werden kann. Vielleicht könnten wir uns einige Fragerunden sparen, wenn wir hier mehr Schwerpunkt in den persönlichen Kontakt via ConfCall legen würden.·    

Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung

Gibt es was Zermürbendes als wochenlange Vertragsverhandlungen? Monate gehen ins Land bevor auch nur ein Strich Code geschrieben wird. Penaltys werden für den Fall einer zu späten oder unvollständigen Lieferung definiert und Preise gedrückt. Schlussendlich ist die Stimmung schon schlecht, bevor sich die Teammitglieder überhaupt kennen gelernt haben. Am Schluss werkelt jeder in seinem Kämmerchen und der prophezeite Penalty wird tatsächlich Realität. Waren das jetzt erfolgreiche Vertragsverhandlungen?

Bei uns habe ich beides schon erlebt. Projekte, die an den Vertragsverhandlungen scheiterten, weil die Energie nicht für die Software verwendet wurde, aber auch gute Zusammenarbeit und erfolgreiche Einführungen. Aus meiner Sicht steht und fällt der Erfolg mit der Wertschätzung, die die Teammitglieder spüren. Weiss der Entwickler des externen Providers, dass sein Input geschätzt wird? Kann ich mich als Business Analyst darauf verlassen, dass die Anforderungen so umgesetzt werden, wie ich sie priorisiert und kommuniziert habe? Die Zusammenarbeit ist ein Geben und Nehmen, das durch harte Vertragsverhandlung gestört werden kann.

Reagieren auf Veränderung mehr als das Befolgen eines Plans

Im Grundsatz einen Plan zu haben, ist sicher sinnvoll. Mit einer Liste von Anforderungen, eingeordnet in den Kontext der Zeit, kann beurteilt werden, welche Ressourcen nötig sind und ob die Timeline eingehalten werden kann. Eine Planung zwingt aber auch zu einer klaren Priorisierung der Anforderungen. Aber der Plan darf nicht Sakrosankt sein, sondern soll unkompliziert angepasst werden können. Die Aufnahme neuer Anforderungen muss möglich sein, die Umpriorisierung von bestehenden Tasks darf nicht zu einem riesen Akt verkommen. Das Projektteam muss die Fähigkeit beibehalten agil auf Veränderungen zu reagieren.

Ich habe schon erlebt, wie Projekte laufen, die ohne Task- und Ressourcenplanung geführt werden. Am Schluss mussten wichtige Anforderungen verschoben werden, weil die Zeit ausging.

Obwohl bei uns in der Unternehmung festgelegt Planungssheets zur Verfügung stehen, steht und fällt der sinnvolle Umgang mit dem Projektleiter. Aktuell erlebe ich eine Situation, die in einem agilen Projekt mit grosser Wahrscheinlichkeit nicht geschehen wäre. Geplante Tasks haben weniger Zeit benötigt als erwartet, die neu geschaffene Zeit wird aber nicht durch Umplanung sinnvoll genutzt. In einem agilen Projekt könnte man im Sinne der Unternehmung agil auf diese Situation reagieren und die Zeit zweckmässig nutzen.

Diese Zusammenstellung zeigt, dass wir in unserer Unternehmung zwar nicht Meilenweilt von einer agilen Unternehmung entfernt sind, aber doch noch viele Stolpersteine vor uns liegen. Projekte sind ein People-Business und als das sollte es auch behandelt werden.

Posted in Agile Basics, Team Agility | No Comments »

Die Grundzüge der agilen Methoden

Posted by Henry Dontschew on 22nd September 2019

Das erste Modul im CAS “Agile Organisation” hat sich den Grundlagen der agilen Methoden gewidmet und einen ersten Einblick in verschiedene Vorgehensmodelle vermittelt.

Summary:
Vor allem in IT-Projekten führt das plangetriebene Vorgehen heute kaum mehr zum Erfolg. Wer das magische Dreieck (Kosten-Zeit-Qualität) ausbalancieren möchte und ein Projekt erfolgreich zum Abschluss bringen will, der kommt ohne agile Ansätze selten zum Ziel.

Verbreitung agiler Methoden in der Arbeitswelt:
Das Buzz-Word “Agilität” ist in der heutigen Arbeitswelt omnipräsent und kaum einer kann sich diesem entziehen.

Was vor knapp 20 Jahren in der Software-Entwicklung seinen Anfang genommen hat, ist heute in aller Munde und kaum eine Branche entkommt den agilen Ansätze.  Die Aussage “Wir sind agil und leistungsfähig” beschränkt sich nicht mehr auf ein paar wenige Nerds, die in Hinterhofgaragen die digitale Revolution planen, sondern kommt aus den Etagen des Managements, von HR-Beauftragten, Maschinenbauern und sogar aus dem Pflegebereich.

Gemäss der Studie “Swiss Agile Study” aus dem Jahr 2016 sind über 4/5 alle befragten IT-Unternehmen agil oder zumindest teilweise agil unterwegs. Es ist als nur noch eine Frage der Zeit, bis auch die wenigen letzten Dinosaurier der Branche sich den starren Vorgehensmodellen entledigen und auf den agilen Zug aufspringen.

Plangetrieben war gestern:

“Wenn du Gott zum Lachen bringen willst, mache einen Plan”

Blaise Pascal

Die bekannten plangetriebenen, statischen Vorgehensmodelle (Phasenmodelle) wie Wasserfall und RUP versagen zunehmend in der heutigen Welt. Das Verlangen nach höherer Geschwindigkeit (Stichwort: time to market), die steigende Komplexität und die vorhandene Unsicherheit verlangen nach neuen Denkweisen. Die Abweichung vom Plan ist heute mehr denn je die Regel als die Ausnahme und somit passen die plangetriebenen, statischen Phasenmodelle so gar nicht in unsere VUCA-Welt und führen häufig zum Scheitern – zu spät, zu teuer, nicht brauchbar.
Leistungsfähig ist heute der, der sich an die ständig ändernden Rahmenbedingungen anpassen kann und Veränderungen als eine Chance willkommen heisst.

“Heisse Anforderungsänderungen selbst spät
in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen
zum Wettbewerbsvorteil des Kunden.”

https://agilemanifesto.org/iso/de/principles.html

Agile Methoden:
Agile Methoden als Antwort auf die VUCA-Welt.
Wem kommt nicht der Begriff “Scrum” in den Sinn wenn es um agile Methoden geht. Der Begriff hat seinen Ursprung im Rugby und bedeutet soviel wie Gedränge. Scrum bildet eine konkrete Umsetzung des Lean Development und berücksichtigt damit die 5 Leitprinzipien:

  1. Wert: Spezifiziere präzise den Wert deines Produktes
  2. Wertstrom: Erkenne den Wertstrom 
  3. Flow: Erzeuge einen Wertstromfluss ohne Unterbrechungen
  4. Pull: Lasse den Kunden den Takt der Bearbeitung bestimmen
  5. Perfektion: Verbessere die Dinge kontinuierlich

Auch wenn Scrum der unangefochtene Platzhirsch unter den agilen Methoden ist, gibt es mit Kanban, XP, FDD, TDD, RAD und Design Thinking noch weitere Vertreter im agilen Vorgehen. Im Zentrum aller Methoden steht das agile Manifest, welches den Menschen und dessen Interaktionen in den Mittelpunkt des Geschehens stellt und schnelle sowie bessere Ergebnisse für wichtiger erklärt als langatmige Dokumentationen.

Nach dem Motto “fail fast fail cheap” stellen agile Vorgehensmethoden den kontinuierlichen Wertestrom, die systematische Gewinnung von Wissen und die transparente Kommunikation in den Fokus.

Iterative Phasen ermöglichen es die Komplexität zu reduzieren und sich an das optimale Ergebnis heranzutasten und somit das Risiko des Scheiterns zu minimieren. Die Stakeholder werden dabei aktiv in den iterativen Prozess einbezogen, können Zwischenergebnisse fortlaufend bewerten und Korrekturen und Änderungen frühzeitig kommunizieren.  

Transfer in den Berufsalltag:
Die im Modul vermittelten Basics und die vorgestellten Methoden waren für mich nichts Neues. Als Mitglied eines agilen Dev-Teams, das täglich mit Scrum, TDD, XP, Kanban, DevOps und Prototyping operiert, kenne ich die Vorzüge agiler Vorgehensmodelle. Wasserfall & Co. sind seit über 5 Jahren aus meiner Organisation verschwunden und niemand trauert diesen nach.
Eine wichtige Erkenntnis, die ich aus dem Modul jedoch mitnehme ist, dass bessere Produkte nicht alleine durch den Einsatz agiler Methoden entstehen. Zwingende Voraussetzung ist detailliertes Wissen über die bestehende Wertschöpfungskette, die Unternehmensprozesse, die enge Einbindung der Kunden in die Prozesse und letztendlich der Wille Neues auszuprobieren. Eine agile IT alleine ist also bei weitem nicht ausreichend.

Posted in Agile Basics | No Comments »

Protected: Check-In (der Einstieg)

Posted by Stefan Winistörfer on 16th September 2019

This content is password protected. To view it please enter your password below:

Posted in Agile Basics | Enter your password to view comments.