Täglich gilt es während eines Projekts Entscheidungen zu treffen & Wege auszuformulieren. Wenn das Team sich auf ein Ticketsystem geeinigt hat, mutieren kontroverse Themen gerne zu "Ticket-Kriegen".
Dabei wird Energie im Team verbraucht, die durch ein klärendes Gespräch schnell anderweitig genutzt werden könnte.
Je interdisziplinärer ein Team aufgestellt ist, desto mehr Fragen sind im Team zu klären.
Sitzt das Team nicht räumlich nah beieinander, findet man in interdisziplinären Teams in Mailboxen oder in Ticketsystemen eine Quasi-Abbildung des klassischen Wasserfall-Modells. Die Tickets werden in einer bestimmten Reihenfolge bearbeitet. Diese Reihenfolge entspricht der "alten" Wasserfall-Reihenfolge.
Was passiert? Nach flüchtiger Lektüre werden die Tickets zurückgewiesen, weil die Anforderungen und das zugelieferte Material zu dürftig, zu unklar, zu unvollständig sind. Aber auch Fragen zum CodingStyleGuide (z.B. wie "Spaces oder Tabs" zu nutzen sind) mutieren zu energischen Auseinandersetzungen, die in Mails oder Tickets abgebildet werden.
Hier wird das klassische Anforderungsdenken und der klassische Hierachiebegriff mit einem interdisziplinäre Team vermischt. Das knirrscht. Und kostet Energie. In den zwölf Prinzipien des agilen Manifests heißt es dazu:
"The best architectures, requirements, and designs emerge from self-organizing teams."
Eine gute Teamarbeit setzt voraus, dass das Ziel des Projekts von allen mitgetragen wird. Eine weitere Voraussetzung ist, dass das Team sich auf gemeinsame Regeln geeinigt hat. Dies geschieht entweder "einfach so" (aber es passiert), oder es passiert willentlich und offen. Beim initialen Festlegen der Teamregeln gilt es die Regel zu verankern:
"Wenn wir uns nicht einig sind, sprechen wir mit einander."
Im ersten Moment ist es anstrengend,
- für jede Abstimmung ein Gespräch einzufordern bzw. ein (gutes) Meeting zu veranstalten (abhängig von der "Größe" der Fragestellung) und
- die Ergebnisse im Ticketsystem / per Mail zu dokumentieren.
Dieses Vorgehen spart aber die vielen Fragen, Antworten und Emotionen ein, die sich durch das bloße Nutzen des Ticketsystems ergeben.
Kommentar schreiben
Sebs (Sonntag, 28 Oktober 2012 10:27)
Tach und einige Anmerkungen
1. Gut für die Dokumentation von Meetings fand ich immer ein Wiki. Das ist persistent, mehrere können dran arbeiten und es ist von vielen einsehbar. Protokolle werden dann nicht mehr per Mail verschickt. Um so weniger Aufwand mit dem "verstecken" oder "schützen" von Informationen verbracht werden muss, um so besser. Also gar nicht anfangen irgendwelche geheimen Protokolle zu schreiben die nicht jedem zugänglich sind. Der Aufwand hierfür ist immens und jeder Mitarbeiter ist sowieso der Geheimhaltung verpflichtet. Was geschützt werden muss ist eine überraschend kleine Anzahl an Informationen. Aber blos weil das Linemanagement ein Meeting hat ist das nicht automatisch geheim.
2. Gerade wenn über die Köpfe anderer hinweg entschieden wird, auf Teamleiterebene z.B., hilft es die Ergebnisse dann sofort, persönlich zu kommunizieren. Also zum Team gehen, nicht anwesende anrufen. Warum das gut ist? Weil die Leute ihren Unmut, Widerspruch und was da so kommt, direkt äussern können. Was sonst zu einer 1-N Kommunikation mit N-1 Rückläufen ausartet (1 Teamleiter, N Teammitglieder) und potentiell in N einzelne Emailkonversatonen ausartet, jeder hat vielleicht eigene Bedenken, geht so recht flott. Insbesondere weil ein interner Diskusrs in einem Team entsteht.
2 cents
Judith Andresen (Sonntag, 28 Oktober 2012 10:34)
Hallo Sebs,
da bin ich bei Dir. Eines der Forderungen an agiles Management ist, Informationen zu open sourcen. Das sollte mit einem technischen Hilfsmittel (Extranet, Wiki) gestützt werden. Je mehr Informationen "offen" vorliegen, desto agiler & interdisziplinärer denkt das Management.
Es gibt immer mal Informationen, die im ersten Schritt nur "weiterzugeben" sind. Auch da glaube ich - genauso wie Du - an die direkte & persönliche Kommunikation. Schwierige Themen in Mails auszulagern wird das Thema schwieriger machen (siehe auch: http://www.andresen.de/2012/06/23/e-mail-bomben/)
Judith
Sebs (Sonntag, 28 Oktober 2012 13:16)
Zu Risiken nd Nebenwirkung von öffentliche Informationen befragen Sie bitte ihren Datenschutzbeauftragten und Betriebsrat. Die hatten sich immer als sehr wertvolle Helfer erwiesen und waren immer konstruktiv.
Grade nochmal geschaut: Das Konzept von 2. nennt sich Cascading Communication.