CAS Agile Organisation

making your organisation agile

4 Hauptwerte des agilen Manifestes

Posted by Cindy Wittmer on 25.10.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.