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.